Subject: [MMUSIC] help - question on SDP negotiation (additional media format subject)

From: "BOURGEAIS ANNIE" <[email-masked]>
Date: Mon, 12 Mar 2007 17:27:04 +0100

Hello,

				Thank you very for your answer. 
				I have 2 additional questions, I am not
sure to well understand the offer/answer exchanges when formats are
updated (that means, formats present in the answer are not the ones
present in the offer).

				In case Alice calls Bob  with the
following offer

				Offer :
				v=0
				o=alice 2890844526 2890842807 IN IP4
192.168.0.1
				s=-
				c=IN IP4 192.168.0.1
				t=0 0
				m=audio 8000 RTP/AVP 18
				a=rtpmap:18 G729/8000

				In case Bob answers with a different
audio format
				Answer:
				v=0
				o=bob 2890844526 2890842807 IN IP4
192.168.0.2
				s=-
				c=IN IP4 192.168.0.2
				t=0 0
				m=audio 8000 RTP/AVP 19
				a=rtpmap:19 G729/8000

				Question 1: Is the previous offer-answer
really correct ?  Will Alice and Bob really able to communicate (from
audio point of view) after this SDP exchange ?  Is it really possible
and consistent with the RFC 3264  ?  
				6.1 Unicast Streams
				For streams marked as sendrecv in the
answer,
				   the "m=" line MUST contain at least
one codec the answerer is willing to both send and receive, from amongst
those listed in the offer.
				   The stream MAY indicate additional
media formats, not listed in the corresponding stream in the offer, that
the answerer is willing to send or receive (of course, it will not be
able to send them at this time, since it was not listed in the offer).

				Question 2: If Alice wants to add for
example video media, and sends a new offer, what has Alice to send for
audio line : format '18' or format '19'or both? .
				Is this new offer from Alice correct ?

				New Offer :
				v=0
				o=alice 2890844526 2890842808 IN IP4
192.168.0.1
				s=-
				c=IN IP4 192.168.0.1
				t=0 0
				m=audio 8000 RTP/AVP 18
				a=rtpmap:18 G729/8000
				m=video 53000 RTP/AVP 32
				a=rtpmap:32 MPV/9000

				New Answer 
				v=0
				o=bob 2890844526 2890842807 IN IP4
192.168.0.2
				s=-
				c=IN IP4 192.168.0.2
				t=0 0
				m=audio 8000 RTP/AVP 19
				a=rtpmap:19 G729/8000
				m=video 13000 RTP/AVP 32
				a=rtpmap:32 MPV/9000

				Thank you very much for your help

				----- Forwarded by Annie
BOURGEAIS/FR/ALCATEL on 12/03/2007 09:59 -----

	Colin Perkins <[email-masked]>
			10/03/2007 18:32		
	To:	Annie BOURGEAIS/FR/ALCATEL@ALCATEL
	cc:	[email-masked]
	Subject:	Re: [MMUSIC] help - question on SDP negotiation
(additional media format subject)	

				On 8 Mar 2007, at 14:17,
[email-masked] wrote:
				> I have a question about the SDP media
negotiation, regarding an  
				> answer I
				> have found on this address :
				>
				>
https://lists.cs.columbia.edu/pipermail/sip-implementors/2005-September/
010241.html
				>
				> I would like to know if the answer
given is specific to DTMF  
				> exchanges, or
				> if this is true for all possible
exchanges.
				> To be more specific about my question,
I  can give this example :  
				> is the
				> following offer-answer exchange
correct ?

				No - it's not syntactically valid SDP,
for starters. These should be  
				something like the following:

				> Offer:
				> m: audio 8000 RTP/AVP 18 0 96
				> rtpmap: 18 G729/8000
				> rtpmap: 0 PCMU/8000
				> fmtp:96 0-15
				> rtpmap:96 telephone-event/8000

				v=0
				o=alice 2890844526 2890842807 IN IP4
192.168.0.1
				s=-
				c=IN IP4 192.168.0.1
				t=0 0
				m=audio 8000 RTP/AVP 18 0 96
				a=rtpmap:18 G729/8000
				a=rtpmap:0 PCMU/8000
				a=rtpmap:96 telephone-event/8000
				a=fmtp:96 0-15

				> Answer
				> m: audio 8000 RTP/AVP 19 0 97
				> rtpmap: 19 G729/8000
				> rtpmap: 0 PCMU/8000
				> fmtp:97 0-15
				> rtpmap:97 telephone-event/8000

				v=0
				o=bob 2890844526 2890842807 IN IP4
192.168.0.2
				s=-
				c=IN IP4 192.168.0.2
				t=0 0
				m=audio 8000 RTP/AVP 19 0 97
				a=rtpmap:19 G729/8000
				a=rtpmap:0 PCMU/8000
				a=rtpmap:97 telephone-event/8000
				a=ftmp:97 0-15

				-- 
				Colin Perkins
				http://csperkins.org/

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

---

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Tue, 13 Mar 2007 17:57:53 +0100

Hi

The word "format" you use is not really appropriate. You are actually talking about "payload types".
The media format is audio/G729 and is the same in the offer and the answer. So Alice and Bob will be able to communicate, they both support G729.

In your example Alice expects to receive G729 RTP packets with payload type 18 and Bob expects to receive G729 RTP packets with payload type 19.

It is not recommended by RFC3264 to have different payload types in each direction for the same codec, but it is not prohibited :
 §6.1 
   In the case of RTP, if a particular codec was referenced with a
   specific payload type number in the offer, that same payload type
   number SHOULD be used for that codec in the answer.

Your second example works. But same comments apply.

In addition, note that payload type 18 is registered for audio/G729 (RFC3551) so it would anyway be better to use 18 than 19 which is reserved...

Aurelien

________________________________

	De : BOURGEAIS ANNIE [mailto:[email-masked]] 
	Envoyé : lundi 12 mars 2007 17:27
	À : [email-masked]
	Objet : [MMUSIC] help - question on SDP negotiation (additional media formatsubject)

					Hello, 

					Thank you very for your answer. 
					I have 2 additional questions, I am not sure to well understand the offer/answer exchanges when formats are updated (that means, formats present in the answer are not the ones present in the offer).

					In case Alice calls Bob  with the following offer 

					Offer : 
					v=0 
					o=alice 2890844526 2890842807 IN IP4 192.168.0.1 
					s=- 
					c=IN IP4 192.168.0.1 
					t=0 0 
					m=audio 8000 RTP/AVP 18 
					a=rtpmap:18 G729/8000 

					In case Bob answers with a different audio format 
					Answer: 
					v=0 
					o=bob 2890844526 2890842807 IN IP4 192.168.0.2 
					s=- 
					c=IN IP4 192.168.0.2 
					t=0 0 
					m=audio 8000 RTP/AVP 19 
					a=rtpmap:19 G729/8000 

					Question 1: Is the previous offer-answer really correct ?  Will Alice and Bob really able to communicate (from audio point of view) after this SDP exchange ?  Is it really possible and consistent with the RFC 3264  ?  

					6.1 Unicast Streams 
					For streams marked as sendrecv in the answer, 
					   the "m=" line MUST contain at least one codec the answerer is willing to both send and receive, from amongst those listed in the offer.

					   The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer).

					Question 2: If Alice wants to add for example video media, and sends a new offer, what has Alice to send for audio line : format '18' or format '19'or both? .

					New Offer : 
					v=0 
					o=alice 2890844526 2890842808 IN IP4 192.168.0.1 
					s=- 
					c=IN IP4 192.168.0.1 
					t=0 0 
					m=audio 8000 RTP/AVP 18 
					a=rtpmap:18 G729/8000 
					m=video 53000 RTP/AVP 32 
					a=rtpmap:32 MPV/9000 

					New Answer 
					v=0 
					o=bob 2890844526 2890842807 IN IP4 192.168.0.2 
					s=- 
					c=IN IP4 192.168.0.2 
					t=0 0 
					m=audio 8000 RTP/AVP 19 
					a=rtpmap:19 G729/8000 
					m=video 13000 RTP/AVP 32 
					a=rtpmap:32 MPV/9000