Subject: [MMUSIC] Comment on draft-ietf-mmusic-sdp-capability-negotiation-07

From: "Even, Roni" <[email-masked]>
Date: Tue, 6 Nov 2007 18:24:56 +0200

Flemming,

Section 3.6.2 says

"The "a=acfg" attribute MUST identify the configuration number for the selected potential configuration as well as the actual parameters that were used from that potential configuration; if the potential configuration included alternatives, the selected alternatives only MUST be included." 

The way I read it is that the acfg must have all the actual parameters even though they may appear as part of the answer.

For example if the potential configuration had an fmtp potential configuration it will appear in the SDP as an a=fmtp line so why list it also in the acfg. Or if a transport was chosen it will be in the answer m-line so why need the t= in the acfg

Since Bob and I are working now media capabilities extensions and adding more parameters we tried to understand if there was a specific reason for this requirement.

Thanks

Roni Even

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

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 06 Nov 2007 11:39:59 -0500

Even, Roni wrote:
>
> Flemming,
>
>  
>
> Section 3.6.2 says
>
> "The "a=acfg" attribute MUST identify the configuration number for the 
> selected potential configuration as well as the actual parameters that 
> were used from that potential configuration; if the potential 
> configuration included alternatives, the selected alternatives only 
> MUST be included."
>
> The way I read it is that the acfg must have all the actual parameters 
> even though they may appear as part of the answer.
>
> For example if the potential configuration had an fmtp potential 
> configuration it will appear in the SDP as an a=fmtp line so why list 
> it also in the acfg. Or if a transport was chosen it will be in the 
> answer m-line so why need the t= in the acfg
>
Not all attributes from an offer are repeated in an answer, and some 
parameters may differ between the offer and the answer. For example, an 
"a=crypto" attribute in the offer differs from the one provided in the 
answer. Telephone-events using fmtp parameters is an example where you 
may find different "fmtp" values between the offer and answer as well.
>
>  
>
> Since Bob and I are working now media capabilities extensions and 
> adding more parameters we tried to understand if there was a specific 
> reason for this requirement.
>
See above. Taking a step back, the reason is that you want the offerer 
to be able to (easily) determine the potential configuration that was 
used for the O/A exchange, thereby enabling it to determine if the 
answer satisfies all the necessary requirements as well as what the 
configuration to use actually is.

-- Flemming

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 6 Nov 2007 18:44:28 +0200

Flemming,

The question is about the requirement to have all of them for example the transport is repeated in the m-line in the answer so why do we need the t= in the acfg line also

Roni

________________________________

From: Flemming Andreasen [mailto:[email-masked]] 
Sent: Tuesday, November 06, 2007 6:40 PM
To: Even, Roni
Cc: [email-masked]
Subject: Re: Comment on draft-ietf-mmusic-sdp-capability-negotiation-07

Even, Roni wrote: 

Flemming,

Section 3.6.2 says

Not all attributes from an offer are repeated in an answer, and some parameters may differ between the offer and the answer. For example, an "a=crypto" attribute in the offer differs from the one provided in the answer. Telephone-events using fmtp parameters is an example where you may find different "fmtp" values between the offer and answer as well. 

See above. Taking a step back, the reason is that you want the offerer to be able to (easily) determine the potential configuration that was used for the O/A exchange, thereby enabling it to determine if the answer satisfies all the necessary requirements as well as what the configuration to use actually is. 

-- Flemming 

 

Thanks

Roni Even

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 06 Nov 2007 11:58:50 -0500

Even, Roni wrote:
>
> Flemming,
>
> The question is about the requirement to have all of them for example 
> the transport is repeated in the m-line in the answer so why do we 
> need the t= in the acfg line also
>
Consistency and simplicity basically. While we could start anaylizing 
individual capabilities and even particular values to determine whether 
they are truly needed or not, I think we just increase overall 
complexity and the gain is minimal.

-- Flemming

>  
>
> Roni
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Flemming Andreasen [mailto:[email-masked]]
> *Sent:* Tuesday, November 06, 2007 6:40 PM
> *To:* Even, Roni
> *Cc:* [email-masked]
> *Subject:* Re: Comment on draft-ietf-mmusic-sdp-capability-negotiation-07
>
>  
>
>
> Even, Roni wrote:
>
> Flemming,
>
>  
>
> Section 3.6.2 says
>
> parameters may differ between the offer and the answer. For example, 
> an "a=crypto" attribute in the offer differs from the one provided in 
> the answer. Telephone-events using fmtp parameters is an example where 
> you may find different "fmtp" values between the offer and answer as 
> well.
>
>  
>
> ------------------------------------------------------------------------
>