Re: [MMUSIC] Difficulties accepting and rejecting with bundling

"Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> Mon, 11 March 2013 18:21 UTC

Return-Path: <richard.ejzak@alcatel-lucent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E9021F8CD2 for <mmusic@ietfa.amsl.com>; Mon, 11 Mar 2013 11:21:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZZ6qUZfgEaQ for <mmusic@ietfa.amsl.com>; Mon, 11 Mar 2013 11:21:56 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id CBD5721F8CCB for <mmusic@ietf.org>; Mon, 11 Mar 2013 11:21:55 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BILVZu028709 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 19:21:41 +0100
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 19:21:39 +0100
Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.224]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 11 Mar 2013 14:21:37 -0400
From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
To: "Dale R. Worley" <worley@ariadne.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Difficulties accepting and rejecting with bundling
Thread-Index: AQHOHgF3Mop2zAIAB0ia8HPK7HA92Zignn4A
Date: Mon, 11 Mar 2013 18:21:36 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EB73DA@US70TWXCHMBA12.zam.alcatel-lucent.com>
References: <201303110237.r2B2btIS180463@shell01.TheWorld.com>
In-Reply-To: <201303110237.r2B2btIS180463@shell01.TheWorld.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2013 18:21:58 -0000

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Dale R. Worley


> it does not see media.  (It does not suffice for the answerer to
> provide a null transport address and non-zero port for the MD, or for
> the answerer to send "a=inactive", as an intermediate entity may see
> the MD as being accepted and expect the offerer to send RTCP.)
> 

Considering the following text from RFC 3264:

"Of course, when used, the port number MUST NOT be zero, which would specify that the stream has been disabled.  An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer."

There is no ambiguity here about the meaning of zero port.

While this text could be interpreted to not specifically preclude the peer that indicates an unspecified address from sending RTCP to the peer indicating a valid address, this seems really far-fetched to me.  Sending this RTCP would be pointless and wasteful since by definition it would have nothing to report on and there is no possibility to receive reports.  

If would be nice to eliminate this ambiguity by ending the quoted sentence "...neither RTP nor RTCP should be sent to either peer."

The text also says that the peer indicating an unspecified address "...doesn't know the addresses and ports at the time..."  Again, it seems like a real stretch to assume that the peer can send RTCP if it doesn't have an address or port available for receipt of RTP.

Richard