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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Jul 2007 19:14:11 +0200

Hi,

I think it is quite important to try to avoid sending media if the 
answerer do not use the actual configuration. This due to the problem 
with the receivier not knowing what to do with this media.

A related issue is that of send direction configuration information that 
for example H.264 over RTP suffers from. A device sending media needs to 
provide the receiver with some configuration information to enable it to 
decode things. This doesn't work particular well in normal offer/answer. 
In cases when the sender correctly can guess the configuration in the 
answer it works. But if the answerer changes the configuration it 
accepts to receive with things stops working well. This can be helped by 
providing potential configurations that narrows things down to have the 
answerer select a potential configuration that it actually can use.

But in these cases it is quite clear, even if all potential 
configurations are AVP they still can't decode them because they are 
likely to use the same payload type number.

Cheers

Magnus

Flemming Andreasen skrev:
>   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
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 Jul 2007 12:25:37 -0400

Magnus Westerlund wrote:
> A related issue is that of send direction configuration information 
> that for example H.264 over RTP suffers from. A device sending media 
> needs to provide the receiver with some configuration information to 
> enable it to decode things. This doesn't work particular well in 
> normal offer/answer. In cases when the sender correctly can guess the 
> configuration in the answer it works. But if the answerer changes the 
> configuration it accepts to receive with things stops working well. 
> This can be helped by providing potential configurations that narrows 
> things down to have the answerer select a potential configuration that 
> it actually can use.
>
Do you have any concerns with the relevant text on this point in the 
draft right now (if so, which parts ?)

Thanks

-- Flemming

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 24 Jul 2007 01:46:16 +0200

> draft right now (if so, which parts ?)

I think section 3.10 might be not contain enough normative requirement 
on the media handling. Is this written somewhere else? I think it is 
important to point out that for an answer, he really shouldn't send any 
media if he selects a potential configuration.

Cheers

Magnus Westerlund

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 24 Jul 2007 07:50:22 -0400

Magnus Westerlund wrote:
> important to point out that for an answer, he really shouldn't send 
> any media if he selects a potential configuration.
I believe the last two paragraphs in Section 3.7.1 (Generating the 
Initial Offer) and 3.7.2 (Generating the Answer) address this concern.

 From Section 3.7.1:
</quote>
        Per [RFC3264], once the offerer generates the offer, he must be
        prepared to receive incoming media in accordance with that offer.
        That rule applies here as well, but for the actual configurations
        provided in the offer only: Media received by the offerer according
        to one of the potential configurations MAY be discarded, until the
        offerer receives an answer indicating what the actual selected
        configuration is. Once that answer is received, incoming media MUST
        be processed in accordance with the actual selected configuration
        indicated and the answer received (provided the offer/answer 
exchange
        completed successfully).  

        The above rule assumes that the offerer can determine whether
        incoming media adheres to the actual configuration offered or 
one of
        the potential configurations instead; this may not always be the
        case. If the offerer wants to ensure he does not play out any
        garbage, the offerer SHOULD discard all media received before the
        answer SDP is received. Conversely, if the offerer wants to avoid
        clipping, he should attempt to play any incoming media as soon 
as it
        is received (at the risk of playing out garbage). For further
        details, please refer to Section 3.10. 
</quote>

and from Section 3.7.2:
<quote>
        The offerer's originally provided actual configuration is contained
        in the media description's "m=" line (and associated 
parameters). The
        answerer MAY send media to the offerer in accordance with that 
actual
        configuration as soon as it receives the offer, however it MUST NOT
        send media based on that actual configuration if it selects an
        alternative potential configuration. If the answerer selects one of
        the potential configurations, then the answerer MAY immediately 
start
        to send media to the offerer in accordance with the selected
        potential configuration, however the offerer MAY discard such media
        or play out garbage until the offerer receives the answer. Please
        refer to section 3.10. for additional considerations and possible
        alternative solutions outside the base SDP Capability Negotiation
        framework. 

        If the offerer selected a potential configuration instead of the
        actual configuration, then it is RECOMMENDED that the answerer 
sends
        back an answer SDP as soon as possible. This minimizes the risk of
        having media discarded or played out as garbage by the offerer. In
        the case of SIP [RFC3261] without any extensions, this implies that
        if the offer was received in an INVITE message, then the answer SDP
        should be provided in the first non-100 provisional response sent
        back (per RFC3261, the answer would need to be repeated in the 200
        response as well, unless a relevant extension such as [RFC3262] is
        being used).
</quote>

-- Flemming

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 24 Jul 2007 23:06:30 +0200

Hi,

I think the text in this regard is fine. I didn't spend enough time to 
dig out the right paragraphs when you asked for concreate examples. 
Sorry about that.

Magnus

Flemming Andreasen skrev:
>        incoming media adheres to the actual configuration offered or one of
>        clipping, he should attempt to play any incoming media as soon as it
>        details, please refer to Section 3.10. </quote>
> 
> and from Section 3.7.2:
> <quote>
>        in the media description's "m=" line (and associated parameters). 
> The
>        actual configuration, then it is RECOMMENDED that the answerer sends

-- 

Magnus Westerlund