Subject: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-01.txt

From: Colin Perkins <[email-masked]>
Date: Mon, 25 Sep 2006 18:39:08 +0100

Thanks for the various comments on the muxing draft. This version  
fixes the easy issues - expect another update in a week or two to  
address the rest.

Colin

Begin forwarded message:
> From: [email-masked]
> Date: 25 September 2006 15:50:01 BDT
> To: [email-masked]
> Subject: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-01.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Multiplexing RTP Data and Control Packets on a Single Port
> 	Author(s)	: M. Westerlund, C. Perkins
> 	Filename	: draft-perkins-avt-rtp-and-rtcp-mux-01.txt
> 	Pages		: 12
> 	Date		: 2006-9-25
> 	
> 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-perkins-avt-rtp-and-rtcp- 
> mux-01.txt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 25 Sep 2006 21:26:31 +0200

Colin and Magnus,
Thanks, the new version covers my concerns by providing a better defined
area of application described in the introduction.

Good!

Gunnar

----------------------------------------------------------------------------
-
Gunnar Hellstrom, Omnitor
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 25, 2006 4:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-01.txt

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-perkins-avt-rtp-and-rtcp-mux-01.tx
t

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.

---

From: Randell Jesup <[email-masked]>
Date: Mon, 25 Sep 2006 16:08:22 -0400

Colin Perkins <[email-masked]> writes:

>Thanks for the various comments on the muxing draft. This version  fixes
>the easy issues - expect another update in a week or two to  address the
>rest.

> http://www.ietf.org/internet-drafts/draft-perkins-avt-rtp-and-rtcp-mux-01.txt
...
>      Note: since all RTCP packets MUST be sent as compound packets
>      beginning with an SR or an RR packet ([1] Section 6.1), one might
>      wonder why RTP payload types other than 72 and 73 are prohibited
>      when multiplexing RTP and RTCP.  This is done to ensure robustness
>      against broken nodes which send non-compliant RTCP packets, which
>      might otherwise be confused with multiplexed RTP packets.

The only RTCP payload types that can conflict with RTP payload types are RR
and SR.  Since this draft requires that the receiver understand it (or per
the draft the answer must be rejected), it's also reasonable to assume that
a receiver that implements the draft not be broken with regards to RTCP
formation.  I don't see that these restrictions buy us anything given that
requirement.  If we were trying to interoperate with implementations that
don't know about this draft (i.e. don't 'reject' the answer), then perhaps
the restriction might buy us something (though I'd still be tempted to
argue against it).

Are there any known implementations that don't start RTCP with SR/RR?  
Are they actually in any serious use?

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

>   The bandwidth required for a multiplexed stream comprises the session
>   bandwidth of the RTP stream, plus the bandwidth used by RTCP.  In the
>   usual case, the RTP session bandwidth is signalled in the SDP "b=AS:"
>   line, and the RTCP traffic is limited to 5% of this value.  Any QoS
>   reservation SHOULD therefore be made for 105% of the "b=AS:" value.
>   If a non-standard RTCP bandwidth fraction is used, signalled by the
>   SDP "b=RR:" and/or "b=RS:" lines [11], then any QoS reservation
>   SHOULD be made for bandwidth equal to (AS + RS + RR), taking the RS
>   and RR values from the SDP answer.

This will cause problems, since the QoS-reserving may well occur in
mid-stream devices that don't know about this draft/RFC, and may not know
about it for a long time.  These devices exist already, and will reserve
bandwidth for RTP according to 100% of b=AS, not 105%.  It may well work
anyways, but there's no guarantee.

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.

As for RR/RS, I's say include them, and add their bandwidth to the b=AS
line before sending it.  Knowledgeable devices will know RS/RR is included
in the AS total, and will just not bother reserving separate bandwidth for
RTCP; non-knowledgeable devices will over-reserve (AS (which includes
RS/RR) for RTP, RS/RR for RTCP), but will work.

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

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Wed, 27 Sep 2006 13:34:39 -0700

> RS/RR) for RTP, RS/RR for RTCP), but will work.

RTP media path can be different from the signaling path. RS and RR are
meant for RTP entities. I am not sure what you mean by knowledgeable
devices in RTP-path. Are you referring to RTP Mixers and Translators? 

- - - - - - - - - - - - - - - - - -
Harikishan Desineni
Qualcomm Inc.,
mailto:[email-masked]
> 
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga
OS
> team

---

From: Randell Jesup <[email-masked]>
Date: Wed, 27 Sep 2006 17:20:39 -0400

"Desineni, Harikishan" <[email-masked]> writes:
>> >   The bandwidth required for a multiplexed stream comprises the
>> >   session bandwidth of the RTP stream, plus the bandwidth used by
>> >   RTCP.  In the usual case, the RTP session bandwidth is signalled in
>> >   the SDP "b=AS:" line, and the RTCP traffic is limited to 5% of this
>> >   value.  Any QoS reservation SHOULD therefore be made for 105% of the
>> >   "b=AS:" value.  If a non-standard RTCP bandwidth fraction is used,
>> >   signalled by the SDP "b=RR:" and/or "b=RS:" lines [11], then any QoS
>> >   reservation SHOULD be made for bandwidth equal to (AS + RS + RR),
>> >   taking the RS and RR values from the SDP answer.
>> 
>> mid-stream devices that don't know about this draft/RFC, and may not
>> know about it for a long time.  These devices exist already, and will
>> reserve bandwidth for RTP according to 100% of b=AS, not 105%.  It may
>> well work anyways, but there's no guarantee.
>> 
>> line before sending it.  Knowledgeable devices will know RS/RR is
>> included in the AS total, and will just not bother reserving separate
>> bandwidth for RTCP; non-knowledgeable devices will over-reserve (AS
>> (which includes RS/RR) for RTP, RS/RR for RTCP), but will work.
>

For example, a cable company may reserve DOCSIS QoS bandwidth (at/via the
CMTS - the cable company's end of your cable modem connection) for a media
stream when it (the SIP proxy) sees the SIP INVITE with a b=AS value.

DOCSIS upstream (and downstream) bandwidth is shared by typically 50-500
homes, but it supports reservations.  If they see b=AS:200, they may well
reserve 200Kbps for that stream (and 10kbps for the an RTCP port you may
not be using), and if you try to push 210kbps through it, they may delay
and/or drop some of your packets.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 27 Sep 2006 23:37:34 +0200

On 25 Sep 2006, at 22:08, Randell Jesup wrote:
>> fixes

I agree that this restriction doesn't buy us much, but I don't think  
it harms either, and extra sanity checks are always a good thing  
(especially since the requirement to send all RTCP packets as  
compound packets is often misunderstood).

> Are they actually in any serious use?

RFC 2032 could be (mis)interpreted as allowing FIR and NACK packets  
to be sent as non-compound packets.

> $500 to complete the call (ref: sipping early-media example draft),  

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?

>> session

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.

Colin