[Standards] LAST CALL: XEP-0166 (Jingle)

Peter Saint-Andre stpeter at stpeter.im
Thu Nov 29 18:12:27 UTC 2007


Lauri Kaila wrote:
> 2007/11/28, Peter Saint-Andre <stpeter at stpeter.im>:
>> What is the SIP flow for the 415 error? Do you return 100 trying and
>> then send 415 unsupported media type? Or do you not return the 100?
> 
> SIP allows 0..n provisional responses before the final. 

Right. That seems to map to IQ-result followed by session-info etc.,
followed by session-accept.

> I'm not really
> a SIP expert (although I play one here), 

That's OK, I'm not really a geek, either. :) And I'm certainly not a SIP
expert!

> but the following flow should
> be quite normal:
> 
> INVITE ->
>            <- 100 trying (sent by SIP proxy before receiver got the inivite)
>            <- 180 Ringing
>            <- 486 Busy Here (human rejects the call)
> ACK     ->
> 
> How would that convert to Jingle actions? 

Hmm. To exactly map to that flow, we'd need to do:

session-initiate ->
                    <- IQ-result
                    <- session-info <ringing/>
IQ-result        ->
                    <- session-info <busy/>
IQ-result        ->
                    <- session-terminate
IQ-result        ->

But that flow goes against these check-ins:

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0167.xml?r1=930&r2=1378

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0166.xml?r1=1364&r2=1377#seg7

However, we could retain the following flow but require the gateway to
send 100 and 180, then send 486 when it receives the <busy/> error:

session-initiate ->
                    <- IQ-error <busy/>

(That flow has a lot fewer stanzas!)

I suppose the question is: what does busy really mean? Does the
recipient's client know immediately that the user or device cannot
accept the call? If so, the second flow is fine. If not, then we should
retain the session-info <busy/> from the first flow.

> Case with 415 is similar
> except that 180 wouldn't be sent:
> 
> INVITE ->
>            <- 100 trying
>            <- 415 Unsupported Media Type
> ACK     ->
> 
> And this is the happy flow:
> 
> INVITE ->
>            <- 100 trying
>            <- 180 Ringing
>            <- 200 OK
> ACK     ->
> 
> It seems that the gateway would need to wait for the final SIP
> response before it can send IQ ack. 

Before it can send IQ-result in response to session-initiate? I don't
think it needs to wait that long. That IQ-result just means "yes I see
that you want to start a session, let's try" (i.e., I think it's similar
to SIP's 100 trying).

> Using session-terminate to reject
> session always (instead of iq response) would map to SIP better:
> 
> session-initiate ->
>                      INVITE ->
>                      <- 100 trying
> <- IQ ack
>                      <- 180 Ringing
> <- session-info
> IQ ack ->
>                       <- 486 Busy Here
>                       ACK ->
> <- session-terminate
> IQ ack ->

I suppose my only concern with that (other than more packets!) is ICE,
because a lot of stanzas might flow back and forth before the terminate
is received by the initiator, but XEP-0176 allows the initiator to send
ICE candidates even before it receives the IQ-result for the
session-initiate, so I suppose this worry is not justified.

> Logically SIP ACK would map to the iq response for session-terminate.
> But the gateway can send SIP ACK immediately because its purpose is to
> stop UDP retransmissions and we don't need those in XMPP.

Right.

In general, I wonder how much of the SIP flows are dependent on the
following two factors:

1. They use UDP for the signalling channel, whereas XMPP uses TCP.

2. They have smart intermediate entities like proxies, whereas XMPP
servers are just dumb XML routers where Jingle is concerned.

Naturally a Jingle<->SIP gateway will need to worry about this kind of
thing, but I don't know how much we should try to mimic the SIP flows in
Jingle itself when used by native XMPP entities.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20071129/ddf80698/attachment.bin>


More information about the Standards mailing list