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

Peter Saint-Andre stpeter at stpeter.im
Wed Nov 28 17:12:07 UTC 2007


Lauri Kaila wrote:
> 2007/11/28, juha.p.hartikainen at nokia.com <juha.p.hartikainen at nokia.com>:
>> Is this moreless the clients internal implementation issue, than
>> related protocol.
> 
> Hi Juha,
> 
> Yes, but... It depends how you see it ;). Maybe it's a protocol issue:
> if  there was a SIP-Jingle gateway where "100 trying" is mapped to iq
> "ack" (just my intuition, I don't know would that be the case), 

That sounds right. I'm working on the SIP<->Jingle mapping spec now,
which should help us understand the interworking issues more clearly.

> then
> you have a problem how to map "415 unsupported media type" because you
> can't use <unsupported-content> error because the iq is already acked.

Hmm, maybe I don't understand your concern. In your previous message you
said:

***

There's one point in the protocol I'm not very fond of: returning
application-level errors (especially unsupported-content) with iq
response to session-initiate. Because if one implements XEP-0166 and
XEP-0167 (and video, file transfer, whiteboard, etc) as a separate
logical modules, it means that the generic Jingle code must consult
the upper-level module before it can send IQ response. The generic
Jingle code must have a separate state for a not-acked session, instad
of making the transaction "atomic" by sending ack immediately.

The alternative would be to ack session-initiate always, and have a
unsupported-content info carried with session-terminate. I believe
that would be easier to implement, although the protocol flow may not
seem optimal.

***

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?

This maps to what Jingle defines now:

INITIATOR		     RESPONDER
   |                            |
   | session-initiate           |
   |--------------------------->|
   | IQ-error                   |
   | (unsupported-content = 415)|
   |<---------------------------|

This maps to what you propose:

INITIATOR		     RESPONDER
   |                            |
   | session-initiate           |
   |--------------------------->|
   | IQ-result = 100            |
   |<---------------------------|
   | session-terminate          |
   | (unsupported-content = 415)|
   |<---------------------------|

It seems to me that a SIP<->Jingle gateway could handle the IQ-error
with unsupported-content to 100 then 415.

But that still doesn't address your concern about modular code and
clearer layering between the Jingle core and various applications.

> But as I said, I think this is only a minor annouyance for me.

Well, that's good. :)

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/20071128/248f1ab9/attachment.bin>


More information about the Standards mailing list