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

["Christer Holmberg" <[e-mail]>]

Hi,

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

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.

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

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
	 
	 

________________________________

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


	Ingemar Johansson S wrote: 

		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.
		  

	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 
	
	

		Regards
		Ingemar
		
		
		
		  

			-----Original Message-----
			From: Flemming Andreasen [mailto:[e-mail]] 
			Sent: den 18 maj 2008 22:19
			To: Ingemar Johansson S
			Cc: [e-mail]
			Subject: Re: [MMUSIC] SDPCapNeg, modified m-line issue
			
			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