Subject: Re: [MMUSIC] SDP Capability Negotation: Should the scope of a=capar: narrowed down to transport protocol negotiation?

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 13 Feb 2007 12:08:07 +0100

a 
  "crypto_v2" attribute tomorrow - how will that work ? <BR><SPAN 
  class=054011808-13022007><FONT face=Arial color=#0000ff size=2>[Stach 
  Thomas]&nbsp;In this case the above ABNF must be extended by the usual means 
  (definition of an additional token, IANA registry)</FONT></SPAN></DIV><SPAN 
  class=054011808-13022007></SPAN>
  <DIV><SPAN class=054011808-13022007><FONT face=Arial color=#0000ff size=2>Does 
  this make sense?&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=054011808-13022007><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN><BR><SPAN class=054011808-13022007><FONT face=Arial 
  color=#0000ff size=2>Regards,</FONT></SPAN></DIV>
  <DIV><SPAN class=054011808-13022007><FONT face=Arial color=#0000ff 
  size=2>Thomas</FONT>&nbsp;</SPAN><BR><BR>-- Flemming <BR><BR><SPAN 
  class=054011808-13022007><FONT face=Arial color=#0000ff size=2>[Stach 
  Thomas]&nbsp;&lt;snip&gt;&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C74F5F.48B5BC7F--

--=======30214331=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=======30214331=--

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 13 Feb 2007 12:08:07 +0100

Fleming, 

maybe my reasoning wasn't clear enough, I try to explain inline.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: Monday, February 12, 2007 11:22 PM
> To: Stach, Thomas
> Cc: [email-masked]
> Subject: Re: [MMUSIC] SDP Capability Negotation: Should the 
> scope of a=capar: narrowed down to transport protocol negotiation?
> 
> 
> 
> Stach, Thomas wrote:
> > Hi all,
> >  
> > in the context of SDP media capability negotiation it is 
> currently discussed to define new SDP attributes like 
> > a=cmed:, a=cenc:, a=cfmt:, a=cptmap: that negotiate 
> parameters that usually go into the a=rtpmap:, a=fmtp:, a=ptime, etc.
> >
> > In draft-ietf-mmusic-sdp-capability-negotiation-01 the new 
> SDP attribute a=capar: is going to be defined.
> > It is basically a container that can carry everything that 
> is specified as an SDP attribute.
> > Hence it could carry e.g. a=rtpmap as well, which will 
> introduce some ambiguity and unclear semantics in combination 
> with media capability negotiation.
> >   
> Why is that ? It's just one of several building blocks that 
> can be used 
> to piece together a potential configuration - it really 
> doesn't matter 
> whether it's done with one or the other.

I think it does matter. 
In my view, the scope of draft-ietf-mmusic-sdp-capability-negotiation-01 is the basic 
framework and negotiation of transport protocols. 
Dependend on the transport protocol various transport-specific attributes must be negotiated. 
This is done using the "a=capar:" attribute.
I think the the corresponding semantics for attribute received in an "a=capar:" line must be defined as well. 
Currently "a=capar:" allows for transport of attributes that are not needed to fulfill the task above.
However, we cannot spell out the semantics for each attribute that can potentially be found in the "a=capar:" line.
Therefore I'd like to restrict the number of attributes that can be included after "a=capar:".

Another concern that I have is that already the base spec could be used for a poor man's media capability negotiation.
For the sake of discussion, I could build the following offer.

v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 96
a=rtpmap:96 iLBC/8000
a=creq: v0
a=ctrpr:1 RTP/SAVP
a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=capar:2 a=rtpmap:96 pcmu
a=capar:3 a=ptime:20
a=capar:4 a=rtpmap:96 g729
a=pcfg: t=1 a=1,2,3
a=pcfg: t=1 a=1,4

Currently draft 01 of the base spec does not define the semantics for such an offer. 
This gives way for different interpretations.
My interpretation would be that in this example payload type 96 has different meaning whether the media stream is encrypted or not (encrypted G711 with 20ms packets or encrypted G.729 vs. unencrypted ILBC).  
Such an interpretation could be expressed using the media capability negotiation extension as follows:

v=0
o=- 25678 753849 IN IP4 192.0.2.1/24
s=
c=IN IP4 192.0.2.1/24
t=0 0
a=creq:v1
a=cmed:1 audio pcmu g729 
a=ctrpr:1 RTP/SAVP
m=audio 3456 RTP/AVP 96
a=rtpmap:96 iLBC/8000
a=mcap:3
a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=capar:2 a=ptime:20
a=pcfg:1 m=1 t=1 a=2 
a=pcfg:2 m=2 t=1 

We would have two different ways to express the same information (modulo different interpretations of the first offer). 
This introduces more complexity for the parser at the receiving side. 
I think that should be avoided. Additionally, I'd like to avoid that an implementation of the base spec has to be prepared for something like the first offer. 

<SNIP>

> >
> > As the main driver for this initiative is best-://www1.ietf.org/mailman/listinfo/mmusic>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Fleming, 

maybe my reasoning wasn't clear enough, I try to explain inline.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: Monday, February 12, 2007 11:22 PM
> To: Stach, Thomas
> Cc: [email-masked]
> Subject: Re: [MMUSIC] SDP Capability Negotation: Should the 
> scope of a=capar: narrowed down to transport protocol negotiation?
> 
> 
> 
> Stach, Thomas wrote:
> > Hi all,
> >  
> > in the context of SDP media capability negotiation it is 
> currently discussed to define new SDP attributes like 
> > a=cmed:, a=cenc:, a=cfmt:, a=cptmap: that negotiate 
> parameters that usually go into the a=rtpmap:, a=fmtp:, a=ptime, etc.
> >
> > In draft-ietf-mmusic-sdp-capability-negotiation-01 the new 
> SDP attribute a=capar: is going to be defined.
> > It is basically a container that can carry everything that 
> is specified as an SDP attribute.
> > Hence it could carry e.g. a=rtpmap as well, which will 
> introduce some ambiguity and unclear semantics in combination 
> with media capability negotiation.
> >   
> Why is that ? It's just one of several building blocks that 
> can be used 
> to piece together a potential configuration - it really 
> doesn't matter 
> whether it's done with one or the other.

I think it does matter. 
In my view, the scope of draft-ietf-mmusic-sdp-capability-negotiation-01 is the basic 
framework and negotiation of transport protocols. 
Dependend on the transport protocol various transport-specific attributes must be negotiated. 
This is done using the "a=capar:" attribute.
I think the the corresponding semantics for attribute received in an "a=capar:" line must be defined as well. 
Currently "a=capar:" allows for transport of attributes that are not needed to fulfill the task above.
However, we cannot spell out the semantics for each attribute that can potentially be found in the "a=capar:" line.
Therefore I'd like to restrict the number of attributes that can be included after "a=capar:".

Another concern that I have is that already the base spec could be used for a poor man's media capability negotiation.
For the sake of discussion, I could build the following offer.

v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 96
a=rtpmap:96 iLBC/8000
a=creq: v0
a=ctrpr:1 RTP/SAVP
a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=capar:2 a=rtpmap:96 pcmu
a=capar:3 a=ptime:20
a=capar:4 a=rtpmap:96 g729
a=pcfg: t=1 a=1,2,3
a=pcfg: t=1 a=1,4

Currently draft 01 of the base spec does not define the semantics for such an offer. 
This gives way for different interpretations.
My interpretation would be that in this example payload type 96 has different meaning whether the media stream is encrypted or not (encrypted G711 with 20ms packets or encrypted G.729 vs. unencrypted ILBC).  
Such an interpretation could be expressed using the media capability negotiation extension as follows:

v=0
o=- 25678 753849 IN IP4 192.0.2.1/24
s=
c=IN IP4 192.0.2.1/24
t=0 0
a=creq:v1
a=cmed:1 audio pcmu g729 
a=ctrpr:1 RTP/SAVP
m=audio 3456 RTP/AVP 96
a=rtpmap:96 iLBC/8000
a=mcap:3
a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=capar:2 a=ptime:20
a=pcfg:1 m=1 t=1 a=2 
a=pcfg:2 m=2 t=1 

We would have two different ways to express the same information (modulo different interpretations of the first offer). 
This introduces more complexity for the parser at the receiving side. 
I think that should be avoided. Additionally, I'd like to avoid that an implementation of the base spec has to be prepared for something like the first offer. 

<SNIP>

> >
> > As the main driver for this initiative is best-effort SRTP 
> and as we already received complaints about complexity,
> > I wonder if we should not lay the hurdle for implementation 
> even lower by defining 4 clearly separate modules for basic
> > SDP capability negotiation, namely  "best-effort srtp", 
> "comedia", "bfcp" and "flute". 
> > Support for each could be indicated using 4 option tags for 
> a=csup/creq:. 
> > Replacing the a=capar by 4 specifc attributes would also be 
> something to consider in this context.
> >
> > The modules could be separately implemented as needed for 
> the specific application of the capabilitiy negotiation framework.
> >
> > Comments?
> >   
> It looks like the SDP equivalent of coming up with specific feature 
> definition and identification in SIP as opposed to producing 
> and using a 
> general framework. We received AD guidance to come up with a general 
> framework that could be used for things beyond best-effort SRTP and 
> althought you could argue that your proposal still allows for 
> that, it 
> doesn't encourage any kind of generality in an actual 
> implementation and 
> we might as well define point solutions for each of these instead.
> 
> You can register me as opposed.
> 
> -- Flemming

Fleming, I agree.
I think I overshot here, but still I'd like to see a restriction on the number of 
attributes that have to be dealt with when only the base spec is implemented.

> 
> > mit freundlichen Grüßen/Kind Regards
> >
> > Dr.-Ing. Thomas Stach 
> > PSE KB B1 
> > Siemens Austria AG 
> > Gudrunstr. 11 Tel: +43-51707-47364 
> > A-1100 Vienna Fax: +43-51707-56992 
> > mailto:[email-masked] <mailto:[email-masked]> 
> >
> >
> >

effort SRTP 
> and as we already received complaints about complexity,
> > I wonder if we should not lay the hurdle for implementation 
> even lower by defining 4 clearly separate modules for basic
> > SDP capability negotiation, namely  "best-effort srtp", 
> "comedia", "bfcp" and "flute". 
> > Support for each could be indicated using 4 option tags for 
> a=csup/creq:. 
> > Replacing the a=capar by 4 specifc attributes would also be 
> something to consider in this context.
> >
> > The modules could be separately implemented as needed for 
> the specific application of the capabilitiy negotiation framework.
> >
> > Comments?
> >   
> It looks like the SDP equivalent of coming up with specific feature 
> definition and identification in SIP as opposed to producing 
> and using a 
> general framework. We received AD guidance to come up with a general 
> framework that could be used for things beyond best-effort SRTP and 
> althought you could argue that your proposal still allows for 
> that, it 
> doesn't encourage any kind of generality in an actual 
> implementation and 
> we might as well define point solutions for each of these instead.
> 
> You can register me as opposed.
> 
> -- Flemming

Fleming, I agree.
I think I overshot here, but still I'd like to see a restriction on the number of 
attributes that have to be dealt with when only the base spec is implemented.

> 
> > mit freundlichen Grüßen/Kind Regards
> >
> > Dr.-Ing. Thomas Stach 
> > PSE KB B1 
> > Siemens Austria AG 
> > Gudrunstr. 11 Tel: +43-51707-47364 
> > A-1100 Vienna Fax: +43-51707-56992 
> > mailto:[email-masked] <mailto:[email-masked]> 
> >
> >
> >