[Standards] questions regarding XEP-0177 jingle raw-udp transport
sebastia at l00-bugdead-prods.de
Sun Sep 4 23:54:18 UTC 2011
I'm in the process of reviewing the whole jingle implementation in Coccinella. The actual implementation follows a very old version of XEP-0166. Its only used in Coccinella for the JingleIAX VoIP functionality.
While I am now reading, and trying to rewrite the jingle stuff in the jabberlib that comes with coccinella, I thought I start with implementing XEP-0177 raw-udp transport, which seems to be fairly easy and straightforward.
However, while reading the XEP-0177, I got some questions:
In section 4.2 Transport Initiation, it states that:
* If the client is aware of which type of candidate it is sending, the candidate element MAY contain a 'type' attribute.
* But in section 9 XML schema, the type attribute of the candidate is use='required'
* Question is: which section is right?
Another question is about the number and types of candidates to be sent, also in section 4.2 it states:
The <transport/> element MAY include more than one <candidate/> element (typically one for RTP and another for RTCP).
Note: The "Raw UDP candidate" is the candidate that the entity has reason to believe will be most likely to succeed for that content type, and thus is equivalent to the "default" candidate as described in the ICE specification. This is not necessarily the entity's preferred address for communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. To determine reachability, the sender needs to classify ahead of time the permissiveness of the NAT or firewall it is behind, if any. It then SHOULD assign the Raw UDP candidate as follows, where the candidate types are as described in ICE...
So I should only include one candidate per component? Or do I can include multiple candidates per component? I.e. offering two candidates for each component (RTP and RTCP). For each of the component, offer for example one host and one srflx type candidate, so in sum having four candidates?
The examples only show either one candidate, or two candidates, but then for different components. But as far as I understand the XML schema in section 9, I could be able to send multiple transport candidates for a single component?
More information about the Standards