[jitsi-dev] [jitsi-videobridge] Error in reply to raw UDP channel request (#102)


#1

When posting the following (note the *raw* in the namespace)

    {
        "contents": [
            {
                "channels": [
                    {
                        "expire": 60,
                        "rtp-level-relay-type": "mixer",
                        "transport": {
                            "xmlns": "urn:xmpp:jingle:transports:raw-udp:1"
                        }
                    }
                ],
                "name": "audio"
            }
        ]
    }

to the REST interface,I get the following reply:

    {
    "contents":[
        {
            "channels":[
                {
                "sources":[
                    783642886
                ],
                "rtp-level-relay-type":"translator",
                "expire":60,
                "initiator":true,
                "id":"65f2743ac85bd3f9",
                "transport":{
                    "candidates":[
                        {
                            "generation":0,
                            "component":1,
                            "port":10002,
                            "ip":"127.0.0.1",
                            "id":"3",
                            "type":"host"
                        },
                        {
                            "generation":0,
                            "component":2,
                            "port":10003,
                            "ip":"127.0.0.1",
                            "id":"4",
                            "type":"host"
                        }
                    ],
                    "xmlns":"urn:xmpp:jingle:transports:raw-udp:1"
                },
                "direction":"sendrecv"
                }
            ],
            "name":"audio"
        }
    ],
    "id":"8c68373d95edc463"
    }

which has 2 drawbacks:

1. I get "translator" back although a "mixer" was requested. Is translator mode generally not supported in this case?
2. The candidates reported back have 127.0.0.1 as the IP address, which is not very useful in real cases. Note that I don't have any XMPP set up, so the helper lookup by using XMPP domains fails.
It could be fixed by using getLocalHostLANAddress in RawUdpTransportManager.createStreamConnector, as proposed here
http://stackoverflow.com/questions/9481865/getting-the-ip-address-of-the-current-machine-using-java

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/102


#2

I'm happy to fix these problems myself, but please respond whether there are fundamental problems with it (translator vs. mixer case for raw UDP), and whether you consider the 127.0.0.1 a bug that should be fixed.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/102#issuecomment-160063339


#3

I think both of these are bugs. Note that while not unsupported, both the raw-udp transport and the mixer mode are not actively used, so regressions might have crept in.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/102#issuecomment-160190473


#4

Isn't "mixer" at least the standard way for audio?

The control flow causing the first problem is actually the very same as in
https://github.com/jitsi/jitsi-videobridge/issues/9
namely getRTPLevelRelayType getting called before getRTPLevelRelayType.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/102#issuecomment-162535690


#5

The default is "mixer" for both audio and video.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/102#issuecomment-162628891


#6

Closed #102.

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/102#event-1049013750