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

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 9 May 2008 16:03:35 +0200

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.

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.

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.

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.

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: +46 (0)8 4043042
ECN: 850-43042
ECC: 850-43074
Mobile: +46 (0)730 783289
******************************************* 
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 18 May 2008 16:18:48 -0400

Hi Ingemar

Sorry for the delayed response - please see below.

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

> 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

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 19 May 2008 14:02:15 +0200

Hi

Thanks for the comments. To your questions/comments.

Sofar e.g CSCF's are identified as nodes that may be problematic. In many cases it is likely that a B2BUA (e.g an SBC) may act as a "translator" (between e.g IMS and non-IMS) as it may anyway need to handle things such as encryption and transcoding but still a P-CSCF in the path may cause problems for different scenarios and may increase the number of interop scenarios and issues that must be dealt with. It is really difficult to say what might happen ( http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-08 does not consider unacceptable answers).

It is true that some kind of a mandate for a 2nd offer/answer will very likely in the end lead to that media will not flow until the 2nd offer the earliest. Currently it is unclear if it will lead to increased setup times or if it is hidden by other signaling (e.g precondition)

I tried to find some info about the modified "m=" line in the SDPCapNeg draft, more specifically if it is connected to a MUST. Sofar I have not found any such requirement. I may have missed it, please correct me.
The only more specific info I found is in section 3.4.2 that says that the receiver of the answer must be able to handle the case that an intermediary may rewrite the "m=" line. 
This would then mean that the answer may leave the "m=" line unaltered ?. The offer when it receives the answer will then see that the "a=acfg" and the "m=" line does not correlate well and will issue another offer/answer round (probably as an UPDATE). There may occur some transmission of "faulty" media but as the receivers MAY discard this media this should be a minor issue (could be some early media security issues though).

Regards
Ingemar

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: den 18 maj 2008 22:19
> To: Ingemar Johansson S
> Cc: [email-masked]
> Subject: Re: [MMUSIC] SDPCapNeg, modified m-line issue
> 
> Hi Ingemar
> 
> > As you may know, SDP Capability Negotiation Framework 
> (SDPCapNeg) is gaining interest in the 3GPP community 
> especially in the SA4 and CT1 working groups. 
> > 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..
> > 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
> 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.
> >
> 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 
> 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:
> 
> 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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 19 May 2008 17:00:02 -0400

> I tried to find some info about the modified "m=" line in the SDPCapNeg draft, more specifically if it is connected to a MUST. Sofar I have not found any such requirement. I may have missed it, ple…
It follows from the description in Section 3.6.2 (Generating the 
answer), and in particular the following excerpt:

Once the answerer has selected a valid and supported offered
   potential configuration for all of the media streams (or has fallen
   back to the actual configuration plus any added session attributes),
   the answerer MUST generate a valid answer SDP based on the selected
   potential configuration SDP, as "seen" by the answerer (see Section
   3.6.2.1. for examples).

> The only more specific info I found is in section 3.4.2 that says that the receiver of the answer must be able to handle the case that an intermediary may rewrite the "m=" line. 
I'm not sure where in Section 3.4.2 you see that. Answers are supposed 
to follow the rules in Section 3.6.2. and if an intermediary changes 
that, then things may or may not work (if it's a B2BUA, then obviously 
we are in a different situation).

> This would then mean that the answer may leave the "m=" line unaltered ?. 
No - see Section 3.6.2
> The offer when it receives the answer will then see that the "a=acfg" and the "m=" line does not correlate well and will issue another offer/answer round (probably as an UPDATE). There may occur some transmission of "faulty" media but as the receivers MAY discard this media this should be a minor issue (could be some early media security issues though).
>   
Again, this is not what the draft specifies (see Section 3.6.3 as well)

-- Flemming

>>> 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. 
>>     
>>> In this example the preferred configuration is only 
>>>       
>> indicated by the a=acfg line.
>>     
>>>   
>>>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 20 May 2008 09:50:15 +0200

Hi
 
Thanks for pointing at the correct spec paragaphs. 
Actually tried to find the necessary "MUST text" in this section earlier but I missed it somehow. 
Is it maybe a good idea to copy some of this text to the beginning of the section like for instance.
"The generated (first) answer MUST be a valid SDP based on the selected actual configuration"  
 
I belive that this piece of info is pretty important. 
 
Back to the problem, the present formulation in 3.6.2 may cause problems as the handling of "unaccepted" aswer SDP's seems to be unclear. These problems are in some cases are avoided by B2BUA and perhaps the rest of the issues are corner cases that can be avoided by some other means, I need to look deeper into this and see if the problems are reason enough to motivate a change in the draft. 
 
/Ingemar

________________________________

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: den 19 maj 2008 23:00
	To: Ingemar Johansson S
	Cc: [email-masked]
	Subject: Re: [MMUSIC] SDPCapNeg, modified m-line issue

		Hi

		

	It follows from the description in Section 3.6.2 (Generating the answer), and in particular the following excerpt: 

	I'm not sure where in Section 3.4.2 you see that. Answers are supposed to follow the rules in Section 3.6.2. and if an intermediary changes that, then things may or may not work (if it's a B2BUA, then obviously we are in a different situation). 

	No - see Section 3.6.2

	
	-- Flemming 

		Regards
		Ingemar

			-----Original Message-----
			From: Flemming Andreasen [mailto:[email-masked]] 
			Sent: den 18 maj 2008 22:19
			To: Ingemar Johansson S
			Cc: [email-masked]
			Subject: Re: [MMUSIC] SDPCapNeg, modified m-line issue
			
			Hi Ingemar

				Hi

				An example is the SDP
				Offer:
				   m=audio 1234 RTP/AVP 97
				   a=fmtp..
				   a=rtpmap..

				  

				  

			Agreed.

				   m=audio 5678 RTP/AVP 97
				   a=fmtp..
				   a=rtpmap..
				   a=acfg:1 t=1

				  

			

			

			Regards
			
			-- Flemming

				Regards
				Ingemar

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 May 2008 17:06:27 +0200

Hi Flemming,
 
I don't think having a 2nd offer/answer breaks the requirement (REQ-100). The capabilities ARE negotiated within a single offer/answer. The second offer/answer is then used to "synchronize" possible intermediates. And, if there are no intermediates, there is no need for a second offer/answer even with the changes proposed by Ingemar.
 
The big advantage is that intermediates not understanding SDPCapNeg will only see "normal" offer/answer transactions.
 
Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Flemming Andreasen
Sent: 20. toukokuuta 2008 0:00
To: Ingemar Johansson S
Cc: [email-masked]
Subject: Re: [MMUSIC] SDPCapNeg, modified m-line issue

	Hi

	

No - see Section 3.6.2

-- Flemming 

	Regards
	Ingemar

		-----Original Message-----
		From: Flemming Andreasen [mailto:[email-masked]] 
		Sent: den 18 maj 2008 22:19
		To: Ingemar Johansson S
		Cc: [email-masked]
		Subject: Re: [MMUSIC] SDPCapNeg, modified m-line issue
		
		Hi Ingemar

			Hi

			An example is the SDP
			Offer:
			   m=audio 1234 RTP/AVP 97
			   a=fmtp..
			   a=rtpmap..

			  

			  

		Agreed.

			   m=audio 5678 RTP/AVP 97
			   a=fmtp..
			   a=rtpmap..
			   a=acfg:1 t=1

			  

		

		

		Regards
		
		-- Flemming

			Regards
			Ingemar

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 20 May 2008 10:46:09 -0400

Ingemar Johansson S wrote:
> Back to the problem, the present formulation in 3.6.2 may cause 
> problems as the handling of "unaccepted" aswer SDP's seems to be unclear.
It's basically saying to follow RFC 3264 (but based on the potential 
configuration SDP that was actually used), so I don't think this is 
raising any new issues.

> These problems are in some cases are avoided by B2BUA and perhaps the 
> rest of the issues are corner cases that can be avoided by some other 
> means, I need to look deeper into this and see if the problems are 
> reason enough to motivate a change in the draft.
ok.

-- Flemming
>  
> /Ingemar
>  
>
>     ------------------------------------------------------------------------
>     *From:* Flemming Andreasen [mailto:[email-masked]]
>     *Sent:* den 19 maj 2008 23:00
>     *To:* Ingemar Johansson S
>     *Cc:* [email-masked]
>     *Subject:* Re: [MMUSIC] SDPCapNeg, modified m-line issue
>
>
>
>     I'm not sure where in Section 3.4.2 you see that. Answers are
>     supposed to follow the rules in Section 3.6.2. and if an
>     intermediary changes that, then things may or may not work (if
>     it's a B2BUA, then obviously we are in a different situation).
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 20 May 2008 18:00:45 -0400

Christer Holmberg wrote:
> Hi Flemming,
>  
> I don't think having a 2nd offer/answer breaks the requirement (REQ-100).
Agreed (and this is also what we have in the current draft).
> The capabilities ARE negotiated within a single offer/answer. The 
> second offer/answer is then used to "synchronize" possible 
> intermediates. And, if there are no intermediates, there is no need 
> for a second offer/answer even with the changes proposed by Ingemar.
Agreed and again, this is also what is in the current draft, however I 
don't believe this is what Ingemar is proposing.
>  
> The big advantage is that intermediates not understanding SDPCapNeg 
> will only see "normal" offer/answer transactions.
Maybe so, but the media streams for sure will not reflect that "normal" 
offer/answer transaction and hence may use very different resources than 
the intermediary expected. As I noted previously, we discussed this 
option last year, but declined to pursue it (see below mentioned 
thread). Since the concerns you are raising here are essentially the 
same as were raised last year, and consensus back then was for the 
current solution, I think it's a bit late to try and change that at this 
point.

-- Flemming

> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Flemming Andreasen
> *Sent:* 20. toukokuuta 2008 0:00

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 May 2008 06:08:48 +0200

Hi,

>>The capabilities ARE negotiated within a single offer/answer. The second offer/answer is then used to "synchronize" 
>>possible intermediates. And, if there are no intermediates, there is no need for a second offer/answer even with the 
>>changes proposed by Ingemar.
>
>Agreed and again, this is also what is in the current draft, however I don't believe this is what Ingemar is proposing. 

As I understand, Ingemar is proposing that the m= line is not changed in the answer. And, my point is that even in that case the capabilities WOULD still be negotiated in a single/offer answer. After all, the "final choise" is not indicated by the m= line, but by certain attributes.

>Maybe so, but the media streams for sure will not reflect that "normal" offer/answer transaction and hence may use very 
>different resources than the intermediary expected.

That is true, but THAT can be fixed with a second offer/answer. The problem AT THE MOMENT is that it is difficult to say exactly what intermediates will do, what resources they will reserve (if they will reserve anything, or if they will release the whole stream/call).

Even with the current draft I think, in order to be on the safe side, that a UA should always send a second offer/answer, because the UA has no clue about whether possible intermediates "need" it or not.

>As I noted previously, we discussed this option last year, but declined to pursue it (see below mentioned thread). Since 
>the concerns you are raising here are essentially the same as were raised last year, and consensus back then was for the 
>current solution, I think it's a bit late to try and change that at this point. 

I am aware that this is coming late, and I appologize for that, but it's not the first time things are re-discussed. One difference is that now we also have the CS draft from Miguel, which allows the change of the c= line, which may make the whole thing even worse (see separate thread).

Regards,

Christer

	Regards,
	 
	Christer

		Hi

		

	

	No - see Section 3.6.2

	
	-- Flemming 

		Regards
		Ingemar

			-----Original Message-----
			From: Flemming Andreasen [mailto:[email-masked]] 
			Sent: den 18 maj 2008 22:19
			To: Ingemar Johansson S
			Cc: [email-masked]
			Subject: Re: [MMUSIC] SDPCapNeg, modified m-line issue
			
			Hi Ingemar

				Hi

				An example is the SDP
				Offer:
				   m=audio 1234 RTP/AVP 97
				   a=fmtp..
				   a=rtpmap..

				  

				  

			Agreed.

				   m=audio 5678 RTP/AVP 97
				   a=fmtp..
				   a=rtpmap..
				   a=acfg:1 t=1

				  

			

			

			Regards
			
			-- Flemming

				Regards
				Ingemar

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 21 May 2008 09:36:32 -0400

> As I understand, Ingemar is proposing that the m= line is not changed in the answer. And, my point is that even in that case the capabilities WOULD still be negotiated in a single/offer answer. Aft…
I'm not sure what you mean by "negotiating capabilities" so let me try 
and clarify: In the current draft, the offerer provides an actual 
configuration for one or more media streams, a set of capabilities, and 
one or more alternative potential configurations using those 
capabilities. The answerer in turn chooses one of the configurations 
(actual or potential) and then generates an answer indicating the now 
negotiated media stream based on that configuration. The answerer may 
also include additional capabilities in his answer (but doesn't have to 
do so).

As I understand Ingemar's proposal, he instead wants to have two O/A 
exchanges where in the first exchange, there is merely an exchange of 
capabilities, and in the second exchange, based on the capabilities 
exchanged, he then negotiates the actual configuration for the media 
stream. As I noted in a previous response, it is indeed possible to 
satisfy those semantics with the current draft, albeit with a few 
limitations on expressiveness. Those limitations however are lifted by 
use of the media capabilities extensions (latent configurations in 
particular) and hence we have a solution to the problem that was posed 
that 3GPP and others can use if they don't upgrade their intermediaries.

> That is true, but THAT can be fixed with a second offer/answer. The problem AT THE MOMENT is that it is difficult to say exactly what intermediates will do, what resources they will reserve (if the…
Agreed. Given that however, I have a hard time seeing why you think your 
proposal is any better since we both seem to agree that it is entirely 
speculative whether a particular intermediary will have problems with 
the current solution, the alternative Ingemar proposed, or both.

> Even with the current draft I think, in order to be on the safe side, that a UA should always send a second offer/answer, because the UA has no clue about whether possible intermediates "need" it o…
Right - and that is also what the draft specifies in Section 3.6.3.

> I am aware that this is coming late, and I appologize for that, but it's not the first time things are re-discussed. One difference is that now we also have the CS draft from Miguel, which allows t…
Sure, and we can probably find loads of other parameters both new and in 
the future that compounds the problem. At the end of the day, the 
problem boils down to having an intermediary trying to do things with an 
SDP it only partially understands. This is a fundamental and unsolvable 
problem that applies to all intermediaries, whether they are NAT ALGs, 
Firewall, 3GPP P-CSCFs, PacketCable CMSes, etc.  I really don't see 
anything new in this discussion, and as I noted, we've been through it 
several times before, we designed the solution around the consensus 
decision, and I have furthermore outlined a solution based on the 
current mechanism that seems to address the problems you have described.

-- Flemming