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.

>   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).

-- Flemming


>  
> My 2 cents.
>
>  
>
>     ------------------------------------------------------------------------
>     *From:* Flemming Andreasen [mailto:fandreas@cisco.com]
>     *Sent:* Tuesday, June 26, 2007 08:36
>     *To:* Dan Wing
>     *Cc:* 'mmusic'
>     *Subject:* Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer
>
>
>
>     Dan Wing wrote:
>>     Was the use of a payload type for this, as mentioned in
>>     draft-kaplan-mmusic-best-effort-srtp-01, considered and discarded?  I'm fine
>>     if it was, I'm just asking.  It seemed useful although it only increases the
>>     chances of not playing garbage (because you don't know until you get the
>>     answer if the answerer understood that technique).
>>       
>     It's mentioned as one possible approach in Section 3.8 (but not
>     mandated).
>
>     -- Flemming
>>     -d
>>
>>       
>>>     -----Original Message-----
>>>     From: Flemming Andreasen [mailto:fandreas@cisco.com] 
>>>     Sent: Monday, June 25, 2007 10:15 AM
>>>     To: mmusic
>>>     Subject: [MMUSIC] SDPCapNeg Issue #5: Media before answer
>>>
>>>     The answerer may select a potential configuration containing 
>>>     parameters that require the offerer to receive the answer 
>>>     before he can process media correctly. The issue is explained 
>>>     in Section 3.8 in the SDP Capability Negotiation framework, 
>>>     where one possible solutions is outlined (preconditions), but 
>>>     not actually specified. The question was raised whether we 
>>>     want to say more about this issue and if we want to define 
>>>     additional solutions to it. For example, Jonathan Rosenberg 
>>>     suggested that use of ICE can help the answerer determine 
>>>     when the answer has been received by the offerer and hence it 
>>>     is safe to send media to the offerer. 
>>>
>>>     The design team discussed this issue in Prague and agreed to 
>>>     elaborate slightly on the current text. It will be noted that 
>>>     the offerer can discard media until he receives the answer, 
>>>     if he wants to make sure he doesn't play garbage. If the 
>>>     offerer wants to avoid clipping on the other hand, he can 
>>>     play media as soon as it is received, but at the risk of 
>>>     playing garbage. To avoid both, a three-way handshake is 
>>>     needed (e.g. precondtion), however that is outside the basic 
>>>     SDP Capability Negotiation. We will add a note to mention the 
>>>     use of ICE (STUN) as a possible solution to this three-way 
>>>     handshake as well. 
>>>
>>>     If you disagree with this, please let me know. 
>>>
>>>     Thanks
>>>
>>>     -- Flemming 
>>>
>>>
>>>
>>>
>>>
>>>
>>>         
>>
>>       
>