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

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 6 Feb 2007 15:28:57 +0100

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.

Now, I wonder if it would be useful to restrict the number of allowed values in the a=capar: attribute when negotiating transport protocol using the a=ctrpr attribute to the necessary subset of attributes.
 
Scanning through IANA the following values are assigned for the <proto> field in the m-line.
 
proto           RTP/AVP                      [RFC4566]
                vat                          [historic]
                rtp                          [historic]
                udptl                        [ITU-T Rec. T.38 (Section 9)]  
                TCP                          [RFC4145]
                RTP/AVPF                     [RFC4585.txt]
                TCP/RTP/AVP                  [RFC4571]
                RTP/SAVP                     [RFC3711]
                TCP/BFCP                     [RFC4583]
                TCP/TLS/BFCP                 [RFC4583]
                TCP/TLS                      [RFC4572]
                FLUTE/UDP                    [RFC-mehta-rmt-flute-sdp-05.txt]

Until now we just considered RTP/AVP(F) and RTP/SAVP(F) for best effort SRTP. 
The related attributes are a=kmgmt:, a=crypto:, a=rtcp-fb: with their specific values.
Others might be specified in the future.

I think  that TCP/RTP/AVP, TCP and TCP/TLS are worth considering as well for e.g. for T.38 fax.
The related attributes are a=setup:, a=connection:, a=fingerprint: 

What about TCP/BFCP and TCP/TLS/BFCP, which have a completely different context .
The related attributes are a=confid:, a=userid:, a=floorctrl: and a=floorid:

Flute introduces the attributes flute-tsi","flute-ch", "FEC-declaration", "FEC", "FEC-OTI-extension" 
and "content-desc".

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?

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

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

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 12 Feb 2007 17:27:37 +0100

Hi, 

as a follow-up here is a proposal for an ABNF that restricts the defined/allowed values for "a=capar" to those necessary for transport protocol negotiation. 

           a=capar: <att-tr-num> <att-par>
           <att-par> = rtcp-fb-syntax / ; from RFC 4585
                       crypto-syntax /
                       key-mgmt-syntax /  
                       setup-attr / ; from RFC 4145
                       connection-attr / ; from RFC 4145
                       fingerprint-syntax / 
                       floor-control-attribute / ; from RFC 4583
                       confid-attribute / ; from RFC 4583
                       userid-attribute / ; from RFC 4583
                       flute-tsi-line / ; from RFC-mehta-rmt-flute-sdp-05.txt
                       flute-channel-line / ; from RFC-mehta-rmt-flute-sdp-05.txt
                       fec-declaration-line / ; from RFC-mehta-rmt-flute-sdp-05.txt
                       fec-line / ; from RFC-mehta-rmt-flute-sdp-05.txt
                       content-desc-line / ; from RFC-mehta-rmt-flute-sdp-05.txt
                       fec-oti-extension-line /  ; from RFC-mehta-rmt-flute-sdp-05.txt
                       attpar-extension 

                       crypto-syntax = "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params
                                           *(1*WSP session-param) ; from RFC 4568
                       key-mgmt-syntax = "a=" key-mgmt-attribute  ; from RFC 4567
                       fingerprint-syntax = "a=" fingerprint-attribute / ; from RFC 4572

                       attpar-extension =  token 

<att-cap-num> is an integer between 1 and 2^32-1 (both included) used to number the attribute capability 

It is extensible for yet to be defined attributes for yet to be defined transport protocols.
Any extension to the capability negotiation framework should then define its own new attribute that carries attributes specific to that extension like its is currently done for media capabilites.
Any thoughts?

Beware: Even more boring content follows!
The following is the complete IANA list for SDP parameters that I used to produce the ABNF above

Type            SDP Name                     Reference
----            ------------------           ---------
att-field (session level)
                cat                          [RFC4566]
                keywds                       [RFC4566]
                type                         [RFC4566]
                type:broadcast               [RFC4566]
                type:H332                    [ITU Recommendation H.332]
                type:meeting                 [RFC4566]
                type:moderated               [RFC4566]
                type:test                    [RFC4566]
                charset                      [RFC4566]
                charset:iso8895-1            [RFC4566]
                tool                         [RFC4566]
                ipbcp                        [ITU-T Q.1970]
                group                        [RFC3388]
TS:--> None of the above has to be negotiated together with a specifc transport protocol

Type            SDP Name                     Reference
----            ------------------           ---------
att-field (both session and media level)
                recvonly                     [RFC4566]
                sendrecv                     [RFC4566]
                sendonly                     [RFC4566]
                sdplang                      [RFC4566]
                lang                         [RFC4566]
TS:--> None of the above must be negotiated for a specific transport.
                h248item                     [ITU-T H.248.15]
TS:--> The above does not seem to be negotiated for a specific transport.
                sqn                          [RFC3407]
                cdsc                         [RFC3407]				
                cpar                         [RFC3407]
                cparmin                      [RFC3407]
                cparmax                      [RFC3407]
TS:--> The above is out of scope for SDP transport protocol negotiation.
                rtcp-xr                      [RFC-ietf-avt-rtcp-report-extns-06.txt]  ---> already 3611
TS:--> The above does not seem to be negotiated for a specific transport. Who can confirm?
TS:--> The reference above should be RFC3611, this seems to an error in IANA.
                maxprate                     [RFC3890]
TS:--> The above is related to media and should be considered for media capability negotiation
                setup                        [RFC4145]
                connection                   [RFC4145]
TS:--> The above are transport protocol specific and must be included as attributes 
                key-mgmt                     [RFC4567]
TS:--> The above are transport protocol specific and must be included as attribute 
                source-filter                [RFC4570]
TS:--> The above is out of scope for SDP transport protocol negotiation.
                inactive                     [RFC4566]
TS:--> The above is out of scope for SDP transport protocol negotiation.
                fingerprint                  [RFC4572]
                flute-tsi                    [RFC-mehta-rmt-flute-sdp-05.txt]
                flute-ch                     [RFC-mehta-rmt-flute-sdp-05.txt]
                FEC-declaration              [RFC-mehta-rmt-flute-sdp-05.txt]
                FEC-OTI-extension            [RFC-mehta-rmt-flute-sdp-05.txt]
                content-desc                 [RFC-mehta-rmt-flute-sdp-05.txt]
TS:--> The above are transport protocol specific and must be included as attribute 

Type            SDP Name                     Reference
----            ------------------           ---------
att-field (media level only)
                ptime                        [RFC4566]
TS:--> The above is related to media and should be considered for media capability negotiation
                orient                       [RFC4566]
                orient:portrait              [RFC4566]
                orient:landscape             [RFC4566]
                orient:seascape              [RFC4566]
TS:--> The above are transport protocol specific and must be included as attribute 
                framerate                    [RFC4566]
                quality                      [RFC4566]
                rtpmap                       [RFC4566]
                fmtp                         [RFC4566]
TS:--> The above is related to media and should be considered for media capability negotiation
                rtpred1                      [historic; use fmtp as per RFC2198]
                rtpred2                      [historic; use fmtp as per RFC2198]
TS:--> The above is out of scope for SDP transport protocol negotiation.
                T38FaxVersion                [ITU-T Rec. T.38 Annex D]
                T38MaxBitRate                [ITU-T Rec. T.38 Annex D]
                T38FaxFillBitRemoval         [ITU-T Rec. T.38 Annex D]
                T38FaxTranscodingMMR         [ITU-T Rec. T.38 Annex D]
                T38FaxTranscodingJBIG        [ITU-T Rec. T.38 Annex D]
                T38FaxRateManagement         [ITU-T Rec. T.38 Annex D] 
                T38FaxMaxBuffer              [ITU-T Rec. T.38 Annex D] 
                T38FaxMaxDatagram            [ITU-T Rec. T.38 Annex D]
                T38FaxUdpEC                  [ITU-T Rec. T.38 Annex D] 
TS:--> The above is related to media and should be considered for media capability negotiation
                maxptime                     [RFC4566]
TS:--> The above is out of scope for SDP transport protocol negotiation.
                des                          [RFC3312]
                curr                         [RFC3312]
                conf                         [RFC3312]
TS:--> The above is for precondition and out of scope for SDP transport protocol negotiation.
                mid                          [RFC3388]
TS:--> The above is for grouping and out of scope for SDP transport protocol negotiation.
                rtcp                         [RFC3605]
TS:--> The above (explicit RTCP port assignment) is out of scope for SDP transport protocol negotiation.
                rtcp-fb                      [RFC4585]
TS:--> The above are transport protocol specific and must be included as attribute 
                label                        [RFC4574]
TS:--> The above is out of scope for SDP transport protocol negotiation.
                T38VendorInfo                [ITU-T Rec. T.38 Annex D]
TS:--> The above is related to media and should be considered for media capability negotiation
                crypto                       [RFC4568]
TS:--> The above are transport protocol specific and must be included as attribute 
                eecid                        [RFC3108]
                aalType                      [RFC3108] 
                capability                   [RFC3108]
                qosClass                     [RFC3108]
                bcob                         [RFC3108]
                stc                          [RFC3108]
                upcc                         [RFC3108]
                atmQOSparms                  [RFC3108]
                atmTrfcDesc                  [RFC3108]
                abrParms                     [RFC3108]
                abrSetup                     [RFC3108]
                bearerType                   [RFC3108]
                lij                          [RFC3108]
                anycast                      [RFC3108]
                cache                        [RFC3108]
                bearerSigIE                  [RFC3108]
                aalApp                       [RFC3108]
                cbrRate                      [RFC3108]
                sbc                          [RFC3108]
                clkrec                       [RFC3108]
                fec                          [RFC3108]
                prtfl                        [RFC3108]
                structure                    [RFC3108]
                cpsSDUsize                   [RFC3108]
                aal2CPS                      [RFC3108]
                aal2CPSSDUrate               [RFC3108]
                aal2sscs3661unassured        [RFC3108]
                aal2sscs3661assured          [RFC3108]
                aal2sscs3662                 [RFC3108]
                aal5sscop                    [RFC3108]
                atmmap                       [RFC3108]
                silenceSupp                  [RFC3108]
                ecan                         [RFC3108]
                gc                           [RFC3108]
                profileDesc                  [RFC3108]
                vsel                         [RFC3108]
                dsel                         [RFC3108]
                fsel                         [RFC3108]
                onewaySel                    [RFC3108]
                codecconfig                  [RFC3108]
                isup_usi                     [RFC3108]
                uiLayer1_Prot                [RFC3108]
                chain                        [RFC3108]
TS:--> The above (ATM Bearer Connections) is out of scope for SDP transport protocol negotiation.
                floorctrl                    [RFC4583]
                confid                       [RFC4583]
                userid                       [RFC4583]
                floorid                      [RFC4583]
TS:--> The above are transport protocol specific and must be included as attribute 
                FEC                          [RFC-mehta-rmt-flute-sdp-05.txt]
TS:--> The above are transport protocol specific and must be included as attribute 

Kind Regards

Thomas 

> -----Original Message-----
> From: Stach, Thomas 
> Sent: Tuesday, February 06, 2007 3:29 PM
> To: [email-masked]
> Subject: [MMUSIC] SDP Capability Negotation: Should the scope 
> of a=capar:narrowed down to transport protocol negotiation?
> 
> 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.
> Hence it could carry e.g. a=rtpmap as well, which will 
> introduce some ambiguity and unclear semantics in combination 
> with media capability negotiation.
> 
> Now, I wonder if it would be useful to restrict the number of 
> allowed values in the a=capar: attribute when negotiating 
> transport protocol using the a=ctrpr attribute to the 
> necessary subset of attributes.
>  
> I think  that TCP/RTP/AVP, TCP and TCP/TLS are worth 
> considering as well for e.g. for T.38 fax.
> Flute introduces the attributes flute-tsi","flute-ch", 
> "FEC-declaration", "FEC", "FEC-OTI-extension" 
> and "content-desc".
> 
> 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
> The modules could be separately implemented as needed for the 
> specific application of the capabilitiy negotiation framework.
> 
> Comments?
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 12 Feb 2007 17:22:26 -0500

> 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.
> The modules could be separately implemented as needed for the specific application of the capabilitiy negotiation framework.
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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 12 Feb 2007 17:27:15 -0500

> Any extension to the capability negotiation framework should then define its own new attribute that carries attributes specific to that extension like its is currently done for media capabilites.
If I understand your proposal correctly, it has zero forward 
compatibility with new or changed attributes that may be of relevance, 
and that seems like a rather undesirable property for a general 
framework. Let's say we define a "crypto_v2" attribute tomorrow - how 
will that work ?

-- Flemming

---

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

Fleming,
 
again I try to clarify my proposal inline.

________________________________

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: Monday, February 12, 2007 11:27 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, 
		
		as a follow-up here is a proposal for an ABNF that
restricts the defined/allowed values for "a=capar" to those necessary
for transport protocol negotiation. 
		
		           a=capar: <att-tr-num> <att-par>
		           <att-par> = rtcp-fb-syntax / ; from RFC 4585
		                       crypto-syntax /
		  From [email-masked] Tue Feb 13 06:09:19 2007
Content-class: urn:content-classes:message
Subject: RE: [MMUSIC] SDP Capability Negotation: Should the scope
	of	aÊpar:narrowed down to transport protocol negotiation?
Date: Tue, 13 Feb 2007 12:08:26 +0100
From: "Stach, Thomas" <[email-masked]>
To: "Flemming Andreasen" <[email-masked]>
Cc: [email-masked]

This is a multi-part message in MIME format.
Fleming,
 
again I try to clarify my proposal inline.

________________________________

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: Monday, February 12, 2007 11:27 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, 
		
		as a follow-up here is a proposal for an ABNF that
restricts the defined/allowed values for "a=capar" to those necessary
for transport protocol negotiation. 
		
		           a=capar: <att-tr-num> <att-par>
		           <att-par> = rtcp-fb-syntax / ; from RFC 4585
		                       crypto-syntax /
		                       key-mgmt-syntax /  
		                       setup-attr / ; from RFC 4145
		                       connection-attr / ; from RFC 4145
		                       fingerprint-syntax / 
		                       floor-control-attribute / ; from
RFC 4583
		                       confid-attribute / ; from RFC
4583
		                       userid-attribute / ; from RFC
4583
		                       flute-tsi-line / ; from
RFC-mehta-rmt-flute-sdp-05.txt
		                       flute-channel-line / ; from
RFC-mehta-rmt-flute-sdp-05.txt
		                       fec-declaration-line / ; from
RFC-mehta-rmt-flute-sdp-05.txt
		                       fec-line / ; from
RFC-mehta-rmt-flute-sdp-05.txt
		                       content-desc-line / ; from
RFC-mehta-rmt-flute-sdp-05.txt
		                       fec-oti-extension-line /  ; from
RFC-mehta-rmt-flute-sdp-05.txt
		                       attpar-extension 
		
		                       crypto-syntax = "a=crypto:" tag
1*WSP crypto-suite 1*WSP key-params
		                                           *(1*WSP
session-param) ; from RFC 4568
		                       key-mgmt-syntax = "a="
key-mgmt-attribute  ; from RFC 4567
		                       fingerprint-syntax = "a="
fingerprint-attribute / ; from RFC 4572
		
		                       attpar-extension =  token 
		
		<att-cap-num> is an integer between 1 and 2^32-1 (both
included) used to number the attribute capability 
		
		It is extensible for yet to be defined attributes for
yet to be defined transport protocols.
		Any extension to the capability negotiation framework
should then define its own new attribute that carries attributes
specific to that extension like its is currently done for media
capabilites.
		Any thoughts?

	If I understand your proposal correctly, it has zero forward
compatibility with new or changed attributes that may be of relevance,
and that seems like a rather undesirable property for a general
framework. 
	[Stach Thomas] Maybe the proposal above some improvement, but
the syntax above is meant to be extensible using the contruct
"attpar-extension= token". 
	I assumed that unknown attributes in the "a=capar:" lines are
ignored. This needs to be specified in the document. 
	Another case appears, when attributes are received, that are
defined above but are related to transport protocols that are not
implemented by the answerer. 
	Based on the content of creq/csup they should be ignored or
fallback to plain SDP should happen.
	 Let's say we define a "crypto_v2" attribute tomorrow - how will
that work ? 
	[Stach Thomas] In this case the above ABNF must be extended by
the usual means (definition of an additional token, IANA registry)
	
	Does this make sense? 
	
	Regards,
	Thomas 
	
	-- Flemming 
	
	[Stach Thomas] <snip>