Re: [MMUSIC] [rtcweb] Is bundle just a port override? (Dale R. Worley) Fri, 22 March 2013 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E38DA21F900E for <>; Fri, 22 Mar 2013 12:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.775
X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=-0.995, BAYES_00=-2.599, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pCE8fUR1Y9vb for <>; Fri, 22 Mar 2013 12:29:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 47AB221F8FDD for <>; Fri, 22 Mar 2013 12:29:05 -0700 (PDT)
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r2MJShWs016761; Fri, 22 Mar 2013 15:28:46 -0400
Received: from ( []) by (8.13.6/8.12.8) with ESMTP id r2MJShVW956659; Fri, 22 Mar 2013 14:28:43 -0500 (EST)
Received: (from worley@localhost) by (8.13.6/8.13.6/Submit) id r2MJShtu960817; Fri, 22 Mar 2013 15:28:43 -0400 (EDT)
Date: Fri, 22 Mar 2013 15:28:43 -0400
Message-Id: <>
To: "Mo Zanaty (mzanaty)" <>
In-reply-to: <> (
References: <> <> <> <> <> <> <>
Subject: Re: [MMUSIC] [rtcweb] Is bundle just a port override?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Mar 2013 19:29:06 -0000

> From: "Mo Zanaty (mzanaty)" <>
> Your bundle alternatives (and Richard's) also work fine with a simple
> attribute without complex grouping semantics.
> Offer to mux audio and video on the same port:
> m=audio 10000 RTP/AVP 0
> m=video 10002 RTP/AVP 31
> a=port 10000
> i=I really want 10000, but lied on the m-line for fear of confusing
>     you. Confused yet?
> Answer supports the port override attribute and agrees to mux audio and video:
> m=audio 40000 RTP/AVP 0
> m=video 0 RTP/AVP 31         <-- Dale's variant to answer with port 0
> a=port 40000
> audio and video ports are 10000<->40000.

Well, the analysis depends on exactly how "a=port" works.

Option 1A:  "a=port" specifies the port number for the packets.

The difficulty with this is that, at the time the offer is made, we
don't actually know what port number (or IP address) will be used,
because (commonly) ICE will be used to negotiate the transport
association, and "a=port" doesn't provide any way to specify ICE

Worse, we don't want the video m= line to have perform an ICE
negotiation regarding "port 40000", we want the video m= line to
utilize the *same* ICE negotiation that the audio m= line will have.

So what we really want "a=port" to do is:

Option 1B:  "a=port" is a pointer to another media description, and the
packets from this media description will be multiplexed on the
transport association for the other media description.

That is, it's an indirection mechanism.  The question is how to
organize the indirection?  And the most pleasant choice is to use the
grouping mechanism that we already have.

Once we've decided that media descriptions should have a pointer to
another media description that will carry its packets if bundling is
negotiated, there are two main choices:

Option 2A:  One of the constituent media descriptions, the "master",
will be used to carry the bundled media.

Option 2B:  There is a separate "bundle" media description that
describes the bundled media.

2B has the advantage that it allows presenting an SDP description for
the bundle transport flow *as a whole*, while still presenting an SDP
description for each of the constituent media descriptions.  Otherwise
it becomes difficult to, for instance, specify the bandwidth or QoS of
the "master" constituent media flow independently of the bandwidth or
QoS of the entire bundle media flow.