Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-and-rtcp-mux-00.txt

From: [email-masked]
Date: Mon, 02 Oct 2006 10:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: Multiplexing RTP Data and Control Packets on a Single Port
	Author(s)	: C. Perkins, M. Westerlund
	Filename	: draft-ietf-avt-rtp-and-rtcp-mux-00.txt
	Pages		: 12
	Date		: 2006-10-2
	
This memo discusses issues that arise when multiplexing RTP data
packets and RTP control protocol (RTCP) packets on a single UDP port.
It updates RFC 3550 to describe when such multiplexing is, and is
not, appropriate, and explains how the Session Description Protocol
(SDP) can be used to signal multiplexed sessions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-and-rtcp-mux-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-avt-rtp-and-rtcp-mux-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtp-and-rtcp-mux-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Mon, 02 Oct 2006 12:13:39 -0400

>>>  If the answer contains an "a=rtcp:" attribute, but that attribute
>>>  specifies a different port for RTCP than for RTP, then the answer
>>>  MUST be rejected, and the session re-negotiated using separate RTP
>>>  and RTCP ports.
>>
>> The answer cannot generally be 'rejected'; the session has been created
>> already (offer + answer).  You can either end the session (BYE/ CANCEL)
>> and start a new one (which causes serious problems - ringing, forking,
>> etc) or you can renegotiate the session (re-INVITE/UPDATE).
>>
>> This also means that you have to deal with media until any renegotiation
>> occurs.  If you kill the session, realize that early media may have
>> already occurred, forking may have been resolved, the user may have
>> agreed to pay $500 to complete the call (ref: sipping early-media example
>> draft), etc, etc.
>
>Yep - this is already on my list of things to clarify in the next  
>revision. I'm not sure there is a solution other than "deal with  
>broken RTCP until you can re-negotiate" though?

BTW, I should note that a quick re-reading of RFC 3605 doesn't contain any
stipulation that that the port be different than the RTP port, so this
draft wouldn't violate RFC 3605 (and a 3605 implementation SHOULD
transparently respond to signalling proposed by the draft by sending the
RTCP to the RTP port).

Possible answers: 
1) Don't require 'rejection' or renegotiation.  In most cases, if the
   answerer supports a=rtcp but not this spec, then rtcp will very likely
   work anyways.  You won't know for sure unless/until you get RTCP data on
   the RTP port (since support for RFC 3605 doesn't mean you have to insert
   it in replies unless you need to).

   As for those that don't support a=rtcp, handle it exactly as you would
   handle such an answerer under RFC 3605, which is to say entirely up to
   the implementation - for some reason, RFC 3605 doesn't even mention the
   issue.  Probably because in most cases if the answerer doesn't support
   it, there's _nothing_ you can do to solve the problem.  In our case
   here, we might be able to get RTCP running on the odd port; we could say
   in that case the implementation "SHOULD try to receive RTCP data on the
   odd port of the pair if possible", which might involve a
   renegotation/restun/reICE - but you may well be out of luck no matter
   what.

2) Require a new a= value to indicate support for this spec by the
   answerer.  This solves the "wait and see" issue above, and if you want
   to renegotiate/etc you can do so immediately (though media is already
   flowing).  This is distinct from the case in the draft in that it
   doesn't require the receiver to demux if it doesn't want to, which is
   impossible in the draft since requesting rtp=rtcp is a signal back to
   the caller.

3) Require a new a= value to request (and acknowledge) the request
   (a=rtcpmux).  Similar to 2, avoids problems with ambiguity about
   support.  You lose the ability to transparently cause older (RFC
   3605-supporting) implementations to send you muxed RTP/RTCP data -
   this is a minus to me, though the draft as per above loses that
   advantage anyways by requiring "rejection" of the answer.

My preference is for #2.

>> It's much safer to increase the b=AS value instead.  Any intermediary
>> device that understands the draft won't be confused by this, and devices
>> that don't understand the draft are more likely to work.
>
>RFC 4566 explicitly states that a "b=AS:" is the RTP session  
>bandwidth, which excludes RTCP. I understand your reasoning, but I  
>don't think we can make this change without breaking compatibility.

I really think that this might cause problems for existing QoS-enabled
channels that hook into or sniff the signalling.  You suggest it will break
compatibility - what device will get broken?  Worst case I can see is a
channel allocating QoS for both RTP+RTCP on one port, and RTCP on another
(though I suspect most QoS devices don't allocate for RTCP at all).  That's
actually correct, with some wasted bandwidth, and until the call is
completed you actually don't know you won't need the RTCP port bandwidth
anyways.  And I don't see that as a problem.  A device aware of this spec
won't have a problem, and a device unaware of this should just do the right
thing if we include it in b=AS.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]