Subject: Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer

From: Flemming Andreasen <[email-masked]>
Date: Mon, 02 Jul 2007 17:56:24 -0400

Belling, Thomas wrote:
> Hi all,
>  
> in my understanding including an answer in an unreliable provisional 
> response is not allowed by RFC 3261 even it you repeat the answer in 
> the 200 OK, see top of page 79:
> "If the initial offer is in an INVITE, the answer MUST be in 
> a reliable non-failure message from UAS back to UAC which 
> is correlated to that INVITE."
> Note that this quotations speaks about "the" answer, and I read that 
> as a requirement that there is only one answer.
You need to read the whole bullet:
<quote>
      o  If the initial offer is in an INVITE, the answer MUST be in a
         reliable non-failure message from UAS back to UAC which is
         correlated to that INVITE.  For this specification, that is
         only the final 2xx response to that INVITE.  That same exact
         answer MAY also be placed in any provisional responses sent
         prior to the answer.  The UAC MUST treat the first session
         description it receives as the answer, and MUST ignore any
         session descriptions in subsequent responses to the initial
         INVITE.
</quote>

Clearly, an answer can be provided in unreliable provisional responses 
as well, but then needs to be repeated in a reliable response.

>  
> Even if you might argue there is a bit of ambiguity in the quotation, 
> I suspect that there may be interoperabilty issues with clients either 
> not beeing prepared to handle the answer in an unreliable provisional 
> response (e.g. if they do not support 100rel), or getting confused if 
> obtaining the same answer both in a provisional response and the 200 OK.
>  
> So I would recommend that you use at least 100rel for option 1 - 
> preconditions is not really related and indeed not required for this 
> issue.
I think RFC 3261 is pretty clear on this, and we also have call flow 
documents showing this kind of operation (see e.g. BCP 76/RFC 3666), so 
I don't see a problem here.

Thanks

-- Flemming

> Regards, Thomas
>  
>
> ----------------------------------
> Dr. Thomas Belling
> Nokia Siemens Networks  GmbH & Co. KG.        
>
>  
>
> Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft/ 
> Registered office: München (Munich) - Registergericht /Commercial 
> register: München (Munich), HRA 88537 - WEEE-Reg.-No. DE 52984304. 
> Persönlich haftende Gesellschafterin /General Partner: Nokia Siemens 
> Networks Management GmbH - Geschäftsführer /Board of Directors: 
> Christian Unterberger, Joachim Malterer, Roland Meinzer - Sitz der 
> Gesellschaft / Registered office: München (Munich) - Registergericht 
> /Commercial register: München (Munich), HRB 163416
>
>
>     ------------------------------------------------------------------------
>     *From:* Francois Audet [mailto:[email-masked]]
>     *Sent:* Wednesday, June 27, 2007 2:14 AM
>     *To:* Flemming Andreasen
>     *Cc:* mmusic; Dan Wing
>     *Subject:* RE: [MMUSIC] SDPCapNeg Issue #5: Media before answer
>
>      
>
>         Francois Audet wrote:
>>         The preconditions approach to me seems like the least likely
>>         approach to be used in the real world.
>>          
>>         I really see only two practical way forward:
>>
>>           1.
>>               You have to wait for the answer before playing
>>               anything. For this to work, we'd effectively have to
>>               rely on provisional responses including the SDP-answer
>>               (and not include the answer in the 200, since it would
>>               cause clipping). That in itself would be a change for
>>               many SIP clients who never tought it necessary to
>>               provide an answer before 200 before (at least, they
>>               didn't think they needed it).
>>
>         You'd have to include the answer in both the provisional
>         response and the 200, unless you use reliable provisional
>         responses. 
>          
>
>     Yes, agreed. Both cases are valid. 
>
>>           1.
>>               Use the different payload type as per our kaplan draft.
>>
>>         My take is that option 1 is the more likely to have wide
>>         support. But we should explain it a bit.
>>         Option 2 is interesting, in a geeky way, and probaly better
>>         than pre-conditions. But if people can live with 1, it seems
>>         much simpler.
>
>     I'll include an explanation of all of them (there's already some
>     text on the above, however I'll elaborate on the points you made). 
>
>      Excellent. Thanks. 
>
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic