IETF Logo Mail Archive

Re: [MMUSIC] 0.0.0.0 address in draft-rescorla-mmusic-ice-trickle-01

"Dan Wing" <dwing@cisco.com> Fri, 26 October 2012 01:03 UTC

Return-Path: <dwing@cisco.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 9BA3B21F8672 for <mmusic@ietfa.amsl.com>; Thu, 25 Oct 2012 18:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.588
X-Spam-Level:
X-Spam-Status: No, score=-110.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EGw4ySAr3lj for <mmusic@ietfa.amsl.com>; Thu, 25 Oct 2012 18:03:43 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C773E21F8620 for <mmusic@ietf.org>; Thu, 25 Oct 2012 18:03:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2113; q=dns/txt; s=iport; t=1351213423; x=1352423023; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=9fLtrBwz8H4ck7V0abbxiTdmLVg2v2Ff6foK12mWKVw=; b=FtxLhYv3VHYShA3jddrSUyJYhK7js+fil8AqKuLM2kkc3/Kupor9XLqQ BVJDhGBNrRWqcoI8sG9Cq0s9Ff+3YF/jXUaPWM/O2JgP2QzHIn0VRUzQM b9qGLGr+2IGJbB3w7C7naLFp0si96MesHuW2Qml+GnR7LPMSkIJH/RfTq s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAAfhiVCrRDoJ/2dsb2JhbABEwjWBCIIeAQEBAwEBAQEFAggBJzQQBwEDAgkRBAEBKAcZDh8JCAIEARILBRKHXAUMnVqgHYthhm0DiFyFFYgFgReNO4Frgw8
X-IronPort-AV: E=Sophos;i="4.80,650,1344211200"; d="scan'208";a="59205506"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 26 Oct 2012 01:03:43 +0000
Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9Q13hhR031906; Fri, 26 Oct 2012 01:03:43 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Matthew Kaufman' <matthew@matthew.at>, mmusic@ietf.org
References: <5089BFD6.5070109@matthew.at>
In-Reply-To: <5089BFD6.5070109@matthew.at>
Date: Thu, 25 Oct 2012 18:03:43 -0700
Message-ID: <0b3001cdb315$be747240$3b5d56c0$@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLMrXEBLWMzMhvy8/ikuAnrOWlIwJXM0Dnw
Content-Language: en-us
Subject: Re: [MMUSIC] 0.0.0.0 address in draft-rescorla-mmusic-ice-trickle-01
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: Fri, 26 Oct 2012 01:03:44 -0000

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Matthew Kaufman
> Sent: Thursday, October 25, 2012 3:40 PM
> To: mmusic@ietf.org
> Subject: [MMUSIC] 0.0.0.0 address in draft-rescorla-mmusic-ice-trickle-
> 01
> 
> "In some cases, agents may choose to just send an offer that the remote
> party would reject as invalid unless it supports trickling. One such
> example would be an offer with no ICE candidates and an invalid default
> address (e.g. 0.0.0.0)."
> 
> Is there in fact evidence that some/most/all existing SDP-parsing SIP
> applications will in fact reject c= (and a=rtcp) lines that contain
> 0.0.0.0 with an appropriate SDP-rejecting answer, rather than just
> answering affirmatively and attempting to send the media packets there?

By my read, they violate the last paragraph of RFC3264 Section 8.4,
http://tools.ietf.org/html/rfc3264#section-8.4, which says:

   RFC 2543 [10] specified that placing a user on hold was accomplished
   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and breaks
   with connection oriented media.  However, it can be useful in an
   initial offer when the offerer knows it wants to use a particular set
   of media streams and formats, but doesn't know the addresses and
   ports at the time of the offer.  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.

-d

> If we can't confirm this to be the case, this is an inappropriate
> "negotiation" mechanism and the spec needs to get a little more concrete
> about it.
> 
> Matthew Kaufman
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

v2.23.0 | Report a Bug | By Email