Re: [MMUSIC] SDPCapNeg, modified m-line issue

[Flemming Andreasen <[e-mail]>]

Hi Ingemar

Sorry for the delayed response - please see below.

Ingemar Johansson S wrote:
> Hi
>
> As you may know, SDP Capability Negotiation Framework (SDPCapNeg) is gaining interest in the 3GPP community especially in the SA4 and CT1 working groups. 
> The current plan is to propose SDPCapNeg to be included as a part of the 3GPP standard.
>
> There are however concerns about a potential interoperability issue with SDPCapNeg. 
> Namely that e.g. the m= line in the (first) SDP answer is modified in such a way that intermediaries may reject the SDP with unpredictable/unknown consequences (also mentioned in 3.12 in the SDPCapNeg draft).
> An example is the SDP
> Offer:
>    m=audio 1234 RTP/AVP 97
>    a=fmtp..
>    a=rtpmap..
>    a=tcap:1 RTP/AVPF RTP/AVP
>    a=pcfg:1 t=1|2
>
> The answerer supports AVPF and returns
> Answer:
>    m=audio 5678 RTP/AVPF 97
>    a=fmtp..
>    a=rtpmap..
>    a=acfg:1 t=1
>
> An intermediate may accept the offer but reject the answer for some reason and as it is the answer that is rejected the consequences are worse than if the offer would be rejected.
>   
Is this a general concern or are you looking at a specific intermediary 
(e.g. the P-CSCF) ?

> So far this is only a problem related to the m= line but as the framework allows for extensions that may elevate this problem even more.
>   
Agreed.
> Our proposal is therefore that the SDPCapNeg answer is only allowed to do modifications to lines in the "conventional" SDP parts that are well known to work or supported by "conventional" SDP offer/answer exchange (the definition here is yet unclear). The answer SDP above would then look like 
>    m=audio 5678 RTP/AVP 97
>    a=fmtp..
>    a=rtpmap..
>    a=acfg:1 t=1
> In this example the preferred configuration is only indicated by the a=acfg line.
>   
Would the media stream(s) have been established with the indicated 
answer at this point in time (A) or would you now require a subsequent 
offer/answer exchange before the media stream(s) can be considered 
functional (B) ?

> This could of course make it more necessary to do a 2nd offer/answer exchange, but we believe that mandating a 2nd offer answer will be needed even with the current solution to make sure things will work.
>
> One could rightly argue, as is also hinted in the SDPCapNeg draft, that intermediaries should be upgraded. Problem is however that depending on product cycles and other issues among vendors and operators, this may take time. Also it is worth notice that 3GPP works based on the principle that things should be backward compatible. Furthermore we believe that solutions based on the "products should be upgraded" principle would cause problems even in non-3GPP networks since intermediaries may be found in many network deployments.
>
> Comments and suggestions on this issue are welcome.
>   
Taking a step back, I believe the essence of your comments are, that if 
we want to use SDP Capability Negotiation to establish media streams, 
then we cannot do that in a single offer/answer exchange. Instead, you 
want to have a mechanism whereby we first exchange capabilities between 
the offerer and the answerer (without establishing a stream) followed by 
another exchange where we actually negotiate the media stream 
parameters. In other words, the current single-roundtrip O/A exchange 
provided by RFC 3264 and supported by SDPCapNeg is replaced by a 
two-roundtrip solution.

While I understand the concern you are trying to address, we have been 
around this issue several times and the sdpcapneg document reflects the 
consensus solution. To recap, the requirements document 
(draft-ietf-mmusic-sdp-capability-negotiation-reqts-01) has the 
following requirement:

   REQ-100: The mechanism MUST work within the context of the
   offer/answer model [RFC3264]. Specifically, it MUST be possible to
   negotiate alternatives within a single offer/answer exchange.

That particular requirement was discussed in the design team, in the 
Prague IETF, and subsequently on the MMUSIC mailing list (see "SDPCapNeg 
Issue #2: Answer not getting through middle-boxes if transport protocol 
in answer differs from offer" on 6/25/07) and consensus was for the 
mechanism specified currently.

Note however, that the SDPCapNeg framework as currently defined can be 
used more or less the way you seem to prefer by merely including 
capabilities in the offer without the actual potential configuration 
attributes (which are used to trigger the extended O/A exchange). The 
thing that would be missing is expressing valid combinations of 
capabilites as well as preferences, however this is part of what the 
media capabilities extension document is addressing by introducing the 
"latent configuration" attribute, which you could then use.

In lieu of the above, past history on requiring multiple O/A exchanges, 
the significant changes to the overall scheme your suggestion implies, 
and the fact that we completed WGLC a while ago, I don't think we should 
make this change.

Regards

-- Flemming

> Regards
> Ingemar
> *******************************************
> Ingemar Johansson
> Senior Research Engineer, IETF "nethead" 
> EAB/TVP - Multimedia Technologies
> Ericsson Research Ericsson AB
> Box 920 S-971 28 Luleå, Sweden
> Tel: [phone]
> ECN: 850-43042
> ECC: 850-43074
> Mobile: [phone]
> ******************************************* 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>   
_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic