[Jingle] Understanding jingle handshakes.

Prakash prakash.tester.im at gmail.com
Tue Jul 19 06:42:40 UTC 2011


Peter, You could have just said RTF-XEP0176 :), so thanks taking the time to
explain.


On Mon, Jul 18, 2011 at 3:41 PM, Peter Saint-Andre <stpeter at stpeter.im>wrote:

> On 7/13/11 11:42 AM, Tester Prakash wrote:
>
>> Hello all,
>>
>> I have been going through the jingle xep-0166 and had a bunch of
>> questions about the state transitions involved.
>>
>
> It seems that you're actually talking about RTP sessions (XEP-0167),
> perhaps in combination with ICE-UDP (XEP-0176). Correct?
>
>
>  1. On a session-initiate, is it necessary that we send the transport
>> candidates? It may take some time to retrieve this info, so can this be
>> sent separately in a transport-info action iq? Or should
>> session-initiate always include all content descriptions and all
>> transport candidates for the session?
>>
>
> The Jingle framework doesn't legislate that you must send all (or even any)
> transports at the time of initiating the session. However, individual
> transport methods define appropriate guidelines to ensure interoperability
> and faster session establishment. See for example XEP-0176, Section 5.2 and
> Section 5.5.
>
>
>  2. Related to question 1. If i have to send atleast on tansport
>> candidate, Can I send the local IP + port on session-initiate, and send
>> the stun addresses separately in a transport-info packet following
>> session-initiate packet?
>>
>
> Again, see XEP-0176 for details. The short answer is, yes, you can (and
> should) send high-priority candidates first, and not send low-priority
> candidates until later in the negotiation process.
>
>
>  3. Can the responder send a transport-info packet with its candidates
>> before session-accept or should its candidates be only part of the
>> session-accept? The adv of sending before, is we can do the candidate
>> pair negotiation as the ringing happens.
>>
>
> Again, see XEP-0176.
>
>
>  4. I see there is no mandatory step, for the initiator to tell the
>> responder, the candidate pair it has picked. So i am assuming the
>> responder, waits for a RTP session on all its candidates and closes the
>> unused candidates after an RTP session starts?
>>
>
> Basically, if a candidate is used then media will begin to flow. There is
> no need to bubble this up to the signalling level, although the parties may
> do so. See Section 5.7 of XEP-0176.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20110718/d8f98aa3/attachment.htm>


More information about the Jingle mailing list