Re: [MMUSIC] Difficulties accepting and rejecting with bundling

"Ejzak, Richard P (Richard)" <> Wed, 13 March 2013 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1B9721F8D22 for <>; Wed, 13 Mar 2013 12:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.674
X-Spam-Status: No, score=-9.674 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4zcPeH9eWWEz for <>; Wed, 13 Mar 2013 12:42:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 201A021F8D1B for <>; Wed, 13 Mar 2013 12:42:42 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id r2DJgQNF003095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Mar 2013 14:42:27 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id r2DJg9RD024908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Mar 2013 14:42:26 -0500
Received: from ([]) by ([]) with mapi id 14.02.0247.003; Wed, 13 Mar 2013 15:42:17 -0400
From: "Ejzak, Richard P (Richard)" <>
To: Suhas Nandakumar <>, "Dale R. Worley" <>
Thread-Topic: [MMUSIC] Difficulties accepting and rejecting with bundling
Thread-Index: AQHOHgF3Mop2zAIAB0ia8HPK7HA92Zignn4AgABqlJmAAATFgIAAMN0dgAMM/QD//71iUA==
Date: Wed, 13 Mar 2013 19:42:17 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F36EB8C95US70TWXCHMBA12z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
Cc: "" <>
Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling
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: Wed, 13 Mar 2013 19:42:43 -0000

The direction attribute is one that needs to be preserved for each m line to indicate direction of the media associated with that m line.  It is just not available for other purposes.  Furthermore, inactive does not disable ICE or RTCP, which would still be expected to proceed.

From: Suhas Nandakumar []
Sent: Wednesday, March 13, 2013 2:38 PM
To: Dale R. Worley
Cc: Ejzak, Richard P (Richard);
Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling

I am just curios ... instead of playing with connection address and port numbers for indicating accepting/rejecting a m=line in BUNDLE O/A, would making a particular m=line direction inactive make things simpler ....
since for m=lines with direction as inactive would mean no ICE setup , no reject port needed , no resource allocation on intermediary(?)

Any thoughts ?

On Mon, Mar 11, 2013 at 6:02 PM, Dale R. Worley <<>> wrote:
> From: "Ejzak, Richard P (Richard)" <<>>
> This is the only compatibility concern identified with the
> asymmetric use of the unspecified address, but this concern is
> clearly misplaced for rtcweb applications where ICE and consent are
> mandatory.
I'm not limiting my attention to WebRTC only.  Even in situations
where WebRTC is gatewayed to existing SIP infrastructure these
problems appear.  If we restrict ourselves to WebRTC, then we have
even more freedom, and in that case, I'd simply remove the rule
regarding rejects MDs as members of groups.

mmusic mailing list<>