Subject: [MMUSIC] Signalling transport protocols in SDP

From: Colin Perkins <[email-masked]>
Date: Sun, 18 Mar 2007 13:02:09 +0100

SDP media lines are defined as:

	m=<media> <port> <proto> <fmt> ...

where <media> is a top-level media type, <proto> is the transport  
protocol, and <fmt> maps, directly or indirectly, to a list of media- 
subtypes. This allows to signal a connection, using transport  
protocol <proto>, to convey several media formats sharing a common  
top-level media type. For example, it is possible to signal an RTP/ 
AVP session using two different audio formats, but not one that can  
transport both audio and video.

This works well for RTP, since the limitations of SDP match those of  
RTP, but is not suited for transport protocols which can naturally  
convey multiple top-level media types. This has led to several  
proposals which misuse SDP:

1) In draft-ietf-simple-message-sessions-19.txt, SDP is used to  
negotiate MSRP sessions using "m=message 12763 TCP/MSRP *" to  
indicate arbitrary content over MSRP (with the actual content  
negotiated using MSRP). This conflicts with the usual SDP semantics,  
which indicate a TCP/MSRP connection conveying arbitrary subtypes of  
the message top-level media type.

2) In draft-saito-mmusic-sdp-ike-00.txt, SDP is used to negotiate an  
IPSec VPN with IKE, using "m=application 9500 UDP IKE". According to  
SDP semantics, this should represent a UDP flow conveying media of  
type "application/IKE", however.

3) In RFC 4583, SDP negotiates BFCP using "m=application 50000 TCP/ 
TLS/BFCP *". This should indicate an arbitrary subtype of  
"application" conveyed using BFCP; what is probably intended is to  
convey "application/BFCP" data over TCP/TLS (which would use  
"m=application 50000 TCP/TLS BFCP").

The last example can likely be regarded as a bug that we must work  
around, but the others seem to indicate a real limitation of SDP: it  
can signal a <proto> that transports arbitrary sub-types of a top- 
level media type, but it cannot signal a <proto> that transports data  
of an arbitrary top-level media type.

A possible fix, if this limitation is considered important, would be  
to allow "*" for the media type. This would give something like:

	m=* 12763 TCP/MSRP *
and	m=* 9500 UDP/IKE *

for the above cases, which seems to better reflect the intent.

Comments?

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

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