Subject: [MMUSIC] SDPCapNeg syntax of answer

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 21 Feb 2008 11:20:01 +0100

Hi

Reading the SDPCapNeg and the media capabilities.. The offer contains a set of attribues and potential configurations. The answer contains an actual configuration in an "a=acfg:..." line.

My question is: Can the "a=acfg" line be omitted in the answer provided that the "plain SDP" reflects the "a=acfg" line ? . 
I guess that answer is perhaps no, but I have sofar not find any reason to why, maybe I overlook some issue....

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]
http://www.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 21 Feb 2008 12:03:24 -0500

You must include the "a=acfg" attribute in the answer when using SDP 
Capability Negotiation. The motivation for having this attribute and 
mandating its presence in the answer is that an offer may include 
alternative declarative parameters (declarative parameters apply only to 
media sent by an entity). Since declarative SDP parameters are generally 
not repeated in the SDP answer, there would be no way for the offerer to 
decide which of the alternatives had been selected. Keying material, 
uni-directional levels of redundancy, etc. can be examples of 
declarative parameters.

-- Flemming

Ingemar Johansson S wrote:
>
> Hi
>
> Reading the SDPCapNeg and the media capabilities.. The offer contains 
> a set of attribues and potential configurations. The answer contains 
> an actual configuration in an "a=acfg:..." line.
>
> My question is: Can the "a=acfg" line be omitted in the answer 
> provided that the "plain SDP" reflects the "a=acfg" line ? .
>
> I guess that answer is perhaps no, but I have sofar not find any 
> reason to why, maybe I overlook some issue....
>
> Regards
> Ingemar
> ------------------------------------------------------------------------
>

---

From: "Guangwu.He" <[email-masked]>
Date: Fri, 22 Feb 2008 08:59:56 +0800

I have a question,the example is:
(offerer and answerer all support SDP Cap Neg) 
offer: 
a=tcap:1 RTP/SAVPF RTP/SAVP
m=audio 59000 RTP/AVP 98 
a=rtpmap:98 AMR/8000 
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32    
       inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32  
a=pcfg:1 t=1 a=1
a=pcfg:2 t=2 a=1
 
answerer can not support RTP/SAVPF and RTP/SAVP,according to the SDPCapNeg
3.6.2:If the answerer has exhausted all potential configurations for the 
media description, without finding a valid one that is also 
supported, then the answerer MUST process the offered media stream 
based on the actual configuration plus any session-level attributes 
added by a valid and supported potential configuration from another 
media description in the offered SDP.  
 
so the answer:
m=audio 54568 RTP/AVP 98
a=rtpmap:98 AMR/8000 
 
is right?

Thanks & Regards,

Guangwu.He 

  _____  

 You must include the "a=acfg" attribute in the answer when using SDP
Capability Negotiation. The motivation for having this attribute and
mandating its presence in the answer is that an offer may include
alternative declarative parameters (declarative parameters apply only to
media sent by an entity). Since declarative SDP parameters are generally not
repeated in the SDP answer, there would be no way for the offerer to decide
which of the alternatives had been selected. Keying material,
uni-directional levels of redundancy, etc. can be examples of declarative
parameters. 

-- Flemming 

Hi 

Reading the SDPCapNeg and the media capabilities.. The offer contains a set
of attribues and potential configurations. The answer contains an actual
configuration in an "a=acfg:..." line.

My question is: Can the "a=acfg" line be omitted in the answer provided that
the "plain SDP" reflects the "a=acfg" line ? . 

I guess that answer is perhaps no, but I have sofar not find any reason to
why, maybe I overlook some issue.... 

Regards 
Ingemar 

  _____  

mmusic mailing list

[email-masked]

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 22 Feb 2008 12:25:14 +0100

Thanks for the response. 
 
Now I found this statement in 3.6.2 in the draft as well, however I believe that a motivation like the one below would not hurt.
/Ingemar

________________________________

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: den 21 februari 2008 18:03
	To: Ingemar Johansson S
	Cc: [email-masked]
	Subject: Re: [MMUSIC] SDPCapNeg syntax of answer

	You must include the "a=acfg" attribute in the answer when using SDP Capability Negotiation. The motivation for having this attribute and mandating its presence in the answer is that an offer may include alternative declarative parameters (declarative parameters apply only to media sent by an entity). Since declarative SDP parameters are generally not repeated in the SDP answer, there would be no way for the offerer to decide which of the alternatives had been selected. Keying material, uni-directional levels of redundancy, etc. can be examples of declarative parameters. 
	
	-- Flemming 

		Hi 

		Regards 
		Ingemar 

________________________________

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 22 Feb 2008 07:22:58 -0500

Guangwu.He wrote:
> answerer can not support RTP/SAVPF and RTP/SAVP,according to the 
> SDPCapNeg 3.6.2:If the answerer has exhausted all potential 
> configurations for the
Correct.

-- Flemming

---

From: "Zhengrong Yao" <[email-masked]>
Date: Sat, 23 Feb 2008 17:10:45 +0100

Hi:
 
I have a following up question to this issue if the main answer is declarative SDP parameters:
 
According to the draft
1. We must include the "a=acfg",  and we "may" repeat the declarative SDP parameters in the answer since it seem nothing prevent this.
2. "the offerer SHOULD initiate another offer/answer exchange", I suppose this should also contains the declarative SDP parameters, since if not, the intermediaries need to deduct from both 1st sdp offer and 2nd sdp offer.
 
It is my headache to see this  need of second round offer/answer, and if we still need to bother to send those declarative stuffs in another round, why not just mandate it in the first round answer, so it looks really like a plain sdp ?
 
The gain is probably a much lower need for the second round offer/answer.
 
I guess the need for this 2nd round must have been discussed 1000 times, and please help  to hint me a discussion thread if my answer was already there.

Best regards.
 
Zhengrong

Zhengrong Yao  Ph.D. 
Standardization Manager 
Ericsson AB 
Business Unit Multimedia                          Office: +46 46 19458
Scheelevägen 17                                       Fax: +46 76 130 3945
SE22370, Lund, Sweden                        Mobile: +46 703 674584
www.ericsson.com <http://www.ericsson.com/>                 Email: [email-masked] <mailto:[email-masked]>  

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive emails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
Sent: den 22 februari 2008 12:25
To: Flemming Andreasen
Cc: [email-masked]
Subject: Re: [MMUSIC] SDPCapNeg syntax of answer

Thanks for the response. 

	
	-- Flemming 

		Hi 

		Regards 
		Ingemar

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 25 Feb 2008 12:39:49 -0500

Zhengrong Yao wrote:
> 1. We must include the "a=acfg",  and we "may" repeat the declarative 
> SDP parameters in the answer since it seem nothing prevent this.
>
Not quite. Declarative parameters are usually uni-directional, and hence 
you don't "repeat" them in the answer. You may however provide the 
answerer's declarative SDP parameters.
> 2. "the offerer SHOULD initiate another offer/answer exchange", I 
> suppose this should also contains the declarative SDP parameters, 
> since if not, the intermediaries need to deduct from both 1st sdp 
> offer and 2nd sdp offer.
>  
> It is my headache to see this  need of second round offer/answer, and 
> if we still need to bother to send those declarative stuffs in another 
> round, why not just mandate it in the first round answer, so it looks 
> really like a plain sdp ?
>  
> I guess the need for this 2nd round must have been discussed 1000 
> times, and please help  to hint me a discussion thread if my 
> answer was already there.
>
See above. Also, Section 3.12 provides the rationaly for the second o/a 
exchange.

Thanks

-- Flemming
> *Zhengrong Yao*  Ph.D.
> *Ericsson AB*
> _www.ericsson.com_ <http://www.ericsson.com/>                Email: 
> [email-masked] <mailto:[email-masked]>
>
> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or distribution 
> is prohibited. If you believe this message has been sent to you in 
> error, please notify the sender by replying to this transmission and 
> delete the message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption, 
> interception, unauthorized amendment, tampering and viruses, and we 
> only send and receive emails on the basis that we are not liable for 
> any such corruption, interception, amendment, tampering or viruses or 
> any consequences thereof.
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Ingemar Johansson S
> *Sent:* den 22 februari 2008 12:25
> *To:* Flemming Andreasen
> *Cc:* [email-masked]
> *Subject:* Re: [MMUSIC] SDPCapNeg syntax of answer
>
> Thanks for the response.
>  
> Now I found this statement in 3.6.2 in the draft as well, however I 
> believe that a motivation like the one below would not hurt.
> /Ingemar
>
>     *From:* Flemming Andreasen [mailto:[email-masked]]
>     *Sent:* den 21 februari 2008 18:03
>     *To:* Ingemar Johansson S
>     *Cc:* [email-masked]
>     *Subject:* Re: [MMUSIC] SDPCapNeg syntax of answer
>
>     You must include the "a=acfg" attribute in the answer when using
>     SDP Capability Negotiation. The motivation for having this
>     attribute and mandating its presence in the answer is that an
>     offer may include alternative declarative parameters (declarative
>     parameters apply only to media sent by an entity). Since
>     declarative SDP parameters are generally not repeated in the SDP
>     answer, there would be no way for the offerer to decide which of
>     the alternatives had been selected. Keying material,
>>     Reading the SDPCapNeg and the media capabilities.. The offer
>>     contains a set of attribues and potential configurations. The
>>     answer contains an actual configuration in an "a=acfg:..." line.
>>