Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-11

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Feb 2017 08:46:01 +0000

Hi,

Based on the comments from Ekr, I've submitted a new version of draft-mux-exclusive.

The SDP 'rtcp-mux-only' attribute is now only allowed in SDP offers.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 17 February 2017 10:44
To: [email-masked]
Cc: [email-masked]
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-11.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control of the IETF.

        Title           : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP
        Author          : Christer Holmberg
	Filename        : draft-ietf-mmusic-mux-exclusive-11.txt
	Pages           : 12
	Date            : 2017-02-17

Abstract:
   This document defines a new SDP media-level attribute, 'rtcp-mux-
   only', that can be used by an endpoint to indicate exclusive support
   of RTP/RTCP multiplexing.  The document also updates RFC 5761, by
   clarifying that an offerer can use a mechanism to indicate that it is
   not able to send and receive RTCP on separate ports.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-11

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Feb 2017 12:04:50 -0500

> The SDP 'rtcp-mux-only' attribute is now only allowed in SDP offers.

With the new text the offerer never knows if the answerer supports 
rtcp-mux-only. He only knows that the answerer supports rtcp-mux.

I don't think this matters for that O/A, but it might matter for 
subsequent O/As.

At the least, I think section 4.5 is now confusing. For m-lines 
previously negotiated with rtcp-mux-only, must the side that is sending 
a new offer include the attribute again, while the side that is 
answering must *not* include it? (Note the implications when the new 
offer is in the opposite direction from the original one.) I think this 
will be somewhat of a pain - perhaps more pain than simply always 
including it in all offers and answers.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 17 Feb 2017 13:10:11 -0500

On Fri, Feb 17, 2017 at 12:04 PM, Paul Kyzivat <[email-masked]>
wrote:

> At the least, I think section 4.5 is now confusing. For m-lines previously
> negotiated with rtcp-mux-only, must the side that is sending a new offer
> include the attribute again, while the side that is answering must *not*
> include it? (Note the implications when the new offer is in the opposite
> direction from the original one.) I think this will be somewhat of a pain -
> perhaps more pain than simply always including it in all offers and answers.
>

Based comments from Ekr, the offerer never cares if the answerer supports
rtcp-mux-only. It only cares that answerer supports rtcp-mux. The whole
purpose of rtcp-mux-only attribute is to promise to all the parties on the
signaling path, such as SBC, that offerer will not accept an answer without
rtcp-mux. Based on this promise SBC does not need to allocate an RTCP port
for the duration of offer transaction. There is no difference here between
the initial offer and offers in session updates -- in either case without
rtcp-mux-only attribute SBC would need to allocate an extra port during the
session update transaction. So, it does not matter what was negotiated
before in the session, every offer in every direction must include
rctp-mux-only if offerer is not willing to accept the answer without
rtcp-mux, and should not include rtcp-mux-only if offerer allocated the
RTCP port and is willing to accept an answer without mux. It makes no sense
to include rtcp-mux-only in the answer, since if it includes rtcp-mux
attribute, it is enough of the indication that RTP and RTCP are muxed and
no extra port is needed.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Feb 2017 11:43:43 -0800

> rtcp-mux-only. He only knows that the answerer supports rtcp-mux.

Yes.

I don't think this matters for that O/A, but it might matter for subsequent
> O/As.

Why?

-Ekjr

>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>>