<br><div><span class="gmail_quote">On 10/12/06, <b class="gmail_sendername">Matthew O'Gorman</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
xep-166 (jingle)<br>responder field, I noticed this was added on the final accept. I<br>understand that initiator might be helpful in debugging who started<br>the call and make logging easier, but responder? isn't that just
<br>added fluff that is not needed, i mean if we do a redirect it is a<br>whole redirect when would you have a case where that information would<br>be different?<br>should the states of the call be in the signalling, ringing busy or
<br>not in service etc. Why are they shoved in xep-167?</blockquote><div><br>I can speak to the responder attribute. The original thought behind this is that it is similar to the CONTACT field in SIP. Once a call is established (accepted) all further communication can go directly between the initiator and responder. This lets a server or other entity broker a call but get out of the signalling once the call is established. While it is possible for the entity in the middle to stay in the signalling path this requires storage for each session.
<br><br>This middle entity could be used to implement things like call forking or other interesting call flows. <br><br>As for ringing, busy and not in service -- these states don't apply to all sessions. For instance, busy doesn't really apply to file sharing scenarios.