From fandreas@cisco.com Thu Sep 6 13:37:14 2012 Return-Path: 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 2F16521F8787 for ; Thu, 6 Sep 2012 13:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 wl7LpAAYlebn for ; Thu, 6 Sep 2012 13:37:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 022A221F8762 for ; Thu, 6 Sep 2012 13:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22602; q=dns/txt; s=iport; t=1346963833; x=1348173433; h=message-id:date:from:mime-version:to:cc:subject; bh=p0YfNFQdZ2K8zS2VKMetM3mQSgmhmGqgJVT8TfGrGAE=; b=IAl5MSfGuNkPIdiIaHH+y9anqKXtHC//o4/7iuZGpBAAY/73AZCVF2ct DsqiduwkuiiTaEbD05QKlZhV+QkDH5rhI4zLdHbRpFLfk5ShlCdCGxGti lbYxZ1afkCeiPMZFpyaSaxuZ8I+wRqMf/BuRGrvMZbm57MaTn3PSBzTFA M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACMJSVCtJXG+/2dsb2JhbABFu02BB4I5AQpbATwWARcDAgECAUsNAQcBAQUZh24LmySgK4sRhkUDlVqBFI0hgWeCfw X-IronPort-AV: E=Sophos;i="4.80,381,1344211200"; d="scan'208,217";a="119063653" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 06 Sep 2012 20:37:04 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q86Kb3Kd009696; Thu, 6 Sep 2012 20:37:03 GMT Message-ID: <5049096F.7080908@cisco.com> Date: Thu, 06 Sep 2012 16:37:03 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------010606090503070806010506" Cc: draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Subject: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org 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: Thu, 06 Sep 2012 20:37:14 -0000 This is a multi-part message in MIME format. --------------010606090503070806010506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is to announce a 2 week Working Group Last Call for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt as Proposed Standard. Please review and provide any comments you may have on the document by September 21, 2012. Comments should be sent to the document authors and the MMUSIC WG list. Thanks Flemming Draft Info: This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Robert R. Gilman Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Pages : 19 Date : 2012-08-27 Abstract: SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=' line), connection data ('c=' line), and titles ('i=' line for each session or media). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-caps-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --------------010606090503070806010506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is to announce a 2 week Working Group Last Call for

     draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt

as Proposed Standard. Please review and provide any comments you may have on the document by September 21, 2012. Comments should be sent to the document authors and the MMUSIC WG list.


Thanks

       Flemming




Draft Info:
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP)
	Author(s)       : Miguel A. Garcia-Martin
                          Simo Veikkolainen
                          Robert R. Gilman
	Filename        : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
	Pages           : 19
	Date            : 2012-08-27

Abstract:
   SDP has been extended with a capability negotiation mechanism
   framework that allows the endpoints to negotiate transport protocols
   and attributes.  This framework has been extended with a media
   capabilities negotiation mechanism that allows endpoints to negotiate
   additional media-related capabilities.  This negotiation is embedded
   into the widely-used SDP offer/answer procedures.

   This memo extends the SDP capability negotiation framework to allow
   endpoints to negotiate three additional SDP capabilities.  In
   particular, this memo provides a mechanism to negotiate bandwidth
   ('b=' line), connection data ('c=' line), and titles ('i=' line for
   each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-caps-01


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

--------------010606090503070806010506-- From internet-drafts@ietf.org Sun Sep 9 18:54:30 2012 Return-Path: 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 32E7F21F8615; Sun, 9 Sep 2012 18:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 2YwyNaCErmIh; Sun, 9 Sep 2012 18:54:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9632521F85ED; Sun, 9 Sep 2012 18:54:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120910015429.1014.9007.idtracker@ietfa.amsl.com> Date: Sun, 09 Sep 2012 18:54:29 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-23.txt X-BeenThere: mmusic@ietf.org 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: Mon, 10 Sep 2012 01:54:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : An Extension to the Session Description Protocol (SDP) a= nd Real-time Transport Protocol (RTP) for Media Loopback Author(s) : Hadriel Kaplan Kaynam Hedayat Nagarjuna Venna Paul E. Jones Nathan Stratton Filename : draft-ietf-mmusic-media-loopback-23.txt Pages : 33 Date : 2012-09-09 Abstract: The wide deployment of Voice over IP (VoIP), Text and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media types and attributes, which enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video over IP performance metrics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-23 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-loopback-23 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From martin.thomson@gmail.com Wed Sep 12 17:07:27 2012 Return-Path: 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 C534F21F8475 for ; Wed, 12 Sep 2012 17:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] 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 yBXF6b7GqWOc for ; Wed, 12 Sep 2012 17:07:27 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 158E821F846B for ; Wed, 12 Sep 2012 17:07:26 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so2189442wib.13 for ; Wed, 12 Sep 2012 17:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KfqL5tpspXdePBvJJm86G+nCRQ9nIdJmWSKPqx57Lrc=; b=nNcVUv2ntKwQVCS4yyWfUHhUDCGyr2aHayZqI3i23KKnXLqHVm70XcyuA2B1L2Rv/Q 6p8s/GOohjlmqNZLiCP5RSnRt0DaphhfX5gyKnqrEwcIRqCrkn6T1SMj/f6bS9ZIbTXC 9WSXG/z1gqDld6RjKw4zHYVEaetH5WJekZJtbPpcKu2j9gQw7zOZbBRfEqj0fmm05wYK JlMCYapBIwvMPtMVZr+C6MjWbG6VUa4yWl9pwqgOPIIoCZEGYNghBfiQbHCSTSpxlGTd ccVuHxj2axMiit1IAYeXUX0v1I9xaRsizWWcG+3BYWjMbqflL+G0ETRdyYhiTl3HEJQS VTeQ== MIME-Version: 1.0 Received: by 10.216.135.217 with SMTP id u67mr110214wei.115.1347494846254; Wed, 12 Sep 2012 17:07:26 -0700 (PDT) Received: by 10.180.96.9 with HTTP; Wed, 12 Sep 2012 17:07:26 -0700 (PDT) Date: Wed, 12 Sep 2012 17:07:26 -0700 Message-ID: From: Martin Thomson To: mmusic@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [MMUSIC] Comment on draft-wing-mmusic-ice-mobility-01 X-BeenThere: mmusic@ietf.org 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: Thu, 13 Sep 2012 00:07:27 -0000 I think that this is a worthwhile problem to solve. I have a concern about the mechanism. Specifically: 3. If this interface is the only suitable interface for media (that is, other suitable interfaces have been lost), then the connectivity check from the previous step SHOULD also include the USE-CANDIDATE attribute to signals an aggressive nomination (see Section 2.6 of [RFC5245]), and media MAY immediately begin flowing over that interface. This assumes that the IP:port pair that was previously in use reaches the same host from the new interface. I understand the desire to send straight away, and requiring aggressive nomination even where it is not normally used is reasonable, but sending prior to a connectivity check is not a good idea. Note: Step 4 of the same procedure is initiated on the *other* ICE peer. That is, the one that is not suffering a mobility event. That is very much unclear from the text. --Martin From miguel.a.garcia@ericsson.com Thu Sep 13 00:18:35 2012 Return-Path: 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 2732B21E8043 for ; Thu, 13 Sep 2012 00:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 buSdy2xlj2XX for ; Thu, 13 Sep 2012 00:18:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 690FF21E8040 for ; Thu, 13 Sep 2012 00:18:34 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-61-505188c98c69 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BA.78.17130.9C881505; Thu, 13 Sep 2012 09:18:33 +0200 (CEST) Received: from [159.107.24.230] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Thu, 13 Sep 2012 09:18:33 +0200 Message-ID: <505188C7.1080805@ericsson.com> Date: Thu, 13 Sep 2012 09:18:31 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic , Flemming Andreasen Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFJMWRmVeSWpSXmKPExsUyM+Jvre7JjsAAg1cHxSzeX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlXFlvW9BF1vF+gnfmBoYW1i7GDk5JARMJLau vcQMYYtJXLi3ng3EFhI4xSixtZeji5ELyF7DKLFg2T8mkASvgLbErjVfGUFsFgFVia0Nq8Ea 2ATMJVo3bmQHsUUFgiXObdzGBlEvKHFy5hMWEFtEwFXi8cvJYLYw0OLDi46C1TAL2EpcmHOd BcKWl9j+dg4zxBGaEpNvLmWewMg3C8moWUhaZiFpWcDIvIpRODcxMye93FwvtSgzubg4P0+v OHUTIzC8Dm75bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw epou1XLcctkpzcb4te0z15YO9u32XjlFvhGBP5avUNrmXHHlTNBfH/GUK55S70petV168+uk 5lVbreYrS3Z3rJzteDpLcM2GINkttdNvxqecrn1+5+2ujbu3FF7UPsDNVu7zVP8jl9gNblsF wcvf9xmf/qQw6fCtcMFfscdDMg9HsERX/mQIUGIpzkg01GIuKk4EAL2UFRf9AQAA Subject: [MMUSIC] WG Poll for consensus on duplicated streams X-BeenThere: mmusic@ietf.org 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: Thu, 13 Sep 2012 07:18:35 -0000 At the last IETF meeting we had presentation of two drafts, both related to the expression of duplicated streams in SDP. We noticed there was support to progress these drafts. These drafts are complementary to work going on in AVTEXT, where there is a normative dependency. These are the documents: http://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ http://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/ We would like to poll the working group for adopting these two documents as WG items, once we get approved milestones. Please indicate whether you support or not this new work within the next 5 working days. Flemming and Miguel (co-chairs). /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From emil@sip-communicator.org Thu Sep 13 02:29:19 2012 Return-Path: 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 561C421F8568 for ; Thu, 13 Sep 2012 02:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 zZBt0BrhCsyQ for ; Thu, 13 Sep 2012 02:29:18 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B86621F849B for ; Thu, 13 Sep 2012 02:29:18 -0700 (PDT) Received: by bkty12 with SMTP id y12so370101bkt.31 for ; Thu, 13 Sep 2012 02:29:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=hrroCn+Us1YI76NGVoYP1nW3et6D7miTgr/Qw/gCMpo=; b=QgHNjNr2sVa2qu6rbFskyah737NqTWa62rE/rwVOe5m7+RQd72nNOfDm8NxDXlj+Z0 JdkAPywV6ZDh0Jz6b3NhRS5wKpFrnhgz/g3pFy1dcc8dOFjNT2/9FdodUBC+YYrJbcWt yaUImNfD489+UBc8kTeDpzJIH9l1vBm9hjBOgRV9mMdleM2sNYWZIP32b7tA3kf+EGiy rlshitVkNUITblkJzFjypefT/+Vsnm2/OP7EHdmvQ7vdgnM2tdUbJk5en8vez8hB+Mh0 xbWuy2DihUXuGvvEbof+drkDEl84Cs6fDO/XBTr6v1ElSE4KtKBbCU13A1cMSa0a5WgR usww== Received: by 10.204.156.11 with SMTP id u11mr574370bkw.69.1347528557248; Thu, 13 Sep 2012 02:29:17 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPS id 25sm13649878bkx.9.2012.09.13.02.29.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Sep 2012 02:29:15 -0700 (PDT) Message-ID: <5051A76A.7090606@jitsi.org> Date: Thu, 13 Sep 2012 12:29:14 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A052D666F@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A052D666F@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQktd6yL1/pcJR36Oqp22vbYPE1VfMkku/R7aZQM1hxNDYH/N2BFwvhukw1plP7nyq4+qYUH Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt X-BeenThere: mmusic@ietf.org 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: Thu, 13 Sep 2012 09:29:19 -0000 Hey Tiru, One thing that I think this document is not very clear about is its relationship to standard mobility handling (i.e. through ICE restart). As far as I can see, ICE restart is only mentioned when describing its inefficiency. You did confirm in Vancouver that ICE Mobility is only meant as an optimisation that would only take place until the ICE restart completes but I don't see it anywhere in the text. Or am I missing something? Cheers, Emil On 20.07.12, 13:36, Tirumaleswar Reddy (tireddy) wrote: > Hi all, > > Dan, Prashanth and I have submitted a draft that explains how > endpoint mobility can be achieved using ICE. Two mechanisms are > shown, one where both endpoints support ICE and another where only > one endpoint supports ICE. When only one endpoint supports ICE, a > TURN server provides mobility. > > http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-01.txt > > Please let know your comments. If time permits we'd present the > draft in Vancouver. > > Regards, Tiru. > >> -----Original Message----- From: Tirumaleswar Reddy (tireddy) Sent: >> Friday, July 20, 2012 3:18 PM To: mmusic@ietf.org Subject: FW: New >> Version Notification for draft-wing-mmusic-ice- mobility-01.txt >> >> -----Original Message----- From: internet-drafts@ietf.org >> [mailto:internet-drafts@ietf.org] Sent: Tuesday, July 17, 2012 3:52 >> AM To: Dan Wing (dwing) Cc: Prashanth Patil (praspati); >> Tirumaleswar Reddy (tireddy) Subject: New Version Notification for >> draft-wing-mmusic-ice-mobility- 01.txt >> >> >> A new version of I-D, draft-wing-mmusic-ice-mobility-01.txt has >> been successfully submitted by Dan Wing and posted to the IETF >> repository. >> >> Filename: draft-wing-mmusic-ice-mobility Revision: 01 Title: >> Mobility with ICE (MICE) Creation date: 2012-07-16 WG ID: >> Individual Submission Number of pages: 12 URL: >> http://www.ietf.org/internet-drafts/draft-wing-mmusic- >> ice-mobility-01.txt Status: >> http://datatracker.ietf.org/doc/draft-wing-mmusic-ice- mobility >> Htmlized: http://tools.ietf.org/html/draft-wing-mmusic-ice- >> mobility-01 Diff: >> http://tools.ietf.org/rfcdiff?url2=draft-wing-mmusic- >> ice-mobility-01 >> >> Abstract: This specification describes how endpoint mobility can be >> achieved using ICE. Two mechanisms are shown, one where both >> endpoints support ICE and another where only one endpoint supports >> ICE. >> >> >> >> >> The IETF Secretariat > _______________________________________________ mmusic mailing list > mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > -- Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From kevin.gross@avanw.com Thu Sep 13 06:49:05 2012 Return-Path: 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 A0C8D21F854A for ; Thu, 13 Sep 2012 06:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.794 X-Spam-Level: * X-Spam-Status: No, score=1.794 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] 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 YYlE4iPDQV7E for ; Thu, 13 Sep 2012 06:49:05 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id E61DB21F8527 for ; Thu, 13 Sep 2012 06:49:04 -0700 (PDT) Received: (qmail 17901 invoked by uid 0); 13 Sep 2012 13:48:56 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy7.bluehost.com with SMTP; 13 Sep 2012 13:48:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=9wicnikj3iQazNPVrCJJoZgJ9ckjxulbKZQHnOdlXn4=; b=G5YsPIAjryBcY82lSpX7cPi4/UeUxqpzUBOS62irs8IEz2p7BiVKwiRzX1QtpvlENnR5Xz4tAuUtB7EVQQXEWMVHnF5twlaGYPFQpwir/OYWFzRjCoNasANpQPtgvBgE; Received: from [74.125.82.44] (port=62491 helo=mail-wg0-f44.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1TC9mq-000626-CH for mmusic@ietf.org; Thu, 13 Sep 2012 07:48:56 -0600 Received: by wgbdr13 with SMTP id dr13so1560392wgb.13 for ; Thu, 13 Sep 2012 06:48:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.100.133 with SMTP id ey5mr5059506wib.4.1347544134932; Thu, 13 Sep 2012 06:48:54 -0700 (PDT) Received: by 10.223.198.65 with HTTP; Thu, 13 Sep 2012 06:48:54 -0700 (PDT) In-Reply-To: <505188C7.1080805@ericsson.com> References: <505188C7.1080805@ericsson.com> Date: Thu, 13 Sep 2012 07:48:54 -0600 Message-ID: From: Kevin Gross To: "Miguel A. Garcia" Content-Type: multipart/alternative; boundary=f46d0444ee277b5a5c04c99591b9 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.44 authed with kevin.gross@avanw.com} Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] WG Poll for consensus on duplicated streams X-BeenThere: mmusic@ietf.org 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: Thu, 13 Sep 2012 13:49:05 -0000 --f46d0444ee277b5a5c04c99591b9 Content-Type: text/plain; charset=ISO-8859-1 I support adoption. The drafts look like a good starting point though it seems these two proposals could be combined into a single draft if desired. I assume there's a reason they've been separated. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Thu, Sep 13, 2012 at 1:18 AM, Miguel A. Garcia < Miguel.A.Garcia@ericsson.com> wrote: > At the last IETF meeting we had presentation of two drafts, both > related to the expression of duplicated streams in SDP. We noticed > there was support to progress these drafts. These drafts are > complementary to work going on in AVTEXT, where there is a normative > dependency. > > These are the documents: > > http://datatracker.ietf.org/**doc/draft-begen-mmusic-** > redundancy-grouping/ > http://datatracker.ietf.org/**doc/draft-begen-mmusic-** > temporal-interleaving/ > > We would like to poll the working group for adopting these two > documents as WG items, once we get approved milestones. > > Please indicate whether you support or not this new work within the > next 5 working days. > > Flemming and Miguel (co-chairs). > > /Miguel > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > > ______________________________**_________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/**listinfo/mmusic > --f46d0444ee277b5a5c04c99591b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support adoption. The drafts look like a good starting point though it se= ems these two proposals could be combined into a single draft if desired. I= assume there's a reason they've been separated.

Kevin Gross
+1-303-447-0517
Media Network Consultant
<= div>AVA Networks -=A0ww= w.AVAnw.com,=A0www.X1= 92.org



On Thu, Sep 13, 2012 at 1:18 AM, Miguel = A. Garcia <Miguel.A.Garcia@ericsson.com> wrote:
At the last IETF meeting we had presentation of two drafts, both
related to the expression of duplicated streams in SDP. We noticed
there was support to progress these drafts. These drafts are
complementary to work going on in AVTEXT, where there is a normative
dependency.

These are the documents:

http://datatracker.ietf.org/doc/draft-beg= en-mmusic-redundancy-grouping/
http://datatracker.ietf.org/doc/draft-b= egen-mmusic-temporal-interleaving/

We would like to poll the working group for adopting these two
documents as WG items, once we get approved milestones.

Please indicate whether you support or not this new work within the
next 5 working days.

Flemming and Miguel (co-chairs).

/Miguel
--
Miguel A. Garcia
= +34-91-339-3608
Ericsson Spain

_______________________________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic

--f46d0444ee277b5a5c04c99591b9-- From miguel.a.garcia@ericsson.com Fri Sep 14 01:57:31 2012 Return-Path: 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 19F9F21F8505 for ; Fri, 14 Sep 2012 01:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 IsJ-sKPeG5Vj for ; Fri, 14 Sep 2012 01:57:30 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2D021F84FD for ; Fri, 14 Sep 2012 01:57:30 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-4e-5052f179adc2 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0F.C2.11467.971F2505; Fri, 14 Sep 2012 10:57:29 +0200 (CEST) Received: from [164.48.161.5] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.1; Fri, 14 Sep 2012 10:57:28 +0200 Message-ID: <5052F176.4050100@ericsson.com> Date: Fri, 14 Sep 2012 10:57:26 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+JvrW7lx6AAg+kvZC3eX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbFn4jr2gnOsFeuPdLI0MJ5k6WLk5JAQMJF4 f7yPGcIWk7hwbz1bFyMXh5DAKUaJJ8+6mCGcVYwSJ7+fZgOp4hXQlnjx4yg7iM0ioCrRvKMH zGYTMJdo3bgRzBYVCJY4t3EbVL2gxMmZT8C2iQjISOzdtBlsGzPQnNl3ZjGB2MICjhKzH2xj h4jbSlyYc50FwpaX2P52Dli9kICmxOSbS5knMPLPQjJ2FpKWWUhaFjAyr2IUzk3MzEkvN9RL LcpMLi7Oz9MrTt3ECAy9g1t+6+5gPHVO5BCjNAeLkjgvV9J+fyGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2MLnNenSmwY/3x19ZjHWtN1Um7uVZ7XcTFQ945x6hXX71Y8+/UK5FDNSvW222b 4i4yofp2vOBSl4QPdkEeijbbC95d8e4wvBl0e80C30uzOfs1LvJUN37PeHHUb+nllJuWbZJT e0++nRhTtPnBIl+XnVpH/SNmTFtQs/lGq0WUxL2WuPv6JpzVSizFGYmGWsxFxYkAPd7W2wsC AAA= Cc: Flemming Andreasen Subject: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B X-BeenThere: mmusic@ietf.org 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, 14 Sep 2012 08:57:31 -0000 At the last IETF meeting we had presentation of a draft adding considerations to G.723 Annex and G.729 Annex B. We noticed there was support to progress this draft. We have already clarified with our ADs that if this document gets progressed, it should be done in the MMUSIC WG and should aim standards track document updating RFC 4856: http://datatracker.ietf.org/doc/draft-muthu-mmusic-offer-answer-g723-g729/ We would like to poll the working group for adopting this documents as WG item, once we get an approved milestone. Please indicate whether you support or not this new work within the next 5 days. Flemming and Miguel (co-chairs). -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Fri Sep 14 02:35:15 2012 Return-Path: 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 9F94621F85F3 for ; Fri, 14 Sep 2012 02:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 5b-0Ev18S0xb for ; Fri, 14 Sep 2012 02:35:15 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id ADF1221F85ED for ; Fri, 14 Sep 2012 02:35:14 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-c4-5052fa51abf1 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BF.B8.11467.15AF2505; Fri, 14 Sep 2012 11:35:13 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 14 Sep 2012 11:35:13 +0200 From: Christer Holmberg To: Miguel Garcia A , mmusic Date: Fri, 14 Sep 2012 11:35:12 +0200 Thread-Topic: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B Thread-Index: Ac2SVvtlSu2DAG8mQGOBRrGgOtj0OwABQXvw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A597FD7@ESESSCMS0356.eemea.ericsson.se> References: <5052F176.4050100@ericsson.com> In-Reply-To: <5052F176.4050100@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvrW7gr6AAg3cNOhbvL+haTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgypi79wRzwUvOineP5zA2MLZxdDFyckgImEjM n3GEDcIWk7hwbz2QzcUhJHCKUaJx/0MmCGcBo8Sku9MYuxg5ONgELCS6/2mDNIgI+EhMfbwV rJlZQFti9p1ZTCA2i4CqxPdzu1hBbGGBAIn1m3+xQNQHSvRd62aDsI0kNry/DFbPKxAu0TPz JViNENCc9dumg9VwCuhI9Hy7BBZnBDru+6k1TBC7xCVuPZnPBHG0gMSSPeeZIWxRiZeP/7FC 1ItK3GlfzwhRryOxYPcnuDuXLXzNDLFXUOLkzCcsExjFZiEZOwtJyywkLbOQtCxgZFnFKJyb mJmTXm6ol1qUmVxcnJ+nV5y6iREYOQe3/NbdwXjqnMghRmkOFiVxXq6k/f5CAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGCWSm5dYZTQF/qy0/zY/4+yn/9caQj/N7zg6cdtZ3lXrL2/0DfjJ M3EDq0qO1rRCAXm3S3t5Vu7c7ZNbsuxk+qsZj8JZJ7OnGq8UFf8VfPaK1QGRSf0BraLZ8mFM m4NzS8S2pEw649z+WfLAzfvcVtopH1hU33xjWeygZzdV9fyNnYd3MMz49UOJpTgj0VCLuag4 EQCz7DJFagIAAA== Cc: Flemming Andreasen Subject: Re: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B X-BeenThere: mmusic@ietf.org 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, 14 Sep 2012 09:35:15 -0000 Hi, I don't have the minutes, but wasn't there a suggestion to instead create a= 4856bis? Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Miguel A. Garcia Sent: 14. syyskuuta 2012 11:57 To: mmusic Cc: Flemming Andreasen Subject: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B At the last IETF meeting we had presentation of a draft adding consideratio= ns to G.723 Annex and G.729 Annex B. We noticed there was support to progre= ss this draft. We have already clarified with our ADs that if this document= gets progressed, it should be done in the MMUSIC WG and should aim standar= ds track document updating RFC 4856: http://datatracker.ietf.org/doc/draft-muthu-mmusic-offer-answer-g723-g729/ We would like to poll the working group for adopting this documents as WG i= tem, once we get an approved milestone. Please indicate whether you support or not this new work within the next 5 = days. Flemming and Miguel (co-chairs). -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From ron.even.tlv@gmail.com Fri Sep 14 02:53:22 2012 Return-Path: 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 13D2B21F85AC for ; Fri, 14 Sep 2012 02:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Nn2bXvxnsYHQ for ; Fri, 14 Sep 2012 02:53:20 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A91521F85A0 for ; Fri, 14 Sep 2012 02:53:20 -0700 (PDT) Received: by bkty12 with SMTP id y12so1031341bkt.31 for ; Fri, 14 Sep 2012 02:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=kSlYM2xjkWM1H6y9FEBU4afdzyZbEHXoiAr9/rk4Mt8=; b=R3F/fo6TP6FpOigqw61asCpQ9hTB4Ji42CsthuRV+IasK71J/fjvjxHwIwh55Psc8x ptqFK7wHNt9tNvxY8ES/0xUQcNX6+HhgZVwGYuBQlMITQc1J7iAAN+L7Io9LuGKsLeJO 5HANl19ucOfBW1q1C8oXoO+sh4Rt70pbHCRMlMFXv2PIFIVQpZ/9qnx234yMNzmWo3FM EVg8Q7hoJD4Hfh+IIb4ZgOlVOao/qtRz9BASWPhbXGbdTYUr9tHezJtR5WZPF661qkM3 +wz2sw+FmV9Z/bbxh40K8u7HZiiIuL0VgsCR/23oEk3/uMiHKROu1QgzHI+H/IS/wHn+ lw3A== Received: by 10.204.143.138 with SMTP id v10mr756146bku.114.1347616399283; Fri, 14 Sep 2012 02:53:19 -0700 (PDT) Received: from RoniE (bzq-79-181-188-119.red.bezeqint.net. [79.181.188.119]) by mx.google.com with ESMTPS id c18sm582249bkv.8.2012.09.14.02.53.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Sep 2012 02:53:18 -0700 (PDT) From: "Roni Even" To: "'Miguel A. Garcia'" , "'mmusic'" References: <5052F176.4050100@ericsson.com> In-Reply-To: <5052F176.4050100@ericsson.com> Date: Fri, 14 Sep 2012 12:51:31 +0200 Message-ID: <00a901cd9266$e8cfbba0$ba6f32e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKGIkLFeUnyURYq9jwdCeOqLTG5a5YYiTIQ Content-Language: en-us Cc: 'Flemming Andreasen' Subject: Re: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B X-BeenThere: mmusic@ietf.org 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, 14 Sep 2012 09:53:22 -0000 I support this work in MMUSIC Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia Sent: 14 September, 2012 10:57 AM To: mmusic Cc: Flemming Andreasen Subject: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B At the last IETF meeting we had presentation of a draft adding considerations to G.723 Annex and G.729 Annex B. We noticed there was support to progress this draft. We have already clarified with our ADs that if this document gets progressed, it should be done in the MMUSIC WG and should aim standards track document updating RFC 4856: http://datatracker.ietf.org/doc/draft-muthu-mmusic-offer-answer-g723-g729/ We would like to poll the working group for adopting this documents as WG item, once we get an approved milestone. Please indicate whether you support or not this new work within the next 5 days. Flemming and Miguel (co-chairs). -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From miguel.a.garcia@ericsson.com Fri Sep 14 02:58:58 2012 Return-Path: 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 760A721F8540 for ; Fri, 14 Sep 2012 02:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 ZuJft5Evc8lP for ; Fri, 14 Sep 2012 02:58:58 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 82A3821F8539 for ; Fri, 14 Sep 2012 02:58:57 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-32-5052ffe0b660 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0E.5C.11467.0EFF2505; Fri, 14 Sep 2012 11:58:56 +0200 (CEST) Received: from [164.48.161.5] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.1; Fri, 14 Sep 2012 11:58:55 +0200 Message-ID: <5052FFDA.7060904@ericsson.com> Date: Fri, 14 Sep 2012 11:58:50 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <5052F176.4050100@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340A597FD7@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A597FD7@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvre6D/0EBBl+nqli8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK2PRlVOMBfv5Kj482cnUwHiXu4uRk0NCwETi VetfFghbTOLCvfVsXYxcHEICpxglPl+dxwzhrGKUeHP4AlgVr4C2xLPuy6wgNouAqsTv32/Z QWw2AXOJ1o0bwWxRgWCJcxu3sUHUC0qcnPkErFdEwEzi+udeJhCbWcBVYtWu2cwgtrBAgMSD NYfB6oUEyiW2XtsOVs8pECGx8f8CVoh6W4kLc66zQNjyEtvfzmGGqNeUmHxzKfMERsFZSNbN QtIyC0nLAkbmVYzCuYmZOenlhnqpRZnJxcX5eXrFqZsYgaF6cMtv3R2Mp86JHGKU5mBREufl StrvLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR9ptwqLJusfrJX4oW/RYnPvCen7HiDWvg Sql/ykvnXb5YnBMWobEkUvLgDScLPq/nT75WnEndxnfFwOyphMxzd05H7sNr3i7/zBDPYzj1 hz+TTd6fy2HJF3kPXww+lRhnv0V2y+RqMaFFH3jDLGZP/GYotDe242HkxicHbc4tfcOi9TzF ccUaJZbijERDLeai4kQAUIe8iiMCAAA= Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B X-BeenThere: mmusic@ietf.org 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, 14 Sep 2012 09:58:58 -0000 Yes, there was a suggestion to create a 4856bis that will add this draft. But that will complicate a bit things, because it requires to involved PAYLOAD and MMUSIC, and each WG will have expertise in half of the document. There was also the current authors' proposal to progress this draft in MMUSIC with the current scope (SDP O/A). It seems that a simple solution is to progress this document in MMUSIC with the current scope. /Miguel On 14/09/2012 11:35, Christer Holmberg wrote: > Hi, > > I don't have the minutes, but wasn't there a suggestion to instead create a 4856bis? > > Regards, > > Christer > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia > Sent: 14. syyskuuta 2012 11:57 > To: mmusic > Cc: Flemming Andreasen > Subject: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B > > At the last IETF meeting we had presentation of a draft adding considerations to G.723 Annex and G.729 Annex B. We noticed there was support to progress this draft. We have already clarified with our ADs that if this document gets progressed, it should be done in the MMUSIC WG and should aim standards track document updating RFC 4856: > > http://datatracker.ietf.org/doc/draft-muthu-mmusic-offer-answer-g723-g729/ > > We would like to poll the working group for adopting this documents as WG item, once we get an approved milestone. > > Please indicate whether you support or not this new work within the next 5 days. > > Flemming and Miguel (co-chairs). > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Fri Sep 14 06:58:13 2012 Return-Path: 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 00E3721F852C for ; Fri, 14 Sep 2012 06:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 L1LqGUBUHBVO for ; Fri, 14 Sep 2012 06:58:12 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3000121F850D for ; Fri, 14 Sep 2012 06:58:11 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-33-505337ee3f31 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 53.91.25676.EE733505; Fri, 14 Sep 2012 15:58:06 +0200 (CEST) Received: from [164.48.161.5] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.1; Fri, 14 Sep 2012 15:58:05 +0200 Message-ID: <505337EC.8080202@ericsson.com> Date: Fri, 14 Sep 2012 15:58:04 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Harald Alvestrand , mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNJMWRmVeSWpSXmKPExsUyM+Jvre478+AAgwutuhbH+rrYLKYuf8zi wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGV8WfOJuWCnSsXVn4dYGxhbZLsYOTgkBEwk 3k226GLkBDLFJC7cW8/WxcjFISRwilFiV/cRRghnFaPEuZub2UGqeAW0JV5cf8cO0swioCrx 7IYASJhNwFyideNGsBJRgWCJcxu3sUGUC0qcnPmEBcQWEXCTODZvPVhcWMBC4smWScwgNrOA rcSFOddZIGx5ie1v54DFhQQ0JSbfXMo8gZFvFpJRs5C0zELSsoCReRWjcG5iZk56uZFealFm cnFxfp5eceomRmCAHdzyW3UH451zIocYpTlYlMR5rbfu8RcSSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAWJ+66G579fFtfje3rznxa8490XfbPu76tzabJaq0xnbifMHpQcbLTqVNYZocLhNx RH5vzQcx1jP+AcctNzdMzuE8qGQdHCkpUzph1rLq7y++vJsR8r/PvvpL4JlEL/0jiX9X3lgl 4zQxd+K6g9v9m73ORs/ZldUdYLqUf+3e9x7FL19XXjE8d1aJpTgj0VCLuag4EQA+fnF6/gEA AA== Subject: [MMUSIC] Comments to draft-alvestrand-mmusic-msid-00.txt X-BeenThere: mmusic@ietf.org 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, 14 Sep 2012 13:58:13 -0000 Here are some comments to the MSID draft. - General. I think it would be good to describe in general the structure of the draft. First indicating that it is going to extend the SSRC grouping framework by adding new grouping relations, and then saying that Section 4 describes how WebRTC implementations will benefit and use the already described extension. - On section 1.1, I would like to see the authors framing the discussion a bit more. It is central to this draft to understand what an "RTP session is". Preferable, this there should be a pointer to RFC 3550 where RTP session is defined. And perhaps the draft should highlight the points of that definition that are most relevant for this draft (for example, that RTP and RTCP sent to two different ports are part of the same RTP session). I was just expecting something similar to the first two paragraphs of Section 3 in RFC 5576. - Section 1.1, paragraphs 2 and 3 seem incomplete sentences to me. I was expecting that the sentence indicate what is the desired achievement of the indicated RFCs. I guess the desired effect is to create a relation between two or more RTP streams. Here is some proposed rewording: The SSRC mechanism [RFC5576] can be used to associate RTP media streams when those RTP media streams are part of the same RTP session. The semantics of this mechanism prevent the association of RTP media streams that are spread across different RTP sessions. The SDP grouping framework [RFC5888] can be be used to group RTP sessions. In the particular case when an RTP session has one and only one SSRC contributor, it is possible to associate RTP media streams spread across different RTP sessions. However, generally speaking, RTP sessions are composed of several SSRC contributors, in which case, the SDP grouping framework cannot be used for this purpose. - Section 2. I would have expected this section to begin with an overall solution description, for example: This document extends the Source-Specific Media Attributes framework [RFC5576] by adding a new "msid" attribute to the "a=ssrc" attribute in SDP. This new attribute allows endpoints to associate RTP media streams of diverse RTP sessions, as well as it allows to add application-specific association information. - Section 2, second paragraph starts with a description of how to generate an "ID" without having defined what this "ID" is all about. Probably this paragraph should be moved after... the grammar, but the grammar does not have an "ID" either. - Section 2, 4th paragraph should be prepended with: The extension defined in this document allows applications to exchange application-specific data in relation with the RTP Media stream associations. - Section 2, grammar. The grammar should start with an anchor to RFC 5576, since this document is an extension of it. Besides that, I am confused if the extension of the msid attribute is an extension to the "a=ssrc" attribute or the "a=ssrc-group". - Section 2, Note on generation algorithm. I don't see the point of this note when the previous text has indicated that this is a randomly-generated string. I guess this should be deleted. - Section 2, towards the end. I infer from the text, but not clearly saw it. I guess you are trying to express: Endpoints MAY update the SDP by grouping and ungrouping RTP media streams as tehy wish. Implementations need to be ready to receive updates of the grouping at any time. - Section 3, 2nd paragraph: "This OPTIONAL attributes". Well, all attributes are optional, so I don't see the point in having the word OPTIONAL here. - Section 3. The ABNF of the msid-semantic needs to be anchored to the a=ssrc-group ABNF. - Section 4, first paragraph says: The semantic for WebRTC Media Streams is "WMS". I understand the principle, but you need to put the reader into context. How about some introductory paragraph: This document creates a new semantic to be used to group several RTP Media streams into a WebRTC Media Stream. The associated token to this semantic is "WMS". WebRTC implementations will to signal the association of these RTP media streams into a WebRTC Media Stream should use the "WMS" token for their purpose. Nits: - The last sentence in the abstract refers the reader to the RTCWEB WG and list. I believe this should be changed to MMUSIC now. - I would rename Section 1 to "Requirements for a new RTP media stream association mechanism". /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From pkyzivat@alum.mit.edu Fri Sep 14 08:06:38 2012 Return-Path: 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 D7CAD21F8514 for ; Fri, 14 Sep 2012 08:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 DkOp2Vltl6SN for ; Fri, 14 Sep 2012 08:06:38 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF4521F84EA for ; Fri, 14 Sep 2012 08:06:36 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta05.westchester.pa.mail.comcast.net with comcast id z2941j0011vXlb85536gUW; Fri, 14 Sep 2012 15:06:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id z36i1j00W3ZTu2S3d36i3J; Fri, 14 Sep 2012 15:06:42 +0000 Message-ID: <505347FC.4000805@alum.mit.edu> Date: Fri, 14 Sep 2012 11:06:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <5052F176.4050100@ericsson.com> <00a901cd9266$e8cfbba0$ba6f32e0$@gmail.com> In-Reply-To: <00a901cd9266$e8cfbba0$ba6f32e0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B X-BeenThere: mmusic@ietf.org 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, 14 Sep 2012 15:06:39 -0000 +1 On 9/14/12 6:51 AM, Roni Even wrote: > I support this work in MMUSIC > Roni Even > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of > Miguel A. Garcia > Sent: 14 September, 2012 10:57 AM > To: mmusic > Cc: Flemming Andreasen > Subject: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B > > At the last IETF meeting we had presentation of a draft adding > considerations to G.723 Annex and G.729 Annex B. We noticed there was > support to progress this draft. We have already clarified with our ADs that > if this document gets progressed, it should be done in the MMUSIC WG and > should aim standards track document updating RFC 4856: > > http://datatracker.ietf.org/doc/draft-muthu-mmusic-offer-answer-g723-g729/ > > We would like to poll the working group for adopting this documents as WG > item, once we get an approved milestone. > > Please indicate whether you support or not this new work within the next 5 > days. > > Flemming and Miguel (co-chairs). > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From harald@alvestrand.no Fri Sep 14 11:10:24 2012 Return-Path: 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 EF48221F84E1; Fri, 14 Sep 2012 11:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GLDy4g5dZt3R; Fri, 14 Sep 2012 11:10:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A009421F84D5; Fri, 14 Sep 2012 11:10:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 18DAC39E241; Fri, 14 Sep 2012 20:10:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiHFMaHHSFh0; Fri, 14 Sep 2012 20:10:19 +0200 (CEST) Received: from [172.22.79.234] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 70D8339E235; Fri, 14 Sep 2012 20:10:18 +0200 (CEST) Message-ID: <50537308.4040301@alvestrand.no> Date: Fri, 14 Sep 2012 11:10:16 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: mmusic , "rtcweb@ietf.org" References: <20120912232709.19630.20589.idtracker@ietfa.amsl.com> In-Reply-To: <20120912232709.19630.20589.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120912232709.19630.20589.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020000040500060802040703" Subject: [MMUSIC] FYI: New Version Notification for draft-alvestrand-mmusic-msid-00.txt X-BeenThere: mmusic@ietf.org 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, 14 Sep 2012 18:10:24 -0000 This is a multi-part message in MIME format. --------------020000040500060802040703 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit The MMUSIC chairs have asked me to prepare a version of the MSID draft that is named using the draft--mmusic- convention, in preparation for polling the MMUSIC WG about adopting the draft. This is it. Comments welcome! Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-mmusic-msid-00.txt Date: Wed, 12 Sep 2012 16:27:09 -0700 From: internet-drafts@ietf.org To: harald@alvestrand.no A new version of I-D, draft-alvestrand-mmusic-msid-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-mmusic-msid Revision: 00 Title: Cross Session Stream Identification in the Session Description Protocol Creation date: 2012-09-12 WG ID: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-msid-00.txt Status: http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid Htmlized: http://tools.ietf.org/html/draft-alvestrand-mmusic-msid-00 Abstract: This document specifies a grouping mechanism for RTP media streams that can be used to specify relations betweeen media streams within different RTP sessions. This mechanism is used to signal the association between the RTP concept of SSRC and the WebRTC concept of "media stream" / "media stream track" using SDP signalling. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. The IETF Secretariat --------------020000040500060802040703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit The MMUSIC chairs have asked me to prepare a version of the MSID draft that is named using the draft-<authorname>-mmusic-<subject> convention, in preparation for polling the MMUSIC WG about adopting the draft.

This is it. Comments welcome!

               Harald


-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-mmusic-msid-00.txt
Date: Wed, 12 Sep 2012 16:27:09 -0700
From: internet-drafts@ietf.org
To: harald@alvestrand.no 


A new version of I-D, draft-alvestrand-mmusic-msid-00.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Filename:	 draft-alvestrand-mmusic-msid
Revision:	 00
Title:		 Cross Session Stream Identification in the Session Description Protocol
Creation date:	 2012-09-12
WG ID:		 Individual Submission
Number of pages: 11
URL:             http://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-msid-00.txt
Status:          http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid
Htmlized:        http://tools.ietf.org/html/draft-alvestrand-mmusic-msid-00


Abstract:
   This document specifies a grouping mechanism for RTP media streams
   that can be used to specify relations betweeen media streams within
   different RTP sessions.

   This mechanism is used to signal the association between the RTP
   concept of SSRC and the WebRTC concept of "media stream" / "media
   stream track" using SDP signalling.

   This document is an input document for discussion.  It should be
   discussed in the RTCWEB WG list, rtcweb@ietf.org.


                                                                                  


The IETF Secretariat



--------------020000040500060802040703-- From harald@alvestrand.no Fri Sep 14 18:47:23 2012 Return-Path: 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 D4F3621F857E for ; Fri, 14 Sep 2012 18:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, 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 QxAoBKb4EsgL for ; Fri, 14 Sep 2012 18:47:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 43D5A21F8566 for ; Fri, 14 Sep 2012 18:47:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 11F0F39E235; Sat, 15 Sep 2012 03:47:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1cbDH-nojWL; Sat, 15 Sep 2012 03:47:20 +0200 (CEST) Received: from [IPv6:2620:0:1000:147d:221:6aff:fe8f:cf14] (unknown [IPv6:2620:0:1000:147d:221:6aff:fe8f:cf14]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7BD9239E029; Sat, 15 Sep 2012 03:47:19 +0200 (CEST) Message-ID: <5053DE25.5070300@alvestrand.no> Date: Fri, 14 Sep 2012 18:47:17 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Christer Holmberg References: <503E0B63.3020708@ericsson.com>, , , <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com>, <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com>, <503FCAA1.5080500@alvestrand.no> , <503FDBA1.9000003@alvestrand.no> <504055EF.5070300@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A3DCD92@ESESSCMS0356.eemea.ericsson.se> <50407CE5.3080407@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A3DCE65@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A3DCE65@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] H.264 SVC and BUNDLE X-BeenThere: mmusic@ietf.org 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: Sat, 15 Sep 2012 01:47:24 -0000 On 08/31/2012 03:30 AM, Christer Holmberg wrote: > Hi, > >>> One question is of course whether we are going to move ahead with the m=bundle proposal. In that case, I guess the m=video lines >>> would look like they do today, and the question is how we describe the multiplexed SVC within the m=bundle line. >> The SVC session is simple - just use the same lines (except rtpmap H.264/ -> mime-type-map video/H.264, or whatever we decide to call it). > Correct. > > And, as you indicate, if we move ahead with the m=bundle alternative, we need to decide whether we will use the rtpmap attribute, or whether we need something else. But, that's a separate thread :) > >> The MVC additional session can't be bundled, so it remains outside the BUNDLE line. > Why do you think it can't be bundled? Because it can't use the same port, and/or because it uses multiple RTP sessions? Because if it was using the same RTP session, it would be SST. (not SVC, sorry). From harald@alvestrand.no Sat Sep 15 06:28:26 2012 Return-Path: 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 BC35021F846C for ; Sat, 15 Sep 2012 06:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 n2NIaAjpxHDe for ; Sat, 15 Sep 2012 06:28:25 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7074821F8462 for ; Sat, 15 Sep 2012 06:28:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BD5B539E176; Sat, 15 Sep 2012 15:28:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIlnB0r-AenR; Sat, 15 Sep 2012 15:28:22 +0200 (CEST) Received: from [10.1.7.106] (64-71-8-186.static.wiline.com [64.71.8.186]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CA77E39E166; Sat, 15 Sep 2012 15:28:21 +0200 (CEST) Message-ID: <50548273.6010009@alvestrand.no> Date: Sat, 15 Sep 2012 06:28:19 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <505337EC.8080202@ericsson.com> In-Reply-To: <505337EC.8080202@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic Subject: Re: [MMUSIC] Comments to draft-alvestrand-mmusic-msid-00.txt X-BeenThere: mmusic@ietf.org 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: Sat, 15 Sep 2012 13:28:26 -0000 Thanks for the detailed comments! Will prepare an updated version, hold it for a little while in case of further comments, and then submit. One pusbhack as a matter of principle: I do not believe it is good to add introductions that try to give a tutorial in the technologies that we are designing extensions to. At some level, introductions are going to get it wrong, and they won't be updated if the underlying documents change, years later, leaving wrong text in surprising places. I do agree very much with making the definitions easily findable by adding pointers to the relevant documents and sections. Harald On 09/14/2012 06:58 AM, Miguel A. Garcia wrote: > > > Here are some comments to the MSID draft. > > - General. I think it would be good to describe in general the > structure of the draft. First indicating that it is going to extend > the SSRC grouping framework by adding new grouping relations, and then > saying that Section 4 describes how WebRTC implementations will > benefit and use the already described extension. > > - On section 1.1, I would like to see the authors framing the > discussion a bit more. It is central to this draft to understand what > an "RTP session is". Preferable, this there should be a pointer to RFC > 3550 where RTP session is defined. And perhaps the draft should > highlight the points of that definition that are most relevant for > this draft (for example, that RTP and RTCP sent to two different ports > are part of the same RTP session). I was just expecting something > similar to the first two paragraphs of Section 3 in RFC 5576. > > - Section 1.1, paragraphs 2 and 3 seem incomplete sentences to me. I > was expecting that the sentence indicate what is the desired > achievement of the indicated RFCs. I guess the desired effect is to > create a relation between two or more RTP streams. Here is some > proposed rewording: > > The SSRC mechanism [RFC5576] can be used to associate RTP media > streams when those RTP media streams are part of the same RTP session. > The semantics of this mechanism prevent the association of RTP media > streams that are spread across different RTP sessions. > > The SDP grouping framework [RFC5888] can be be used to group RTP > sessions. In the particular case when an RTP session has one and only > one SSRC contributor, it is possible to associate RTP media streams > spread across different RTP sessions. However, generally speaking, RTP > sessions are composed of several SSRC contributors, in which case, the > SDP grouping framework cannot be used for this purpose. > > - Section 2. I would have expected this section to begin with an > overall solution description, for example: > > This document extends the Source-Specific Media Attributes framework > [RFC5576] by adding a new "msid" attribute to the "a=ssrc" attribute > in SDP. This new attribute allows endpoints to associate RTP media > streams of diverse RTP sessions, as well as it allows to add > application-specific association information. > > - Section 2, second paragraph starts with a description of how to > generate an "ID" without having defined what this "ID" is all about. > Probably this paragraph should be moved after... the grammar, but the > grammar does not have an "ID" either. > > - Section 2, 4th paragraph should be prepended with: The extension > defined in this document allows applications to exchange > application-specific data in relation with the RTP Media stream > associations. > > - Section 2, grammar. The grammar should start with an anchor to RFC > 5576, since this document is an extension of it. Besides that, I am > confused if the extension of the msid attribute is an extension to the > "a=ssrc" attribute or the "a=ssrc-group". > > - Section 2, Note on generation algorithm. I don't see the point of > this note when the previous text has indicated that this is a > randomly-generated string. I guess this should be deleted. > > - Section 2, towards the end. I infer from the text, but not clearly > saw it. I guess you are trying to express: > > Endpoints MAY update the SDP by grouping and ungrouping RTP media > streams as tehy wish. Implementations need to be ready to receive > updates of the grouping at any time. > > - Section 3, 2nd paragraph: "This OPTIONAL attributes". Well, all > attributes are optional, so I don't see the point in having the word > OPTIONAL here. > > - Section 3. The ABNF of the msid-semantic needs to be anchored to the > a=ssrc-group ABNF. > > - Section 4, first paragraph says: > > The semantic for WebRTC Media Streams is "WMS". > > I understand the principle, but you need to put the reader into > context. How about some introductory paragraph: > > This document creates a new semantic to be used to group several RTP > Media streams into a WebRTC Media Stream. The associated token to this > semantic is "WMS". WebRTC implementations will to signal the > association of these RTP media streams into a WebRTC Media Stream > should use the "WMS" token for their purpose. > > > Nits: > > - The last sentence in the abstract refers the reader to the RTCWEB WG > and list. I believe this should be changed to MMUSIC now. > > - I would rename Section 1 to "Requirements for a new RTP media stream > association mechanism". > > > > /Miguel > > From ekr@rtfm.com Mon Sep 17 09:30:15 2012 Return-Path: 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 1C1F721F846E for ; Mon, 17 Sep 2012 09:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.846 X-Spam-Level: X-Spam-Status: No, score=-101.846 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 bvIWtbNVPRea for ; Mon, 17 Sep 2012 09:30:14 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6512E21F867F for ; Mon, 17 Sep 2012 09:30:14 -0700 (PDT) Received: by eekb45 with SMTP id b45so3582979eek.31 for ; Mon, 17 Sep 2012 09:30:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=5XLX7nvL1+W7Lg9CWCTPhnKZ16KfMh3k2sZS6hKTPXI=; b=Ltz23cNSseTkzraHxpNItgWuQo9ePqSdYctSGOxuNZWTBFdhAE9mFGOgaS5Ul+lFFP 3oASFq6YRg4OC6m6wHVPkU3qm+NDPqurF+pEXP82OyCiOgMcDsWrdRp7hYoMqecFvnTS brhAqH+iRfGS44ShJjqA8IzgQT2eyUGBBlc2alWC96AuEZUs6qN/tcVm8AVhf8pkE4Z2 Xjjs2kSC/HoXXMduiNzkgbjcLlAvrgLpj8jNdXw0jc/ZGr4hjFGQfSK/BlqFb9Jvtlot KCXXEF9DumzXbGhSCSCN06u9uRF65fFCW/gqLseyoJuIy88fIujuvifwHOMv1KAXG7vI xnRw== Received: by 10.14.224.4 with SMTP id w4mr14376106eep.21.1347899413545; Mon, 17 Sep 2012 09:30:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.187.10 with HTTP; Mon, 17 Sep 2012 09:29:33 -0700 (PDT) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Mon, 17 Sep 2012 09:29:33 -0700 Message-ID: To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlf7ilwwRz1Xc7Cl6FntlPCq16IkoVRN0e42hR0Uzm62Z2ULwrXddx1S7N47pMAzfwZ0XSb Subject: [MMUSIC] Comments on draft-zhou-mmusic-sdes-keymod-01 X-BeenThere: mmusic@ietf.org 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: Mon, 17 Sep 2012 16:30:15 -0000 This document describes an extension to SDES to address the fact that in the case of retargeting/forking multiple targets get to see the SDES key which the offerer will use for sending data. The proposal here is to add an extension which can be sent by the answerer to modify the key provided by the offerer. This whole line of development doesn't seem like a very good idea. During the RTPSEC work, we considered this problem and a bunch of related problems with SDES (e.g., early media) and concluded that a media-plane key establishment protocol was the right approach to addressing this problem, among others. I don't see a lot of point in doing piecemeal patches to SDES in an attempt to band-aid it's fundamental problems. This particular design seems particularly problematic in that it allows an on-path proxy to force the offerer into using a specific key. The general pattern would look like this: Alice Proxy Bob OFFER with K1 + keymod ---> OFFER w/ K2 ------------> <----------------- ANSWER <- ANSWER with Keymod for K2 With conventional SDES, the proxy gets to see the SDES key but not to modify it. Obviously, he can change the key in flight, but the sender will still use the old key. This design would further weaken even the limited set of protections provided by SDES. -Ekr From bernard_aboba@hotmail.com Mon Sep 17 09:42:22 2012 Return-Path: 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 49D4721F8714 for ; Mon, 17 Sep 2012 09:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.18 X-Spam-Level: X-Spam-Status: No, score=-102.18 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9Y+4gY6Pxzui for ; Mon, 17 Sep 2012 09:42:21 -0700 (PDT) Received: from blu0-omc2-s12.blu0.hotmail.com (blu0-omc2-s12.blu0.hotmail.com [65.55.111.87]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0E821F8711 for ; Mon, 17 Sep 2012 09:42:21 -0700 (PDT) Received: from BLU002-W35 ([65.55.111.72]) by blu0-omc2-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Sep 2012 09:42:19 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f2a59468-9932-4044-9592-4b64c3d1ea3c_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Eric Rescorla , "mmusic@ietf.org" Date: Mon, 17 Sep 2012 09:42:19 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 17 Sep 2012 16:42:19.0954 (UTC) FILETIME=[67973920:01CD94F3] Subject: Re: [MMUSIC] Comments on draft-zhou-mmusic-sdes-keymod-01 X-BeenThere: mmusic@ietf.org 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: Mon, 17 Sep 2012 16:42:22 -0000 --_f2a59468-9932-4044-9592-4b64c3d1ea3c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree. Since the (only) major advantage of SDES is its widespread deploy= ment=2C it makes little sense to introduce patches that are unlikely to be widely i= mplemented=2C particularly when they introduce other security problems. =20 > From: ekr@rtfm.com > Date: Mon=2C 17 Sep 2012 09:29:33 -0700 > To: mmusic@ietf.org > Subject: [MMUSIC] Comments on draft-zhou-mmusic-sdes-keymod-01 >=20 > This document describes an extension to SDES to address the fact that > in the case of retargeting/forking multiple targets get to see the > SDES key which the offerer will use for sending data. The proposal > here is to add an extension which can be sent by the answerer to > modify the key provided by the offerer. >=20 >=20 > This whole line of development doesn't seem like a very good idea. > During the RTPSEC work=2C we considered this problem and a bunch of > related problems with SDES (e.g.=2C early media) and concluded that a > media-plane key establishment protocol was the right approach to > addressing this problem=2C among others. I don't see a lot of point in > doing piecemeal patches to SDES in an attempt to band-aid it's > fundamental problems. >=20 >=20 > This particular design seems particularly problematic in that > it allows an on-path proxy to force the offerer into using a > specific key. The general pattern would look like this: >=20 > Alice Proxy Bob >=20 > OFFER with K1 + keymod ---> > OFFER w/ K2 ------------> > <----------------- ANSWER > <- ANSWER with Keymod for K2 >=20 >=20 > With conventional SDES=2C the proxy gets to see the SDES key but > not to modify it. Obviously=2C he can change the key in flight=2C > but the sender will still use the old key. This design would > further weaken even the limited set of protections provided > by SDES. >=20 >=20 > -Ekr > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = --_f2a59468-9932-4044-9592-4b64c3d1ea3c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree. =3B Since the (only= ) major advantage of SDES is its widespread deployment=2C
it makes littl= e sense to introduce patches that are unlikely to be widely implemented=2C<= br>particularly when they introduce other security problems.  =3B
<= br>
>=3B From: ekr@rtfm.com
= >=3B Date: Mon=2C 17 Sep 2012 09:29:33 -0700
>=3B To: mmusic@ietf.or= g
>=3B Subject: [MMUSIC] Comments on draft-zhou-mmusic-sdes-keymod-01<= br>>=3B
>=3B This document describes an extension to SDES to addres= s the fact that
>=3B in the case of retargeting/forking multiple targe= ts get to see the
>=3B SDES key which the offerer will use for sending= data. The proposal
>=3B here is to add an extension which can be sent= by the answerer to
>=3B modify the key provided by the offerer.
&g= t=3B
>=3B
>=3B This whole line of development doesn't seem like= a very good idea.
>=3B During the RTPSEC work=2C we considered this p= roblem and a bunch of
>=3B related problems with SDES (e.g.=2C early m= edia) and concluded that a
>=3B media-plane key establishment protocol= was the right approach to
>=3B addressing this problem=2C among other= s. I don't see a lot of point in
>=3B doing piecemeal patches to SDES= in an attempt to band-aid it's
>=3B fundamental problems.
>=3B <= br>>=3B
>=3B This particular design seems particularly problematic = in that
>=3B it allows an on-path proxy to force the offerer into usin= g a
>=3B specific key. The general pattern would look like this:
&g= t=3B
>=3B Alice Proxy Bob
&g= t=3B
>=3B OFFER with K1 + keymod --->=3B
>=3B = OFFER w/ K2 ------------>=3B
>=3B = <=3B----------------- ANSWER
>=3B <=3B- ANSWER with Keymod f= or K2
>=3B
>=3B
>=3B With conventional SDES=2C the proxy g= ets to see the SDES key but
>=3B not to modify it. Obviously=2C he can= change the key in flight=2C
>=3B but the sender will still use the ol= d key. This design would
>=3B further weaken even the limited set of p= rotections provided
>=3B by SDES.
>=3B
>=3B
>=3B -Ekr=
>=3B _______________________________________________
>=3B mmusic= mailing list
>=3B mmusic@ietf.org
>=3B https://www.ietf.org/mail= man/listinfo/mmusic
= --_f2a59468-9932-4044-9592-4b64c3d1ea3c_-- From tireddy@cisco.com Mon Sep 17 09:47:18 2012 Return-Path: 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 5336721F8716 for ; Mon, 17 Sep 2012 09:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 roON+hc-KGC2 for ; Mon, 17 Sep 2012 09:47:17 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 041C821F8714 for ; Mon, 17 Sep 2012 09:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14221; q=dns/txt; s=iport; t=1347900437; x=1349110037; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XBWyehhoFQtoRY1hK1M+o3hDY1bi7tisy5kccYDjhXg=; b=XS+bxdM3i7bDDSr7uqC/HTY6v1ZtTxIQ8XGmeL5UdBsLRUW02bpcn4S2 78p6VXkFAeZ5rxPEHm8hxdt1E44Sqv4wUZvlN4gWk0B3mS17Pnf7AqOA/ MdXVYeG4YQ5ufw///2Eh1tfBJpLYVSJ+zlrv8ABuIoKPx5Csi5amyTs0i I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAMZTV1CtJV2b/2dsb2JhbABEgkuoFYhTAYhjgQeCIAEBAQMBAQEBDwEaQQQFAgUHAgICAQgOAwQBAQEKHQcbDAsUCQgCBA4FCAEZh1gGC5pcn3MEix2GCGADlnaKBYMfgWmBLoE4ghc X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208,217";a="119396244" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 17 Sep 2012 16:47:16 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8HGlGG7003499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 16:47:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 11:47:16 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Emil Ivov Thread-Topic: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt Thread-Index: AQHNY6F+/LEFvCvLC0CLcDi4fxclSZcx8gqQgAAM1pCAVrIoAP//1knQ Date: Mon, 17 Sep 2012 16:47:15 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A147AA88C@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A052D666F@xmb-rcd-x10.cisco.com> <5051A76A.7090606@jitsi.org> In-Reply-To: <5051A76A.7090606@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.29.37] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--26.863400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A147AA88Cxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "Prashanth Patil \(praspati\)" , "mmusic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt X-BeenThere: mmusic@ietf.org 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: Mon, 17 Sep 2012 16:47:18 -0000 --_000_913383AAA69FF945B8F946018B75898A147AA88Cxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Emil - Thanks for the comments. we are in the process of updating the draft - We are planning to add the high-lighted sentence in Introduction, please le= t us know if you have any further comments. Although ICE does allow an "ICE restart", this is done by sending a re-INVI= TE which goes over the SIP signaling path. The SIP signaling path is often = slower than the media path (which needs to be recovered as quickly as possi= ble), consumes an extra half round trip, and incurs an additional delay if = the mobility event forces the endpoint to re-connect with its SIP proxy. Wh= en a device changes its IP address, it is necessary for it to re-establish = connectivity with its SIP proxy, which can be performed in parallel with th= e steps described in this document. This document describes how mobility is= performed entirely in the media path, without the additional delay of re-e= stablishing SIP connectivity, issuing a new offer/answer, or the complicati= ons of multiple SIP offers. This document considers re-establishing bi-dire= ctional media the most critical aspect of a successful mobility event, and = its efforts are towards meeting that goal. We will also added the following text at the end of section 3.1 The Mobile device would also in parallel re-establish connection with the S= IP proxy and if the ICE connectivity checks in the previous steps are not s= uccessful then issues new offer/answer and restarts ICE. --Tiru. > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Thursday, September 13, 2012 2:59 PM > To: Tirumaleswar Reddy (tireddy) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice- > mobility-01.txt > > Hey Tiru, > > One thing that I think this document is not very clear about is its > relationship to standard mobility handling (i.e. through ICE restart). > > As far as I can see, ICE restart is only mentioned when describing its > inefficiency. > > You did confirm in Vancouver that ICE Mobility is only meant as an > optimisation that would only take place until the ICE restart completes > but I don't see it anywhere in the text. Or am I missing something? > > Cheers, > Emil > > On 20.07.12, 13:36, Tirumaleswar Reddy (tireddy) wrote: > > Hi all, > > > > Dan, Prashanth and I have submitted a draft that explains how > > endpoint mobility can be achieved using ICE. Two mechanisms are > > shown, one where both endpoints support ICE and another where only > > one endpoint supports ICE. When only one endpoint supports ICE, a > > TURN server provides mobility. > > > > http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-01.t= xt > > > > Please let know your comments. If time permits we'd present the > > draft in Vancouver. > > > > Regards, Tiru. > > > >> -----Original Message----- From: Tirumaleswar Reddy (tireddy) Sent: > >> Friday, July 20, 2012 3:18 PM To: mmusic@ietf.org Subject: FW: New > >> Version Notification for draft-wing-mmusic-ice- mobility-01.txt > >> > >> -----Original Message----- From: internet-drafts@ietf.org > >> [mailto:internet-drafts@ietf.org] Sent: Tuesday, July 17, 2012 3:52 > >> AM To: Dan Wing (dwing) Cc: Prashanth Patil (praspati); > >> Tirumaleswar Reddy (tireddy) Subject: New Version Notification for > >> draft-wing-mmusic-ice-mobility- 01.txt > >> > >> > >> A new version of I-D, draft-wing-mmusic-ice-mobility-01.txt has > >> been successfully submitted by Dan Wing and posted to the IETF > >> repository. > >> > >> Filename: draft-wing-mmusic-ice-mobility Revision: 01 Title: > >> Mobility with ICE (MICE) Creation date: 2012-07-16 WG ID: > >> Individual Submission Number of pages: 12 URL: > >> http://www.ietf.org/internet-drafts/draft-wing-mmusic- > >> ice-mobility-01.txt Status: > >> http://datatracker.ietf.org/doc/draft-wing-mmusic-ice- mobility > >> Htmlized: http://tools.ietf.org/html/draft-wing-mmusic-ice- > >> mobility-01 Diff: > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-wing-mmusic- > >> ice-mobility-01 > >> > >> Abstract: This specification describes how endpoint mobility can be > >> achieved using ICE. Two mechanisms are shown, one where both > >> endpoints support ICE and another where only one endpoint supports > >> ICE. > >> > >> > >> > >> > >> The IETF Secretariat > > _______________________________________________ mmusic mailing list > > mmusic@ietf.org https://www.ietf.org/mailman/li= stinfo/mmusic > > > > -- > Emil Ivov, Ph.D. 67000 Strasbourg, > Project Lead France > Jitsi > emcho@jitsi.org PHONE: +33= .1.77.62.43.30 > http://jitsi.org FAX: +33.1.77.62.47.31 --_000_913383AAA69FF945B8F946018B75898A147AA88Cxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Emil -
 
Thanks for the comments. we are in the process of updating the draft -=
 
We are planning to add the high-lighted sentence in Introduction, plea= se let us know if you have any further comments.
 
Although ICE does allow an "ICE restart", this is done by se= nding a re-INVITE which goes over the SIP signaling path. The SIP signaling= path is often slower than the media path (which needs to be recovered as q= uickly as possible), consumes an extra half round trip, and incurs an additional delay if the mobility event forces the= endpoint to re-connect with its SIP proxy. When a device changes its IP= address, it is necessary for it to re-establish connectivity with its SIP = proxy, which can be performed in parallel with the steps described in this document. This document descr= ibes how mobility is performed entirely in the media path, without the addi= tional delay of re-establishing SIP connectivity, issuing a new offer/answe= r, or the complications of multiple SIP offers. This document considers re-establishing bi-directional media th= e most critical aspect of a successful mobility event, and its efforts are = towards meeting that goal.
 
We will also added the following text at the end of section 3.1
 
The Mobile device would also in parallel re-establish connection wi= th the SIP proxy and if the ICE connectivity checks in the previous steps a= re not successful then issues new offer/answer and restarts ICE.
 
--Tiru.
 
> -----Original Message-----
> From: Emil Ivov [mailto:emcho@= jitsi.org]
> Sent: Thursday, September 13, 2012 2:59 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmu= sic-ice-
> mobility-01.txt
>
> Hey Tiru,
>
> One thing that I think this document is not very clear about is i= ts
> relationship to standard mobility handling (i.e. through ICE rest= art).
>
> As far as I can see, ICE restart is only mentioned when describin= g its
> inefficiency.
>
> You did confirm in Vancouver that ICE Mobility is only meant as a= n
> optimisation that would only take place until the ICE restart com= pletes
> but I don't see it anywhere in the text. Or am I missing somethin= g?
>
> Cheers,
> Emil
>
> On 20.07.12, 13:36, Tirumaleswar Reddy (tireddy) wrote:
> > Hi all,
> >
> > Dan, Prashanth and I have submitted a draft that explains ho= w
> > endpoint mobility can be achieved using ICE.  Two mecha= nisms are
> > shown, one where both endpoints support ICE and another wher= e only
> > one endpoint supports ICE. When only one endpoint supports I= CE, a
> > TURN server provides mobility.
> >
> >
> >  Please let know your comments. If time permits we'd pr= esent the
> > draft in Vancouver.
> >
> > Regards, Tiru.
> >
> >> -----Original Message----- From: Tirumaleswar Reddy (tir= eddy) Sent:
> >> Friday, July 20, 2012 3:18 PM To: mmusic@ietf.org Subject= : FW: New
> >> Version Notification for draft-wing-mmusic-ice- mobility= -01.txt
> >>
> >> -----Original Message----- From: internet-drafts@ietf.org
> >> [mailto:internet-drafts@ietf.org] Sent:= Tuesday, July 17, 2012 3:52
> >> AM To: Dan Wing (dwing) Cc: Prashanth Patil (praspati);<= /div>
> >> Tirumaleswar Reddy (tireddy) Subject: New Version Notifi= cation for
> >> draft-wing-mmusic-ice-mobility- 01.txt
> >>
> >>
> >> A new version of I-D, draft-wing-mmusic-ice-mobility-01.= txt has
> >> been successfully submitted by Dan Wing and posted to th= e IETF
> >> repository.
> >>
> >> Filename:   draft-wing-mmusic-ice-mobility Rev= ision:         01 Title:
> >> Mobility with ICE (MICE) Creation date:   = ;  2012-07-16 WG ID:
> >> Individual Submission Number of pages: 12 URL:
> >> ice-mobility-01.txt Status:
> >> Htmlized:        http://tools.ietf.org/html/draft-wing-mmusic-ice-
> >> mobility-01 Diff:
> >> ice-mobility-01
> >>
> >> Abstract: This specification describes how endpoint mobi= lity can be
> >> achieved using ICE.  Two mechanisms are shown, one = where both
> >> endpoints support ICE and another where only one endpoin= t supports
> >> ICE.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> > _______________________________________________ mmusic maili= ng list
> >
>
> --
> Emil Ivov, Ph.D.        &= nbsp;           &nbs= p;  67000 Strasbourg,
> Project Lead         = ;            &n= bsp;     France
> Jitsi
> emcho@= jitsi.org        &nb= sp;            =    PHONE: +33.1.77.62.43.30
> http://jitsi= .org         &n= bsp;            = ; FAX:   +33.1.77.62.47.31
 
 --_000_913383AAA69FF945B8F946018B75898A147AA88Cxmbrcdx10ciscoc_-- From emil@sip-communicator.org Mon Sep 17 10:09:07 2012 Return-Path: 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 A2EC621F8723 for ; Mon, 17 Sep 2012 10:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] 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 p5-8eRYaP+K4 for ; Mon, 17 Sep 2012 10:09:06 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 417F521F86E4 for ; Mon, 17 Sep 2012 10:09:06 -0700 (PDT) Received: by wibhi8 with SMTP id hi8so2246163wib.13 for ; Mon, 17 Sep 2012 10:09:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=g/UuI5fKcRr8k5bH79DKjf6gb/Idn9JeLZoURlxIwH4=; b=eTSflDoqRBCjpnMsONtK9GLiJvmRL593la1dyvtYE6dTDogmbH90zzXm+QFIZkX0To bbMKfVElpsYnHcqboPKR4wzzSmXquQKVRYFm2NqoLyX27z0FlirY8CStP6cVmnsvTmyK j8auqT7bTnx72SVrf+fVR7izOrahNYRbJZhicb5IweQbk7+vUjthMPzD/YsDMAdsRvTK Hv29fX9TkiSyvocj6QDjYnAchyPEmee5aVgWnGx7qIxc5Kc520CBOWZVB9prx5XTYQzg DKwjgFmwNjhY7/K3PjXpLYOAZT5H+w+n20M3uZv+4gfQIbEbaKDiEvbuIgTFf3FfDYiK BQsg== Received: by 10.216.136.227 with SMTP id w77mr5921703wei.111.1347901745207; Mon, 17 Sep 2012 10:09:05 -0700 (PDT) Received: from pastropnet.u-strasbg.fr (pastropnet.u-strasbg.fr. [130.79.90.87]) by mx.google.com with ESMTPS id do5sm27086621wib.10.2012.09.17.10.09.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2012 10:09:03 -0700 (PDT) Message-ID: <5057592B.9070904@jitsi.org> Date: Mon, 17 Sep 2012 19:08:59 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A052D666F@xmb-rcd-x10.cisco.com> <5051A76A.7090606@jitsi.org> <913383AAA69FF945B8F946018B75898A147AA88C@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A147AA88C@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmD/LCROStzHYt1OMHVncsVpZIBQrz08ShLg2IqY8emqqXT7biBIP7Bp6mWRwPm0tnnqcgJ Cc: "Prashanth Patil \(praspati\)" , "mmusic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt X-BeenThere: mmusic@ietf.org 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: Mon, 17 Sep 2012 17:09:07 -0000 Hey Tiru, On 17.09.12, 18:47, Tirumaleswar Reddy (tireddy) wrote: > Hi Emil - > > Thanks for the comments. we are in the process of updating the draft - > > We are planning to add the high-lighted sentence in Introduction, please > let us know if you have any further comments. > > Although ICE does allow an "ICE restart", this is done by sending a > re-INVITE which goes over the SIP signaling path. The SIP signaling path > is often slower than the media path (which needs to be recovered as > quickly as possible), consumes an extra half round trip, and incurs an > additional delay if the mobility event forces the endpoint to re-connect > with its SIP proxy. *When a device changes its IP address, it is > necessary for it to re-establish connectivity with its SIP proxy, which > can be performed in parallel with the steps described in this document.* > This document describes how mobility is performed entirely in the media > path, without the additional delay of re-establishing SIP connectivity, > issuing a new offer/answer, or the complications of multiple SIP offers. > This document considers re-establishing bi-directional media the most > critical aspect of a successful mobility event, and its efforts are > towards meeting that goal. > > We will also added the following text at the end of section 3.1 > > *The Mobile device would also in parallel re-establish connection with > the SIP proxy and if the ICE connectivity checks in the previous steps > are not successful then issues new offer/answer and restarts ICE.* The above statement implies that the mobile node would need to first declare failure of ICE mobility and only then would it try an ICE restart. Yet, declaring failure would take many seconds with the default STUN timers so as a result handover latency is probably going to worsen more often than not. Besides, even in cases where ICE mobility succeeds, an ICE restart could still allow the use of higher priority candidates. Wouldn't it make more sense to always perform an ICE restart in parallel and basically consider ICE mobility a best effort attempt to shorten handover latency? Emil -- https://jitsi.org > > --Tiru. > >> -----Original Message----- >> From: Emil Ivov [mailto:emcho@jitsi.org] >> Sent: Thursday, September 13, 2012 2:59 PM >> To: Tirumaleswar Reddy (tireddy) >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice- >> mobility-01.txt >> >> Hey Tiru, >> >> One thing that I think this document is not very clear about is its >> relationship to standard mobility handling (i.e. through ICE restart). >> >> As far as I can see, ICE restart is only mentioned when describing its >> inefficiency. >> >> You did confirm in Vancouver that ICE Mobility is only meant as an >> optimisation that would only take place until the ICE restart completes >> but I don't see it anywhere in the text. Or am I missing something? >> >> Cheers, >> Emil >> >> On 20.07.12, 13:36, Tirumaleswar Reddy (tireddy) wrote: >> > Hi all, >> > >> > Dan, Prashanth and I have submitted a draft that explains how >> > endpoint mobility can be achieved using ICE. Two mechanisms are >> > shown, one where both endpoints support ICE and another where only >> > one endpoint supports ICE. When only one endpoint supports ICE, a >> > TURN server provides mobility. >> > >> > _http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-01.txt_ >> > >> > Please let know your comments. If time permits we'd present the >> > draft in Vancouver. >> > >> > Regards, Tiru. >> > >> >> -----Original Message----- From: Tirumaleswar Reddy (tireddy) Sent: >> >> Friday, July 20, 2012 3:18 PM To: _mmusic@ietf.org_ Subject: FW: New >> >> Version Notification for draft-wing-mmusic-ice- mobility-01.txt >> >> >> >> -----Original Message----- From: _internet-drafts@ietf.org_ >> >> _[mailto:internet-drafts@ietf.org]_ > Sent: Tuesday, July 17, 2012 3:52 >> >> AM To: Dan Wing (dwing) Cc: Prashanth Patil (praspati); >> >> Tirumaleswar Reddy (tireddy) Subject: New Version Notification for >> >> draft-wing-mmusic-ice-mobility- 01.txt >> >> >> >> >> >> A new version of I-D, draft-wing-mmusic-ice-mobility-01.txt has >> >> been successfully submitted by Dan Wing and posted to the IETF >> >> repository. >> >> >> >> Filename: draft-wing-mmusic-ice-mobility Revision: 01 Title: >> >> Mobility with ICE (MICE) Creation date: 2012-07-16 WG ID: >> >> Individual Submission Number of pages: 12 URL: >> >> _http://www.ietf.org/internet-drafts/draft-wing-mmusic-_ >> >> ice-mobility-01.txt Status: >> >> _http://datatracker.ietf.org/doc/draft-wing-mmusic-ice-_ mobility >> >> Htmlized: _http://tools.ietf.org/html/draft-wing-mmusic-ice-_ >> >> mobility-01 Diff: >> >> _http://tools.ietf.org/rfcdiff?url2=draft-wing-mmusic-_ >> >> ice-mobility-01 >> >> >> >> Abstract: This specification describes how endpoint mobility can be >> >> achieved using ICE. Two mechanisms are shown, one where both >> >> endpoints support ICE and another where only one endpoint supports >> >> ICE. >> >> >> >> >> >> >> >> >> >> The IETF Secretariat >> > _______________________________________________ mmusic mailing list >> > _mmusic@ietf.org_ > _https://www.ietf.org/mailman/listinfo/mmusic_ >> > From tireddy@cisco.com Mon Sep 17 10:30:36 2012 Return-Path: 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 2FB5421F8739 for ; Mon, 17 Sep 2012 10:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8] 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 eWP28dca8M0K for ; Mon, 17 Sep 2012 10:30:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EA4F721F8735 for ; Mon, 17 Sep 2012 10:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11594; q=dns/txt; s=iport; t=1347903035; x=1349112635; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LQZrGrB7niLwLEqViqMyCifrUeYVPV876WHoUQGiq2c=; b=JD5nYWsfgfZBsYxAhuk3jjkk8CltmnDEjhkmh3Vgcm/NTHsutbit1XzG pIvz8XTxu5MD+6rUNGr1ItD7SWIsxMA0K8lUnqDkHB+EgVq4nVTmMKhmc cllO8D0RYSKc6RCcBSijnhXKnyBskZpBsSsLHr3z7SQ50cCIjGFZGdPxJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAAFeV1CtJXG+/2dsb2JhbABEhge1JHOBB4IgAQEBAwESARAROA0FBwQCAQgRAwEBAQECAgYdAwICAh8RFAEICAEBBA4FCBqHTwMGBppdjRuIfg2JU4EhiR1jGoU8MmADlA2MbIMhgWmCZoFjNA X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="122393375" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 17 Sep 2012 17:30:22 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8HHUMnN002947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 17:30:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 12:30:21 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Martin Thomson Thread-Topic: Re : [MMUSIC] Comment on draft-wing-mmusic-ice-mobility-01 Thread-Index: Ac2U0iTJeZLknc5OSJWuefLN0sbqnAASrUOAAAou49A= Date: Mon, 17 Sep 2012 17:30:20 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A147AA925@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A147AA564@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.29.37] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--61.572800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Prashanth Patil \(praspati\)" , "mmusic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] Re : Comment on draft-wing-mmusic-ice-mobility-01 X-BeenThere: mmusic@ietf.org 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: Mon, 17 Sep 2012 17:30:36 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0NCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIg MTcsIDIwMTIgMTA6MDkgUE0NCj4gVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4g Q2M6IERhbiBXaW5nIChkd2luZyk7IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBQYWwgTWFy dGluc2VuIChwYWxtYXJ0aSkNCj4gU3ViamVjdDogUmU6IFJlIDogW01NVVNJQ10gQ29tbWVudCBv biBkcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDENCj4gDQo+IEhpIFRpcnUsDQo+IA0K PiBJcyB0aGVyZSBhbnkgcGFydGljdWxhciByZWFzb24gdGhhdCB5b3UgZGlkIG5vdCBpbmNsdWRl IHRoZSBtbXVzaWMNCj4gbGlzdCBpbiB5b3VyIHJlcGx5ID8NCkFkZGVkIG1tdXNpYyBsaXN0Lg0K PiANCj4gV291bGQgaXQgbm90IGJlIHN1ZmZpY2llbnQgdG8gbWFrZSB0aGUgZm9sbG93aW5nIG9i c2VydmF0aW9ucyAod2hpY2gNCj4gZG9uJ3QgZXZlbiByZXF1aXJlIFJGQyAyMTE5IGxhbmd1YWdl KToNCj4gIC0gYSBuZXcgaW50ZXJmYWNlIGFycml2aW5nIHRyaWdnZXJzIHRoZSBjcmVhdGlvbiBv ZiBhIG5ldyBsb2NhbCBjYW5kaWRhdGUNCj4gIC0gYSBuZXcgbG9jYWwgY2FuZGlkYXRlIGlzIGFk ZGVkIHRvIGEgcGFpciB3aXRoIGFsbCBrbm93biByZW1vdGUgY2FuZGlkYXRlcw0KPiAgLSBjb25u ZWN0aXZpdHkgY2hlY2tpbmcgY2FuIGJlIHBlcmZvcm1lZCBvbiBuZXcgY2FuZGlkYXRlIHBhaXJz DQo+ICAtIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiBtaWdodCBiZSBtb3JlIGVmZmljaWVudCBpZiB0 aGUgaW50ZXJmYWNlDQo+IGNoYW5nZSBsZWF2ZXMgeW91IHdpdGggbm8gYWN0aXZlIGludGVyZmFj ZXMgKGlmIGl0IHdlcmVuJ3QgYWxyZWFkeQ0KPiBvYnZpb3VzIHRoYXQgMSBSVFQgPCAyIFJUVCkN Cg0KQWdncmVzc2l2ZSBub21pbmF0aW9uIGV4cGxhaW5lZCBpbiBzZWN0aW9uIDMuMSBpcyBvbmx5 IHJlbGV2YW50IGZvciBzY2VuYXJpb3MgaW52b2x2aW5nICJicmVhayBiZWZvcmUgbWFrZSIgYW5k IG5vdCBmb3Igb3RoZXIgc2NlbmFyaW9zLiANCklmIGl0IGlzICJtYWtlIGJlZm9yZSBicmVhayIg dGhlbiB0aGUgTW9iaWxlIERldmljZSBjYW4gcmUtZXN0YWJsaXNoIGNvbm5lY3Rpb24gd2l0aCBT SVAgcHJveHkgdXNpbmcgdGhlIG5ldyBpbnRlcmZhY2UsIGdhdGhlciBuZXcgY2FuZGlkYXRlcyBm b3IgdGhlIG5ldyBpbnRlcmZhY2UsIHNlbmQgdXBkYXRlZCBvZmZlci9hbnN3ZXIgYW5kIHVzZSBJ Q0UgcmVzdGFydC4gT25seSBhZnRlciB0aGUgbWVkaWEgc3RhcnRzIGZsb3dpbmcgdXNpbmcgdGhl IG5ldyBpbnRlcmZhY2UgZGlzYWJsZSB0aGUgb2xkIGludGVyZmFjZS4NCg0Kd2Ugd2lsbCBpbmNs dWRlIG1vcmUgZGVzY3JpcHRpb24gb24gd2hlbiBpdCBzaG91bGQgYmUgdXNlZC4NCg0KPiANCj4g U2lnbmFsbGluZyBNT0JJTElUWS1FVkVOVCBpcyBub3Qgc29tZXRoaW5nIHRoYXQgaXMgYWRlcXVh dGVseQ0KPiBleHBsYWluZWQgYnkgeW91ciB0ZXh0LCBjb25jZW50cmF0aW5nIGFzIGl0IGRvZXMg b24gdGhlIHdoYXQgYW5kIG5vdA0KPiB0aGUgd2h5LiAgSSBtaWdodCBpbmZlciBmcm9tIHRoZSBi ZWhhdmlvdXIgdGhhdCBNT0JJTElUWS1FVkVOVA0KPiBpbmRpY2F0ZXMgdGhhdCBvdGhlciBpbnRl cmZhY2VzIGFyZSBpbnZhbGlkLiAgDQoNClllcywgdGhpcyBpcyBzY2VuYXJpbyBvZiBpbnRlcmVz dCB0byBNb2JpbGl0eSB1c2luZyBJQ0UuDQoNCj4gSSB3b3VsZCBwcmVmZXIgbm90IHRvDQo+IGhh dmUgdGhlIHZhbGlkIGxpc3RzIGNsZWFyZWQgY29tcGxldGVseSBhcyBhIHJlc3VsdCBvZiBhICpu ZXcqDQo+IGludGVyZmFjZS4gIFRoZSBiZWhhdmlvdXIgeW91IGRlc2NyaWJlIGlzIG1vcmUgYXBw cm9wcmlhdGUgZm9yIHRoZQ0KPiBldmVudCB3aGVyZSBhbGwgZXhpc3RpbmcgaW50ZXJmYWNlcyBk cm9wLg0KPiBJJ2QgcHJlZmVyIHRvIHNlZSBhIGNsZWFyIGRlc2NyaXB0aW9uIG9mIHRoZSBzZW1h bnRpY3Mgb2YgdGhlDQo+IE1PQklMSVRZLUVWRU5ULiAgDQo+IFRoZSBtb3JlIHRoYXQgSSB0aGlu ayBvbiBpdCwgdGhlIGxlc3MgSSBhbSBjb252aW5jZWQNCj4gb2YgaXRzIHZhbHVlLiAgRm9yIGlu c3RhbmNlLCBJIGJlbGlldmUgaXQgdG8gYmUgYSBiZXR0ZXIgbW9kZWwgdG8NCj4gYXNzdW1lIHRo YXQgSUNFIG5ldmVyIGNvbXBsZXRlcywgaXQganVzdCBvY2Nhc2lvbmFsbHkgcHJvZHVjZXMgYQ0K PiB1c2FibGUgcGFpciBvZiB0cmFuc3BvcnQgYWRkcmVzc2VzLiAgSSdkIGJlIGhhcHB5IHRvIGJl IGNvbnZpbmNlZA0KPiBvdGhlcndpc2UsIG9mIGNvdXJzZS4NCj4gDQo+IA0KPiBOaXRzOg0KPiBJ Q0UgZG9lc24ndCB0YWxrIGFib3V0IG1lZGlhIHN0cmVhbXMuICBJdCBtaWdodCBiZSBnb29kIHRv IHVzZQ0KPiB0ZXJtaW5vbG9neSBjb25zaXN0ZW50IHdpdGggUkZDIDUyNDUuDQoNClRoYW5rcywg d2Ugd2lsbCBmaXggdGhhdCBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KDQotLVRpcnUuDQoNCj4gDQo+ IC0tTWFydGluDQo+IA0KPiBPbiAxNyBTZXB0ZW1iZXIgMjAxMiAwNTo0NCwgVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KQ0KPiA8dGlyZWRkeUBjaXNjby5jb20+IHdyb3RlOg0KPiA+IEhpIE1h cnRpbiDigJMNCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSBjb21tZW50cywgcGxl YXNlIHNlZSBpbmxpbmUgW1RpcnVdDQo+ID4NCj4gPg0KPiA+DQo+ID4+IE1lc3NhZ2U6IDENCj4g Pg0KPiA+PiBEYXRlOiBXZWQsIDEyIFNlcCAyMDEyIDE3OjA3OjI2IC0wNzAwDQo+ID4NCj4gPj4g RnJvbTogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NCj4gPg0KPiA+ PiBUbzogbW11c2ljQGlldGYub3JnDQo+ID4NCj4gPj4gU3ViamVjdDogW01NVVNJQ10gQ29tbWVu dCBvbiBkcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDENCj4gPg0KPiA+PiBNZXNzYWdl LUlEOg0KPiA+DQo+ID4+ICAgICA8Q0FCa2dubldKdzZxdWVTRDVqaDFPdGF4QmVKV0p3RUUxNF9Z NUt0ZTBTRkhDSzF3aWR3QG1haWwuZ21haWwuY29tPg0KPiA+DQo+ID4+IENvbnRlbnQtVHlwZTog dGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtOA0KPiA+DQo+ID4+DQo+ID4NCj4gPj4gSSB0aGluayB0 aGF0IHRoaXMgaXMgYSB3b3J0aHdoaWxlIHByb2JsZW0gdG8gc29sdmUuICBJIGhhdmUgYSBjb25j ZXJuDQo+ID4NCj4gPj4gYWJvdXQgdGhlIG1lY2hhbmlzbS4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+ IFNwZWNpZmljYWxseToNCj4gPg0KPiA+Pg0KPiA+DQo+ID4+ICAgIDMuICBJZiB0aGlzIGludGVy ZmFjZSBpcyB0aGUgb25seSBzdWl0YWJsZSBpbnRlcmZhY2UgZm9yIG1lZGlhICh0aGF0DQo+ID4N Cj4gPj4gICAgICAgIGlzLCBvdGhlciBzdWl0YWJsZSBpbnRlcmZhY2VzIGhhdmUgYmVlbiBsb3N0 KSwgdGhlbiB0aGUNCj4gPg0KPiA+PiAgICAgICAgY29ubmVjdGl2aXR5IGNoZWNrIGZyb20gdGhl IHByZXZpb3VzIHN0ZXAgU0hPVUxEIGFsc28gaW5jbHVkZSB0aGUNCj4gPg0KPiA+PiAgICAgICAg VVNFLUNBTkRJREFURSBhdHRyaWJ1dGUgdG8gc2lnbmFscyBhbiBhZ2dyZXNzaXZlIG5vbWluYXRp b24gKHNlZQ0KPiA+DQo+ID4+ICAgICAgICBTZWN0aW9uIDIuNiBvZiBbUkZDNTI0NV0pLCBhbmQg bWVkaWEgTUFZIGltbWVkaWF0ZWx5IGJlZ2luDQo+ID4NCj4gPj4gICAgICAgIGZsb3dpbmcgb3Zl ciB0aGF0IGludGVyZmFjZS4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+IFRoaXMgYXNzdW1lcyB0aGF0 IHRoZSBJUDpwb3J0IHBhaXIgdGhhdCB3YXMgcHJldmlvdXNseSBpbiB1c2UgcmVhY2hlcw0KPiA+ DQo+ID4+IHRoZSBzYW1lIGhvc3QgZnJvbSB0aGUgbmV3IGludGVyZmFjZS4gIEkgdW5kZXJzdGFu ZCB0aGUgZGVzaXJlIHRvIHNlbmQNCj4gPg0KPiA+PiBzdHJhaWdodCBhd2F5LCBhbmQgcmVxdWly aW5nIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiBldmVuIHdoZXJlIGl0IGlzDQo+ID4NCj4gPj4gbm90 IG5vcm1hbGx5IHVzZWQgaXMgcmVhc29uYWJsZSwgYnV0IHNlbmRpbmcgcHJpb3IgdG8gYSBjb25u ZWN0aXZpdHkNCj4gPg0KPiA+PiBjaGVjayBpcyBub3QgYSBnb29kIGlkZWEuDQo+ID4NCj4gPg0K PiA+DQo+ID4gT3VyIGludGVudGlvbiBpcyB0byBzZW5kIG1lZGlhIHN0cmFpZ2h0IGF3YXkgb25s eSBhZnRlciBJQ0UgY29ubmVjdGl2aXR5DQo+ID4gY2hlY2sgaXMgc3VjY2Vzc2Z1bCB1c2luZyBh Z2dyZXNzaXZlIG5vbWluYXRpb24uIFdlIHdpbGwgZml4IHRoZSB0ZXh0IGZvcg0KPiA+IHBvaW50 IDMuDQo+ID4NCj4gPg0KPiA+DQo+ID4+DQo+ID4NCj4gPj4gTm90ZTogU3RlcCA0IG9mIHRoZSBz YW1lIHByb2NlZHVyZSBpcyBpbml0aWF0ZWQgb24gdGhlICpvdGhlciogSUNFDQo+ID4NCj4gPj4g cGVlci4gIFRoYXQgaXMsIHRoZSBvbmUgdGhhdCBpcyBub3Qgc3VmZmVyaW5nIGEgbW9iaWxpdHkg ZXZlbnQuICBUaGF0DQo+ID4NCj4gPj4gaXMgdmVyeSBtdWNoIHVuY2xlYXIgZnJvbSB0aGUgdGV4 dC4NCj4gPg0KPiA+DQo+ID4NCj4gPiBXZSBhcmUgdXBkYXRpbmcgc2VjdGlvbnMgMy4xIGFuZCAz LjIsIFBsZWFzZSBsZXQga25vdyBpZiB0aGUgYmVsb3cNCj4gPiBleHBsYW5hdGlvbiBtYWtlcyBp dCBiZXR0ZXINCj4gPg0KPiA+DQo+ID4NCj4gPiAzLjEuICBHYWluaW5nIGFuIEludGVyZmFjZQ0K PiA+DQo+ID4NCj4gPg0KPiA+ICAgIFdoZW4gZ2FpbmluZyBhbiBpbnRlcmZhY2Ugd2hpY2ggaXMg c3VpdGFibGUgdG8gc2VuZCBtZWRpYSBieSB0aGUNCj4gPg0KPiA+ICAgIGhvc3QncyBwb2xpY3kg KGlmIGFueSksIHRoZSBJQ0UgZW5kcG9pbnQgcGVyZm9ybXMgSUNFIE1vYmlsaXR5LiAgSUNFDQo+ ID4NCj4gPiAgICBNb2JpbGl0eSBpcyBwZXJmb3JtZWQgYnk6DQo+ID4NCj4gPg0KPiA+DQo+ID4g ICAgMS4gIFRoZSBJQ0UgZW5kcG9pbnQgY2xlYXJzIGl0cyBJQ0UgY2hlY2sgbGlzdCBhbmQgSUNF IFZhbGlkIExpc3QuDQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgMi4gIFRoZSBJQ0UgZW5kcG9pbnQg aW5pdGlhdGluZyBhbiBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrIG9uIHRoZSBuZXcNCj4gPg0KPiA+ ICAgICAgICBpbnRlcmZhY2UsIHdpdGggdGhlIE1PQklMSVRZLUVWRU5UIGF0dHJpYnV0ZS4NCj4g Pg0KPiA+DQo+ID4NCj4gPiAgICAzLiAgSWYgdGhpcyBpbnRlcmZhY2UgaXMgdGhlIG9ubHkgc3Vp dGFibGUgaW50ZXJmYWNlIGZvciBtZWRpYSAodGhhdA0KPiA+DQo+ID4gICAgICAgIGlzLCBvdGhl ciBzdWl0YWJsZSBpbnRlcmZhY2VzIGhhdmUgYmVlbiBsb3N0KSwgdGhlbiB0aGUNCj4gPg0KPiA+ ICAgICAgICBjb25uZWN0aXZpdHkgY2hlY2sgZnJvbSB0aGUgcHJldmlvdXMgc3RlcCBTSE9VTEQg YWxzbyBpbmNsdWRlIHRoZQ0KPiA+DQo+ID4gICAgICAgIFVTRS1DQU5ESURBVEUgYXR0cmlidXRl IHRvIHNpZ25hbHMgYW4gYWdncmVzc2l2ZSBub21pbmF0aW9uIChzZWUNCj4gPg0KPiA+ICAgICAg ICBTZWN0aW9uIDIuNiBvZiBbUkZDNTI0NV0pLCBhbmQgbWVkaWEgTUFZIGltbWVkaWF0ZWx5IGJl Z2luDQo+ID4NCj4gPiAgICAgICAgZmxvd2luZyBvdmVyIHRoYXQgaW50ZXJmYWNlIGFmdGVyIElD RSBjb25uZWN0aXZpdHkgY2hlY2sgaXMNCj4gPiBzdWNjZXNzZnVsLg0KPiA+DQo+ID4NCj4gPg0K PiA+ICAgIDQuICBUaGUgSUNFIGVuZHBvaW50IHBlcmZvcm1zICJEaXNjb3ZlcmluZyBQZWVyIFJl ZmxleGl2ZSBDYW5kaWRhdGVzIg0KPiA+DQo+ID4gICAgICAgIChTZWN0aW9uIDcuMS4zLjIuMSBv ZiBbUkZDNTI0NV0pLCAiQ29uc3RydWN0aW5nIGEgVmFsaWQgUGFpciINCj4gPg0KPiA+ICAgICAg ICAoU2VjdGlvbiA3LjEuMy4yLjIgb2YgW1JGQzUyNDVdKSwgIlVwZGF0aW5nIFBhaXIgU3RhdGVz IiAoU2VjdGlvbg0KPiA+DQo+ID4gICAgICAgIDcuMS4zLjIuMyBvZiBbUkZDNTI0NV0pLCBhbmQg IlVwZGF0aW5nIHRoZSBOb21pbmF0ZWQgRmxhZyINCj4gPg0KPiA+ICAgICAgICAoU2VjdGlvbiA3 LjEuMy4yLjQgb2YgW1JGQzUyNDVdKS4NCj4gPg0KPiA+DQo+ID4NCj4gPiAgICA1LiAgSWYgdGhl IElDRSBjb25uZWN0aXZpdHkgY2hlY2sgc3VjY2VlZHMgdGhlbiBJQ0UgYWdlbnRzIGNyZWF0ZXMg YQ0KPiA+DQo+ID4gICAgICAgIG5ldyBwYWlyLCBhZGRzIHRoZSBwYWlyIHRvIHRoZSB2YWxpZCBs aXN0IGFuZCBtYXJrcyBpdCBhcw0KPiA+DQo+ID4gICAgICAgIHNlbGVjdGVkLiAgVGhlIElDRSBh Z2VudCBjYW4gbm93IHNlbmQgbWVkaWEgdXNpbmcgdGhlIG5ld2x5DQo+ID4NCj4gPiAgICAgICAg c2VsZWN0ZWQgY2FuZGlkYXRlIHBhaXIsIGV2ZW4gaWYgaXQgaXMgcnVubmluZyBpbiBSZWd1bGFy DQo+ID4NCj4gPiAgICAgICAgTm9taW5hdGlvbiBtb2RlLg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAg IDYuICBPbmNlIElDRSBjb25uZWN0aXZpdHkgY2hlY2tzIGZvciBhbGwgb2YgdGhlIG1lZGlhIHN0 cmVhbXMgYXJlDQo+ID4NCj4gPiAgICAgICAgY29tcGxldGVkLCB0aGUgY29udHJvbGxpbmcgSUNF IGVuZHBvaW50IGZvbGxvd3MgdGhlIHByb2NlZHVyZXMgaW4NCj4gPg0KPiA+ICAgICAgICBTZWN0 aW9uIDExLjEgb2YgW1JGQzUyNDVdLCBzcGVjaWZpY2FsbHkgdG8gc2VuZCB1cGRhdGVkIG9mZmVy IGlmDQo+ID4NCj4gPiAgICAgICAgdGhlIGNhbmRpZGF0ZXMgaW4gdGhlIG0gYW5kIGMgbGluZXMg Zm9yIHRoZSBtZWRpYSBzdHJlYW0gKGNhbGxlZA0KPiA+DQo+ID4gICAgICAgIHRoZSBERUZBVUxU IENBTkRJREFURVMpIGRvIG5vdCBtYXRjaCBJQ0UncyBTRUxFQ1RFRCBDQU5ESURBVEVTDQo+ID4N Cj4gPiAgICAgICAgKGFsc28gc2VlIEFwcGVuZGl4IEIuOSBvZiBbUkZDNTI0NV0pLg0KPiA+DQo+ ID4NCj4gPg0KPiA+IDMuMi4gIFJlY2VpdmluZyBJQ0UgTW9iaWxpdHkgZXZlbnQNCj4gPg0KPiA+ DQo+ID4NCj4gPiAgICBBIFNUVU4gQmluZGluZyBSZXF1ZXN0IGNvbnRhaW5pbmcgdGhlIE1PQklM SVRZLUVWRU5UIGF0dHJpYnV0ZSBNQVkgYmUNCj4gPg0KPiA+ICAgIHJlY2VpdmVkIGJ5IGFuIElD RSBlbmRwb2ludC4gIElmIHRoaXMgaXMgcmVjZWl2ZWQgYmVmb3JlIHRoZSBlbmRwb2ludA0KPiA+ DQo+ID4gICAgaXMgaW4gdGhlIElDRSBDb21wbGV0ZWQgc3RhdGUsIGl0IHNob3VsZCBiZSBzaWxl bnRseSBkaXNjYXJkZWQuDQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgVGhlIGFnZW50IHJlbWVtYmVy cyB0aGUgaGlnaGVzdC1wcmlvcml0eSBub21pbmF0ZWQgcGFpcnMgaW4gdGhlIFZhbGlkDQo+ID4N Cj4gPiAgICBsaXN0IGZvciBlYWNoIGNvbXBvbmVudCBvZiB0aGUgbWVkaWEgc3RyZWFtLCBjYWxs ZWQgdGhlIHByZXZpb3VzDQo+ID4NCj4gPiAgICBzZWxlY3RlZCBwYWlycy4gIEl0IGNvbnRpbnVl cyBzZW5kaW5nIG1lZGlhIHRvIHRoYXQgYWRkcmVzcyB1bnRpbCBpdA0KPiA+DQo+ID4gICAgZmlu aXNoZXMgd2l0aCB0aGUgc3RlcHMgZGVzY3JpYmVkIGJlbG93LiAgQmVjYXVzZSB0aG9zZSBwYWNr ZXRzIG1pZ2h0DQo+ID4NCj4gPiAgICBub3QgYmUgcmVjZWl2ZWQgZHVlIHRvIHRoZSBtb2JpbGl0 eSBldmVudCwgaXQgTUFZIGNhY2hlIGEgY29weSBvZg0KPiA+DQo+ID4gICAgdGhvc2UgcGFja2V0 cy4NCj4gPg0KPiA+DQo+ID4NCj4gPiAgICAxLiAgVGhlIElDRSBlbmRwb2ludCBjbGVhcnMgaXRz IElDRSBjaGVjayBsaXN0IGFuZCBJQ0UgVmFsaWQgTGlzdC4NCj4gPg0KPiA+DQo+ID4NCj4gPiAg ICAyLiAgVGhlIElDRSBhZ2VudCBjb25zdHJ1Y3RzIGEgcGFpciB3aG9zZSBsb2NhbCBjYW5kaWRh dGUgaXMgZXF1YWwgdG8NCj4gPg0KPiA+ICAgICAgICB0aGUgdHJhbnNwb3J0IGFkZHJlc3Mgb24g d2hpY2ggdGhlIFNUVU4gcmVxdWVzdCB3YXMgcmVjZWl2ZWQgd2l0aA0KPiA+DQo+ID4gICAgICAg IE1PQklMSVRZLUVWRU5UIGF0dHJpYnV0ZSwgYW5kIGEgcmVtb3RlIGNhbmRpZGF0ZSBlcXVhbCB0 byB0aGUNCj4gPg0KPiA+ICAgICAgICBzb3VyY2UgdHJhbnNwb3J0IGFkZHJlc3Mgd2hlcmUgdGhl IFNUVU4gcmVxdWVzdCBjYW1lIGZyb20uICBUaGUNCj4gPg0KPiA+ICAgICAgICBJQ0UgYWdlbnQg d2lsbCBwZXJmb3JtIHRyaWdnZXJlZCBjaGVjayB1c2luZyB0aGlzIG5ldyBwYWlyIGFuZCBpZg0K PiA+DQo+ID4gICAgICAgIHRoZSBjb25uZWN0aXZpdHkgY2hlY2sgaXMgc3VjY2Vzc2Z1bCwgdGhl IHBhaXIgaXMgdGhlbiBhZGRlZCB0bw0KPiA+DQo+ID4gICAgICAgIHRoZSB2YWxpZCBsaXN0LiAg VGhlIGFnZW50IHNldHMgdGhlIG5vbWluYXRlZCBmbGFnIGluIHRoZSB2YWxpZA0KPiA+DQo+ID4g ICAgICAgIHBhaXIgdG8gdHJ1ZSBhbmQgY2FuIG5vdyB1c2UgdGhlIG5ldyBwYWlyIGZvciBzZW5k aW5nIG1lZGlhLg0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tVGlydS4NCj4gPg0KPiA+DQo+ID4NCj4g Pj4NCj4gPg0KPiA+PiAtLU1hcnRpbg0KPiA+DQo+ID4NCg== From abegen@cisco.com Mon Sep 17 10:39:48 2012 Return-Path: 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 E156321F8713 for ; Mon, 17 Sep 2012 10:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.932 X-Spam-Level: X-Spam-Status: No, score=-8.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666] 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 N+EHsqTa84PH for ; Mon, 17 Sep 2012 10:39:48 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D4F2621F8712 for ; Mon, 17 Sep 2012 10:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7191; q=dns/txt; s=iport; t=1347903587; x=1349113187; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=6Thziiz82oVAeeJH3QgdUwzLaC8tczW4LQPzPuE2Hck=; b=eHtOiCZZMP1+nPbnw/VHNq+NvKL5O8IrI0ZyH1Xyp0UCtX7tWTnP34E1 dE9eWYsRsuo5O3zqa1YYd3DphfBj5p2nQ5oZAGKv9WJUqP4rmZ8LXeTPZ ABlmApwgE0dZckc1Mv9qZaKUvEgRj50aDqbBJZjfSetNCjSaeW2quZuoK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAM9fV1CtJXG//2dsb2JhbABBA4JLI6d5iFMBiGOBB4IgAQEBBAEBAQ8BNiULEgEIBwoDAQIoLgsUCQgCBAENBSKHXgEKmk6feYshg0SDJAOVYoEUjSSBaYEugTiCFw X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208,217";a="122416987" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 17 Sep 2012 17:39:47 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8HHdlpL021089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 17:39:47 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 12:39:45 -0500 From: "Ali C. Begen (abegen)" To: Kevin Gross , "Miguel A. Garcia" Thread-Topic: [MMUSIC] WG Poll for consensus on duplicated streams Thread-Index: AQHNkX//TyTi1wyzUUm4ClYuCMrGmZeIndgAgAZGwIA= Date: Mon, 17 Sep 2012 17:39:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.250.247] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--45.997900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC7CD831A078abegenciscocom_" MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , mmusic Subject: Re: [MMUSIC] WG Poll for consensus on duplicated streams X-BeenThere: mmusic@ietf.org 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: Mon, 17 Sep 2012 17:39:49 -0000 --_000_CC7CD831A078abegenciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kevin, Although the drafts are related to each other, they define different things= and should better be kept separate. For example, one of them defines the s= emantics for duplication and the duplication can be done via several differ= ent ways. The other one is just the temporal interleaving - a standalone at= tribute in SDP. Thanks, -acbegen From: Kevin Gross > Date: Thursday, September 13, 2012 9:48 AM To: "Miguel com>" > Cc: Flemming Andreasen >, "mm= usic@ietf.org" > Subject: Re: [MMUSIC] WG Poll for consensus on duplicated streams I support adoption. The drafts look like a good starting point though it se= ems these two proposals could be combined into a single draft if desired. I= assume there's a reason they've been separated. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com, www.X192.org On Thu, Sep 13, 2012 at 1:18 AM, Miguel A. Garcia > wrote: At the last IETF meeting we had presentation of two drafts, both related to the expression of duplicated streams in SDP. We noticed there was support to progress these drafts. These drafts are complementary to work going on in AVTEXT, where there is a normative dependency. These are the documents: http://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ http://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/ We would like to poll the working group for adopting these two documents as WG items, once we get approved milestones. Please indicate whether you support or not this new work within the next 5 working days. Flemming and Miguel (co-chairs). /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_CC7CD831A078abegenciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4CC87CA7C639464D8D575CB371FDD7C5@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Kevin,

Although the drafts are related to each other, they define different t= hings and should better be kept separate. For example, one of them defines = the semantics for duplication and the duplication can be done via several d= ifferent ways. The other one is just the temporal interleaving - a standalone attribute in SDP.

Thanks,
-acbegen

From: Kevin Gross <kevin.gross@avanw.com>
Date: Thursday, September 13, 2012 = 9:48 AM
To: "Miguel com>" <= miguel.a.garcia@ericsson.co= m>
Cc: Flemming Andreasen <fandreas@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] WG Poll for c= onsensus on duplicated streams

I support adoption. The drafts look like a good starting point though = it seems these two proposals could be combined into a single draft if desir= ed. I assume there's a reason they've been separated.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com, www.X192.org



On Thu, Sep 13, 2012 at 1:18 AM, Miguel A. Garci= a <Migue= l.A.Garcia@ericsson.com> wrote:
At the last IETF meeting we had presentation of two drafts, both
related to the expression of duplicated streams in SDP. We noticed
there was support to progress these drafts. These drafts are
complementary to work going on in AVTEXT, where there is a normative
dependency.

These are the documents:

http://datatracker.ietf.org/doc/draft-beg= en-mmusic-redundancy-grouping/
http://datatracker.ietf.org/doc/draft-b= egen-mmusic-temporal-interleaving/

We would like to poll the working group for adopting these two
documents as WG items, once we get approved milestones.

Please indicate whether you support or not this new work within the
next 5 working days.

Flemming and Miguel (co-chairs).

/Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

_______________________________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic

 --_000_CC7CD831A078abegenciscocom_-- From tireddy@cisco.com Mon Sep 17 19:57:52 2012 Return-Path: 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 1773E21F8440 for ; Mon, 17 Sep 2012 19:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Y4mU8ZZCK-3R for ; Mon, 17 Sep 2012 19:57:51 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E42A221E803D for ; Mon, 17 Sep 2012 19:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8144; q=dns/txt; s=iport; t=1347937071; x=1349146671; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qocWrJSJfHhtSEEncabHgyVSCiw+Wakh2DcXVJr5TVw=; b=Jay+CGcE3iCNp4YjDPZkrPEtAkGJ8AcbRh4J1MaZcon4rzzpcDVlepTx Qbz2jdi+HZd20pHOBrl12+2O11weODzUDI0KqwmgEjnpzAGfq0ikD9y10 NS064bh1sPV3ehipA2WJhWGw8TosEqGfJlld+OiMJweQejl36yv/o43nb E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAF3iV1CtJXG+/2dsb2JhbABFvCSBB4IgAQEBAwEBAQEPAScyAgQFAgwEAgEIDgMEAQEBChQJBycLFAkIAgQOBQgBGYdYBguaL6A2iyGGCGADkjGERY0kgWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,439,1344211200"; d="scan'208";a="122582281" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 18 Sep 2012 02:57:50 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8I2vm4C020365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 02:57:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 21:56:51 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Emil Ivov Thread-Topic: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt Thread-Index: AQHNY6F+/LEFvCvLC0CLcDi4fxclSZcx8gqQgAAM1pCAVrIoAP//1knQgAbzf4D//8gbsA== Date: Tue, 18 Sep 2012 02:56:51 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A147AB415@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A052D666F@xmb-rcd-x10.cisco.com> <5051A76A.7090606@jitsi.org> <913383AAA69FF945B8F946018B75898A147AA88C@xmb-rcd-x10.cisco.com> <5057592B.9070904@jitsi.org> In-Reply-To: <5057592B.9070904@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.81.132] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--74.210400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Prashanth Patil \(praspati\)" , "mmusic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt X-BeenThere: mmusic@ietf.org 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: Tue, 18 Sep 2012 02:57:52 -0000 > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Monday, September 17, 2012 10:39 PM > To: Tirumaleswar Reddy (tireddy) > Cc: mmusic@ietf.org; Dan Wing (dwing); Prashanth Patil (praspati); Pal > Martinsen (palmarti) > Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice- > mobility-01.txt >=20 > Hey Tiru, >=20 > On 17.09.12, 18:47, Tirumaleswar Reddy (tireddy) wrote: > > Hi Emil - > > > > Thanks for the comments. we are in the process of updating the draft - > > > > We are planning to add the high-lighted sentence in Introduction, pleas= e > > let us know if you have any further comments. > > > > Although ICE does allow an "ICE restart", this is done by sending a > > re-INVITE which goes over the SIP signaling path. The SIP signaling pat= h > > is often slower than the media path (which needs to be recovered as > > quickly as possible), consumes an extra half round trip, and incurs an > > additional delay if the mobility event forces the endpoint to re-connec= t > > with its SIP proxy. *When a device changes its IP address, it is > > necessary for it to re-establish connectivity with its SIP proxy, which > > can be performed in parallel with the steps described in this document.= * > > This document describes how mobility is performed entirely in the media > > path, without the additional delay of re-establishing SIP connectivity, > > issuing a new offer/answer, or the complications of multiple SIP offers= . > > This document considers re-establishing bi-directional media the most > > critical aspect of a successful mobility event, and its efforts are > > towards meeting that goal. > > > > We will also added the following text at the end of section 3.1 > > > > *The Mobile device would also in parallel re-establish connection with > > the SIP proxy and if the ICE connectivity checks in the previous steps > > are not successful then issues new offer/answer and restarts ICE.* >=20 > The above statement implies that the mobile node would need to first > declare failure of ICE mobility and only then would it try an ICE > restart. Yet, declaring failure would take many seconds with the default > STUN timers so as a result handover latency is probably going to worsen > more often than not. The only reason I can think why ICE Mobility would fail and ICE restart suc= ceed is because of Simultaneous Mobility, we are trying to solve the proble= m in a different way (This text is yet to be published in the next version = of the draft) 3.3 Simultaneous Mobility Mobile device SHOULD include MOBILTY-ROAM attribute in all of its STUN requests and STUN responses. If the ICE peer also includes MOBILTY-ROAM attribute in all its STUN requests and STUN responses then it means both the endpoints are mobile and can roam at the same time between networks. In order to support simultaneously mobility without breaking media sessions between them, both ICE agents MUST perform the following steps : 1. The ICE agent will keep the relayed candidates alive using Refresh transaction, as described in [RFC5766]. 2. When gaining an interface, the ICE agent will refresh it's allocation with TURN server using Section 4.2. 3. The ICE agent will perform the steps described in Section 3.1. 4. If the ICE connectivity check succeeds only with local and remote relayed candidates, it suggests that even the other peer is roaming at the same time. The ICE agent creates a new pair using the relayed candidates, adds the pair to the valid list and marks it as selected. The ICE agent can now send media using the newly selected relayed candidate pair. The Mobile device in parallel re-establishes connection with SIP proxy, issues new offer/answer and restarts ICE. Hence media will only be sent briefly on TURN relays. >=20 > Besides, even in cases where ICE mobility succeeds, an ICE restart could > still allow the use of higher priority candidates. ICE Mobility will pick the candidates on the new interface based on priorit= y (RFC 3484 or latest RFC 6724). Is there any specific case you have in min= d that ICE restart would pick higher priority candidates and not ICE Mobility othe= r than Simultaneous Mobility problem ? --Tiru. >=20 > Wouldn't it make more sense to always perform an ICE restart in parallel > and basically consider ICE mobility a best effort attempt to shorten > handover latency? >=20 > Emil > -- > https://jitsi.org > > > > --Tiru. > > > >> -----Original Message----- > >> From: Emil Ivov [mailto:emcho@jitsi.org] > >> Sent: Thursday, September 13, 2012 2:59 PM > >> To: Tirumaleswar Reddy (tireddy) > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-i= ce- > >> mobility-01.txt > >> > >> Hey Tiru, > >> > >> One thing that I think this document is not very clear about is its > >> relationship to standard mobility handling (i.e. through ICE restart). > >> > >> As far as I can see, ICE restart is only mentioned when describing its > >> inefficiency. > >> > >> You did confirm in Vancouver that ICE Mobility is only meant as an > >> optimisation that would only take place until the ICE restart complete= s > >> but I don't see it anywhere in the text. Or am I missing something? > >> > >> Cheers, > >> Emil > >> > >> On 20.07.12, 13:36, Tirumaleswar Reddy (tireddy) wrote: > >> > Hi all, > >> > > >> > Dan, Prashanth and I have submitted a draft that explains how > >> > endpoint mobility can be achieved using ICE. Two mechanisms are > >> > shown, one where both endpoints support ICE and another where only > >> > one endpoint supports ICE. When only one endpoint supports ICE, a > >> > TURN server provides mobility. > >> > > >> > _http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility- > 01.txt_ > >> > > >> > Please let know your comments. If time permits we'd present the > >> > draft in Vancouver. > >> > > >> > Regards, Tiru. > >> > > >> >> -----Original Message----- From: Tirumaleswar Reddy (tireddy) Sent: > >> >> Friday, July 20, 2012 3:18 PM To: _mmusic@ietf.org_ > Subject: FW: New > >> >> Version Notification for draft-wing-mmusic-ice- mobility-01.txt > >> >> > >> >> -----Original Message----- From: _internet-drafts@ietf.org_ > > >> >> _[mailto:internet-drafts@ietf.org]_ > > Sent: Tuesday, July 17, 2012= 3:52 > >> >> AM To: Dan Wing (dwing) Cc: Prashanth Patil (praspati); > >> >> Tirumaleswar Reddy (tireddy) Subject: New Version Notification for > >> >> draft-wing-mmusic-ice-mobility- 01.txt > >> >> > >> >> > >> >> A new version of I-D, draft-wing-mmusic-ice-mobility-01.txt has > >> >> been successfully submitted by Dan Wing and posted to the IETF > >> >> repository. > >> >> > >> >> Filename: draft-wing-mmusic-ice-mobility Revision: 01 Tit= le: > >> >> Mobility with ICE (MICE) Creation date: 2012-07-16 WG ID: > >> >> Individual Submission Number of pages: 12 URL: > >> >> _http://www.ietf.org/internet-drafts/draft-wing-mmusic-_ > >> >> ice-mobility-01.txt Status: > >> >> _http://datatracker.ietf.org/doc/draft-wing-mmusic-ice-_ mobility > >> >> Htmlized: _http://tools.ietf.org/html/draft-wing-mmusic-ice-= _ > >> >> mobility-01 Diff: > >> >> _http://tools.ietf.org/rfcdiff?url2=3Ddraft-wing-mmusic-_ > >> >> ice-mobility-01 > >> >> > >> >> Abstract: This specification describes how endpoint mobility can be > >> >> achieved using ICE. Two mechanisms are shown, one where both > >> >> endpoints support ICE and another where only one endpoint supports > >> >> ICE. > >> >> > >> >> > >> >> > >> >> > >> >> The IETF Secretariat > >> > _______________________________________________ mmusic mailing list > >> > _mmusic@ietf.org_ > > _https://www.ietf.org/mailman/listinfo/mmusic_ > >> > From emil@sip-communicator.org Tue Sep 18 02:41:39 2012 Return-Path: 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 0C99C21F87D7 for ; Tue, 18 Sep 2012 02:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 PvlQAfZl8TZL for ; Tue, 18 Sep 2012 02:41:38 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5991621F87D6 for ; Tue, 18 Sep 2012 02:41:37 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4110022wgb.13 for ; Tue, 18 Sep 2012 02:41:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=yDicBX4ePeA60s8TE9j1J0HgE0A6dnJ8AxWorBHbSLE=; b=QNmq6p6cpc3mUpxTWvyb+f4acy8rU+6oi4+OP0f3KfP0sXxD4wSA+3+BHTr7sdsbPM CFnuiZBSb6IwP1tKz7By1e5ZdWcpS/yhRZjM4z1ZbmtlMONl5QkbjLoZ5SHd1T6O0I5i kffYwBOIt1I5UXPcZxn89FeN1inKGbhNFaqGbuh1D4QrzEGX5JbfGQ7CmULQKD8IOpPn 0exWRloR9oBs2g7weYkEB63RMFtizoqmHA6bEaEb2At2tOHZ3b1kFxVTfatkup5KZ7Ew dXZXpGfVEP4qfIr52Y5l+rOP8s7Vv8A/kpNdHAIFrNW3xINbxb7RaUDjYefVZGEyKLOC I2WA== Received: by 10.180.85.167 with SMTP id i7mr22128922wiz.8.1347961296420; Tue, 18 Sep 2012 02:41:36 -0700 (PDT) Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:6d9e:5cc0:90cb:9fbb]) by mx.google.com with ESMTPS id dp8sm30979187wib.3.2012.09.18.02.41.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 02:41:35 -0700 (PDT) Message-ID: <505841CE.30602@jitsi.org> Date: Tue, 18 Sep 2012 11:41:34 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A052D666F@xmb-rcd-x10.cisco.com> <5051A76A.7090606@jitsi.org> <913383AAA69FF945B8F946018B75898A147AA88C@xmb-rcd-x10.cisco.com> <5057592B.9070904@jitsi.org> <913383AAA69FF945B8F946018B75898A147AB415@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A147AB415@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm6mvO+9IzTX534T7YqUJDHkcY5tfG9JYwzvPtKyNGj79Zgit8a4isksvxMfvw9rsBb1KMf Cc: "Prashanth Patil \(praspati\)" , "mmusic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt X-BeenThere: mmusic@ietf.org 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: Tue, 18 Sep 2012 09:41:39 -0000 Hey Tiru, On 18.09.12, 04:56, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- From: Emil Ivov >> [mailto:emcho@jitsi.org] Sent: Monday, September 17, 2012 10:39 PM >> To: Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org; Dan Wing >> (dwing); Prashanth Patil (praspati); Pal Martinsen (palmarti) >> Subject: Re: [MMUSIC] New Version Notification for >> draft-wing-mmusic-ice- mobility-01.txt >> >> Hey Tiru, >> >> On 17.09.12, 18:47, Tirumaleswar Reddy (tireddy) wrote: >>> Hi Emil - >>> >>> Thanks for the comments. we are in the process of updating the >>> draft - >>> >>> We are planning to add the high-lighted sentence in Introduction, >>> please let us know if you have any further comments. >>> >>> Although ICE does allow an "ICE restart", this is done by sending >>> a re-INVITE which goes over the SIP signaling path. The SIP >>> signaling path is often slower than the media path (which needs >>> to be recovered as quickly as possible), consumes an extra half >>> round trip, and incurs an additional delay if the mobility event >>> forces the endpoint to re-connect with its SIP proxy. *When a >>> device changes its IP address, it is necessary for it to >>> re-establish connectivity with its SIP proxy, which can be >>> performed in parallel with the steps described in this >>> document.* This document describes how mobility is performed >>> entirely in the media path, without the additional delay of >>> re-establishing SIP connectivity, issuing a new offer/answer, or >>> the complications of multiple SIP offers. This document considers >>> re-establishing bi-directional media the most critical aspect of >>> a successful mobility event, and its efforts are towards meeting >>> that goal. >>> >>> We will also added the following text at the end of section 3.1 >>> >>> *The Mobile device would also in parallel re-establish connection >>> with the SIP proxy and if the ICE connectivity checks in the >>> previous steps are not successful then issues new offer/answer >>> and restarts ICE.* >> >> The above statement implies that the mobile node would need to >> first declare failure of ICE mobility and only then would it try an >> ICE restart. Yet, declaring failure would take many seconds with >> the default STUN timers so as a result handover latency is probably >> going to worsen more often than not. > > The only reason I can think why ICE Mobility would fail and ICE > restart succeed is because of Simultaneous Mobility Well ... I might be missing something but it seems to me that the only time it would succeed would be when there's a direct reachability between the mobile node's new address and their correspondent. This would be the case when the mobile node has moved into the same NATed network as the correspondent, or when the correspondent has a public address with no one to perform endpoint dependent filtering in front of them. In all other situations (which would likely represent the majority of the cases) ICE mobility would fail and one would need to perform an ICE restart. Emil > we are trying to > solve the problem in a different way (This text is yet to be > published in the next version of the draft) > > 3.3 Simultaneous Mobility > > Mobile device SHOULD include MOBILTY-ROAM attribute in all of its > STUN requests and STUN responses. If the ICE peer also includes > MOBILTY-ROAM attribute in all its STUN requests and STUN responses > then it means both the endpoints are mobile and can roam at the same > time between networks. In order to support simultaneously mobility > without breaking media sessions between them, both ICE agents MUST > perform the following steps : > > 1. The ICE agent will keep the relayed candidates alive using > Refresh transaction, as described in [RFC5766]. > > 2. When gaining an interface, the ICE agent will refresh it's > allocation with TURN server using Section 4.2. > > 3. The ICE agent will perform the steps described in Section 3.1. > > 4. If the ICE connectivity check succeeds only with local and > remote relayed candidates, it suggests that even the other peer is > roaming at the same time. The ICE agent creates a new pair using the > relayed candidates, adds the pair to the valid list and marks it as > selected. The ICE agent can now send media using the newly selected > relayed candidate pair. The Mobile device in parallel re-establishes > connection with SIP proxy, issues new offer/answer and restarts ICE. > Hence media will only be sent briefly on TURN relays. >> >> Besides, even in cases where ICE mobility succeeds, an ICE restart >> could still allow the use of higher priority candidates. > > ICE Mobility will pick the candidates on the new interface based on > priority (RFC 3484 or latest RFC 6724). Is there any specific case > you have in mind that ICE restart would pick higher priority > candidates and not ICE Mobility other than Simultaneous Mobility > problem ? > > --Tiru. > >> >> Wouldn't it make more sense to always perform an ICE restart in >> parallel and basically consider ICE mobility a best effort attempt >> to shorten handover latency? >> >> Emil -- https://jitsi.org >>> >>> --Tiru. >>> >>>> -----Original Message----- From: Emil Ivov >>>> [mailto:emcho@jitsi.org] Sent: Thursday, September 13, 2012 >>>> 2:59 PM To: Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] New Version Notification for >>>> draft-wing-mmusic-ice- mobility-01.txt >>>> >>>> Hey Tiru, >>>> >>>> One thing that I think this document is not very clear about is >>>> its relationship to standard mobility handling (i.e. through >>>> ICE restart). >>>> >>>> As far as I can see, ICE restart is only mentioned when >>>> describing its inefficiency. >>>> >>>> You did confirm in Vancouver that ICE Mobility is only meant as >>>> an optimisation that would only take place until the ICE >>>> restart completes but I don't see it anywhere in the text. Or >>>> am I missing something? >>>> >>>> Cheers, Emil >>>> >>>> On 20.07.12, 13:36, Tirumaleswar Reddy (tireddy) wrote: >>>>> Hi all, >>>>> >>>>> Dan, Prashanth and I have submitted a draft that explains >>>>> how endpoint mobility can be achieved using ICE. Two >>>>> mechanisms are shown, one where both endpoints support ICE >>>>> and another where only one endpoint supports ICE. When only >>>>> one endpoint supports ICE, a TURN server provides mobility. >>>>> >>>>> _http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility- >> >>>>> 01.txt_ >>>>> >>>>> Please let know your comments. If time permits we'd present >>>>> the draft in Vancouver. >>>>> >>>>> Regards, Tiru. >>>>> >>>>>> -----Original Message----- From: Tirumaleswar Reddy >>>>>> (tireddy) Sent: Friday, July 20, 2012 3:18 PM To: >>>>>> _mmusic@ietf.org_ >> Subject: FW: New >>>>>> Version Notification for draft-wing-mmusic-ice- >>>>>> mobility-01.txt >>>>>> >>>>>> -----Original Message----- From: >>>>>> _internet-drafts@ietf.org_ >> >>>>>> _[mailto:internet-drafts@ietf.org]_ >>> Sent: Tuesday, July >>> 17, 2012 3:52 >>>>>> AM To: Dan Wing (dwing) Cc: Prashanth Patil (praspati); >>>>>> Tirumaleswar Reddy (tireddy) Subject: New Version >>>>>> Notification for draft-wing-mmusic-ice-mobility- 01.txt >>>>>> >>>>>> >>>>>> A new version of I-D, draft-wing-mmusic-ice-mobility-01.txt >>>>>> has been successfully submitted by Dan Wing and posted to >>>>>> the IETF repository. >>>>>> >>>>>> Filename: draft-wing-mmusic-ice-mobility Revision: >>>>>> 01 Title: Mobility with ICE (MICE) Creation date: >>>>>> 2012-07-16 WG ID: Individual Submission Number of pages: 12 >>>>>> URL: >>>>>> _http://www.ietf.org/internet-drafts/draft-wing-mmusic-_ >>>>>> ice-mobility-01.txt Status: >>>>>> _http://datatracker.ietf.org/doc/draft-wing-mmusic-ice-_ >>>>>> mobility Htmlized: >>>>>> _http://tools.ietf.org/html/draft-wing-mmusic-ice-_ >>>>>> mobility-01 Diff: >>>>>> _http://tools.ietf.org/rfcdiff?url2=draft-wing-mmusic-_ >>>>>> ice-mobility-01 >>>>>> >>>>>> Abstract: This specification describes how endpoint >>>>>> mobility can be achieved using ICE. Two mechanisms are >>>>>> shown, one where both endpoints support ICE and another >>>>>> where only one endpoint supports ICE. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>> _______________________________________________ mmusic >>>>> mailing list _mmusic@ietf.org_ >>> _https://www.ietf.org/mailman/listinfo/mmusic_ >>>>> > -- Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 https://jitsi.org FAX: +33.1.77.62.47.31 From tireddy@cisco.com Tue Sep 18 05:07:23 2012 Return-Path: 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 493CC21E80C4 for ; Tue, 18 Sep 2012 05:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 sy-F8gkV6pUP for ; Tue, 18 Sep 2012 05:07:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A980221E80C1 for ; Tue, 18 Sep 2012 05:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30196; q=dns/txt; s=iport; t=1347970040; x=1349179640; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H59QoniL6qZSAdXG2vWiUalg2WS09lAe4bBHDUjK2nA=; b=eIsshGz8A7jv03GuVPTbceXYqIL429MVXXkYQgVl5r9i968+J56LEsQo N7gvjHirOV3H3D/Kd6ftOVC/Ga1p/UN0OyAkj9WjAJtLqPFlD1Wo7kcu/ Pxab7y3MeWNwb/3RYEpllzmd2eqCjUDP+Xb/1NgouaI+3Q5acU/80xMXV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPliWFCtJXG9/2dsb2JhbABFgku5aIEHgiABAQEDAQEBAQ8BBxM/AgQFAgUHAgICAQgOAwQBAQEKFgcHGwwLFAkIAgQOBQgBGYdYBguZf6AzBIsdhghgA5IxhEWNJIFpgmaCFw X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208,217";a="122694013" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 18 Sep 2012 12:07:19 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8IC7Jdf016470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 12:07:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 07:07:19 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Emil Ivov Thread-Topic: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt Thread-Index: AQHNY6F+/LEFvCvLC0CLcDi4fxclSZcx8gqQgAAM1pCAVrIoAP//1knQgAbzf4D//8gbsIABTTgA//+uX4A= Date: Tue, 18 Sep 2012 12:07:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A147AB976@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A052D666F@xmb-rcd-x10.cisco.com> <5051A76A.7090606@jitsi.org> <913383AAA69FF945B8F946018B75898A147AA88C@xmb-rcd-x10.cisco.com> <5057592B.9070904@jitsi.org> <913383AAA69FF945B8F946018B75898A147AB415@xmb-rcd-x10.cisco.com> <505841CE.30602@jitsi.org> In-Reply-To: <505841CE.30602@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.29.82] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004 x-tm-as-result: No--26.863400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A147AB976xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "Prashanth Patil \(praspati\)" , "mmusic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt X-BeenThere: mmusic@ietf.org 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: Tue, 18 Sep 2012 12:07:23 -0000 --_000_913383AAA69FF945B8F946018B75898A147AB976xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Tuesday, September 18, 2012 3:12 PM > To: Tirumaleswar Reddy (tireddy) > Cc: mmusic@ietf.org; Dan Wing (dwing); Prashanth Patil (praspati); Pal > Martinsen (palmarti) > Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice- > mobility-01.txt > > Hey Tiru, > > On 18.09.12, 04:56, Tirumaleswar Reddy (tireddy) wrote: > >> -----Original Message----- From: Emil Ivov > >> [mailto:emcho@jitsi.org] Sent: Monday, September 17, 2012 10:39 PM > >> To: Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org; Dan Wing > >> (dwing); Prashanth Patil (praspati); Pal Martinsen (palmarti) > >> Subject: Re: [MMUSIC] New Version Notification for > >> draft-wing-mmusic-ice- mobility-01.txt > >> > >> Hey Tiru, > >> > >> On 17.09.12, 18:47, Tirumaleswar Reddy (tireddy) wrote: > >>> Hi Emil - > >>> > >>> Thanks for the comments. we are in the process of updating the > >>> draft - > >>> > >>> We are planning to add the high-lighted sentence in Introduction, > >>> please let us know if you have any further comments. > >>> > >>> Although ICE does allow an "ICE restart", this is done by sending > >>> a re-INVITE which goes over the SIP signaling path. The SIP > >>> signaling path is often slower than the media path (which needs > >>> to be recovered as quickly as possible), consumes an extra half > >>> round trip, and incurs an additional delay if the mobility event > >>> forces the endpoint to re-connect with its SIP proxy. *When a > >>> device changes its IP address, it is necessary for it to > >>> re-establish connectivity with its SIP proxy, which can be > >>> performed in parallel with the steps described in this > >>> document.* This document describes how mobility is performed > >>> entirely in the media path, without the additional delay of > >>> re-establishing SIP connectivity, issuing a new offer/answer, or > >>> the complications of multiple SIP offers. This document considers > >>> re-establishing bi-directional media the most critical aspect of > >>> a successful mobility event, and its efforts are towards meeting > >>> that goal. > >>> > >>> We will also added the following text at the end of section 3.1 > >>> > >>> *The Mobile device would also in parallel re-establish connection > >>> with the SIP proxy and if the ICE connectivity checks in the > >>> previous steps are not successful then issues new offer/answer > >>> and restarts ICE.* > >> > >> The above statement implies that the mobile node would need to > >> first declare failure of ICE mobility and only then would it try an > >> ICE restart. Yet, declaring failure would take many seconds with > >> the default STUN timers so as a result handover latency is probably > >> going to worsen more often than not. > > > > The only reason I can think why ICE Mobility would fail and ICE > > restart succeed is because of Simultaneous Mobility > > Well ... I might be missing something but it seems to me that the only > time it would succeed would be when there's a direct reachability > between the mobile node's new address and their correspondent. > > This would be the case when the mobile node has moved into the same > NATed network as the correspondent, or when the correspondent has a > public address with no one to perform endpoint dependent filtering in > front of them. > > In all other situations (which would likely represent the majority of > the cases) ICE mobility would fail and one would need to perform an ICE > restart. > > Emil Hi Emil, Thanks for the review. I have assumed that the other Mobile Device (Correspondent Node in this cas= e) would include MOBILITY-SUPPORT only in the following cases : IPv6 Global Address, Correspondent Node is behind Endpoint-Independent Mapp= ing/Filtering NAT as recommended in RFC 4787. But to make it work in other scenarios where Correspondent Node(CN) is behi= nd Address-Dependent Filtering/Mapping, CN can detect the NAT behavior usin= g simple tests suggested in RFC 5780 and so not include MOBILITY-SUPPORT at= tribute. [Even without ICE Mobility, if both Mobile devices are behind non-BEHAVE co= mpliant NAT then ICE connectivity checks using host/server-reflexive candid= ates will fail and end up using UDP relay] =3D=3D=3D Section 3 Endpoints that support ICE Mobility perform ICE normally, and MUST also inc= lude the MOBILITY-SUPPORT attribute in all of their STUN requests and their= STUN responses. The inclusion of this attribute allows the ICE peer to det= ermine if it can achieve mobility using ICE or needs to use TURN (or needs = to use some other mechanism, such as Mobile IP). To force the use of TURN t= o achieve ICE mobility, the ICE endpoint SHOULD NOT respond to ICE connecti= vity checks that have an IP address and port different from the TURN server= , unless those connectivity checks contain the MOBILITY-SUPPORT attribute. = In this way, the remote peer will think those other candidates are invalid = (because its connectivity checks did not succeed). =3D=3D=3D --Tiru. > > > we are trying to > > solve the problem in a different way (This text is yet to be > > published in the next version of the draft) > > > > 3.3 Simultaneous Mobility > > > > Mobile device SHOULD include MOBILTY-ROAM attribute in all of its > > STUN requests and STUN responses. If the ICE peer also includes > > MOBILTY-ROAM attribute in all its STUN requests and STUN responses > > then it means both the endpoints are mobile and can roam at the same > > time between networks. In order to support simultaneously mobility > > without breaking media sessions between them, both ICE agents MUST > > perform the following steps : > > > > 1. The ICE agent will keep the relayed candidates alive using > > Refresh transaction, as described in [RFC5766]. > > > > 2. When gaining an interface, the ICE agent will refresh it's > > allocation with TURN server using Section 4.2. > > > > 3. The ICE agent will perform the steps described in Section 3.1. > > > > 4. If the ICE connectivity check succeeds only with local and > > remote relayed candidates, it suggests that even the other peer is > > roaming at the same time. The ICE agent creates a new pair using the > > relayed candidates, adds the pair to the valid list and marks it as > > selected. The ICE agent can now send media using the newly selected > > relayed candidate pair. The Mobile device in parallel re-establishes > > connection with SIP proxy, issues new offer/answer and restarts ICE. > > Hence media will only be sent briefly on TURN relays. > >> > >> Besides, even in cases where ICE mobility succeeds, an ICE restart > >> could still allow the use of higher priority candidates. > > > > ICE Mobility will pick the candidates on the new interface based on > > priority (RFC 3484 or latest RFC 6724). Is there any specific case > > you have in mind that ICE restart would pick higher priority > > candidates and not ICE Mobility other than Simultaneous Mobility > > problem ? > > > > --Tiru. > > > >> > >> Wouldn't it make more sense to always perform an ICE restart in > >> parallel and basically consider ICE mobility a best effort attempt > >> to shorten handover latency? > >> > >> Emil -- https://jitsi.org > >>> > >>> --Tiru. > >>> > >>>> -----Original Message----- From: Emil Ivov > >>>> [mailto:emcho@jitsi.org] Sent: Thursday, September 13, 2012 > >>>> 2:59 PM To: Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org > >>>> Subject: Re: [MMUSIC] New Version Notification for > >>>> draft-wing-mmusic-ice- mobility-01.txt > >>>> > >>>> Hey Tiru, > >>>> > >>>> One thing that I think this document is not very clear about is > >>>> its relationship to standard mobility handling (i.e. through > >>>> ICE restart). > >>>> > >>>> As far as I can see, ICE restart is only mentioned when > >>>> describing its inefficiency. > >>>> > >>>> You did confirm in Vancouver that ICE Mobility is only meant as > >>>> an optimisation that would only take place until the ICE > >>>> restart completes but I don't see it anywhere in the text. Or > >>>> am I missing something? > >>>> > >>>> Cheers, Emil > >>>> > >>>> On 20.07.12, 13:36, Tirumaleswar Reddy (tireddy) wrote: > >>>>> Hi all, > >>>>> > >>>>> Dan, Prashanth and I have submitted a draft that explains > >>>>> how endpoint mobility can be achieved using ICE. Two > >>>>> mechanisms are shown, one where both endpoints support ICE > >>>>> and another where only one endpoint supports ICE. When only > >>>>> one endpoint supports ICE, a TURN server provides mobility. > >>>>> > >>>>> _http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility= - > >> > >>>>> > 01.txt_ > >>>>> > >>>>> Please let know your comments. If time permits we'd present > >>>>> the draft in Vancouver. > >>>>> > >>>>> Regards, Tiru. > >>>>> > >>>>>> -----Original Message----- From: Tirumaleswar Reddy > >>>>>> (tireddy) Sent: Friday, July 20, 2012 3:18 PM To: > >>>>>> _mmusic@ietf.org_ > >> Subject: FW: New > >>>>>> Version Notification for draft-wing-mmusic-ice- > >>>>>> mobility-01.txt > >>>>>> > >>>>>> -----Original Message----- From: > >>>>>> _internet-drafts@ietf.org_ > >> > >>>>>> _[mailto:internet-drafts@ietf.org]_ > >>> Sent: Tuesday, July > >>> 17, 2012 3:52 > >>>>>> AM To: Dan Wing (dwing) Cc: Prashanth Patil (praspati); > >>>>>> Tirumaleswar Reddy (tireddy) Subject: New Version > >>>>>> Notification for draft-wing-mmusic-ice-mobility- 01.txt > >>>>>> > >>>>>> > >>>>>> A new version of I-D, draft-wing-mmusic-ice-mobility-01.txt > >>>>>> has been successfully submitted by Dan Wing and posted to > >>>>>> the IETF repository. > >>>>>> > >>>>>> Filename: draft-wing-mmusic-ice-mobility Revision: > >>>>>> 01 Title: Mobility with ICE (MICE) Creation date: > >>>>>> 2012-07-16 WG ID: Individual Submission Number of pages: 12 > >>>>>> URL: > >>>>>> _http://www.ietf.org/internet-drafts/draft-wing-mmusic-_ > >>>>>> ice-mobility-01.txt Status: > >>>>>> _http://datatracker.ietf.org/doc/draft-wing-mmusic-ice-_ > >>>>>> mobility Htmlized: > >>>>>> _http://tools.ietf.org/html/draft-wing-mmusic-ice-_ > >>>>>> mobility-01 Diff: > >>>>>> _http://tools.ietf.org/rfcdiff?url2=3Ddraft-wing-mmusic-_ > >>>>>> ice-mobility-01 > >>>>>> > >>>>>> Abstract: This specification describes how endpoint > >>>>>> mobility can be achieved using ICE. Two mechanisms are > >>>>>> shown, one where both endpoints support ICE and another > >>>>>> where only one endpoint supports ICE. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> The IETF Secretariat > >>>>> _______________________________________________ mmusic > >>>>> mailing list _mmusic@ietf.org_ > >>> _https://www.ietf.org/mailman/listinfo/mmusic_ > >>>>> > > > > -- > Emil Ivov, Ph.D. 67000 Strasbourg, > Project Lead France > Jitsi > emcho@jitsi.org PHONE: +33.1.77.62.43.30 > https://jitsi.org FAX: +33.1.77.62.47.31 --_000_913383AAA69FF945B8F946018B75898A147AB976xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
> -----Original Message-----
> From: Emil Ivov [mailto:emcho@= jitsi.org]
> Sent: Tuesday, September 18, 2012 3:12 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: mmusic@ietf.org; Dan Wing (dwing); Prashanth Patil (praspati)= ; Pal
> Martinsen (palmarti)
> Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmu= sic-ice-
> mobility-01.txt
>
> Hey Tiru,
>
> On 18.09.12, 04:56, Tirumaleswar Reddy (tireddy) wrote:
> >> -----Original Message----- From: Emil Ivov
> >> [mailto:emcho@jitsi.o= rg] Sent: Monday, September 17, 2012 10:39 PM
> >> To: Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org; Da= n Wing
> >> (dwing); Prashanth Patil (praspati); Pal Martinsen (palm= arti)
> >> Subject: Re: [MMUSIC] New Version Notification for
> >> draft-wing-mmusic-ice- mobility-01.txt
> >>
> >> Hey Tiru,
> >>
> >> On 17.09.12, 18:47, Tirumaleswar Reddy (tireddy) wrote:<= /div>
> >>> Hi Emil -
> >>>
> >>> Thanks for the comments. we are in the process of up= dating the
> >>> draft -
> >>>
> >>> We are planning to add the high-lighted sentence in = Introduction,
> >>> please let us know if you have any further comments.=
> >>>
> >>> Although ICE does allow an "ICE restart", = this is done by sending
> >>> a re-INVITE which goes over the SIP signaling path. = The SIP
> >>> signaling path is often slower than the media path (= which needs
> >>> to be recovered as quickly as possible), consumes an= extra half
> >>> round trip, and incurs an additional delay if the mo= bility event
> >>> forces the endpoint to re-connect with its SIP proxy= . *When a
> >>> device changes its IP address, it is necessary for i= t to
> >>> re-establish connectivity with its SIP proxy, which = can be
> >>> performed in parallel with the steps described in th= is
> >>> document.* This document describes how mobility is p= erformed
> >>> entirely in the media path, without the additional d= elay of
> >>> re-establishing SIP connectivity, issuing a new offe= r/answer, or
> >>> the complications of multiple SIP offers. This docum= ent considers
> >>> re-establishing bi-directional media the most critic= al aspect of
> >>> a successful mobility event, and its efforts are tow= ards meeting
> >>> that goal.
> >>>
> >>> We will also added the following text at the end of = section 3.1
> >>>
> >>> *The Mobile device would also in parallel re-establi= sh connection
> >>> with the SIP proxy and if the ICE connectivity check= s in the
> >>> previous steps are not successful then issues new of= fer/answer
> >>> and restarts ICE.*
> >>
> >> The above statement implies that the mobile node would n= eed to
> >> first declare failure of ICE mobility and only then woul= d it try an
> >> ICE restart. Yet, declaring failure would take many seco= nds with
> >> the default STUN timers so as a result handover latency = is probably
> >> going to worsen more often than not.
> >
> > The only reason I can think why ICE Mobility would fail and = ICE
> > restart succeed is because of Simultaneous Mobility
>
> Well ... I might be missing something but it seems to me that the= only
> time it would succeed would be when there's a direct reachability=
> between the mobile node's new address and their correspondent.
>
> This would be the case when the mobile node has moved into the sa= me
> NATed network as the correspondent, or when the correspondent has= a
> public address with no one to perform endpoint dependent filterin= g in
> front of them.
>
> In all other situations (which would likely represent the majorit= y of
> the cases) ICE mobility would fail and one would need to perform = an ICE
> restart.
>
> Emil
 
Hi Emil,
 
Thanks for the review.
 
I have assumed that the other Mobile Device (Correspondent Node in thi= s case) would include MOBILITY-SUPPORT only in the following cases :
IPv6 Global Address, Correspondent Node is behind Endpoint-Independent= Mapping/Filtering NAT as recommended in RFC 4787.
 
But to make it work in other scenarios where Correspondent Node(CN) is= behind Address-Dependent Filtering/Mapping, CN can detect the NAT behavior= using simple tests suggested in RFC 5780 and so not include MOBILITY-SUPPO= RT attribute.
 
[Even without ICE Mobility, if both Mobile devices are behind non-BEHA= VE compliant NAT then ICE connectivity checks using host/server-reflexive c= andidates will fail and end up using UDP relay]
 
=3D=3D=3D
Section 3
 
Endpoints that support ICE Mobility perform ICE normally, and MUST als= o include the MOBILITY-SUPPORT attribute in all of their STUN requests and = their STUN responses. The inclusion of this attribute allows the ICE peer t= o determine if it can achieve mobility using ICE or needs to use TURN (or needs to use some other mechanism, such = as Mobile IP). To force the use of TURN to achieve ICE mobility, the ICE= endpoint SHOULD NOT respond to ICE connectivity checks that have an IP add= ress and port different from the TURN server, unless those connectivity checks contain the MOBILITY-SUPPORT = attribute. In this way, the remote peer will think those other candidates a= re invalid (because its connectivity checks did not succeed).
=3D=3D=3D
 
--Tiru.
 
>
> > we are trying to
> > solve the problem in a different way (This text is yet to be=
> > published in the next version of the draft)
> >
> > 3.3 Simultaneous Mobility
> >
> > Mobile device SHOULD include MOBILTY-ROAM attribute in all o= f its
> > STUN requests and STUN responses.  If the ICE peer also= includes
> > MOBILTY-ROAM attribute in all its STUN requests and STUN res= ponses
> > then it means both the endpoints are mobile and can roam at = the same
> > time between networks.  In order to support simultaneou= sly mobility
> > without breaking media sessions between them, both ICE agent= s MUST
> > perform the following steps :
> >
> > 1.  The ICE agent will keep the relayed candidates aliv= e using
> > Refresh transaction, as described in [RFC5766].
> >
> > 2.  When gaining an interface, the ICE agent will refre= sh it's
> > allocation with TURN server using Section 4.2.
> >
> > 3.  The ICE agent will perform the steps described in S= ection 3.1.
> >
> > 4.  If the ICE connectivity check succeeds only with lo= cal and
> > remote relayed candidates, it suggests that even the other p= eer is
> > roaming at the same time.  The ICE agent creates a new = pair using the
> > relayed candidates, adds the pair to the valid list and mark= s it as
> > selected.  The ICE agent can now send media using the n= ewly selected
> > relayed candidate pair.  The Mobile device in parallel = re-establishes
> > connection with SIP proxy, issues new offer/answer and resta= rts ICE.
> > Hence media will only be sent briefly on TURN relays.
> >>
> >> Besides, even in cases where ICE mobility succeeds, an I= CE restart
> >> could still allow the use of higher priority candidates.=
> >
> > ICE Mobility will pick the candidates on the new interface b= ased on
> > priority (RFC 3484 or latest RFC 6724). Is there any specifi= c case
> > you have in mind that ICE restart would pick higher priority=
> > candidates and not ICE Mobility other than Simultaneous Mobi= lity
> > problem ?
> >
> > --Tiru.
> >
> >>
> >> Wouldn't it make more sense to always perform an ICE res= tart in
> >> parallel and basically consider ICE mobility a best effo= rt attempt
> >> to shorten handover latency?
> >>
> >>>
> >>> --Tiru.
> >>>
> >>>> -----Original Message----- From: Emil Ivov
> >>>> [mailto:emcho= @jitsi.org] Sent: Thursday, September 13, 2012
> >>>> 2:59 PM To: Tirumaleswar Reddy (tireddy) Cc: mmu= sic@ietf.org
> >>>> Subject: Re: [MMUSIC] New Version Notification f= or
> >>>> draft-wing-mmusic-ice- mobility-01.txt
> >>>>
> >>>> Hey Tiru,
> >>>>
> >>>> One thing that I think this document is not very= clear about is
> >>>> its relationship to standard mobility handling (= i.e. through
> >>>> ICE restart).
> >>>>
> >>>> As far as I can see, ICE restart is only mention= ed when
> >>>> describing its inefficiency.
> >>>>
> >>>> You did confirm in Vancouver that ICE Mobility i= s only meant as
> >>>> an optimisation that would only take place until= the ICE
> >>>> restart completes but I don't see it anywhere in= the text. Or
> >>>> am I missing something?
> >>>>
> >>>> Cheers, Emil
> >>>>
> >>>> On 20.07.12, 13:36, Tirumaleswar Reddy (tireddy)= wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> Dan, Prashanth and I have submitted a draft = that explains
> >>>>> how endpoint mobility can be achieved using = ICE.  Two
> >>>>> mechanisms are shown, one where both endpoin= ts support ICE
> >>>>> and another where only one endpoint supports= ICE. When only
> >>>>> one endpoint supports ICE, a TURN server pro= vides mobility.
> >>>>>
> >>>>> _http://www.ietf.org/internet-drafts/draft-w= ing-mmusic-ice-mobility-
> >>
> >>>>>
> 01.txt_
> >>>>>
> >>>>> Please let know your comments. If time permi= ts we'd present
> >>>>> the draft in Vancouver.
> >>>>>
> >>>>> Regards, Tiru.
> >>>>>
> >>>>>> -----Original Message----- From: Tirumal= eswar Reddy
> >>>>>> (tireddy) Sent: Friday, July 20, 2012 3:= 18 PM To:
> >>>>>> _mmusic@ietf.org_
> >> <mailto:mmusic@iet= f.org> Subject: FW: New
> >>>>>> Version Notification for draft-wing-mmus= ic-ice-
> >>>>>> mobility-01.txt
> >>>>>>
> >>>>>> -----Original Message----- From:
> >>>>>> _internet-drafts@ietf.org_
> >>> <mailto:[mailto:internet-drafts@ietf.org]> Sent: Tuesday, July
> >>> 17, 2012 3:52
> >>>>>> AM To: Dan Wing (dwing) Cc: Prashanth Pa= til (praspati);
> >>>>>> Tirumaleswar Reddy (tireddy) Subject: Ne= w Version
> >>>>>> Notification for draft-wing-mmusic-ice-m= obility- 01.txt
> >>>>>>
> >>>>>>
> >>>>>> A new version of I-D, draft-wing-mmusic-= ice-mobility-01.txt
> >>>>>> has been successfully submitted by Dan W= ing and posted to
> >>>>>> the IETF repository.
> >>>>>>
> >>>>>> Filename:   draft-wing-mmusic-= ice-mobility Revision:
> >>>>>> 01 Title: Mobility with ICE (MICE) Creat= ion date:
> >>>>>> 2012-07-16 WG ID: Individual Submission = Number of pages: 12
> >>>>>> URL:
> >>>>>> _http://www.ietf.org/internet-drafts/dra= ft-wing-mmusic-_
> >>>>>> ice-mobility-01.txt Status:
> >>>>>> _http://datatracker.ietf.org/doc/draft-w= ing-mmusic-ice-_
> >>>>>> mobility Htmlized:
> >>>>>> _http://tools.ietf.org/html/draft-wing-m= music-ice-_
> >>>>>> mobility-01 Diff:
> >>>>>> _http://tools.ietf.org/rfcdiff?url2=3Ddr= aft-wing-mmusic-_
> >>>>>> ice-mobility-01
> >>>>>>
> >>>>>> Abstract: This specification describes h= ow endpoint
> >>>>>> mobility can be achieved using ICE. = ; Two mechanisms are
> >>>>>> shown, one where both endpoints support = ICE and another
> >>>>>> where only one endpoint supports ICE.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> The IETF Secretariat
> >>>>> ____________________________________________= ___ mmusic
> >>>>> mailing list _mmusic@ietf.org_ <mailto:mmusic@ietf.org>
> >>> _https://www.ietf.org/mailman/listinfo/mmusic_
> >>>>>
> >
>
> --
> Emil Ivov, Ph.D.        &= nbsp;           &nbs= p;  67000 Strasbourg,
> Project Lead         = ;            &n= bsp;     France
> Jitsi
> emcho@jitsi.org        &n= bsp;            = ;   PHONE: +33.1.77.62.43.30
> https://jitsi.org  &n= bsp;            = ;       FAX:   +33.1.77.62.47.3= 1
 
 --_000_913383AAA69FF945B8F946018B75898A147AB976xmbrcdx10ciscoc_-- From emil@sip-communicator.org Tue Sep 18 05:49:52 2012 Return-Path: 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 2D25121E80C1 for ; Tue, 18 Sep 2012 05:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 JrKYL5G1oVdY for ; Tue, 18 Sep 2012 05:49:51 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA4C21F8766 for ; Tue, 18 Sep 2012 05:49:50 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4208203wgb.13 for ; Tue, 18 Sep 2012 05:49:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=3eKTh8IwJjJoM33hRUTAY7q0WUqJIyo3Ez7dBPn6uqM=; b=GgyaO725EegtVvJfxH4t/k1aLd7+tSql2R0fVXZ2FEi8A44Vi94qrqvekM2lVLs1K4 QtzNYIcQG5YCyU2kxNAMWcnaUfNjeELRLcd4DEHvDJdMDHCCbcVPBqoqZ5g+rXuQF78O gDeR6i70gQ9w3HhT0QujzHXc4yLU2hEHlH8t4tkWNHc6vfCq3NjQICWkKdNuO7faQEKm bydu0vqoF7nUSHwdrBxiEtNy7Cuih/4U/8NbA6v/CouJAJuRm9RnlwoRtjQwf5HSJoBW zpZ6h3XgKQCGeJZMuRHQDcJM4BA90/fwbhXI6TsB7VrmYk3JvFkVoOVFFs10wAjVm5eb crPA== Received: by 10.180.91.1 with SMTP id ca1mr23185872wib.8.1347972590108; Tue, 18 Sep 2012 05:49:50 -0700 (PDT) Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:6d9e:5cc0:90cb:9fbb]) by mx.google.com with ESMTPS id j6sm31736591wiy.4.2012.09.18.05.49.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 05:49:44 -0700 (PDT) Message-ID: <50586DE8.4030101@jitsi.org> Date: Tue, 18 Sep 2012 14:49:44 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A052D666F@xmb-rcd-x10.cisco.com> <5051A76A.7090606@jitsi.org> <913383AAA69FF945B8F946018B75898A147AA88C@xmb-rcd-x10.cisco.com> <5057592B.9070904@jitsi.org> <913383AAA69FF945B8F946018B75898A147AB415@xmb-rcd-x10.cisco.com> <505841CE.30602@jitsi.org> <913383AAA69FF945B8F946018B75898A147AB976@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A147AB976@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl1COql64ZjBgHJYHdvJ7gIiomiddf6GfhqWrVsp2hP0295mdtyzADBfGZGBVKoChNH8Ve0 Cc: "Prashanth Patil \(praspati\)" , "mmusic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt X-BeenThere: mmusic@ietf.org 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: Tue, 18 Sep 2012 12:49:52 -0000 Hey Tiru, On 18.09.12, 14:07, Tirumaleswar Reddy (tireddy) wrote: >> > The only reason I can think why ICE Mobility would fail and ICE >> > restart succeed is because of Simultaneous Mobility >> >> Well ... I might be missing something but it seems to me that the only >> time it would succeed would be when there's a direct reachability >> between the mobile node's new address and their correspondent. >> >> This would be the case when the mobile node has moved into the same >> NATed network as the correspondent, or when the correspondent has a >> public address with no one to perform endpoint dependent filtering in >> front of them. >> >> In all other situations (which would likely represent the majority of >> the cases) ICE mobility would fail and one would need to perform an ICE >> restart. >> >> Emil > > Hi Emil, > > Thanks for the review. > > I have assumed that the other Mobile Device (Correspondent Node in this > case) would include MOBILITY-SUPPORT only in the following cases : > IPv6 Global Address, And I insist, even with IPv6 there should be no that performs endpoint dependent filtering in front of the CN. Many corporate firewalls would not allow incoming traffic unless it has been initiated from the inside. Just as they would for IPv4. > Correspondent Node is behind Endpoint-Independent > Mapping/Filtering NAT as recommended in RFC 4787. While 4787 is quite adamant about avoiding endpoint dependent mapping this is not the case for endpoint dependent filtering: RTF 4787, REQ-8: ... If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior. That text aside, while one could hope that (at least in certain parts of the world) a decent number of CNs would be behind a NAT with endpoint independent mapping, it is very rare to see commercial deployments with endpoint independent filtering. > But to make it work in other scenarios where Correspondent Node(CN) is > behind Address-Dependent Filtering/Mapping, CN can detect the NAT > behavior using simple tests suggested in RFC 5780 and so not include > MOBILITY-SUPPORT attribute. That kind of diagnostics are extremely difficult to apply in practice (which is one of the reasons for ICE to exist) and even if they weren't, disabling ICE mobility for NATs with endpoint dependent filtering would leave you with very few cases where one would be able to use it. > [Even without ICE Mobility, if both Mobile devices are behind non-BEHAVE > compliant NAT then ICE connectivity checks using host/server-reflexive > candidates will fail and end up using UDP relay] Well again, NATs with endpoint dependent filtering are totally fine with 4787 and they do work with server-reflexive addresses. Cheers, Emil -- https://jitsi.org From miguel.a.garcia@ericsson.com Wed Sep 19 00:23:13 2012 Return-Path: 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 67CCD21E8098 for ; Wed, 19 Sep 2012 00:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 zffYPNLqWJEe for ; Wed, 19 Sep 2012 00:23:12 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 54AB321E8096 for ; Wed, 19 Sep 2012 00:23:12 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-15-505972df7703 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B2.5B.17130.FD279505; Wed, 19 Sep 2012 09:23:11 +0200 (CEST) Received: from [159.107.24.242] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Wed, 19 Sep 2012 09:23:10 +0200 Message-ID: <505972DD.3060908@ericsson.com> Date: Wed, 19 Sep 2012 09:23:09 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+Jvre79osgAg5ZmMYv3F3Qtpi5/zOLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZTRPuslc8E2k4tHEv6wNjD8Fuhg5OSQETCR2 /lrCAmGLSVy4t56ti5GLQ0jgFKPEq78/2SGcNYwSnbMPM4NU8QpoSxx/NIMRxGYRUJVo33qd HcRmEzCXaN24EcwWFQiWOLdxGxtEvaDEyZlPwDaICMhI7N20GWwOM9Cc2XdmMYHYwgIOEi+W fGeDiNtKXJhznQXClpfY/nYOWL2QgKbE5JtLmScw8s9CMnYWkpZZSFoWMDKvYhTOTczMSS83 10stykwuLs7P0ytO3cQIDL2DW34b7GDcdF/sEKM0B4uSOK+e6n5/IYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYw7Z1UKy6reO+vENOuIi1HTt88P3dbuL+7afXiBzYOPB55wXWDjqtIMfrso I49v/u4behE8jJNezp3P0/4qqUGn+OAvzq/Fnsf3MG7lv8cm8zlVOW3ZwmI1h1t6k6ubZnxZ kTgn6cBC/bczzh2ds/RZzK3Yv047p+QpBu84/36dvlxf2Q3le0UqSizFGYmGWsxFxYkAdc4A 3QsCAAA= Cc: Flemming Andreasen Subject: [MMUSIC] Poll for path on ICE extensions and updates/corrections X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 07:23:13 -0000 Hi all, This mail relates to ICE [RFC 5245]. In the past few months, we have seen a number of documents that are trying to improve the usage of ICE in different ways. The list of documents include at least the following drafts: - draft-keranen-mmusic-ice-address-selection-01 - draft-petithuguenin-mmusic-ice-attributes-level-03 - draft-wing-mmusic-ice-mobility-01 - draft-elwell-mmusic-ice-updated-offer-02 There is, in addition, a long discussion in the RTCWEB mailing list about "trickle ICE", and a couple of other ICE-related drafts and discussions in RTCWEB. Most likely, we can categorize these documents in two big classes: a) Documents that identify underspecified areas or errors in the spec, which are often driven by implementation experience b) Documents that update or extend ICE with new functionality, such as "tricke ICE" (see e.g. the e-mail thread at http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html) . Such documents may involve normative updates to the ICE specification or they may simply be ICE extensions.". Assuming that we would get consensus to adopt some or all of these documents as work to proceed on, the MMUSIC chairs and RAI ADs would like to get some sense of how should we aim at documenting it. Below are some options, please comment on them or add alternatives. a) Create a revision of ICE (i.e., a document what will obsolete RFC 5245), including all the extensions and corrections that we want to choose from the list. This sounds like a big effort in time, and presumably will create a big spec. We should make sure that people have enough cycles to devote to this activity. b) Create a revision of ICE (obsoleting RFC 5245), but only addressing bug fixing and opening hooks to extensions, with the idea that extensions won't need to violate 5245bis. Additionally, document each extension in a separate RFC. Extensions will depend and refer to the 5245bis draft. c) Leave the current ICE core spec as is. Document each extension separately (referring to 5245). Create open or more documents listing bug fixes and corrections (will also update RFC 5245). Needless to say, at this point in time, there is no decision as for which of the ICE-related drafts will proceed or not. We are just trying to get consensus of how to document ICE-related drafts, and in particular if the WG believes we should do a revision of RFC 5245. If so, we also need to hear who is willing to work on such a revision. Now, it is your time to express your opinion. Kindly regards, Flemming and Miguel. -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From emil@sip-communicator.org Wed Sep 19 07:26:43 2012 Return-Path: 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 51B3021F870B for ; Wed, 19 Sep 2012 07:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 9xpXA8TGL-Vk for ; Wed, 19 Sep 2012 07:26:42 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 598EF21F8622 for ; Wed, 19 Sep 2012 07:26:42 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so963109wib.13 for ; Wed, 19 Sep 2012 07:26:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding:x-gm-message-state; bh=J3YTN6u9yOIyNUOaepAoQYKdUSdd5peiWmSVKQ3y/4E=; b=hiV/2g3LWV8lRsjwIJY+vABkFJYRVK//wR4d70EoWdO8FQ2H1sDUoDTvcPIeWWCQI1 rct1+BrC9ru6wzIKNSzGwI5DsXQlk2MeaL6tGSYaEiWOxV1DON6llNhsJOQPjFqhROZN AzzpSZwkgZ62N/aiaqpYmdm4KHE0Pj31IohceIPBER5JdtYsjJoVGzCrRBUndg862VGm 2JCu+HumNZdaFnBKL6INACDMt4NuIjECovoZzP77diSdGaCuWp9Q6dC+XQR6bLIoTQgU KSl4qL3675pKxlg0332MWXgMIrgvg1gJrj/9gn1VoB2yXnjWeMndAdOLdxxUN/ksxn1r /Skw== Received: by 10.216.181.195 with SMTP id l45mr1822608wem.52.1348064799222; Wed, 19 Sep 2012 07:26:39 -0700 (PDT) Received: from camionet.local (lec67-2-82-226-207-96.fbx.proxad.net. [82.226.207.96]) by mx.google.com with ESMTPS id h9sm27908115wiz.1.2012.09.19.07.26.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 07:26:38 -0700 (PDT) Message-ID: <5059D616.60905@jitsi.org> Date: Wed, 19 Sep 2012 16:26:30 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "MMUSIC WG" References: <20120919141507.4883.72967.idtracker@ietfa.amsl.com> In-Reply-To: <20120919141507.4883.72967.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120919141507.4883.72967.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl0Ky7Q6ANQvl+7GKaLyqSot9Hq3BTWjn7IikkbhGgD8a4VDSkL7pAkrRO3roiBg+lZ92Q5 Subject: [MMUSIC] Fwd: New Version Notification for draft-ivov-mmusic-latching-01.txt X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 14:26:43 -0000 Hey all, We've just posted a new version of the latching draft addressing AD and WG chair comments. In addition to the editorial changes we also try to make it clearer that this is only a description of current operation and not a presentation of best practices or even recommended operations. Diff2 available here: http://tools.ietf.org/rfcdiff?url2=draft-ivov-mmusic-latching-01.txt Cheers, Emil -- https://jitsi.org -------- Original Message -------- Subject: New Version Notification for draft-ivov-mmusic-latching-01.txt Date: Wed, 19 Sep 2012 07:15:07 -0700 From: internet-drafts@ietf.org To: emcho@jitsi.org CC: dwing@cisco.com, hkaplan@acmepacket.com A new version of I-D, draft-ivov-mmusic-latching-01.txt has been successfully submitted by Emil Ivov and posted to the IETF repository. Filename: draft-ivov-mmusic-latching Revision: 01 Title: Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication Creation date: 2012-09-19 WG ID: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ivov-mmusic-latching-01.txt Status: http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching Htmlized: http://tools.ietf.org/html/draft-ivov-mmusic-latching-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ivov-mmusic-latching-01 Abstract: This document describes behavior of signalling intermediaries in RTC deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as well as an informative description to manufacturers, and users. The IETF Secretariat From tireddy@cisco.com Wed Sep 19 07:45:33 2012 Return-Path: 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 4F47A21F8688 for ; Wed, 19 Sep 2012 07:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 CAg-mU2rlNfa for ; Wed, 19 Sep 2012 07:45:32 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF6B21F8658 for ; Wed, 19 Sep 2012 07:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3932; q=dns/txt; s=iport; t=1348065932; x=1349275532; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1Hbb89eh1EzhvKMf4szwqCNC1+241cDqppBr0tlC3sE=; b=Q+ffrGruOuvhR/IAEa4/KptIVpqJxN7Nr9rLfCGCpbB7ROVWGsq08KJf Dup/hkLlIObXT7SxUQS3lbijeCOxCeAVnMfHPQ4Okwg/3MZtBGbDAg5hh 2NfoFLuq5UuIYdzlMvr5/V5r4F0PEYfnfbGn/ECThjg0kn6IYHSVhJQfi M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAELaWVCtJXHB/2dsb2JhbABFvEKBCIIgAQEBBBIBFBM9AgwEAgEIDgMEAQEBChQJBzIUCQgCBA4FCBqHXppyoBAEixyFYWADpByBaYJmghc X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="122966055" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 19 Sep 2012 14:45:11 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8JEjBF4019727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 14:45:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 19 Sep 2012 09:45:10 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Emil Ivov Thread-Topic: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt Thread-Index: AQHNY6F+/LEFvCvLC0CLcDi4fxclSZcx8gqQgAAM1pCAVrIoAP//1knQgAbzf4D//8gbsIABTTgA//+uX4AAEMZ8AAArzWbQ Date: Wed, 19 Sep 2012 14:45:09 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A147AC70E@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A052D666F@xmb-rcd-x10.cisco.com> <5051A76A.7090606@jitsi.org> <913383AAA69FF945B8F946018B75898A147AA88C@xmb-rcd-x10.cisco.com> <5057592B.9070904@jitsi.org> <913383AAA69FF945B8F946018B75898A147AB415@xmb-rcd-x10.cisco.com> <505841CE.30602@jitsi.org> <913383AAA69FF945B8F946018B75898A147AB976@xmb-rcd-x10.cisco.com> <50586DE8.4030101@jitsi.org> In-Reply-To: <50586DE8.4030101@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.234.59] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19192.002 x-tm-as-result: No--51.792500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Prashanth Patil \(praspati\)" , "mmusic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 14:45:33 -0000 > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Tuesday, September 18, 2012 6:20 PM > To: Tirumaleswar Reddy (tireddy) > Cc: mmusic@ietf.org; Dan Wing (dwing); Prashanth Patil (praspati); Pal > Martinsen (palmarti) > Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice- > mobility-01.txt >=20 > Hey Tiru, >=20 > On 18.09.12, 14:07, Tirumaleswar Reddy (tireddy) wrote: > >> > The only reason I can think why ICE Mobility would fail and ICE > >> > restart succeed is because of Simultaneous Mobility > >> > >> Well ... I might be missing something but it seems to me that the only > >> time it would succeed would be when there's a direct reachability > >> between the mobile node's new address and their correspondent. > >> > >> This would be the case when the mobile node has moved into the same > >> NATed network as the correspondent, or when the correspondent has a > >> public address with no one to perform endpoint dependent filtering in > >> front of them. > >> > >> In all other situations (which would likely represent the majority of > >> the cases) ICE mobility would fail and one would need to perform an IC= E > >> restart. > >> > >> Emil > > > > Hi Emil, > > > > Thanks for the review. > > > > I have assumed that the other Mobile Device (Correspondent Node in this > > case) would include MOBILITY-SUPPORT only in the following cases : > > IPv6 Global Address, >=20 > And I insist, even with IPv6 there should be no that performs endpoint > dependent filtering in front of the CN. Many corporate firewalls would > not allow incoming traffic unless it has been initiated from the inside. > Just as they would for IPv4. >=20 > > Correspondent Node is behind Endpoint-Independent > > Mapping/Filtering NAT as recommended in RFC 4787. >=20 > While 4787 is quite adamant about avoiding endpoint dependent mapping > this is not the case for endpoint dependent filtering: >=20 > RTF 4787, REQ-8: ... If a more stringent filtering behavior is most > important, it is RECOMMENDED that a NAT have an "Address-Dependent > Filtering" behavior. >=20 > That text aside, while one could hope that (at least in certain parts of > the world) a decent number of CNs would be behind a NAT with endpoint > independent mapping, it is very rare to see commercial deployments with > endpoint independent filtering. >=20 > > But to make it work in other scenarios where Correspondent Node(CN) is > > behind Address-Dependent Filtering/Mapping, CN can detect the NAT > > behavior using simple tests suggested in RFC 5780 and so not include > > MOBILITY-SUPPORT attribute. >=20 > That kind of diagnostics are extremely difficult to apply in practice > (which is one of the reasons for ICE to exist) and even if they weren't, > disabling ICE mobility for NATs with endpoint dependent filtering would > leave you with very few cases where one would be able to use it. Hi Emil, Thanks for the detailed explanation. We will add details that ICE agent wil= l try ICE Mobility and ICE restart in parallel. So that in case of Endpoint= dependent filtering/Firewall scenarios even if ICE Mobility fails, ICE res= tart would succeed.=20 [1]Endpoint independent mapping/filtering -> No issues with ICE Mobility. [2]Endpoint dependent mapping -> ICE peers will have to use UDP relays. Mob= ile Devices will end up using the technique in section 4 of the draft (Mobi= lity with TURN) --Tiru. >=20 > > [Even without ICE Mobility, if both Mobile devices are behind non-BEHAV= E > > compliant NAT then ICE connectivity checks using host/server-reflexive > > candidates will fail and end up using UDP relay] >=20 > Well again, NATs with endpoint dependent filtering are totally fine with > 4787 and they do work with server-reflexive addresses. >=20 > Cheers, > Emil >=20 > -- > https://jitsi.org From fluffy@cisco.com Wed Sep 19 09:39:15 2012 Return-Path: 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 66E5821F86BA for ; Wed, 19 Sep 2012 09:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, 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 AebdNMKDEowS for ; Wed, 19 Sep 2012 09:39:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 546B221F869C for ; Wed, 19 Sep 2012 09:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5627; q=dns/txt; s=iport; t=1348072754; x=1349282354; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=b5DpvM+9QH9ISvdoGeyOIpNDvQ+KlnUuYzxIbXFeBjo=; b=J44OzNqUzNgAkEsN03GmWcQBn9vp57zEbVkMPw4E9dUufCxxr+Gqbjp6 AYxIxksdfXfZeUmw4FqRN6Mq2YXXZH+6CE4epklUddRTF6ifu1XPFuf1W /c2P1ISmV5T/U6dHl1NXCaYOd8Vtoap4QolmUhVrto7uFXgJvk5wDZHJ3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoFANDzWVCtJV2a/2dsb2JhbABCA6pVkW6BCIIgAQEBAwEBAQEPAVsEBwULAgEIGC4nCyUCBA4FIodPAwYGC5ptoBAEijpigx2CRGADiCGLb4FUixeDIYFpgmaCFw X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="123013333" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 19 Sep 2012 16:39:13 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8JGdDGj000863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 16:39:13 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Wed, 19 Sep 2012 11:39:10 -0500 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [MMUSIC] H.264 SVC and BUNDLE Thread-Index: AQHNloVLMhpQ5M3/Q0ylwrKrMlDtkw== Date: Wed, 19 Sep 2012 16:39:10 +0000 Message-ID: <11997BCA-DD8D-4823-AB51-4D4999F31590@cisco.com> References: <503E0B63.3020708@ericsson.com>, , , <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com>, <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com>, <503FCAA1.5080500@alvestrand.no> , <503FDBA1.9000003@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19192.002 x-tm-as-result: No--48.401500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2B2A419943A1D34E938C1B4D7277E7C7@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] H.264 SVC and BUNDLE X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 16:39:15 -0000 If you do what have been suggesting for bundle, the offer of SVC with bundl= e looks exactly the same with the exception that an a=3Dbundle line gets ad= ded and if the receiver supports bundle, they know they put things on the s= ame port. We can talk about this more but I have a hard time imaging anythi= ng else working with existing SDP.=20 So the only change to SDP in offer below is the addition of line "a=3Dgroup= :BUNDLE SST L1 L2"=20 a=3Dgroup:BUNDLE SST L1 L2 a=3Dgroup:DDP L1 L2 m=3Dvideo 20000 RTP/AVP 97 96 a=3Drtpmap:96 H264-SVC/90000 a=3Dfmtp:96 profile-level-id=3D53001e; packetization-mode=3D0; a=3Drtpmap:97 H264-SVC/90000 a=3Dfmtp:97 profile-level-id=3D53001f; packetization-mode=3D1; a=3Dmid:SST m=3Dvideo 20002 RTP/AVP 98 a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D4de00a; packetization-mode=3D0; mst-mode=3DNI-T; a=3Dmid:L1 m=3Dvideo 20004 RTP/AVP 99 a=3Drtpmap:99 H264-SVC/90000 a=3Dfmtp:99 profile-level-id=3D53001F; packetization-mode=3D1; mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c, 3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>; a=3Dmid:L2 a=3Ddepend:99 lay L1:98 I have a hard time imagining any SIP UAS that would did SVC that would have= a problem with this even if it did not understand bundle.=20 On Aug 30, 2012, at 7:30 PM, Bernard Aboba wrot= e: > Harald said: >=20 > I lack the background to think about this... in existing equipment, if yo= u want to do SST, but would be willing to do MST if the other end did not s= upport SST, how would your offer look (without BUNDLE)? >=20 > My head hurts a little when trying to guess, but from your question it so= unds like you've done it, so it's better if you just paste an example. >=20 > (BTW, this is really an MMUSIC discussion) >=20 > [BA] RFC 6190 gives several examples of SST and MST offers: >=20 > 7.3.1. Example for Offering a Single SVC Session >=20 > 7.3.2. Example for Offering a Single SVC Session Using scalable-layer-Id >=20 > 7.3.3. Example for Offering Multiple Sessions in MST >=20 > 7.3.4. Example for Offering Multiple Sessions in MST Including Operation= with Answerer Using scalable-layer-id >=20 > 7.3.5. Example for Negotiating an SVC Stream with a Constrained Base Lay= er in SST >=20 > I believe that the answer to your question is closest to example 7.3.5 (S= ST) with a bit of 7.3.4 (MST) thrown in. Notice that Payload types 97 and 9= 9 are similar but not the same (97 is SST, 99 is MST):=20 >=20 > Offer:=20 > a=3Dgroup:DDP L1 L2 > m=3Dvideo 20000 RTP/AVP 97 96 > a=3Drtpmap:96 H264-SVC/90000 > a=3Dfmtp:96 profile-level-id=3D53001e; packetization-mode=3D0; > a=3Drtpmap:97 H264-SVC/90000 > a=3Dfmtp:97 profile-level-id=3D53001f; packetization-mode=3D1; >=20 > a=3Dmid:SST > m=3Dvideo 20002 RTP/AVP 98 > a=3Drtpmap:98 H264/90000 > a=3Dfmtp:98 profile-level-id=3D4de00a; packetization-mode=3D0; > mst-mode=3DNI-T; > a=3Dmid:L1 > m=3Dvideo 20004 RTP/AVP 99 > a=3Drtpmap:99 H264-SVC/90000 > a=3Dfmtp:99 profile-level-id=3D53001F; packetization-mode=3D1; > mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c, > 3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>; > a=3Dmid:L2 > a=3Ddepend:99 lay L1:98 >=20 >=20 > On 08/30/2012 11:19 PM, Bernard Aboba wrote: > Harald said:=20 >=20 > > My assumption has always been that if you were operating on a network=20 > > that could only apply diffserv to separate 5-tuples, you would allocate= =20 > > the SSRCs comprising a multilayer encoding to different 5-tuples. >=20 > [BA] RFC 6190 Section 1 says: >=20 > This memo defines two basic modes for transmission of SVC data, > single-session transmission (SST) and multi-session transmission > (MST). In SST, a single RTP session is used for the transmission of > all scalability layers comprising an SVC bitstream; in MST, the > scalability layers are transported on different RTP sessions. =20 >=20 >=20 > [BA] So it is possible either to use multiple 5-tuples (MST) or a single = 5-tuple (SST). However, my understanding=20 > is that the SST approach is more popular than MST.=20 >=20 > > This choice seems to be a choice that the application writer should tak= e=20 > > before deciding whether or not to use BUNDLE, so it's a little hard to= =20 > > see what the relationship to BUNDLE is. >=20 > [BA] The open question has been how to indicate the desire for both layer= ed coding and BUNDLE in SDP,=20 > given the backward compatibility issues we have talked about. For exampl= e, if it is desired to do SST and > BUNDLE, do you signal MST and BUNDLE on different ports in the offer and = then if SST and BUNDLE are > supported by the answer, have the answer respond with BUNDLE as well as d= ependency groups using=20 > the same port? That would seem to imply an assumption that every MST imp= lementation can also do SST. =20 > Or do do you signal SST and BUNDLE on the same port, and then if the resp= onse indicates that the SDP > was rejected, formulate an alternative offer (MST with BUNDLE? H.264/AVC= with BUNDLE?=20 > SST without BUNDLE??) =20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Wed Sep 19 09:41:59 2012 Return-Path: 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 3663621F8714 for ; Wed, 19 Sep 2012 09:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 j2X-ckCAAeYa for ; Wed, 19 Sep 2012 09:41:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 99E8B21F86BA for ; Wed, 19 Sep 2012 09:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=270; q=dns/txt; s=iport; t=1348072918; x=1349282518; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iwefjAjsuk0O65kBaYzk11DKCKP00ZlTAXx6JPLdIgc=; b=Cc3ytsqHNNJ3ogAEb14HJmLwQQIW2qYV825hLMo/1gPBqmx3D7MZMhOg tGoNLndagv+jscoQe/ErrgzFhdrny/V0xdKwj27UPwMpwAkYACCSbZW+M aCZGQBABIla90nArSDZTSvICozZFLruKom3pWY8t3AGSgCPM990asg8uR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4GAPr0WVCtJV2b/2dsb2JhbABFhUKlE5FugQiCIAEBAQMBEgEnPxACAQg2EDIlAgQOBSKHTwMGBpp8oBSKOmKFYWADlBCBVIsXgyGBaYJmghc X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="123235923" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 19 Sep 2012 16:41:58 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8JGfwhC020661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 16:41:58 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Wed, 19 Sep 2012 11:41:58 -0500 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloWuD9Ycc2NyQEeW/u8tEHQmlQ== Date: Wed, 19 Sep 2012 16:41:57 +0000 Message-ID: References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19192.002 x-tm-as-result: No--28.220000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 16:41:59 -0000 On Aug 25, 2012, at 11:01 AM, Bernard Aboba wro= te: >=20 > Cullen -- did you mean to include "baz" on the=20 > a=3Dgroup:BUNDLE foo L1 L2 baz >=20 > line, since the a=3Dmid:baz line is now gone?=20 oops - think that was a typo From fluffy@cisco.com Wed Sep 19 09:43:20 2012 Return-Path: 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 0885721F84AF for ; Wed, 19 Sep 2012 09:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 AvO6R+9eikCY for ; Wed, 19 Sep 2012 09:43:19 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0836A21F846F for ; Wed, 19 Sep 2012 09:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=285; q=dns/txt; s=iport; t=1348072999; x=1349282599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TwXtLnBJRU+5AFlEge/U8NkNDBdwgpgXlDGNkbgoqcg=; b=Dm1XdWftPAMjHiQu9S7txIynQrxY0CRfsQaKu8MJadgJynBtUcwnVDEJ 1pSwqn/OtfVFGEzTNEjTZ0/Ygs96tmw0BJ12vSAi85LBXKlOSt2h3YPsq xgGtGookiT6ngyJ09wjgZoxF6nUdyaOMm3Qeb4t1EYExRsvxoIeVPw1Zs w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGAPr0WVCtJV2b/2dsb2JhbABFhUK3AYEIgiABAQEDARIBJz8QAgEINhAyJQIEDgUih1gGmnygFIschWFgA5VkjjiBaYJmghc X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="123236422" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 19 Sep 2012 16:43:18 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8JGhIH3022964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 16:43:18 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Wed, 19 Sep 2012 11:43:18 -0500 From: "Cullen Jennings (fluffy)" To: Harald Alvestrand Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeyjR8ykvghUOGAUODX8YoJg== Date: Wed, 19 Sep 2012 16:43:17 +0000 Message-ID: <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no> In-Reply-To: <503B29B6.5000000@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19192.002 x-tm-as-result: No--28.534400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <9A562C658268074D96F6EA0D3F56DE36@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 16:43:20 -0000 On Aug 27, 2012, at 2:03 AM, Harald Alvestrand wrote= : >> So, IF people think that offering the same port will cause problem, For me this is not longer an IF, for equipment I am concerned about it has = become a does as I explain at last meeting.=20 From fluffy@cisco.com Wed Sep 19 09:50:51 2012 Return-Path: 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 5B66521F86F7 for ; Wed, 19 Sep 2012 09:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 hkHi4uaSRrcI for ; Wed, 19 Sep 2012 09:50:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6927121F865F for ; Wed, 19 Sep 2012 09:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3329; q=dns/txt; s=iport; t=1348073447; x=1349283047; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=P6LjbrixUgJpmixMhhs3S72aZDnRTrMosZ/t1ay1IFw=; b=bvg7wjqlgapSyerKR6K44CQAWflhhUGJRNdURBcJAze5qsdcSNkreVxK M76AZNCNoL0EK+EYKqCtOSvk56OM83vbJl8X+P5Pjbabu2NRrNWxDbKuJ /EcZtlWQGYlIWajzsvFjI0UbuJhAisEw3FrQqFuh2c7D1mq/4S8PIfQUZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGH3WVCtJV2Z/2dsb2JhbAA7CrxDgQiCIAEBAQMBEgEnNAsFCwIBCDYQMiUCBA4FCRmHWAYLmnagFYscEAqFR2ADlWSOOIFpgmaBYzQ X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="123269390" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 19 Sep 2012 16:50:47 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8JGokHq021239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 16:50:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Wed, 19 Sep 2012 11:50:46 -0500 From: "Cullen Jennings (fluffy)" To: "Miguel A. Garcia" Thread-Topic: [MMUSIC] Poll for path on ICE extensions and updates/corrections Thread-Index: AQHNlobp4vdKNLtouUuqL0uCYj/gtw== Date: Wed, 19 Sep 2012 16:50:45 +0000 Message-ID: References: <505972DD.3060908@ericsson.com> In-Reply-To: <505972DD.3060908@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19192.002 x-tm-as-result: No--43.928500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , mmusic Subject: Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 16:50:51 -0000 On Sep 19, 2012, at 1:23 AM, Miguel A. Garcia wrote: > Hi all, >=20 > This mail relates to ICE [RFC 5245]. >=20 > In the past few months, we have seen a number of documents that are > trying to improve the usage of ICE in different ways. The list of > documents include at least the following drafts: >=20 > - draft-keranen-mmusic-ice-address-selection-01 > - draft-petithuguenin-mmusic-ice-attributes-level-03 > - draft-wing-mmusic-ice-mobility-01 > - draft-elwell-mmusic-ice-updated-offer-02 >=20 > There is, in addition, a long discussion in the RTCWEB mailing list > about "trickle ICE", and a couple of other ICE-related drafts > and discussions in RTCWEB. >=20 > Most likely, we can categorize these documents in two big classes: >=20 > a) Documents that identify underspecified areas or errors in the spec, > which are often driven by implementation experience >=20 > b) Documents that update or extend ICE with new functionality, such as > "tricke ICE" (see e.g. the e-mail thread at > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html) . > Such documents may involve normative updates to the ICE specification or > they may simply be ICE extensions.". >=20 > Assuming that we would get consensus to adopt some or all of these > documents as work to proceed on, the MMUSIC chairs and RAI ADs would > like to get some sense of how should we aim at documenting it. Below > are some options, please comment on them or add alternatives. >=20 > a) Create a revision of ICE (i.e., a document what will obsolete RFC 5245= ), including all the extensions and corrections that > we want to choose from the list. This sounds like a big effort in > time, and presumably will create a big spec. We should make sure that > people have enough cycles to devote to this activity. >=20 > b) Create a revision of ICE (obsoleting RFC 5245), but only addressing > bug fixing and opening hooks to extensions, with the idea that > extensions won't need to violate 5245bis. Additionally, document each > extension in a separate RFC. Extensions will depend and refer to the > 5245bis draft. >=20 > c) Leave the current ICE core spec as is. Document each extension > separately (referring to 5245). Create open or more documents listing > bug fixes and corrections (will also update RFC 5245). >=20 > Needless to say, at this point in time, there is no decision as for > which of the ICE-related drafts will proceed or not. We are just > trying to get consensus of how to document ICE-related drafts, and in par= ticular if the WG believes we should do a revision of RFC 5245. If so, we a= lso need to hear who is willing to work on such a revision. >=20 > Now, it is your time to express your opinion. First of all, I think it is critical we do one of these and which one we ch= oose is not as critical.=20 >From the point of view of what would be best for folks implementing ICE, th= at would be a complete rewrite that fixed the problems and added in the new= stuff. However that would be the most work to create at IETF.=20 If some experienced editor has the time and energy to take on "A" I would b= e in favor of A. But if we don't have someone willing to step up to do that= , then I would favor "B".=20 Cullen From christer.holmberg@ericsson.com Wed Sep 19 09:55:16 2012 Return-Path: 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 25DBD21F875B for ; Wed, 19 Sep 2012 09:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 dKkItnWTjhKY for ; Wed, 19 Sep 2012 09:55:14 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 22D3121F8551 for ; Wed, 19 Sep 2012 09:55:12 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-60-5059f8efc49e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E7.5E.25676.FE8F9505; Wed, 19 Sep 2012 18:55:11 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 19 Sep 2012 18:55:11 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , Harald Alvestrand Date: Wed, 19 Sep 2012 18:53:45 +0200 Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeyjR8ykvghUOGAUODX8YoJpeR4Z5S Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> In-Reply-To: <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvre77H5EBBnsaJS06JrNZHOvrYrOY uvwxiwOzx5UJV1g9pvzeyOqxZMlPpgDmKC6blNSczLLUIn27BK6M/jcf2Ar62Soad75ibmD8 ztLFyMkhIWAi8a//K5QtJnHh3nq2LkYuDiGBU4wSBz+tZIJwFjBK3Lr9kbWLkYODTcBCovuf NkiDiECsxK6lf9lAwswC6hJXFweBhFkEVCWunetiBbGFBeIlVmxbygxRniCxa9JaRgjbSOJK 11UmkFZegXCJW2+qIDZNYJGYfeI3WA2ngK3ErLlPweYwAt32/dQaJhCbWUBc4taT+UwQNwtI LNlznhnCFpV4+fgfVL2oxJ329YwQ9ToSC3Z/YoOwtSWWLXwNVs8rIChxcuYTlgmMYrOQjJ2F pGUWkpZZSFoWMLKsYhTOTczMSS830kstykwuLs7P0ytO3cQIjKWDW36r7mC8c07kEKM0B4uS OK/11j3+QgLpiSWp2ampBalF8UWlOanFhxiZODilGhj5pm3ccuxGns5J7yT2p/O1CnOuZD15 N0Xww7HkBTqrZ73R3RiwZK/UA1bXfzIngxYlvr0xefqV9JCil9F7HX/qhTeI2Aa/tWJUtPup /ddOd9n3dyZ/Ny1a5SC95azdrZs3mDVbPPbb8LQuuD1n9sLN/HbvQyI1V7x/6uN3bqndrdlG aqaf71pyKbEUZyQaajEXFScCAFqr9+JzAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 16:55:16 -0000 Hi, I've put together a new version of BUNDLE, with a dedicated m- line for the= bundled media. It will be submitted very soon, once I get some editorial fixes done. Regards, Christer ________________________________________ From: Cullen Jennings (fluffy) [fluffy@cisco.com] Sent: Wednesday, September 19, 2012 7:43 PM To: Harald Alvestrand Cc: Christer Holmberg; mmusic@ietf.org Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line f= or bundled session On Aug 27, 2012, at 2:03 AM, Harald Alvestrand wrote= : >> So, IF people think that offering the same port will cause problem, For me this is not longer an IF, for equipment I am concerned about it has = become a does as I explain at last meeting.= From fluffy@cisco.com Wed Sep 19 10:11:03 2012 Return-Path: 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 2ED0521F867F for ; Wed, 19 Sep 2012 10:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.913 X-Spam-Level: X-Spam-Status: No, score=-109.913 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, 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 GOhBkWXChNbT for ; Wed, 19 Sep 2012 10:11:02 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 21AEC21F867E for ; Wed, 19 Sep 2012 10:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1769; q=dns/txt; s=iport; t=1348074662; x=1349284262; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6TvZnT/PGxoYCfrxgrBTXYKHE6uJtTNfKxU2pwaPwcM=; b=I56s+sDJmaSH2jaCMVsg8RZo0uY2gqez2PiyB2oIHhl6bBMy8e5l9oiT q8YsB2vpl24nNZadPEXl5pMyL0EQH/9CBqezOUNQ/cglr7cJ/Fspfsjk0 RSR3bBhWUOh4PSSxcYKVKCRd7WiNDW9uv0mkXvUo9rw28R14v2st30B7J o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFj7WVCtJV2a/2dsb2JhbABFvEOBCIIgAQEBAwEBAQEPASc0CwULAgEIEQQBAQEeECcLHQgCBA4FIodYBguaf6AOBIschWFgA5VkjjiBaYJmghc X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="120244868" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 19 Sep 2012 17:11:00 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8JHB0Vb006253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 17:11:00 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Wed, 19 Sep 2012 12:11:00 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeyjR8ykvghUOGAUODX8YoJpeR4Z5SgABYooA= Date: Wed, 19 Sep 2012 17:10:59 +0000 Message-ID: <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19192.002 x-tm-as-result: No--46.437700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <23A943028E0FB243A129C866311B7DF0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 17:11:03 -0000 As an individual draft or WG draft? because I am definitely don't think we= have consensus for the "m=3Dbundle" approach yet. I just think the m=3Dbun= dle approach is going to be much harder to get to work with existing equipm= ent. Stuff is used to seeing a=3Dfoo lines they don't understand. They are = not used to seeing m=3Dfoo lines they don't understand. It doubles the size= of the SDP. It creates confusing when rest of SDP in the non bundle part d= oes not match bundle part. It's harder to add other things like opportunist= ic encryption. But my real problem with it is I don't see any advantage of = the m=3Dbundle approach over the a=3Dbundle approach.=20 On Sep 19, 2012, at 10:53 AM, Christer Holmberg wrote: > Hi, >=20 > I've put together a new version of BUNDLE, with a dedicated m- line for t= he bundled media. >=20 > It will be submitted very soon, once I get some editorial fixes done. >=20 > Regards, >=20 > Christer >=20 > ________________________________________ > From: Cullen Jennings (fluffy) [fluffy@cisco.com] > Sent: Wednesday, September 19, 2012 7:43 PM > To: Harald Alvestrand > Cc: Christer Holmberg; mmusic@ietf.org > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line= for bundled session >=20 > On Aug 27, 2012, at 2:03 AM, Harald Alvestrand wro= te: >=20 >>> So, IF people think that offering the same port will cause problem, >=20 > For me this is not longer an IF, for equipment I am concerned about it ha= s become a does as I explain at last meeting. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Wed Sep 19 10:15:56 2012 Return-Path: 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 9D09121F8526 for ; Wed, 19 Sep 2012 10:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 kJtE7dQi0Cdy for ; Wed, 19 Sep 2012 10:15:56 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 986CF21F8525 for ; Wed, 19 Sep 2012 10:15:55 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-75-5059fdcac9bd Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B0.84.17130.ACDF9505; Wed, 19 Sep 2012 19:15:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 19 Sep 2012 19:15:54 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Date: Wed, 19 Sep 2012 19:12:27 +0200 Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeyjR8ykvghUOGAUODX8YoJpeR4Z5SgABYooD//6yYEQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> In-Reply-To: <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre6pv5EBBv9mqVl0TGazONbXxWYx dfljFgdmjysTrrB6TPm9kdVjyZKfTAHMUVw2Kak5mWWpRfp2CVwZX54dYCtYx1+x8vM31gbG ZTxdjJwcEgImEpe+3GKEsMUkLtxbz9bFyMUhJHCKUeLQrnfsEM4cRok7M08CZTg42AQsJLr/ aYM0iAgYSjTtmccEYjMLBEtce3APzGYRUJXomvCLDcQWFoiXWLFtKTNEfYLErklrGSFsJ4kj O/6xgNi8AuESW5/8ZYbYNYlVYsKW72AJTgFbiZ6Zk8GaGYGu+35qDdQycYlbT+YzQVwtILFk z3lmCFtU4uXjf6wQ9aISd9rXM0LU60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSbhWTsLCQt s5C0zELSsoCRZRWjcG5iZk56ublealFmcnFxfp5eceomRmA8Hdzy22AH46b7YocYpTlYlMR5 9VT3+wsJpCeWpGanphakFsUXleakFh9iZOLglGpg1Orkj36mu8op0WOS7ufAAKZNqaVvAx9t Zme+GjvTmTPsxjH/g/cPv2dQeW/Je3/eLq6KQz8P5AnF7znEsnJaFkfLjVILb84JzCfSMpt4 K/Wjm7mnvNRM5BTUtee/9N/pdZqY8unHt+wdV1jE1xwO59R+9lBhT541m+uXmMgf6b1mD5Re PXmpxFKckWioxVxUnAgA9wxs+3UCAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 17:15:56 -0000 Hi, >As an individual draft or WG draft? It was meant to be a new version of bundle... >because I am definitely don't think we have consensus for the "m=3Dbundle"= approach yet. I just think the >m=3Dbundle approach is going to be much ha= rder to get to work with existing equipment. Stuff is used to >seeing a=3Df= oo lines they don't understand. They are not used to seeing m=3Dfoo lines t= hey don't understand. >It doubles the size of the SDP. It creates confusing= when rest of SDP in the non bundle part does not >match bundle part. It's = harder to add other things like opportunistic encryption. But my real probl= em >with it is I don't see any advantage of the m=3Dbundle approach over th= e a=3Dbundle approach. What is the a=3Dbundle approach? Offering "normal" (audio, video, etc) m- l= ines, and then use one of them for the whole bundle? Regards, Christer On Sep 19, 2012, at 10:53 AM, Christer Holmberg wrote: > Hi, > > I've put together a new version of BUNDLE, with a dedicated m- line for t= he bundled media. > > It will be submitted very soon, once I get some editorial fixes done. > > Regards, > > Christer > > ________________________________________ > From: Cullen Jennings (fluffy) [fluffy@cisco.com] > Sent: Wednesday, September 19, 2012 7:43 PM > To: Harald Alvestrand > Cc: Christer Holmberg; mmusic@ietf.org > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line= for bundled session > > On Aug 27, 2012, at 2:03 AM, Harald Alvestrand wro= te: > >>> So, IF people think that offering the same port will cause problem, > > For me this is not longer an IF, for equipment I am concerned about it ha= s become a does as I explain at last meeting. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic= From palmarti@cisco.com Wed Sep 19 11:08:11 2012 Return-Path: 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 7948121F867F for ; Wed, 19 Sep 2012 11:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 PlWdqGBpS4uh for ; Wed, 19 Sep 2012 11:08:10 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 82EEF21F8678 for ; Wed, 19 Sep 2012 11:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4257; q=dns/txt; s=iport; t=1348078090; x=1349287690; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8bKU82DbOW5h4EIsTHvSw36seA+ztWQrYVScXuFsXns=; b=iwW8nuctnZZlZj4ZKyWrIBStlPJv2yhjRbMAGsOgWGBgZnGICgcRWdRK 9rcPBlqP7P3VPdjLsgUxOwAC4y0Kpq13QDA8rpNFgO4VDBosnP3t31Rpx TFcM2uEWKnnM9AUtvkou/onVyI3cY5Ka+rCQ95qOngtgZAGKSKgI7IS6m c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIIIWlCtJV2b/2dsb2JhbAA7CrxDgQiCIAEBAQMBAQEBDwFbCwULAgEIGC4nCyUCBA4FCRmHWAYLmn2gFYscEAqFR2ADiCGNQ444gWmCZoFjNA X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="123248597" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 19 Sep 2012 18:08:10 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8JI89HZ003654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 18:08:10 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Wed, 19 Sep 2012 13:08:09 -0500 From: "Pal Martinsen (palmarti)" To: "Cullen Jennings (fluffy)" Thread-Topic: [MMUSIC] Poll for path on ICE extensions and updates/corrections Thread-Index: AQHNljel6XExWKzLsk2D6sU0rQ5Q5peSNTWAgAAVnwA= Date: Wed, 19 Sep 2012 18:08:08 +0000 Message-ID: <5FC46A0A-11F9-494C-B248-42D3D15BF0AB@cisco.com> References: <505972DD.3060908@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.103.210] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19192.002 x-tm-as-result: No--48.763300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <590F9EE08B9199418E3EEF5895359663@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , mmusic Subject: Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 18:08:11 -0000 On Sep 19, 2012, at 6:50 PM, "Cullen Jennings (fluffy)" wrote: >=20 > On Sep 19, 2012, at 1:23 AM, Miguel A. Garcia wrote: >=20 >> Hi all, >>=20 >> This mail relates to ICE [RFC 5245]. >>=20 >> In the past few months, we have seen a number of documents that are >> trying to improve the usage of ICE in different ways. The list of >> documents include at least the following drafts: >>=20 >> - draft-keranen-mmusic-ice-address-selection-01 >> - draft-petithuguenin-mmusic-ice-attributes-level-03 >> - draft-wing-mmusic-ice-mobility-01 >> - draft-elwell-mmusic-ice-updated-offer-02 >>=20 >> There is, in addition, a long discussion in the RTCWEB mailing list >> about "trickle ICE", and a couple of other ICE-related drafts >> and discussions in RTCWEB. >>=20 >> Most likely, we can categorize these documents in two big classes: >>=20 >> a) Documents that identify underspecified areas or errors in the spec, >> which are often driven by implementation experience >>=20 >> b) Documents that update or extend ICE with new functionality, such as >> "tricke ICE" (see e.g. the e-mail thread at >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html) . >> Such documents may involve normative updates to the ICE specification or >> they may simply be ICE extensions.". >>=20 >> Assuming that we would get consensus to adopt some or all of these >> documents as work to proceed on, the MMUSIC chairs and RAI ADs would >> like to get some sense of how should we aim at documenting it. Below >> are some options, please comment on them or add alternatives. >>=20 >> a) Create a revision of ICE (i.e., a document what will obsolete RFC 524= 5), including all the extensions and corrections that >> we want to choose from the list. This sounds like a big effort in >> time, and presumably will create a big spec. We should make sure that >> people have enough cycles to devote to this activity. >>=20 >> b) Create a revision of ICE (obsoleting RFC 5245), but only addressing >> bug fixing and opening hooks to extensions, with the idea that >> extensions won't need to violate 5245bis. Additionally, document each >> extension in a separate RFC. Extensions will depend and refer to the >> 5245bis draft. >>=20 >> c) Leave the current ICE core spec as is. Document each extension >> separately (referring to 5245). Create open or more documents listing >> bug fixes and corrections (will also update RFC 5245). >>=20 >> Needless to say, at this point in time, there is no decision as for >> which of the ICE-related drafts will proceed or not. We are just >> trying to get consensus of how to document ICE-related drafts, and in pa= rticular if the WG believes we should do a revision of RFC 5245. If so, we = also need to hear who is willing to work on such a revision. >>=20 >> Now, it is your time to express your opinion. >=20 > First of all, I think it is critical we do one of these and which one we = choose is not as critical.=20 >=20 agree > From the point of view of what would be best for folks implementing ICE, = that would be a complete rewrite that fixed the problems and added in the n= ew stuff. However that would be the most work to create at IETF.=20 >=20 I think one of the things that slows down the adoption rate of ICE is that = people still seems to have this feeling that ICE is still unstable and not = proven. The different flavours of ICE out in the wild might suggest that t= hey are right.=20 Developing a ICE stack is also a fair amount of work and have a minimum set= of features described in a core specification would help developers focus= on the right things. And then add the extensions later. Would make interop= testing at SipIT easier as well. > If some experienced editor has the time and energy to take on "A" I would= be in favor of A. But if we don't have someone willing to step up to do th= at, then I would favor "B".=20 >=20 I would favour B then C and at last A. .-. P=E5l-Erik > Cullen >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From richard.ejzak@alcatel-lucent.com Wed Sep 19 15:25:23 2012 Return-Path: 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 1A50F21E80B7 for ; Wed, 19 Sep 2012 15:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.049 X-Spam-Level: X-Spam-Status: No, score=-9.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8] 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 4Q+slzkHuDqa for ; Wed, 19 Sep 2012 15:25:22 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 48DA821E80B6 for ; Wed, 19 Sep 2012 15:25:22 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8JMPIPq030016 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 20 Sep 2012 00:25:19 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 20 Sep 2012 00:25:18 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.110]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Wed, 19 Sep 2012 18:25:13 -0400 From: "Ejzak, Richard P (Richard)" To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeD9Ycc2NyQEeW/u8tEHQmlZeSJKuAgAAE0YCAAABpgIAADcgg Date: Wed, 19 Sep 2012 22:24:57 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] 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] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 22:25:23 -0000 Christer, I also did not get the impression that there was agreement on the m=3Dbundl= e approach since there were a number of open issues. As Cullen suggested in http://www.ietf.org/mail-archive/web/mmusic/current/= msg09561.html, just offer a normal SDP, add a bundle line, and assume the u= se of the connection information from the first m line. I agree with Culle= n. I do not agree with the m=3Dbundle approach for all the reasons Cullen = mentions. The only thing I would add is that some networks may require an = updated offer be sent listing the correct port (the same one) on each media= line if bundle is negotiated. ICE already requires a 2nd offer in many ca= ses, so I don't see this as a problem. Richard=20 =20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Wednesday, September 19, 2012 12:12 PM > To: Cullen Jennings (fluffy) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line > for bundled session >=20 > Hi, >=20 > >As an individual draft or WG draft? >=20 > It was meant to be a new version of bundle... >=20 > >because I am definitely don't think we have consensus for the "m=3Dbundl= e" > approach yet. I just think the >m=3Dbundle approach is going to be much > harder to get to work with existing equipment. Stuff is used to >seeing > a=3Dfoo lines they don't understand. They are not used to seeing m=3Dfoo = lines > they don't understand. >It doubles the size of the SDP. It creates > confusing when rest of SDP in the non bundle part does not >match bundle > part. It's harder to add other things like opportunistic encryption. But > my real problem >with it is I don't see any advantage of the m=3Dbundle > approach over the a=3Dbundle approach. >=20 > What is the a=3Dbundle approach? Offering "normal" (audio, video, etc) m- > lines, and then use one of them for the whole bundle? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > On Sep 19, 2012, at 10:53 AM, Christer Holmberg > wrote: >=20 > > Hi, > > > > I've put together a new version of BUNDLE, with a dedicated m- line for > the bundled media. > > > > It will be submitted very soon, once I get some editorial fixes done. > > > > Regards, > > > > Christer > > > > ________________________________________ > > From: Cullen Jennings (fluffy) [fluffy@cisco.com] > > Sent: Wednesday, September 19, 2012 7:43 PM > > To: Harald Alvestrand > > Cc: Christer Holmberg; mmusic@ietf.org > > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m- > line for bundled session > > > > On Aug 27, 2012, at 2:03 AM, Harald Alvestrand > wrote: > > > >>> So, IF people think that offering the same port will cause problem, > > > > For me this is not longer an IF, for equipment I am concerned about it > has become a does as I explain at last meeting. > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Wed Sep 19 15:34:48 2012 Return-Path: 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 0FD4121F8508 for ; Wed, 19 Sep 2012 15:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 idZr+WANm7Cw for ; Wed, 19 Sep 2012 15:34:47 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 68EF221F8505 for ; Wed, 19 Sep 2012 15:34:45 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-3a-505a48843ae1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0F.3F.25676.4884A505; Thu, 20 Sep 2012 00:34:45 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 20 Sep 2012 00:34:44 +0200 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "mmusic@ietf.org" Date: Thu, 20 Sep 2012 00:32:06 +0200 Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeD9Ycc2NyQEeW/u8tEHQmlZeSJKuAgAAE0YCAAABpgIAADcgggAAIemg= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrW6rR1SAwaeFTBZTlz9msehtCHdg 8mh9tpfVY8mSn0wBTFFcNimpOZllqUX6dglcGfPXfmUpuCxTce/fN6YGxibxLkZODgkBE4nN B5qZIWwxiQv31rOB2EICpxgljm5y7WLkArIXMEpsXDYNKMHBwSZgIdH9TxukRkQgS2LrqX4W EJtFQFVi75qzrCC2sEC8xIptS5khahIkdk1aywhh+0nsOT0dbAyvQLjE+ztVEOO3sElcebkH bC+nQKzE04dXmEBsRqB7vp9aA2YzC4hL3HoynwniTgGJJXvOQ90sKvHy8T9WiHpRiTvt6xkh 6nUkFuz+xAZha0ssW/garJ5XQFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxSicm5iZk15u pJdalJlcXJyfp1ecuokRGB8Ht/xW3cF455zIIUZpDhYlcV7rrXv8hQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTDWXi36cWZ7bXnRqcIpahnMcpr3/jl/fTp3/ZkD+SufVfkerDy2KM7ubveC HdkLfjiJiIucYJrceP6bnIWA65sV3fzON5Zf7XnSEXXYfXXO4399a6Pz2JKD39Qf/u774fPv 1YJ1fQdrao5v3/LmypWZYQfsja8vbDl3pzryKd/nFf/uiO0ybNHKUGIpzkg01GIuKk4EAHWb Fp5dAgAA Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 22:34:48 -0000 Hi, >I also did not get the impression that there was agreement on the m=3Dbund= le approach since there were a number of open issues. Ok. >As Cullen suggested in http://www.ietf.org/mail-archive/web/mmusic/current= /msg09561.html, just offer a normal SDP, add a bundle line, and=20 >assume the use of the connection information from the first m line. I agr= ee with Cullen.=20 This is what Harald origianlly suggested, and I raised issues with that sol= ution. > I do not agree with the m=3Dbundle approach for all the reasons Cullen me= ntions. The only thing I would add is that some networks may=20 > require an updated offer be sent listing the correct port (the same one) = on each media line if bundle is negotiated. ICE already requires=20 > a 2nd offer in many cases, so I don't see this as a problem. I don't understand... The reason m=3Dbundle came up was because people did = NOT want to use the same port on each media line... Regards, Christer > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Wednesday, September 19, 2012 12:12 PM > To: Cullen Jennings (fluffy) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line > for bundled session > > Hi, > > >As an individual draft or WG draft? > > It was meant to be a new version of bundle... > > >because I am definitely don't think we have consensus for the "m=3Dbundl= e" > approach yet. I just think the >m=3Dbundle approach is going to be much > harder to get to work with existing equipment. Stuff is used to >seeing > a=3Dfoo lines they don't understand. They are not used to seeing m=3Dfoo = lines > they don't understand. >It doubles the size of the SDP. It creates > confusing when rest of SDP in the non bundle part does not >match bundle > part. It's harder to add other things like opportunistic encryption. But > my real problem >with it is I don't see any advantage of the m=3Dbundle > approach over the a=3Dbundle approach. > > What is the a=3Dbundle approach? Offering "normal" (audio, video, etc) m- > lines, and then use one of them for the whole bundle? > > Regards, > > Christer > > > > > > On Sep 19, 2012, at 10:53 AM, Christer Holmberg > wrote: > > > Hi, > > > > I've put together a new version of BUNDLE, with a dedicated m- line for > the bundled media. > > > > It will be submitted very soon, once I get some editorial fixes done. > > > > Regards, > > > > Christer > > > > ________________________________________ > > From: Cullen Jennings (fluffy) [fluffy@cisco.com] > > Sent: Wednesday, September 19, 2012 7:43 PM > > To: Harald Alvestrand > > Cc: Christer Holmberg; mmusic@ietf.org > > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m- > line for bundled session > > > > On Aug 27, 2012, at 2:03 AM, Harald Alvestrand > wrote: > > > >>> So, IF people think that offering the same port will cause problem, > > > > For me this is not longer an IF, for equipment I am concerned about it > has become a does as I explain at last meeting. > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic= From richard.ejzak@alcatel-lucent.com Wed Sep 19 16:28:28 2012 Return-Path: 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 8F6E821E8048 for ; Wed, 19 Sep 2012 16:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.049 X-Spam-Level: X-Spam-Status: No, score=-9.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8] 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 7hCNsRkWbmdA for ; Wed, 19 Sep 2012 16:28:27 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7215821E804E for ; Wed, 19 Sep 2012 16:28:26 -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 q8JNSOGF007290 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Sep 2012 01:28:24 +0200 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 20 Sep 2012 01:28:24 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.110]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 19 Sep 2012 19:28:21 -0400 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeD9Ycc2NyQEeW/u8tEHQmlZeSJKuAgAAE0YCAAABpgIAADcgggAAIemiAAA7iwA== Date: Wed, 19 Sep 2012 23:28:20 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] 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] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 23:28:28 -0000 What I understood is that the group (Cullen in particular) does not want th= e same port on multiple media lines when it is not known whether the peer s= upports bundle. Once you get agreement to use bundle I don't see a problem= , but maybe I missed something... Does anyone have a different perspective= ? > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, September 19, 2012 5:32 PM > To: Ejzak, Richard P (Richard); mmusic@ietf.org > Subject: RE: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line > for bundled session >=20 > Hi, >=20 > >I also did not get the impression that there was agreement on the > m=3Dbundle approach since there were a number of open issues. >=20 > Ok. >=20 > >As Cullen suggested in http://www.ietf.org/mail- > archive/web/mmusic/current/msg09561.html, just offer a normal SDP, add a > bundle line, and > >assume the use of the connection information from the first m line. I > agree with Cullen. >=20 > This is what Harald origianlly suggested, and I raised issues with that > solution. >=20 > > I do not agree with the m=3Dbundle approach for all the reasons Cullen > mentions. The only thing I would add is that some networks may > > require an updated offer be sent listing the correct port (the same one= ) > on each media line if bundle is negotiated. ICE already requires > > a 2nd offer in many cases, so I don't see this as a problem. >=20 > I don't understand... The reason m=3Dbundle came up was because people di= d > NOT want to use the same port on each media line... >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal= f > > Of Christer Holmberg > > Sent: Wednesday, September 19, 2012 12:12 PM > > To: Cullen Jennings (fluffy) > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m- > line > > for bundled session > > > > Hi, > > > > >As an individual draft or WG draft? > > > > It was meant to be a new version of bundle... > > > > >because I am definitely don't think we have consensus for the > "m=3Dbundle" > > approach yet. I just think the >m=3Dbundle approach is going to be much > > harder to get to work with existing equipment. Stuff is used to >seeing > > a=3Dfoo lines they don't understand. They are not used to seeing m=3Dfo= o > lines > > they don't understand. >It doubles the size of the SDP. It creates > > confusing when rest of SDP in the non bundle part does not >match bundl= e > > part. It's harder to add other things like opportunistic encryption. Bu= t > > my real problem >with it is I don't see any advantage of the m=3Dbundle > > approach over the a=3Dbundle approach. > > > > What is the a=3Dbundle approach? Offering "normal" (audio, video, etc) = m- > > lines, and then use one of them for the whole bundle? > > > > Regards, > > > > Christer > > > > > > > > > > > > On Sep 19, 2012, at 10:53 AM, Christer Holmberg > > wrote: > > > > > Hi, > > > > > > I've put together a new version of BUNDLE, with a dedicated m- line > for > > the bundled media. > > > > > > It will be submitted very soon, once I get some editorial fixes done. > > > > > > Regards, > > > > > > Christer > > > > > > ________________________________________ > > > From: Cullen Jennings (fluffy) [fluffy@cisco.com] > > > Sent: Wednesday, September 19, 2012 7:43 PM > > > To: Harald Alvestrand > > > Cc: Christer Holmberg; mmusic@ietf.org > > > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m- > > line for bundled session > > > > > > On Aug 27, 2012, at 2:03 AM, Harald Alvestrand > > wrote: > > > > > >>> So, IF people think that offering the same port will cause problem, > > > > > > For me this is not longer an IF, for equipment I am concerned about i= t > > has become a does as I explain at last meeting. > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Wed Sep 19 16:42:43 2012 Return-Path: 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 ACAB321F8522 for ; Wed, 19 Sep 2012 16:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.562 X-Spam-Level: X-Spam-Status: No, score=-5.562 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 CpHp7Jii9dMp for ; Wed, 19 Sep 2012 16:42:43 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABB021F843F for ; Wed, 19 Sep 2012 16:42:42 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-e4-505a586e34b7 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D7.63.11467.E685A505; Thu, 20 Sep 2012 01:42:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 20 Sep 2012 01:42:38 +0200 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "mmusic@ietf.org" Date: Thu, 20 Sep 2012 01:42:36 +0200 Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeD9Ycc2NyQEeW/u8tEHQmlZeSJKuAgAAE0YCAAABpgIAADcgggAAIemiAAA7iwIAAAtQ1 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+JvrW5eRFSAwec54hZTlz9msehtCHdg 8mh9tpfVY8mSn0wBTFFcNimpOZllqUX6dglcGds3vmUv+KVS0X3ZooFximwXIyeHhICJRP/t t4wQtpjEhXvr2UBsIYFTjBIfbsRB2AsYJeb/SOxi5OBgE7CQ6P6nDRIWEciS2HqqnwXEZhFQ lWiZv5IVxBYWiJdYsW0pM0RNgsSuSWuBxrMD2VESuwJAhvAKhEs8WlPexcgFNPsyu8SSe2+Z QKo5BWIl5lxrZwexGYGO+X5qDVicWUBc4taT+UwQRwpILNlznhnCFpV4+fgfK0S9qMSd9vWM EPU6Egt2f2KDsLUlli18DVbPKyAocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIUzk3MzEkv N9RLLcpMLi7Oz9MrTt3ECIyLg1t+6+5gPHVO5BCjNAeLkjgvV9J+fyGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MOm4O6+6+Oib84/TJHH6+Jd/4rXhjF6TITq4R3RzTUmrIVaJye+Hl/6YP bjoZnWn6Mm/mpBMiCexS6Yf1P+zjS8g4uvqcm6jn6babm/7YWDPa2Ux0NDt0dNq2JtOCnz6G ESmCm7/82bnvdHDl399arQ57xRQ+qP49OzlFnenAwrvZ7y6p2z82VGIpzkg01GIuKk4EAEDO VItZAgAA Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 19 Sep 2012 23:42:43 -0000 Hi, >What I understood is that the group (Cullen in particular) does not want t= he same port on multiple media=20 >lines when it is not known whether the peer supports bundle. Once you get= agreement to use bundle I=20 >don't see a problem, but maybe I missed something... Does anyone have a d= ifferent perspective? Then one could claim that the initial offer should be sent without bundle (= no matter how the mechanism works), and then enable bundle once you know th= at the other endpoint supports it. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, September 19, 2012 5:32 PM > To: Ejzak, Richard P (Richard); mmusic@ietf.org > Subject: RE: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line > for bundled session > > Hi, > > >I also did not get the impression that there was agreement on the > m=3Dbundle approach since there were a number of open issues. > > Ok. > > >As Cullen suggested in http://www.ietf.org/mail- > archive/web/mmusic/current/msg09561.html, just offer a normal SDP, add a > bundle line, and > >assume the use of the connection information from the first m line. I > agree with Cullen. > > This is what Harald origianlly suggested, and I raised issues with that > solution. > > > I do not agree with the m=3Dbundle approach for all the reasons Cullen > mentions. The only thing I would add is that some networks may > > require an updated offer be sent listing the correct port (the same one= ) > on each media line if bundle is negotiated. ICE already requires > > a 2nd offer in many cases, so I don't see this as a problem. > > I don't understand... The reason m=3Dbundle came up was because people di= d > NOT want to use the same port on each media line... > > Regards, > > Christer > > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal= f > > Of Christer Holmberg > > Sent: Wednesday, September 19, 2012 12:12 PM > > To: Cullen Jennings (fluffy) > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m- > line > > for bundled session > > > > Hi, > > > > >As an individual draft or WG draft? > > > > It was meant to be a new version of bundle... > > > > >because I am definitely don't think we have consensus for the > "m=3Dbundle" > > approach yet. I just think the >m=3Dbundle approach is going to be much > > harder to get to work with existing equipment. Stuff is used to >seeing > > a=3Dfoo lines they don't understand. They are not used to seeing m=3Dfo= o > lines > > they don't understand. >It doubles the size of the SDP. It creates > > confusing when rest of SDP in the non bundle part does not >match bundl= e > > part. It's harder to add other things like opportunistic encryption. Bu= t > > my real problem >with it is I don't see any advantage of the m=3Dbundle > > approach over the a=3Dbundle approach. > > > > What is the a=3Dbundle approach? Offering "normal" (audio, video, etc) = m- > > lines, and then use one of them for the whole bundle? > > > > Regards, > > > > Christer > > > > > > > > > > > > On Sep 19, 2012, at 10:53 AM, Christer Holmberg > > wrote: > > > > > Hi, > > > > > > I've put together a new version of BUNDLE, with a dedicated m- line > for > > the bundled media. > > > > > > It will be submitted very soon, once I get some editorial fixes done. > > > > > > Regards, > > > > > > Christer > > > > > > ________________________________________ > > > From: Cullen Jennings (fluffy) [fluffy@cisco.com] > > > Sent: Wednesday, September 19, 2012 7:43 PM > > > To: Harald Alvestrand > > > Cc: Christer Holmberg; mmusic@ietf.org > > > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m- > > line for bundled session > > > > > > On Aug 27, 2012, at 2:03 AM, Harald Alvestrand > > wrote: > > > > > >>> So, IF people think that offering the same port will cause problem, > > > > > > For me this is not longer an IF, for equipment I am concerned about i= t > > has become a does as I explain at last meeting. > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic= From lishitao@huawei.com Wed Sep 19 23:23:11 2012 Return-Path: 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 B5CFA21F8667 for ; Wed, 19 Sep 2012 23:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 aTRy-Ia8cby4 for ; Wed, 19 Sep 2012 23:23:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 570C221F8607 for ; Wed, 19 Sep 2012 23:23:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJV62066; Thu, 20 Sep 2012 06:23:08 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Sep 2012 07:22:05 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Sep 2012 07:22:28 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Thu, 20 Sep 2012 14:21:47 +0800 From: Lishitao To: Christer Holmberg , "Ejzak, Richard P (Richard)" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNhCqlaaUGA1cGxUKRtxpeaPyBCJeRfUuAgAAC7ICAAATRgIAAAGmAgABXUICAAAH/AIAAD7YAgAAD/QCAAPOyIA== Date: Thu, 20 Sep 2012 06:21:47 +0000 Message-ID: References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 06:23:11 -0000 Hi > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Thursday, September 20, 2012 7:43 AM > To: Ejzak, Richard P (Richard); mmusic@ietf.org > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line= for > bundled session >=20 > Hi, >=20 > >What I understood is that the group (Cullen in particular) does not want= the > same port on multiple media > >lines when it is not known whether the peer supports bundle. Once you g= et > agreement to use bundle I > >don't see a problem, but maybe I missed something... Does anyone have a > different perspective? >=20 > Then one could claim that the initial offer should be sent without bundle= (no > matter how the mechanism works), and then enable bundle once you know > that the other endpoint supports it. >=20 Maybe another way round, the sender can always send the initial offer with = bundle, then if the other end does not supports, =20 the sender can send an update SDP offer without using bundle. Regards shitao > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Wednesday, September 19, 2012 5:32 PM > > To: Ejzak, Richard P (Richard); mmusic@ietf.org > > Subject: RE: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-li= ne > > for bundled session > > > > Hi, > > > > >I also did not get the impression that there was agreement on the > > m=3Dbundle approach since there were a number of open issues. > > > > Ok. > > > > >As Cullen suggested in http://www.ietf.org/mail- > > archive/web/mmusic/current/msg09561.html, just offer a normal SDP, add = a > > bundle line, and > > >assume the use of the connection information from the first m line. I > > agree with Cullen. > > > > This is what Harald origianlly suggested, and I raised issues with that > > solution. > > > > > I do not agree with the m=3Dbundle approach for all the reasons Culle= n > > mentions. The only thing I would add is that some networks may > > > require an updated offer be sent listing the correct port (the same o= ne) > > on each media line if bundle is negotiated. ICE already requires > > > a 2nd offer in many cases, so I don't see this as a problem. > > > > I don't understand... The reason m=3Dbundle came up was because people = did > > NOT want to use the same port on each media line... > > > > Regards, > > > > Christer > > > > > > > > > > > -----Original Message----- > > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf > > > Of Christer Holmberg > > > Sent: Wednesday, September 19, 2012 12:12 PM > > > To: Cullen Jennings (fluffy) > > > Cc: mmusic@ietf.org > > > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m- > > line > > > for bundled session > > > > > > Hi, > > > > > > >As an individual draft or WG draft? > > > > > > It was meant to be a new version of bundle... > > > > > > >because I am definitely don't think we have consensus for the > > "m=3Dbundle" > > > approach yet. I just think the >m=3Dbundle approach is going to be mu= ch > > > harder to get to work with existing equipment. Stuff is used to >seei= ng > > > a=3Dfoo lines they don't understand. They are not used to seeing m=3D= foo > > lines > > > they don't understand. >It doubles the size of the SDP. It creates > > > confusing when rest of SDP in the non bundle part does not >match bun= dle > > > part. It's harder to add other things like opportunistic encryption. = But > > > my real problem >with it is I don't see any advantage of the m=3Dbund= le > > > approach over the a=3Dbundle approach. > > > > > > What is the a=3Dbundle approach? Offering "normal" (audio, video, etc= ) m- > > > lines, and then use one of them for the whole bundle? > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > On Sep 19, 2012, at 10:53 AM, Christer Holmberg > > > wrote: > > > > > > > Hi, > > > > > > > > I've put together a new version of BUNDLE, with a dedicated m- line > > for > > > the bundled media. > > > > > > > > It will be submitted very soon, once I get some editorial fixes don= e. > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > ________________________________________ > > > > From: Cullen Jennings (fluffy) [fluffy@cisco.com] > > > > Sent: Wednesday, September 19, 2012 7:43 PM > > > > To: Harald Alvestrand > > > > Cc: Christer Holmberg; mmusic@ietf.org > > > > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit = m- > > > line for bundled session > > > > > > > > On Aug 27, 2012, at 2:03 AM, Harald Alvestrand > > > wrote: > > > > > > > >>> So, IF people think that offering the same port will cause proble= m, > > > > > > > > For me this is not longer an IF, for equipment I am concerned about= it > > > has become a does as I explain at last meeting. > > > > _______________________________________________ > > > > mmusic mailing list > > > > mmusic@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Thu Sep 20 00:29:17 2012 Return-Path: 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 3BAE521F8448 for ; Thu, 20 Sep 2012 00:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 KilTWbyAWXBq for ; Thu, 20 Sep 2012 00:29:16 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2F70F21F8446 for ; Thu, 20 Sep 2012 00:29:16 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-2d-505ac5ca4edd Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0F.9E.17130.AC5CA505; Thu, 20 Sep 2012 09:29:14 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Thu, 20 Sep 2012 09:29:14 +0200 Message-ID: <505AC5C9.7070209@ericsson.com> Date: Thu, 20 Sep 2012 09:29:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <505972DD.3060908@ericsson.com> In-Reply-To: <505972DD.3060908@ericsson.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvre6po1EBBrtua1q8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK+PVqqOsBYelKpY8tWhgnCraxcjJISFgIjHj 6QxGCFtM4sK99WxdjFwcQgKnGCUWf1sBlhASWM4ocfyMGIjNK6AtsXr9ftYuRg4OFgFVicdz EkHCbAIWEjd/NLKB2KICwRKT9m9hgSgXlDg58wmYLSJgKtE2CyLOLOAqsWrXbGYQW1jAV2Lr 3MOsEKu0JZ5+XgtmcwroSPR9nAZ1m6TEm8k3oXr1JKZcbWGEsOUlmrdCzAHpbWjqYJ3AKDQL yepZSFpmIWlZwMi8ilE4NzEzJ73cXC+1KDO5uDg/T684dRMjMHgPbvltsINx032xQ4zSHCxK 4rx6qvv9hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDGf1fpZ88IKP55SJbt9aVZgY3iV3md JjYyV+78MMmve/uGT9+uTXzzy7mQ3/Tp4ROfNzzViXL+uVW2LtM97s+xhkze2nPvLv3JVeH+ qJgeEVIgItnm8uvN3xx/xpgjCkbTZ/ar/0jf9OId/5szed5yXR6pS5alTyzI3aXuvNzzo0Xs Jst07xVKLMUZiYZazEXFiQCk9sQkLAIAAA== Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 07:29:17 -0000 Hi, My preference is for ensuring something is done, and I would prefer the method B. cheers Magnus Westerlund On 2012-09-19 09:23, Miguel A. Garcia wrote: > Hi all, > > This mail relates to ICE [RFC 5245]. > > In the past few months, we have seen a number of documents that are > trying to improve the usage of ICE in different ways. The list of > documents include at least the following drafts: > > - draft-keranen-mmusic-ice-address-selection-01 > - draft-petithuguenin-mmusic-ice-attributes-level-03 > - draft-wing-mmusic-ice-mobility-01 > - draft-elwell-mmusic-ice-updated-offer-02 > > There is, in addition, a long discussion in the RTCWEB mailing list > about "trickle ICE", and a couple of other ICE-related drafts > and discussions in RTCWEB. > > Most likely, we can categorize these documents in two big classes: > > a) Documents that identify underspecified areas or errors in the spec, > which are often driven by implementation experience > > b) Documents that update or extend ICE with new functionality, such as > "tricke ICE" (see e.g. the e-mail thread at > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html) . > Such documents may involve normative updates to the ICE specification or > they may simply be ICE extensions.". > > Assuming that we would get consensus to adopt some or all of these > documents as work to proceed on, the MMUSIC chairs and RAI ADs would > like to get some sense of how should we aim at documenting it. Below > are some options, please comment on them or add alternatives. > > a) Create a revision of ICE (i.e., a document what will obsolete RFC > 5245), including all the extensions and corrections that > we want to choose from the list. This sounds like a big effort in > time, and presumably will create a big spec. We should make sure that > people have enough cycles to devote to this activity. > > b) Create a revision of ICE (obsoleting RFC 5245), but only addressing > bug fixing and opening hooks to extensions, with the idea that > extensions won't need to violate 5245bis. Additionally, document each > extension in a separate RFC. Extensions will depend and refer to the > 5245bis draft. > > c) Leave the current ICE core spec as is. Document each extension > separately (referring to 5245). Create open or more documents listing > bug fixes and corrections (will also update RFC 5245). > > Needless to say, at this point in time, there is no decision as for > which of the ICE-related drafts will proceed or not. We are just > trying to get consensus of how to document ICE-related drafts, and in > particular if the WG believes we should do a revision of RFC 5245. If so, > we also need to hear who is willing to work on such a revision. > > Now, it is your time to express your opinion. > > Kindly regards, > > Flemming and Miguel. > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Thu Sep 20 03:32:25 2012 Return-Path: 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 83FAC21F84FC for ; Thu, 20 Sep 2012 03:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.11 X-Spam-Level: X-Spam-Status: No, score=-109.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 p5YImjm53h57 for ; Thu, 20 Sep 2012 03:32:24 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 349E221F84A7 for ; Thu, 20 Sep 2012 03:32:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B039F39E127 for ; Thu, 20 Sep 2012 12:32:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKzv1R6vAeUv for ; Thu, 20 Sep 2012 12:32:21 +0200 (CEST) Received: from [10.0.9.187] (unknown [77.241.230.246]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0E6DE39E0F3 for ; Thu, 20 Sep 2012 12:32:14 +0200 (CEST) Message-ID: <505AF0AE.2090406@alvestrand.no> Date: Thu, 20 Sep 2012 12:32:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <505972DD.3060908@ericsson.com> In-Reply-To: <505972DD.3060908@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 10:32:25 -0000 My personal 2 cents: The most wrong thing here is doing nothing at all, blocking progress on ICE refinement/extension work. This will result in people doing private extensions without findable, publicly reviewed documentation. Luckily, that's not a proposed alternative. The second most wrong thing is to make everything depend on everything else, so that nothing comes out of the process until everything's finished. Given our collective experience with finishing ICE specs, this could easily become indistinguishable from the most wrong thing. This is what I'm afraid will happen if we choose alternative a) below. Looking at the alternatives: On 09/19/2012 09:23 AM, Miguel A. Garcia wrote: > a) Create a revision of ICE (i.e., a document what will obsolete RFC > 5245), including all the extensions and corrections that > we want to choose from the list. This sounds like a big effort in > time, and presumably will create a big spec. We should make sure that > people have enough cycles to devote to this activity. As should be clear from the above, I do not prefer this. > > b) Create a revision of ICE (obsoleting RFC 5245), but only addressing > bug fixing and opening hooks to extensions, with the idea that > extensions won't need to violate 5245bis. Additionally, document each > extension in a separate RFC. Extensions will depend and refer to the > 5245bis draft. (Tangent: I would like to extend this to one more task: If any piece or aspect of RFC 5245 can be isolated from the base spec and made into a separate document, it should be. RFC 5245, at 117 pretty dense pages, is a mouthful.) This is the approach that's been taken with, for instance, SMTP (RFC 822 / 2822 / 5322). > > c) Leave the current ICE core spec as is. Document each extension > separately (referring to 5245). Create open or more documents listing > bug fixes and corrections (will also update RFC 5245). This is the approach taken with the DNS, leading to these wonderfully transparent protocol definitions from the RFC index: 1034 Domain names - concepts and facilities. P.V. Mockapetris. November 1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308, RFC2535, RFC4033, RFC4034, RFC4035, RFC4343, RFC4035, RFC4592, RFC5936) (Also STD0013) (Status: STANDARD) 1035 Domain names - implementation and specification. P.V. Mockapetris. November 1987. (Format: TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181, RFC2137, RFC2308, RFC2535, RFC2845, RFC3425, RFC3658, RFC4033, RFC4034, RFC4035, RFC4343, RFC5936, RFC5966) (Also STD0013) (Status: STANDARD) Both B and C are approaches we have experience with, and neither has been abandoned by the people who used them. However, I have a strong preference for the document structure that comes out of doing B. From richard.ejzak@alcatel-lucent.com Thu Sep 20 06:15:06 2012 Return-Path: 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 0B01221F8562 for ; Thu, 20 Sep 2012 06:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 Fye2hS3slaR5 for ; Thu, 20 Sep 2012 06:15:05 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 44CF021F8504 for ; Thu, 20 Sep 2012 06:15:05 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8KDEf76014417 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Sep 2012 15:15:00 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 20 Sep 2012 15:14:48 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.110]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 20 Sep 2012 09:14:43 -0400 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeD9Ycc2NyQEeW/u8tEHQmlZeSJKuAgAAE0YCAAABpgIAADcgggAAIemiAAA7iwIAAAtQ1gADic5A= Date: Thu, 20 Sep 2012 13:14:43 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se> 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.80 Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 13:15:06 -0000 On Sep 19, 2012, at 6:43 PM, Christer Holmberg wrote: > >What I understood is that the group (Cullen in particular) does not want > the same port on multiple media > >lines when it is not known whether the peer supports bundle. Once you > get agreement to use bundle I > >don't see a problem, but maybe I missed something... Does anyone have a > different perspective? >=20 > Then one could claim that the initial offer should be sent without bundle > (no matter how the mechanism works), and then enable bundle once you know > that the other endpoint supports it. What is the advantage of doing this? The format suggested by Cullen will b= e handled correctly by an endpoint that doesn't support bundle and could al= so be handled correctly by an endpoint supporting bundle (if it is understo= od that the connection information comes from the first media line in the b= undle). I suggested a second offer/answer only for the benefit of intermed= iates. From richard.ejzak@alcatel-lucent.com Thu Sep 20 06:15:07 2012 Return-Path: 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 1898521F8504 for ; Thu, 20 Sep 2012 06:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 WCAen6jJECxM for ; Thu, 20 Sep 2012 06:15:06 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 54BB821F8562 for ; Thu, 20 Sep 2012 06:15:06 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8KDEf72014417 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Sep 2012 15:14:58 +0200 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 20 Sep 2012 15:14:46 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.110]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 20 Sep 2012 09:14:44 -0400 From: "Ejzak, Richard P (Richard)" To: Lishitao , Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeD9Ycc2NyQEeW/u8tEHQmlZeSJKuAgAAE0YCAAABpgIAADcgggAAIemiAAA7iwIAAAtQ1gAC0kYCAACpBcA== Date: Thu, 20 Sep 2012 13:14:44 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F1773E64A@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: 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.80 Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 13:15:07 -0000 On Sep 20, 2012, at 1:22 AM, Lishitao wrote: > Maybe another way round, the sender can always send the initial offer wit= h > bundle, then if the other end does not supports, > the sender can send an update SDP offer without using bundle. But then it will take two transactions to negotiate bundle whereas the othe= r proposal allows negotiation of media with or without bundle during the fi= rst offer/answer exchange. The second offer/answer is primarily to avoid m= isrepresenting the use of transport flows to intermediates. From petithug@acm.org Thu Sep 20 07:11:46 2012 Return-Path: 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 1A21D21F847F for ; Thu, 20 Sep 2012 07:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 vJbm0q5d4Jiv for ; Thu, 20 Sep 2012 07:11:45 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 0716C21F8468 for ; Thu, 20 Sep 2012 07:11:45 -0700 (PDT) Received: from [IPv6:2601:9:4b80:32:cff:d0b7:621d:62d9] (unknown [IPv6:2601:9:4b80:32:cff:d0b7:621d:62d9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id D819A20785; Thu, 20 Sep 2012 14:11:40 +0000 (UTC) Message-ID: <505B241A.8010508@acm.org> Date: Thu, 20 Sep 2012 07:11:38 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <505972DD.3060908@ericsson.com> In-Reply-To: <505972DD.3060908@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 14:11:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/19/2012 12:23 AM, Miguel A. Garcia wrote: > Hi all, > > This mail relates to ICE [RFC 5245]. > > In the past few months, we have seen a number of documents that are trying > to improve the usage of ICE in different ways. The list of documents > include at least the following drafts: > > - draft-keranen-mmusic-ice-address-selection-01 - > draft-petithuguenin-mmusic-ice-attributes-level-03 - > draft-wing-mmusic-ice-mobility-01 - > draft-elwell-mmusic-ice-updated-offer-02 > > There is, in addition, a long discussion in the RTCWEB mailing list about > "trickle ICE", and a couple of other ICE-related drafts and discussions in > RTCWEB. > > Most likely, we can categorize these documents in two big classes: > > a) Documents that identify underspecified areas or errors in the spec, > which are often driven by implementation experience > > b) Documents that update or extend ICE with new functionality, such as > "tricke ICE" (see e.g. the e-mail thread at > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html) . Such > documents may involve normative updates to the ICE specification or they > may simply be ICE extensions.". > > Assuming that we would get consensus to adopt some or all of these > documents as work to proceed on, the MMUSIC chairs and RAI ADs would like > to get some sense of how should we aim at documenting it. Below are some > options, please comment on them or add alternatives. > > a) Create a revision of ICE (i.e., a document what will obsolete RFC > 5245), including all the extensions and corrections that we want to choose > from the list. This sounds like a big effort in time, and presumably will > create a big spec. We should make sure that people have enough cycles to > devote to this activity. > > b) Create a revision of ICE (obsoleting RFC 5245), but only addressing bug > fixing and opening hooks to extensions, with the idea that extensions won't > need to violate 5245bis. Additionally, document each extension in a > separate RFC. Extensions will depend and refer to the 5245bis draft. I support b), but I think that we should go one step further in this idea of adding hooks for extensions. ICE, as a general mechanism, is also used outside of RFC3264/SDP, i.e in HIP (RFC 5770) and in RELOAD (draft-ietf-p2psip-base). So why not split RFC 5245 in two specs, one which contains ICE without RFC3264/SDP but with the extension hooks (and bug corrections), and an ICE over RFC3264/SDP extension, which itself will be referred by other extensions. We can then have RFC5770bis and p2psip-base referring the first of these spec. This is equivalent to what Jonathan Rosenberg tried to do with draft-rosenberg-mmusic-ice-nonsip, but with -ice-nonsip becoming the base draft, and RFC5245bis an extension of -ice-nonsip. There is in my future an implementation of -ice-nonsip or equivalent (for RELOAD), so I'll probably will be able to provide useful reviews to such document. > > c) Leave the current ICE core spec as is. Document each extension > separately (referring to 5245). Create open or more documents listing bug > fixes and corrections (will also update RFC 5245). > > Needless to say, at this point in time, there is no decision as for which > of the ICE-related drafts will proceed or not. We are just trying to get > consensus of how to document ICE-related drafts, and in particular if the > WG believes we should do a revision of RFC 5245. If so, we also need to > hear who is willing to work on such a revision. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQWyQYAAoJECnERZXWan7ENPoQAJdL65O8ALej8kivnOpynJ9T G74fpc18KcsAWXRo88uvEpdtxpCmbiSfdor7tL21X9pOiaAuVi+I23VelxjcUV7v ve9RgynPjtJXDkDGEyVy89epJ18Y4VtKTmrVr+9WPMfP4BcKqv03E3CrvmhzQ0BJ dVqXOsNP9mjMou0fKIK0oth3pPzSgfKn9UTaPBYnLECRsuMieeBDB4CqSQy5B/ZH 2mt2rDF64Rn01EUaHWFjKefsyJzzjBtrlL19nY9D8AjKculOlcGa4JsuN1jB71BH bSdjOrVRAADUUNGJowxmAPHM3hOir+XsSaqpLUBvvKX0GBZ9/R1Wt9mmmR7FNbUl HptxKl1m4uG9+K5ALJ6QoFRQ6cSeIBlGDT48tqiiGL4dlhPyg5aEkk8nJLfefRro ivnyYt8FsW06UrguosJl4SM5Feer1WRxNNTqErhED2uC3nicGnpruW2MGXWnga8f hFCjsDCZX/F4zg213K7vjPoU4ky2vHHMSTJG5ErhPRLTQbMmc1r5KLjubPHh7Yxp yiwtsjtJKtIbKvCl4G46rPnw2y9QwK0eGRcfN8voQmdRXhf3PiE1+CZYQPqbD1ze i8JcHwTLA6VRwEdz5jrCynAedH2pTyzasY57/u4VFNkTRstz2aAKsr4ZRBb1FgZR bedNmwA4arMHEdHX/+so =g+hf -----END PGP SIGNATURE----- From bernard_aboba@hotmail.com Thu Sep 20 07:13:06 2012 Return-Path: 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 5D1FC21F86B2 for ; Thu, 20 Sep 2012 07:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.933 X-Spam-Level: X-Spam-Status: No, score=-100.933 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_50=0.001, 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 kf8oYM26tDOF for ; Thu, 20 Sep 2012 07:13:05 -0700 (PDT) Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by ietfa.amsl.com (Postfix) with ESMTP id A29E621F8468 for ; Thu, 20 Sep 2012 07:13:05 -0700 (PDT) Received: from BLU169-DS22 ([65.55.111.73]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Sep 2012 07:13:05 -0700 X-Originating-IP: [24.16.96.166] X-EIP: [AgRsA3GaK2vrmpz39f5Mk8SlqfMAVXAh] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: References: <505972DD.3060908@ericsson.com> <505AF0AE.2090406@alvestrand.no> In-Reply-To: <505AF0AE.2090406@alvestrand.no> Date: Thu, 20 Sep 2012 07:13:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF1CCpSd/56f5U5xgd9EgAZHQgCHgHnwXzemDUlFHA= Content-Language: en-us X-OriginalArrivalTime: 20 Sep 2012 14:13:05.0130 (UTC) FILETIME=[0D56C4A0:01CD973A] Subject: Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 14:13:06 -0000 I'm in favor of option B. From emil@sip-communicator.org Thu Sep 20 07:23:25 2012 Return-Path: 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 0036C21F8779 for ; Thu, 20 Sep 2012 07:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 oXc9luyPRBOu for ; Thu, 20 Sep 2012 07:23:19 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51ED121F8746 for ; Thu, 20 Sep 2012 07:23:19 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so321658wgb.13 for ; Thu, 20 Sep 2012 07:23:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=0O+T8ap5U/giTcKWMhGOG4QICbKT01bSf5JJEliBf2Q=; b=VN3g232VFAItsvDGBUv0pTiT7hnCseKO4VXe2U5Nff6DwrkyqTP0bSNJudFC4oQR2E CSeAPTOALZJ8Sf/RRDy+nfc/TbFkNRDjA56fz1HP9NbyxwHR/BFHwCEocvqeWTH5w2dM aoHwkeUUPt8fnnpy2PqSNribKPFWSoN6U8pzwg3CcvkXpjtwWgwRezXJ+XeqyNbRH72B kdvTw+4/zgUVkyCn72xD5tQy2bWNVXo8Ma1EJJqB+oYlZHaF6Jcr0RNfvi/AsW50W+vL W8tqgJL2485SjpcMaan8Dvtb5mfMQGKAuHXaw3+SWXtxW5QbfrrCYsGJJT4EIjtSSuk8 vYsA== Received: by 10.180.97.106 with SMTP id dz10mr4818167wib.21.1348150998344; Thu, 20 Sep 2012 07:23:18 -0700 (PDT) Received: from camionet.local (proformatique1-gw-std.alionis.net. [77.72.89.60]) by mx.google.com with ESMTPS id v3sm32859440wiw.7.2012.09.20.07.23.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Sep 2012 07:23:16 -0700 (PDT) Message-ID: <505B26D1.7070900@jitsi.org> Date: Thu, 20 Sep 2012 16:23:13 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <505972DD.3060908@ericsson.com> In-Reply-To: <505972DD.3060908@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlQZ3BspwoZhVZsb39wVVX4kuDc/E3ktJM7aH8rParY4ko4aNh4GjUV8cMckzEYF97iG51C Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 14:23:26 -0000 +1 for B Although it might be tricky to classify some of the features you've listed above as either extensions or enhancements. ICE trickle would be one of those. Emil On 19.09.12, 09:23, Miguel A. Garcia wrote: > Hi all, > > This mail relates to ICE [RFC 5245]. > > In the past few months, we have seen a number of documents that are > trying to improve the usage of ICE in different ways. The list of > documents include at least the following drafts: > > - draft-keranen-mmusic-ice-address-selection-01 > - draft-petithuguenin-mmusic-ice-attributes-level-03 > - draft-wing-mmusic-ice-mobility-01 > - draft-elwell-mmusic-ice-updated-offer-02 > > There is, in addition, a long discussion in the RTCWEB mailing list > about "trickle ICE", and a couple of other ICE-related drafts > and discussions in RTCWEB. > > Most likely, we can categorize these documents in two big classes: > > a) Documents that identify underspecified areas or errors in the spec, > which are often driven by implementation experience > > b) Documents that update or extend ICE with new functionality, such as > "tricke ICE" (see e.g. the e-mail thread at > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html) . > Such documents may involve normative updates to the ICE specification or > they may simply be ICE extensions.". > > Assuming that we would get consensus to adopt some or all of these > documents as work to proceed on, the MMUSIC chairs and RAI ADs would > like to get some sense of how should we aim at documenting it. Below > are some options, please comment on them or add alternatives. > > a) Create a revision of ICE (i.e., a document what will obsolete RFC > 5245), including all the extensions and corrections that > we want to choose from the list. This sounds like a big effort in > time, and presumably will create a big spec. We should make sure that > people have enough cycles to devote to this activity. > > b) Create a revision of ICE (obsoleting RFC 5245), but only addressing > bug fixing and opening hooks to extensions, with the idea that > extensions won't need to violate 5245bis. Additionally, document each > extension in a separate RFC. Extensions will depend and refer to the > 5245bis draft. > > c) Leave the current ICE core spec as is. Document each extension > separately (referring to 5245). Create open or more documents listing > bug fixes and corrections (will also update RFC 5245). > > Needless to say, at this point in time, there is no decision as for > which of the ICE-related drafts will proceed or not. We are just > trying to get consensus of how to document ICE-related drafts, and in > particular if the WG believes we should do a revision of RFC 5245. If so, > we also need to hear who is willing to work on such a revision. > > Now, it is your time to express your opinion. > > Kindly regards, > > Flemming and Miguel. > From christer.holmberg@ericsson.com Thu Sep 20 09:30:49 2012 Return-Path: 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 418B021F873E for ; Thu, 20 Sep 2012 09:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.844 X-Spam-Level: X-Spam-Status: No, score=-5.844 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 wDkgdXmwRZhK for ; Thu, 20 Sep 2012 09:30:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8A021F8783 for ; Thu, 20 Sep 2012 09:30:48 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-4e-505b44b5bc43 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EF.75.17130.5B44B505; Thu, 20 Sep 2012 18:30:45 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 20 Sep 2012 18:30:44 +0200 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "mmusic@ietf.org" Date: Thu, 20 Sep 2012 18:29:00 +0200 Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeD9Ycc2NyQEeW/u8tEHQmlZeSJKuAgAAE0YCAAABpgIAADcgggAAIemiAAA7iwIAAAtQ1gADic5CAADi4uQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre5Wl+gAg4WdphZTlz9msehtCHdg 8mh9tpfVY8mSn0wBTFFcNimpOZllqUX6dglcGb/3n2Up6OOsmHVzP1MD43z2LkZODgkBE4mv 3w8wQ9hiEhfurWfrYuTiEBI4xSjxYtoKRghnAaPE29cfWboYOTjYBCwkuv9pgzSICGRJbD3V zwJiswioSpyYOwNsqLBAvMSKbUuZIWoSJHZNWssI0gpSv7lVDCTMKxAucaB/MTvE+E8cEpt/ TgSbwykQK/Hj/1EmEJsR6KDvp9aA2cwC4hK3nsxngjhUQGLJnvNQR4tKvHz8jxWiXlTiTvt6 Roh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIUzk3MzEkv N9dLLcpMLi7Oz9MrTt3ECIyQg1t+G+xg3HRf7BCjNAeLkjivnup+fyGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2Mh9++uRB4+fICpRXTanKyzV79XLDT9pfjCs7LT+eskZn+1Ib3Pae3i9zB 1hViT7l+5579/HxGRqj+PMfAtKj8Jr0ysxyPW4adP8teSCzfXrW27+TBf/xu2duPrDOU/c7+ Za7VUa63r6u3rPm5eE6x/MP3n72Ubr1b6JfXclJB5JtNjV9Ua/+GbCWW4oxEQy3mouJEAFNK LrZeAgAA Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 16:30:49 -0000 Hi, >>>What I understood is that the group (Cullen in particular) does not want >>> the same port on multiple media lines when it is not known whether the = peer supports bundle. Once you >>> get agreement to use bundle I don't see a problem, but maybe I missed s= omething... Does anyone have a >>> different perspective? >> >> Then one could claim that the initial offer should be sent without bundl= e >> (no matter how the mechanism works), and then enable bundle once you kno= w >> that the other endpoint supports it. > > What is the advantage of doing this? The format suggested by Cullen will= be handled correctly by an endpoint that doesn't support=20 > bundle and could also be handled correctly by an endpoint supporting bund= le (if it is understood that the connection information comes > from the first media line in the bundle). I suggested a second offer/ans= wer only for the benefit of intermediates. And how is the m=3Dbundle mechanism not going to be handled correctly by en= dpoints? An endpoint that doesn't support it would reject it, and an endpoi= nt that supports it can accept it. Regards, Christer= From richard.ejzak@alcatel-lucent.com Thu Sep 20 09:52:00 2012 Return-Path: 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 038E021F873E for ; Thu, 20 Sep 2012 09:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8] 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 DQS1tFif+ukD for ; Thu, 20 Sep 2012 09:51:59 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 37A0A21F871A for ; Thu, 20 Sep 2012 09:51:59 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8KGpf6B014163 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Sep 2012 18:51:56 +0200 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; Thu, 20 Sep 2012 18:51:46 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.110]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 20 Sep 2012 12:51:44 -0400 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeD9Ycc2NyQEeW/u8tEHQmlZeSJKuAgAAE0YCAAABpgIAADcgggAAIemiAAA7iwIAAAtQ1gADic5CAADi4uYAAAYIg Date: Thu, 20 Sep 2012 16:51:43 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se> 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.80 Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 16:52:00 -0000 > And how is the m=3Dbundle mechanism not going to be handled correctly by > endpoints? An endpoint that doesn't support it would reject it, and an > endpoint that supports it can accept it. This is true, although Cullen has the not unreasonable concern that some en= dpoints may choke on something this far removed from normal syntax. m=3Dbu= ndle requires significant extensions to the syntax and also a near doubling= in the size of the SDP. It is harder to specify allowed combinations of c= odecs and other options that are normally associated with a single m line. = I think we should avoid having duplicate syntax to express all these thing= s that can already be represented in SDP. =20 The only issue identified with the original approach is that some endpoints= may choke on using the same port for multiple media lines. Why don't we f= ocus on the simplest fix for that one identified problem?=20 From christer.holmberg@ericsson.com Thu Sep 20 10:14:33 2012 Return-Path: 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 94ED921F872E for ; Thu, 20 Sep 2012 10:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.837 X-Spam-Level: X-Spam-Status: No, score=-5.837 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 3KijVHfoxpNu for ; Thu, 20 Sep 2012 10:14:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9638021F872A for ; Thu, 20 Sep 2012 10:14:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-20-505b4ef72a3c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A9.E9.17130.7FE4B505; Thu, 20 Sep 2012 19:14:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Thu, 20 Sep 2012 19:14:31 +0200 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "mmusic@ietf.org" Date: Thu, 20 Sep 2012 19:14:30 +0200 Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeD9Ycc2NyQEeW/u8tEHQmlZeSJKuAgAAE0YCAAABpgIAADcgggAAIemiAAA7iwIAAAtQ1gADic5CAADi4uYAAAYIggAAIs0I= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre53v+gAg/dN0hZTlz9msehtCHdg 8mh9tpfVY8mSn0wBTFFcNimpOZllqUX6dglcGe173zMXfOer2D71O3sD4xfuLkZODgkBE4mZ Wy+zQNhiEhfurWfrYuTiEBI4xSjx/vEmJpCEkMACRok/Bzm7GDk42AQsJLr/aYOERQSyJLae 6gfrZRFQlfj5egYbiC0sEC+xYttSZoiaBIldk9YyQthlEjvXdIHZvALhErMb5jFD7JrIJdH/ by7YLk6BWImbnYtYQWxGoIO+n1oDFmcWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/gdVLypxp309 I0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjEK5yZm5qSX m+ulFmUmFxfn5+kVp25iBEbIwS2/DXYwbrovdohRmoNFSZxXT3W/v5BAemJJanZqakFqUXxR aU5q8SFGJg5OqQZGhjb17PWX2JPybJmmWBTrvM6cmKBt1SR/40b24s97OgX1RH6c7yuwXXPx n7Dtg9K/0S/MJvYLX7C0577gq+wwYYmhzAceoyc1ccIHWlKkpy7ZVVe5O2yF4ss9N6w3V2jv q+48ti9N9EeWRd0UrvQJgbz3t53eX533IdFmgo1Hl6f15mA984VKLMUZiYZazEXFiQAgwZ4/ XgIAAA== Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 17:14:33 -0000 Hi, >> And how is the m=3Dbundle mechanism not going to be handled correctly by >> endpoints? An endpoint that doesn't support it would reject it, and an >> endpoint that supports it can accept it. > > This is true, although Cullen has the not unreasonable concern that some = endpoints may choke on something this far removed from normal syntax. I am not sure what "normal syntax" means. The receiver sees an m- line medi= a type that it doesn't support, so I am not sure whether it's even going to= look deeper into it. But, IF the endpoint "chokes", the offerer can send a new offer, without bu= ndle. I don't see why we should specify our mechanism based on how badly im= plemented endpoints will act... > m=3Dbundle requires significant extensions to the syntax and also a near = doubling in the size of the SDP. It is harder to specify allowed=20 > combinations of codecs and other options that are normally associated wit= h a single m line.=20 Please give an example. > I think we should avoid having duplicate syntax to express all these thin= gs that can already be represented in SDP. We DID have a discussion about whether it should be possible, inside the m= =3Dbundle line, to "reference" information existing in the audio/video/etc = m- lines, in order to avoid duplication. > The only issue identified with the original approach is that some endpoin= ts may choke on using the same port for multiple media lines. Why don't we= focus on the simplest fix for that one identified problem? You have said that we need a second offer/answer, with the same port number= s, in order to handle intermediaries. I don't understand why the first offe= r could not be without bundle, and the second offer (once you know that the= remove endpoint supports bundle) according to the current mechanism, with = the same port numbers. Regards, Christer= From richard.ejzak@alcatel-lucent.com Thu Sep 20 12:19:14 2012 Return-Path: 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 D1FA221E808C for ; Thu, 20 Sep 2012 12:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8] 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 Cz0Dz3o3wYFb for ; Thu, 20 Sep 2012 12:19:10 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 255E421E804A for ; Thu, 20 Sep 2012 12:19:08 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8KJIsC4006878 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Sep 2012 21:19:05 +0200 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 20 Sep 2012 21:19:00 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.110]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 20 Sep 2012 15:18:50 -0400 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeD9Ycc2NyQEeW/u8tEHQmlZeSJKuAgAAE0YCAAABpgIAADcgggAAIemiAAA7iwIAAAtQ1gADic5CAADi4uYAAAYIggAAIs0KAAB2rIA== Date: Thu, 20 Sep 2012 19:18:49 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se> 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.13 Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 19:19:15 -0000 > > m=3Dbundle requires significant extensions to the syntax and also a nea= r > doubling in the size of the SDP. It is harder to specify allowed > > combinations of codecs and other options that are normally associated > with a single m line. >=20 > Please give an example. To specify two types of audio flows with very different characteristics I w= ould normally have separate media lines with separate codec lists and attri= butes. One may require DTMF and the other silence suppression in addition = to the selected (but different) codecs. We need to keep this characteristi= c. We also need a way of specifying bandwidth per (old) media line, which = is already supported using separate media lines but requires that something= new be defined for m=3Dbundle. What about RTCP characteristics? We certa= inly want to specify them per (old) media line. I understand that this can be done with m=3Dbundle, but it requires new syn= tax. Why bother if we have something that can work? > You have said that we need a second offer/answer, with the same port > numbers, in order to handle intermediaries. I don't understand why the > first offer could not be without bundle, and the second offer (once you > know that the remove endpoint supports bundle) according to the current > mechanism, with the same port numbers. It would seem to be attractive to support negotiation of bundle with the fi= rst offer/answer transaction else it will be delayed. And some networks ma= y not need a 2nd offer/answer if the first one successfully negotiates one = of the options. Richard From christer.holmberg@ericsson.com Thu Sep 20 12:32:12 2012 Return-Path: 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 16AF521F86E2 for ; Thu, 20 Sep 2012 12:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.831 X-Spam-Level: X-Spam-Status: No, score=-5.831 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 0Fp95yyrz11O for ; Thu, 20 Sep 2012 12:32:11 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B635B21F86A2 for ; Thu, 20 Sep 2012 12:32:10 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-8e-505b6f391e3c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 89.35.17130.93F6B505; Thu, 20 Sep 2012 21:32:09 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 20 Sep 2012 21:32:09 +0200 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "mmusic@ietf.org" Date: Thu, 20 Sep 2012 21:32:08 +0200 Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNloXeD9Ycc2NyQEeW/u8tEHQmlZeSJKuAgAAE0YCAAABpgIAADcgggAAIemiAAA7iwIAAAtQ1gADic5CAADi4uYAAAYIggAAIs0KAAB2rIIAACLpd Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvra5lfnSAwZfnOhZTlz9msehtCHdg 8mh9tpfVY8mSn0wBTFFcNimpOZllqUX6dglcGX8/dDIVvBWsOHXnGlsD42q+LkZODgkBE4mW HT3sELaYxIV769m6GLk4hAROMUrs6pwE5SxglLi7v4u1i5GDg03AQqL7nzZIg4hAlsTWU/0s IDaLgKpEw6v5YIOEBeIlVmxbygxRkyCxa9JaRgi7iVHi+xUNEJtXIFyi5dt9Joj5G7glJjeC LOPg4BSIlZj0ihOkhhHooO+n1jCB2MwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1gh6kUl7rSv Z4So15FYsPsTG4StLbFs4WtmiL2CEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG4dzEzJz0 cnO91KLM5OLi/Dy94tRNjMAIObjlt8EOxk33xQ4xSnOwKInz6qnu9xcSSE8sSc1OTS1ILYov Ks1JLT7EyMTBKdXAKL87VfFvy9IX7y7r8ZzerHrBPiLo180vMVkqXt23y7Zerz6l6H/gH1/q FJub/Elrlxc/4ptlImRhVmy+NZJbWGX+8mMJBjMWqa/hTWqM+MroeZD781e1Wds3eBvt3DEn M1x9iUTPy+qFf6u1Hsz7cd/xY0RcaSaPD5933bmeCv7c7LAyi98PlViKMxINtZiLihMBrwTm 714CAAA= Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Thu, 20 Sep 2012 19:32:12 -0000 Hi, >>> m=3Dbundle requires significant extensions to the syntax and also a nea= r >>> doubling in the size of the SDP. It is harder to specify allowed >>> combinations of codecs and other options that are normally associated >>> with a single m line. >> >> Please give an example. > > To specify two types of audio flows with very different characteristics I= would normally have separate media lines with separate codec lists and att= ributes. One may require DTMF and the other silence suppression in additio= n to the selected (but different)=20 > codecs. We need to keep this characteristic. We also need a way of spec= ifying bandwidth per (old) media line, which is already supported using sep= arate media lines but requires that something new be defined for m=3Dbundle= . What about RTCP=20 > characteristics? We certainly want to specify them per (old) media line. > > I understand that this can be done with m=3Dbundle, but it requires new s= yntax. Why bother if we have something that can work? I am not sure it requires new syntax, if you e.g. can use the ssrc attribut= e in order to map attributes to specific flows. >> You have said that we need a second offer/answer, with the same port >> numbers, in order to handle intermediaries. I don't understand why the >> first offer could not be without bundle, and the second offer (once you >> know that the remove endpoint supports bundle) according to the current >> mechanism, with the same port numbers. > > It would seem to be attractive to support negotiation of bundle with the = first offer/answer transaction else it will be delayed.=20 > And some networks may not need a 2nd offer/answer if the first one succes= sfully negotiates one of the options. Only if you can assume that there are not intermediaries in those network -= AND that there won't be additional offer/answers for other reasons (you ea= rlier said that there in many cases WILL be additional offer/answers...). I still think it would be wrong to reject the m=3Dbundle proposal based on = badly implemented endpoints. In that case one could claim that endpoints wi= ll "choke" if they receive SDPs with RTCWEB datachannels, CLUE channels, wh= atever channels... Regards, Christer= From lishitao@huawei.com Thu Sep 20 18:52:48 2012 Return-Path: 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 2501721E8051 for ; Thu, 20 Sep 2012 18:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 r3SKP5mWNApl for ; Thu, 20 Sep 2012 18:52:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0892021E8047 for ; Thu, 20 Sep 2012 18:52:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJW36645; Fri, 21 Sep 2012 01:52:45 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 02:50:48 +0100 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 02:51:14 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 09:51:08 +0800 From: Lishitao To: Christer Holmberg , "Ejzak, Richard P (Richard)" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNhCqlaaUGA1cGxUKRtxpeaPyBCJeRfUuAgAAC7ICAAATRgIAAAGmAgABXUICAAAH/AIAAD7YAgAAD/QCAAOLngIAANkgAgAAGWYCAAAZdAIAAIryAgAADuQCAAOzj0A== Date: Fri, 21 Sep 2012 01:51:07 +0000 Message-ID: References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9E@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 21 Sep 2012 01:52:48 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Friday, September 21, 2012 3:32 AM > To: Ejzak, Richard P (Richard); mmusic@ietf.org > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line= for > bundled session >=20 > Hi, >=20 > >>> m=3Dbundle requires significant extensions to the syntax and also a n= ear > >>> doubling in the size of the SDP. It is harder to specify allowed > >>> combinations of codecs and other options that are normally associated > >>> with a single m line. > >> > >> Please give an example. > > > > To specify two types of audio flows with very different characteristics= I would > normally have separate media lines with separate codec lists and attribut= es. > One may require DTMF and the other silence suppression in addition to the > selected (but different) > > codecs. We need to keep this characteristic. We also need a way of > specifying bandwidth per (old) media line, which is already supported usi= ng > separate media lines but requires that something new be defined for m=3Db= undle. > What about RTCP > > characteristics? We certainly want to specify them per (old) media lin= e. > > > > I understand that this can be done with m=3Dbundle, but it requires new= syntax. > Why bother if we have something that can work? >=20 > I am not sure it requires new syntax, if you e.g. can use the ssrc attrib= ute in > order to map attributes to specific flows. I would suggest that put the m=3Dbundle proposal in a separate new personal= draft or in the annex of the existing working draft, and=20 make a comparison for this proposal and the existing proposal. That will ma= ke it more clear. For the existing proposal, I believe that people are not totally against, a= lthough it has some issues. (the m=3Dbundle proposal also has some issues). Regards shitao From ari.keranen@nomadiclab.com Fri Sep 21 06:43:30 2012 Return-Path: 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 0FFA921F8629 for ; Fri, 21 Sep 2012 06:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 rA0aREM-cFbM for ; Fri, 21 Sep 2012 06:43:29 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id E73AB21F8562 for ; Fri, 21 Sep 2012 06:43:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id B75044E6E8; Fri, 21 Sep 2012 16:43:24 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ--d8VxYF3L; Fri, 21 Sep 2012 16:43:23 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 940B34E679; Fri, 21 Sep 2012 16:43:23 +0300 (EEST) Message-ID: <505C6EFD.4000708@nomadiclab.com> Date: Fri, 21 Sep 2012 16:43:25 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <505972DD.3060908@ericsson.com> In-Reply-To: <505972DD.3060908@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections X-BeenThere: mmusic@ietf.org 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, 21 Sep 2012 13:43:30 -0000 Hi, The option B is probably the best in the long run, albeit C would likely have much faster time-to-market. If we do B, Marc's idea about splitting the SDP parts away sounds worth looking into. Cheers, Ari On 9/19/12 10:23 AM, Miguel A. Garcia wrote: > Hi all, > > This mail relates to ICE [RFC 5245]. > > In the past few months, we have seen a number of documents that are > trying to improve the usage of ICE in different ways. The list of > documents include at least the following drafts: > > - draft-keranen-mmusic-ice-address-selection-01 > - draft-petithuguenin-mmusic-ice-attributes-level-03 > - draft-wing-mmusic-ice-mobility-01 > - draft-elwell-mmusic-ice-updated-offer-02 > > There is, in addition, a long discussion in the RTCWEB mailing list > about "trickle ICE", and a couple of other ICE-related drafts > and discussions in RTCWEB. > > Most likely, we can categorize these documents in two big classes: > > a) Documents that identify underspecified areas or errors in the spec, > which are often driven by implementation experience > > b) Documents that update or extend ICE with new functionality, such as > "tricke ICE" (see e.g. the e-mail thread at > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html) . > Such documents may involve normative updates to the ICE specification or > they may simply be ICE extensions.". > > Assuming that we would get consensus to adopt some or all of these > documents as work to proceed on, the MMUSIC chairs and RAI ADs would > like to get some sense of how should we aim at documenting it. Below > are some options, please comment on them or add alternatives. > > a) Create a revision of ICE (i.e., a document what will obsolete RFC > 5245), including all the extensions and corrections that > we want to choose from the list. This sounds like a big effort in > time, and presumably will create a big spec. We should make sure that > people have enough cycles to devote to this activity. > > b) Create a revision of ICE (obsoleting RFC 5245), but only addressing > bug fixing and opening hooks to extensions, with the idea that > extensions won't need to violate 5245bis. Additionally, document each > extension in a separate RFC. Extensions will depend and refer to the > 5245bis draft. > > c) Leave the current ICE core spec as is. Document each extension > separately (referring to 5245). Create open or more documents listing > bug fixes and corrections (will also update RFC 5245). > > Needless to say, at this point in time, there is no decision as for > which of the ICE-related drafts will proceed or not. We are just > trying to get consensus of how to document ICE-related drafts, and in > particular if the WG believes we should do a revision of RFC 5245. If > so, we also need to hear who is willing to work on such a revision. > > Now, it is your time to express your opinion. > > Kindly regards, > > Flemming and Miguel. From partha@parthasarathi.co.in Fri Sep 21 09:26:20 2012 Return-Path: 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 8A27021F86F5 for ; Fri, 21 Sep 2012 09:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] 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 3BObKIa+HrQ3 for ; Fri, 21 Sep 2012 09:26:19 -0700 (PDT) Received: from outbound-us3.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.157]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEA421F86FA for ; Fri, 21 Sep 2012 09:26:19 -0700 (PDT) Received: from userPC (unknown [122.179.31.16]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id 7E67986864B; Fri, 21 Sep 2012 16:26:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1348244778; bh=o9zdOSRVZHa6vPXIeHosvmVoDEGf/tbDJsRXjjgdVyg=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=DpV0Gz/TneF5xpFAikughAJ/EH5b35869Lq78qqHiPVaDcF9YfZ8O3jMT7LaO9iKw wI/Rb0gfTw2edU86qL8c+DzK9uvUpO7B1cVIY0r7qbC4HPzhsF9GidkgYv5hUMD0bl noBuW2fwWCnXVqemowheqwZ3u8jwVRGbI1pCOqtU= From: "Parthasarathi R" To: "'Lishitao'" , "'Christer Holmberg'" , "'Ejzak, Richard P \(Richard\)'" , References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A0585340 9FF2F9E@ESESSCMS0356.e emea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Date: Fri, 21 Sep 2012 21:56:04 +0530 Message-ID: <000001cd9815$d0882190$719864b0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNhCqlaaUGA1cGxUKRtxpeaPyBCJeRfUuAgAAC7ICAAATRgIAAAGmAgABXUICAAAH/AIAAD7YAgAAD/QCAAOLngIAANkgAgAAGWYCAAAZdAIAAIryAgAADuQCAAOzj0IAA9jxg Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B020B.505C952A.014F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 21 Sep 2012 16:26:20 -0000 I agree with Cullen & others that m=bundle does not have consensus. We need more discussion and analysis. The current Bundle syntax is designed in a way to reuse lot of existing SDP mechanism (Syntax & Semantics). If possible, let us try to fix the open issue with the current mechanism before proceeding with m=bundle approach. Thanks Partha -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Lishitao Sent: Friday, September 21, 2012 7:21 AM To: Christer Holmberg; Ejzak, Richard P (Richard); mmusic@ietf.org Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Friday, September 21, 2012 3:32 AM > To: Ejzak, Richard P (Richard); mmusic@ietf.org > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for > bundled session > > Hi, > > >>> m=bundle requires significant extensions to the syntax and also a near > >>> doubling in the size of the SDP. It is harder to specify allowed > >>> combinations of codecs and other options that are normally associated > >>> with a single m line. > >> > >> Please give an example. > > > > To specify two types of audio flows with very different characteristics I would > normally have separate media lines with separate codec lists and attributes. > One may require DTMF and the other silence suppression in addition to the > selected (but different) > > codecs. We need to keep this characteristic. We also need a way of > specifying bandwidth per (old) media line, which is already supported using > separate media lines but requires that something new be defined for m=bundle. > What about RTCP > > characteristics? We certainly want to specify them per (old) media line. > > > > I understand that this can be done with m=bundle, but it requires new syntax. > Why bother if we have something that can work? > > I am not sure it requires new syntax, if you e.g. can use the ssrc attribute in > order to map attributes to specific flows. I would suggest that put the m=bundle proposal in a separate new personal draft or in the annex of the existing working draft, and make a comparison for this proposal and the existing proposal. That will make it more clear. For the existing proposal, I believe that people are not totally against, although it has some issues. (the m=bundle proposal also has some issues). Regards shitao _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Fri Sep 21 10:26:54 2012 Return-Path: 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 B9B8921F871C for ; Fri, 21 Sep 2012 10:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.829 X-Spam-Level: X-Spam-Status: No, score=-5.829 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 kkzbdZNbc71F for ; Fri, 21 Sep 2012 10:26:54 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 42DFE21F869E for ; Fri, 21 Sep 2012 10:26:52 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-03-505ca35b57b1 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0F.74.11467.B53AC505; Fri, 21 Sep 2012 19:26:51 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 21 Sep 2012 19:26:51 +0200 From: Christer Holmberg To: Parthasarathi R , 'Lishitao' , "'Ejzak, Richard P (Richard)'" , "mmusic@ietf.org" Date: Fri, 21 Sep 2012 19:26:50 +0200 Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNhCqlaaUGA1cGxUKRtxpeaPyBCJeRfUuAgAAC7ICAAATRgIAAAGmAgABXUICAAAH/AIAAD7YAgAAD/QCAAOLngIAANkgAgAAGWYCAAAZdAIAAIryAgAADuQCAAOzj0IAA9jxggAAP5uw= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB1@ESESSCMS0356.eemea.ericsson.se> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A0585340 9FF2F9E@ESESSCMS0356.e emea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> , <000001cd9815$d0882190$719864b0$@co.in> In-Reply-To: <000001cd9815$d0882190$719864b0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvrW704pgAgz/vbCwO7rvFbDF1+WMW i8mf+lgtehvCHVg8Wp/tZfVoOfKW1WPJkp9MHh/mf2EPYInisklJzcksSy3St0vgyth/Ia1g lVjFsdeHWBoYW4S6GDk5JARMJH7fXssMYYtJXLi3nq2LkYtDSOAUo8Tus7tYQRJCAgsYJSad T+5i5OBgE7CQ6P6nDVIjIrCPUaLp2iKwZhYBVYnOz5MZQWxhgXiJFduWgsVFBBIkdk1aywjR MI9RYtn8RWBDeQXCJd7e2we1rZVX4kD/MbBuTqCTrk17ygZiMwKd9P3UGiYQm1lAXOLWk/lM EKcKSCzZcx7qbFGJl4//sULUi0rcaV/PCFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUXQW krGzkLTMQtIyC0nLAkaWVYzCuYmZOenlhnqpRZnJxcX5eXrFqZsYgbF0cMtv3R2Mp86JHGKU 5mBREuflStrvLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExz1LrlUGZ0TvL7WJ9P8WuL7i9 52mf+45rn7YZ6P10O3Vu0hn3JZuK3aeo7ZkkoHY+32qytoj5t2u/www5dl1dkmJ7dQZztbuD QbjV25+Cl6yFpJ3ZA9cv1nU73srz6P428TbBRHb2l1dnnflqcbH4ZDqH1WfTlGJxtb1GUwo/ LTmw8dvXlP5vSizFGYmGWsxFxYkAyrACW3MCAAA= Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 21 Sep 2012 17:26:55 -0000 Hi, >I agree with Cullen & others that m=3Dbundle does not have consensus. We n= eed >more discussion and analysis. The current Bundle syntax is designed in a w= ay >to reuse lot of existing SDP mechanism (Syntax & Semantics). If possible, >let us try to fix the open issue with the current mechanism before proceed= ing >with m=3Dbundle approach. Feel free to provide input on how you think we can solve that issue :) Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Lishitao Sent: Friday, September 21, 2012 7:21 AM To: Christer Holmberg; Ejzak, Richard P (Richard); mmusic@ietf.org Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Friday, September 21, 2012 3:32 AM > To: Ejzak, Richard P (Richard); mmusic@ietf.org > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for > bundled session > > Hi, > > >>> m=3Dbundle requires significant extensions to the syntax and also a n= ear > >>> doubling in the size of the SDP. It is harder to specify allowed > >>> combinations of codecs and other options that are normally associated > >>> with a single m line. > >> > >> Please give an example. > > > > To specify two types of audio flows with very different characteristics I would > normally have separate media lines with separate codec lists and attributes. > One may require DTMF and the other silence suppression in addition to the > selected (but different) > > codecs. We need to keep this characteristic. We also need a way of > specifying bandwidth per (old) media line, which is already supported using > separate media lines but requires that something new be defined for m=3Dbundle. > What about RTCP > > characteristics? We certainly want to specify them per (old) media line. > > > > I understand that this can be done with m=3Dbundle, but it requires new syntax. > Why bother if we have something that can work? > > I am not sure it requires new syntax, if you e.g. can use the ssrc attribute in > order to map attributes to specific flows. I would suggest that put the m=3Dbundle proposal in a separate new personal draft or in the annex of the existing working draft, and make a comparison for this proposal and the existing proposal. That will make it more clear. For the existing proposal, I believe that people are not totally against, although it has some issues. (the m=3Dbundle proposal also has some issues)= . Regards shitao _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic= From md3135@att.com Fri Sep 21 20:29:04 2012 Return-Path: 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 7F95321E80F2 for ; Fri, 21 Sep 2012 20:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 D3P9Ta5iqIzd for ; Fri, 21 Sep 2012 20:29:04 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id BC35921E80EF for ; Fri, 21 Sep 2012 20:29:03 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id f703d505.2aaac8a00940.86762.00-588.235946.nbfkord-smmo06.seg.att.com (envelope-from ); Sat, 22 Sep 2012 03:29:03 +0000 (UTC) X-MXL-Hash: 505d307f55fa3f1a-e8f66d2e90ec3daacd2dac43f9314223e11a1d4d Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 6703d505.0.86744.00-454.235898.nbfkord-smmo06.seg.att.com (envelope-from ); Sat, 22 Sep 2012 03:28:54 +0000 (UTC) X-MXL-Hash: 505d3076320ae61d-525a34dae7cd32ebf946cca5d22e229761c05d5d Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8M3SrPf021076; Fri, 21 Sep 2012 20:28:54 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8M3SkPs021054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Sep 2012 20:28:48 -0700 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by fflint03.pst.cso.att.com (RSA Interceptor); Fri, 21 Sep 2012 20:28:24 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0318.001; Fri, 21 Sep 2012 23:28:24 -0400 From: "DOLLY, MARTIN C" To: "Miguel A. Garcia" , mmusic Thread-Topic: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B Thread-Index: AQHNklb+aOOIl9H+7U+XE0SpnqN+EZeVv8Kg Date: Sat, 22 Sep 2012 03:28:23 +0000 Message-ID: References: <5052F176.4050100@ericsson.com> In-Reply-To: <5052F176.4050100@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.97.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=CucIhAED c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=rsqFTfUtOcIA:10 a=Zaqi6ybsqNEA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=-R4QeOVWcl0A:10 a=48vgC7mUAAAA:8 a=xY8z6zIdnATLSA] X-AnalysisOut: [7OtUUA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Cc: Flemming Andreasen Subject: Re: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B X-BeenThere: mmusic@ietf.org 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: Sat, 22 Sep 2012 03:29:04 -0000 I support this -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Miguel A. Garcia Sent: Friday, September 14, 2012 4:57 AM To: mmusic Cc: Flemming Andreasen Subject: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B At the last IETF meeting we had presentation of a draft adding considerations to G.723 Annex and G.729 Annex B. We noticed there was support to progress this draft. We have already clarified with our ADs that if this document gets progressed, it should be done in the MMUSIC WG and should aim standards track document updating RFC 4856: http://datatracker.ietf.org/doc/draft-muthu-mmusic-offer-answer-g723-g729/ We would like to poll the working group for adopting this documents as WG item, once we get an approved milestone. Please indicate whether you support or not this new work within the next 5 days. Flemming and Miguel (co-chairs). --=20 Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From trac+mmusic@trac.tools.ietf.org Sat Sep 22 13:48:36 2012 Return-Path: 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 3AC1B21F857E for ; Sat, 22 Sep 2012 13:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 VPzsMk6sbuXl for ; Sat, 22 Sep 2012 13:48:35 -0700 (PDT) Received: from gamay.tools.ietf.org (unknown [IPv6:2607:f170:8000:1500::de]) by ietfa.amsl.com (Postfix) with ESMTP id 8697521F857D for ; Sat, 22 Sep 2012 13:48:35 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TFWck-0000KF-3Y; Sat, 22 Sep 2012 16:48:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: abegen@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: mmusic Date: Sat, 22 Sep 2012 20:48:25 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/mmusic/trac/ticket/13 Message-ID: <066.685c700e85270f9f6c394ad153378d7b@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: abegen@cisco.com, bernard_aboba@hotmail.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #13: Section 5.14 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 20:48:36 -0000 #13: Section 5.14 In Section 5.14 the description only mentions RTP/AVP and RTP/SAVP. RTP/AVPF and RTP/SAVPF should also be mentioned. -- --------------------------------+------------------------ Reporter: bernard_aboba@… | Owner: abegen@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: rfc4566bis | Version: 1.0 Severity: Active WG Document | Keywords: --------------------------------+------------------------ Ticket URL: mmusic From partha@parthasarathi.co.in Sun Sep 23 11:50:55 2012 Return-Path: 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 5CD7E21F8471 for ; Sun, 23 Sep 2012 11:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_16=0.6, RDNS_NONE=0.1] 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 TPWtd-CEHeBh for ; Sun, 23 Sep 2012 11:50:54 -0700 (PDT) Received: from outbound-us3.mailhostbox.com (unknown [70.87.28.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3AB21F8468 for ; Sun, 23 Sep 2012 11:50:54 -0700 (PDT) Received: from userPC (unknown [122.166.137.12]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id 34B1C14D8164; Sun, 23 Sep 2012 18:50:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1348426253; bh=zNQ7gBoG5o3XSp/aAFYu+L1fe6iiX62y5MZAhJDdrQY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=e5LC7RQqssLP/PHpeGoh5O4XP5GGHgTKUBgqUziZlFGDTzvzFH+gPRfdjwE8HhpoH WLyT9NHHn2B/K3RWreh6AXbqDU307SQfkf2Q7d4YRVXxLlBHiQch5gOhP5cUK9eMqN d3dYEcCYd9Z9ToW4HUu+slrdmu/Z714KhUgfoILk= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Lishitao'" , "'Ejzak, Richard P \(Richard\)'" , References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A0585340 9FF2F9E@ESESSCMS0356. e emea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> , <000001cd9815$d0882190$719864b0$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB1@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB1@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 24 Sep 2012 00:20:44 +0530 Message-ID: <000601cd99bc$5b1e5bb0$115b1310$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNhCqlaaUGA1cGxUKRtxpeaPyBCJeRfUuAgAAC7ICAAATRgIAAAGmAgABXUICAAAH/AIAAD7YAgAAD/QCAAOLngIAANkgAgAAGWYCAAAZdAIAAIryAgAADuQCAAOzj0IAA9jxggAAP5uyAAzJQoA== Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0208.505F5A0D.0073, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Sun, 23 Sep 2012 18:50:55 -0000 Hi Christer, IIUC, The same port offer may be rejected by answerer irrespective of "m=bundle" or "a=group:BUNDLE" as it is not just new SDP syntax but also, the same port offer may have impact in other layers like RTP in answerer side implementation. The bundling of the different media in the same port is not guaranteed to negotiate in the answer side with "m=bundle" mechanism. The point is that answerer will reject in case the same port offer is not accepted in the specific implementation. Apart from this, The individual attribute behavior for bundle has to be defined somewhere irrespective of "m=bundle" or "a=group:BUNDLE". Say ptime attribute applies for the audio codecs only or applies for video codecs as well in the bundle has to be defined. I'm not see much advantage with "m=bundle" here. Instead, Let us discuss the generic categories of attributes and mention in this draft. Thanks Partha -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, September 21, 2012 10:57 PM To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)'; mmusic@ietf.org Subject: RE: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Hi, >I agree with Cullen & others that m=bundle does not have consensus. We need >more discussion and analysis. The current Bundle syntax is designed in a way >to reuse lot of existing SDP mechanism (Syntax & Semantics). If possible, >let us try to fix the open issue with the current mechanism before proceeding >with m=bundle approach. Feel free to provide input on how you think we can solve that issue :) Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Lishitao Sent: Friday, September 21, 2012 7:21 AM To: Christer Holmberg; Ejzak, Richard P (Richard); mmusic@ietf.org Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Friday, September 21, 2012 3:32 AM > To: Ejzak, Richard P (Richard); mmusic@ietf.org > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for > bundled session > > Hi, > > >>> m=bundle requires significant extensions to the syntax and also a near > >>> doubling in the size of the SDP. It is harder to specify allowed > >>> combinations of codecs and other options that are normally associated > >>> with a single m line. > >> > >> Please give an example. > > > > To specify two types of audio flows with very different characteristics I would > normally have separate media lines with separate codec lists and attributes. > One may require DTMF and the other silence suppression in addition to the > selected (but different) > > codecs. We need to keep this characteristic. We also need a way of > specifying bandwidth per (old) media line, which is already supported using > separate media lines but requires that something new be defined for m=bundle. > What about RTCP > > characteristics? We certainly want to specify them per (old) media line. > > > > I understand that this can be done with m=bundle, but it requires new syntax. > Why bother if we have something that can work? > > I am not sure it requires new syntax, if you e.g. can use the ssrc attribute in > order to map attributes to specific flows. I would suggest that put the m=bundle proposal in a separate new personal draft or in the annex of the existing working draft, and make a comparison for this proposal and the existing proposal. That will make it more clear. For the existing proposal, I believe that people are not totally against, although it has some issues. (the m=bundle proposal also has some issues). Regards shitao _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic= From christer.holmberg@ericsson.com Sun Sep 23 13:37:17 2012 Return-Path: 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 1409121F8516 for ; Sun, 23 Sep 2012 13:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.823 X-Spam-Level: X-Spam-Status: No, score=-5.823 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 mjVwJiCAT8FH for ; Sun, 23 Sep 2012 13:37:16 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BD88621F8501 for ; Sun, 23 Sep 2012 13:37:15 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-75-505f72fa4352 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 11.40.11467.AF27F505; Sun, 23 Sep 2012 22:37:14 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Sun, 23 Sep 2012 22:37:14 +0200 From: Christer Holmberg To: Parthasarathi R , 'Lishitao' , "'Ejzak, Richard P (Richard)'" , "mmusic@ietf.org" Date: Sun, 23 Sep 2012 22:37:13 +0200 Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNhCqlaaUGA1cGxUKRtxpeaPyBCJeRfUuAgAAC7ICAAATRgIAAAGmAgABXUICAAAH/AIAAD7YAgAAD/QCAAOLngIAANkgAgAAGWYCAAAZdAIAAIryAgAADuQCAAOzj0IAA9jxggAAP5uyAAzJQoIAAKHiQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB4@ESESSCMS0356.eemea.ericsson.se> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A0585340 9FF2F9E@ESESSCMS0356. e emea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> , <000001cd9815$d0882190$719864b0$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB1@ESESSCMS0356.eemea.ericsson.se>, <000601cd99bc$5b1e5bb0$115b1310$@co.in> In-Reply-To: <000601cd99bc$5b1e5bb0$115b1310$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre6vovgAg8OHTS0O7rvFbDF1+WMW i8mf+lgtehvCHVg8Wp/tZfVoOfKW1WPJkp9MHh/mf2EPYInisklJzcksSy3St0vgynjUcpKt 4JtKxc1J/cwNjO9luxg5OSQETCQ2dNxngrDFJC7cW8/WxcjFISRwilFiQutzVghnAaPE4zsn WLoYOTjYBCwkuv9pg8RFBPYxSjRdW8QM0s0ioCrxoGsmK4gtLBAvsWLbUrC4iECCxK5Jaxkh GlYxShxcegNsHa9AuMTxq+9ZIDb85ZV4vbyHESTBCXTT/p+XwCYxAt30/dQasAZmAXGJW0/m Q90qILFkz3lmCFtU4uXjf1D1ohJ32tczQtTrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJ2F ZOwsJC2zkLTMQtKygJFlFaNwbmJmTnq5oV5qUWZycXF+nl5x6iZGYDwd3PJbdwfjqXMihxil OViUxHm5kvb7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBsE5Cf8Tms9fLJVX//zdPxetPk MePg1KgpKVOPFAQdSH3iUBpyw/aBUuub146nn7Gvm1w/zU4qI7Tz2+RfYmyXrJe/XsJaN1NB sJ9lnnlanIkIz9HX/2artjSX7J4SN5Gz6MnO7vkXTywozjYKbBWeu2kPc0aT4D6WbOb6zt+G tx5dMci8VL9diaU4I9FQi7moOBEAcV7AwXUCAAA= Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Sun, 23 Sep 2012 20:37:17 -0000 Hi, >IIUC, The same port offer may be rejected by answerer irrespective of >"m=3Dbundle" or "a=3Dgroup:BUNDLE" as it is not just new SDP syntax >but also, the same port offer may have impact in other layers like RTP >in answerer side implementation. The bundling of the different media >in the same port is not guaranteed to negotiate in the answer side with >"m=3Dbundle" mechanism. The point is that answerer will reject in case the >same port offer is not accepted in the specific implementation. If the m=3Dbundle proposal, you don't have to use the same ports. You can a= ssign a separate port for the m=3Dbundle media description. >Apart from this, The individual attribute behavior for bundle has to be >defined somewhere irrespective of "m=3Dbundle" or "a=3Dgroup:BUNDLE". Say = ptime >attribute applies for the audio codecs only or applies for video codecs >as well in the bundle has to be defined. I'm not see much advantage with >"m=3Dbundle" here. It is already possible to specify attribute values for individual SSRCs. We= could do something similar for media types if we want. >Instead, Let us discuss the generic categories of attributes and mention i= n this draft. I am not sure I understood. For sure we will have to discuss how/if attributes are affected, but we nee= d to have a general idea on how the multiplexing is going to be offered. Sa= me ports, m=3Dbundle, or something else... So, again, if you have any ideas on how to do it I'd like to hear them :) Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, September 21, 2012 10:57 PM To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)'; mmusic@ietf.org Subject: RE: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Hi, >I agree with Cullen & others that m=3Dbundle does not have consensus. We n= eed >more discussion and analysis. The current Bundle syntax is designed in a way >to reuse lot of existing SDP mechanism (Syntax & Semantics). If possible, >let us try to fix the open issue with the current mechanism before proceeding >with m=3Dbundle approach. Feel free to provide input on how you think we can solve that issue :) Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Lishitao Sent: Friday, September 21, 2012 7:21 AM To: Christer Holmberg; Ejzak, Richard P (Richard); mmusic@ietf.org Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Friday, September 21, 2012 3:32 AM > To: Ejzak, Richard P (Richard); mmusic@ietf.org > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for > bundled session > > Hi, > > >>> m=3Dbundle requires significant extensions to the syntax and also a n= ear > >>> doubling in the size of the SDP. It is harder to specify allowed > >>> combinations of codecs and other options that are normally associated > >>> with a single m line. > >> > >> Please give an example. > > > > To specify two types of audio flows with very different characteristics I would > normally have separate media lines with separate codec lists and attributes. > One may require DTMF and the other silence suppression in addition to the > selected (but different) > > codecs. We need to keep this characteristic. We also need a way of > specifying bandwidth per (old) media line, which is already supported using > separate media lines but requires that something new be defined for m=3Dbundle. > What about RTCP > > characteristics? We certainly want to specify them per (old) media line. > > > > I understand that this can be done with m=3Dbundle, but it requires new syntax. > Why bother if we have something that can work? > > I am not sure it requires new syntax, if you e.g. can use the ssrc attribute in > order to map attributes to specific flows. I would suggest that put the m=3Dbundle proposal in a separate new personal draft or in the annex of the existing working draft, and make a comparison for this proposal and the existing proposal. That will make it more clear. For the existing proposal, I believe that people are not totally against, although it has some issues. (the m=3Dbundle proposal also has some issues)= . Regards shitao _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic=3D= From fandreas@cisco.com Sun Sep 23 20:41:29 2012 Return-Path: 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 EA99221F856D for ; Sun, 23 Sep 2012 20:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 OQ39BekA4F4x for ; Sun, 23 Sep 2012 20:41:29 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9D35621F8566 for ; Sun, 23 Sep 2012 20:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25127; q=dns/txt; s=iport; t=1348458087; x=1349667687; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=YO6DRt9WfbL/AQIYngUXMLYifJeHdFBx565ogc+uFA0=; b=mY+mfpwszO38IIxXGqPJcxOOYJcDapbnIMpYeHGsxB2XCVZZzan6iT8f +qlBZbSHaXD4lvPocSR9tyue76ujV9YcdOkhiGb1YVY4k4NXdTV/cA7TY 8YDOGapSS54l9A1C3vWwn51HkOJbQ09JQ74i+SnvMGqC6Tx9ZvwEmaG5j Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABnVX1CtJXG9/2dsb2JhbABFi2qyRYEIgiABAQEEAQEBDwEKUQoBEAsYCRYBAQ0JAwIBAgEVMAYNAQUCAQEFGYdjC5hnnxqLHIYqA5VlgRWNJYFpgwM X-IronPort-AV: E=Sophos;i="4.80,473,1344211200"; d="scan'208,217";a="124552012" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 24 Sep 2012 03:41:27 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8O3fQ98018046; Mon, 24 Sep 2012 03:41:26 GMT Message-ID: <505FD666.5080205@cisco.com> Date: Sun, 23 Sep 2012 23:41:26 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic References: <5049096F.7080908@cisco.com> In-Reply-To: <5049096F.7080908@cisco.com> Content-Type: multipart/alternative; boundary="------------090009000506060508020803" Cc: draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org 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: Mon, 24 Sep 2012 03:41:30 -0000 This is a multi-part message in MIME format. --------------090009000506060508020803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The WGLC for the Miscellaneous Capabilities draft is now over and we will be proceeding with a publication request. We did not receive any comments on the draft during the WGLC. If you reviewed the document but did not have any comments on it, please let that the chairs now. Thanks -- Flemming On 9/6/12 4:37 PM, Flemming Andreasen wrote: > This is to announce a 2 week Working Group Last Call for > > draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt > > as Proposed Standard. Please review and provide any comments you may > have on the document by September 21, 2012. Comments should be sent to > the document authors and the MMUSIC WG list. > > > Thanks > > Flemming > > > > > Draft Info: > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP) > Author(s) : Miguel A. Garcia-Martin > Simo Veikkolainen > Robert R. Gilman > Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt > Pages : 19 > Date : 2012-08-27 > > Abstract: > SDP has been extended with a capability negotiation mechanism > framework that allows the endpoints to negotiate transport protocols > and attributes. This framework has been extended with a media > capabilities negotiation mechanism that allows endpoints to negotiate > additional media-related capabilities. This negotiation is embedded > into the widely-used SDP offer/answer procedures. > > This memo extends the SDP capability negotiation framework to allow > endpoints to negotiate three additional SDP capabilities. In > particular, this memo provides a mechanism to negotiate bandwidth > ('b=' line), connection data ('c=' line), and titles ('i=' line for > each session or media). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-caps-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------090009000506060508020803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The WGLC for the Miscellaneous Capabilities draft is now over and we will be proceeding with a publication request.

We did not receive any comments on the draft during the WGLC. If you reviewed the document but did not have any comments on it, please let that the chairs now.

Thanks

-- Flemming




On 9/6/12 4:37 PM, Flemming Andreasen wrote:
This is to announce a 2 week Working Group Last Call for

     draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt

as Proposed Standard. Please review and provide any comments you may have on the document by September 21, 2012. Comments should be sent to the document authors and the MMUSIC WG list.


Thanks

       Flemming




Draft Info:
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP)
	Author(s)       : Miguel A. Garcia-Martin
                          Simo Veikkolainen
                          Robert R. Gilman
	Filename        : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
	Pages           : 19
	Date            : 2012-08-27

Abstract:
   SDP has been extended with a capability negotiation mechanism
   framework that allows the endpoints to negotiate transport protocols
   and attributes.  This framework has been extended with a media
   capabilities negotiation mechanism that allows endpoints to negotiate
   additional media-related capabilities.  This negotiation is embedded
   into the widely-used SDP offer/answer procedures.

   This memo extends the SDP capability negotiation framework to allow
   endpoints to negotiate three additional SDP capabilities.  In
   particular, this memo provides a mechanism to negotiate bandwidth
   ('b=' line), connection data ('c=' line), and titles ('i=' line for
   each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-caps-01


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




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--------------090009000506060508020803-- From fandreas@cisco.com Sun Sep 23 20:52:43 2012 Return-Path: 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 578BB21F8567 for ; Sun, 23 Sep 2012 20:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 M25WaTY0dXg0 for ; Sun, 23 Sep 2012 20:52:41 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9BE21F8569 for ; Sun, 23 Sep 2012 20:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22411; q=dns/txt; s=iport; t=1348458761; x=1349668361; h=message-id:date:from:mime-version:to:subject; bh=WYojdam9zKjTzaxBkphscDHqyY9+cL/C5V1vO4kPoQI=; b=akSgKF9OfvKHGPUDVfJkdRFFuXj5xhy2shCVoMYqNxBV9fDFbr78mzCL jOw31YGlJjOjCj88rXwyUIacGtM6YaYzjjAyJ+uK8C4rITYspPKFHIeJj qooWe6zmzbOpcoPBYoXW1HBfv1h8PHZEufm0iRxDeHFPrRxMFAtEZRsUb w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABLYX1CtJXG8/2dsb2JhbABFi2qyRYEIgjkBCls9FgEXAwIBAgFLAQwIAQEFGYdjC5hmnxmLHIYqA5VljjqBaYMD X-IronPort-AV: E=Sophos;i="4.80,473,1344211200"; d="scan'208,217";a="124495249" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 24 Sep 2012 03:52:40 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8O3qd03020847; Mon, 24 Sep 2012 03:52:39 GMT Message-ID: <505FD907.9070800@cisco.com> Date: Sun, 23 Sep 2012 23:52:39 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic , draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org Content-Type: multipart/alternative; boundary="------------070602090905050603010907" Subject: [MMUSIC] WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-05 X-BeenThere: mmusic@ietf.org 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: Mon, 24 Sep 2012 03:52:43 -0000 This is a multi-part message in MIME format. --------------070602090905050603010907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is to announce a 2 week Working Group Last Call for draft-ietf-mmusic-rtsp-nat-evaluation-05 as Informational. Please review and provide any comments you may have on the document by October 7, 2012. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks Flemming Draft Info: This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : The Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) Author(s) : Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-evaluation-05.txt Pages : 38 Date : 2012-05-07 This document describes several Network Address Translator (NAT) traversal techniques that was considered to be used by Real-time Streaming Protocol (RTSP). Each technique includes a description on how it would be used, the security implications of using it and any other deployment considerations it has. There are also disussions on how NAT traversal techniques relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP 2.0 standardized in the MMUSIC WG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/ --------------070602090905050603010907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is to announce a 2 week Working Group Last Call for

    draft-ietf-mmusic-rtsp-nat-evaluation-05

as Informational. Please review and provide any comments you may have on the document by October 7, 2012. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.


Thanks

       Flemming



Draft Info:

This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : The Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
	Author(s)       : Magnus Westerlund
                          Thomas Zeng
	Filename        : draft-ietf-mmusic-rtsp-nat-evaluation-05.txt
	Pages           : 38
	Date            : 2012-05-07

   This document describes several Network Address Translator (NAT)
   traversal techniques that was considered to be used by Real-time
   Streaming Protocol (RTSP).  Each technique includes a description on
   how it would be used, the security implications of using it and any
   other deployment considerations it has.  There are also disussions on
   how NAT traversal techniques relates to firewalls and how each
   technique can be applied in different use cases.  These findings
   where used when selecting the NAT traversal for RTSP 2.0 standardized
   in the MMUSIC WG.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/

 --------------070602090905050603010907-- From miguel.a.garcia@ericsson.com Mon Sep 24 01:51:35 2012 Return-Path: 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 367EA21F85AD for ; Mon, 24 Sep 2012 01:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 VxTLIILzD2jz for ; Mon, 24 Sep 2012 01:51:34 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF2E21F85AC for ; Mon, 24 Sep 2012 01:51:25 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-8b-50601f0c49f2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 54.3A.25676.C0F10605; Mon, 24 Sep 2012 10:51:24 +0200 (CEST) Received: from [159.107.24.225] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.1; Mon, 24 Sep 2012 10:51:23 +0200 Message-ID: <50601F0A.3020406@ericsson.com> Date: Mon, 24 Sep 2012 10:51:22 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic References: <5052F176.4050100@ericsson.com> In-Reply-To: <5052F176.4050100@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3VpdHPiHA4Pk3BYv3F3Qtpi5/zOLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZWzZM4OxoI2j4vSeBsYGxs1sXYycHBICJhI/ Tz9ihLDFJC7cWw8WFxI4xSjx7LhQFyMXkL2GUaJz5xKWLkYODl4BbYlbX+RBalgEVCUO7tvN CmKzCZhLtG7cyA5iiwoES5zbuA1sDq+AoMTJmU9YQGwRARmJvZs2M4PYzEBjZt+ZxQRiCwsE SDxYcxhqr7bE+m3TwWxOAR2Jnm+XWCDqbSUuzLkOZctLbH87hxmiXlNi8s2lzBMYBWchWTcL ScssJC0LGJlXMQrnJmbmpJcb6aUWZSYXF+fn6RWnbmIEhunBLb9VdzDeOSdyiFGag0VJnNd6 6x5/IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwL94q6bD/UJJEda6Z/VaeRye3dyeOnvonb 3WvZyJVxS1STyVvj5KG0Km6tNZzXj54wPtRm5BIb5NeTe3OV1lmZv3F5HubevxP/Of5wYpLb JRCydcX1SQfzTyRnczxJ75V6+TZL/PqCDzsn32NjmtExhetQ9/63EjOd7UOnr+WrXPHzrf63 9JdKLMUZiYZazEXFiQDeavWZIQIAAA== Cc: Flemming Andreasen Subject: Re: [MMUSIC] WG Poll for consensus on G.723 Annex A and G.729 Annex B X-BeenThere: mmusic@ietf.org 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: Mon, 24 Sep 2012 08:51:35 -0000 Hi, We had this poll running for a few days, and we have observed quite a lot of support to progress this work in MMUSIC. Therefore, once we get a milestone for this work, we will proceed to a submission as WG item. /Miguel On 14/09/2012 10:57, Miguel A. Garcia wrote: > At the last IETF meeting we had presentation of a draft adding > considerations to G.723 Annex and G.729 Annex B. We noticed there was > support to progress this draft. We have already clarified with our ADs > that if this document gets progressed, it should be done in the MMUSIC > WG and should aim standards track document updating RFC 4856: > > http://datatracker.ietf.org/doc/draft-muthu-mmusic-offer-answer-g723-g729/ > > We would like to poll the working group for adopting this documents as > WG item, once we get an approved milestone. > > Please indicate whether you support or not this new work within the > next 5 days. > > Flemming and Miguel (co-chairs). > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From jonathan@vidyo.com Mon Sep 24 11:41:32 2012 Return-Path: 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 18E8C21F884D for ; Mon, 24 Sep 2012 11:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] 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 n0szzmmXBpLa for ; Mon, 24 Sep 2012 11:41:31 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 80CE021F8449 for ; Mon, 24 Sep 2012 11:41:31 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C1EEB8BE5C8; Mon, 24 Sep 2012 14:41:30 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 7CE698BE5B9; Mon, 24 Sep 2012 14:41:30 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Mon, 24 Sep 2012 14:41:29 -0400 From: Jonathan Lennox To: Christer Holmberg Date: Mon, 24 Sep 2012 14:41:28 -0400 Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: Ac2ahDQOMJqhOA3YTlO85jEENn3nfQ== Message-ID: <46F70838-8689-4C1C-9C49-B981B1E2D208@vidyo.com> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A0585340 9FF2F9E@ESESSCMS0356. e emea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> , <000001cd9815$d0882190$719864b0$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB1@ESESSCMS0356.eemea.ericsson.se>, <000601cd99bc$5b1e5bb0$115b1310$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB4@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Mon, 24 Sep 2012 18:41:32 -0000 On Sep 23, 2012, at 4:37 PM, Christer Holmberg wrote: >=20 >> Instead, Let us discuss the generic categories of attributes and mention= in this draft. >=20 > I am not sure I understood. >=20 > For sure we will have to discuss how/if attributes are affected, but we n= eed to have a general idea on how the multiplexing is going to be offered. = Same ports, m=3Dbundle, or something else... One of the major benefits of the "pure" m=3Dbundle proposal is that we *don= 't* have to discuss categories of attributes (other than to make recommenda= tions to implementors). The attributes inside each unbundled m=3D line nee= d to be self-consistent, and the attributes inside the m=3Dbundle line also= need to be self-consistent, but there doesn't need to be any standardized = mechanism to infer the one from the others. -- Jonathan Lennox jonathan@vidyo.com From christer.holmberg@ericsson.com Mon Sep 24 12:55:27 2012 Return-Path: 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 73AB021F88CA for ; Mon, 24 Sep 2012 12:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 3z6GH66GTa1c for ; Mon, 24 Sep 2012 12:55:27 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC4821F88C1 for ; Mon, 24 Sep 2012 12:55:26 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-d0-5060baac952d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C8.BB.11467.CAAB0605; Mon, 24 Sep 2012 21:55:24 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 24 Sep 2012 21:55:24 +0200 From: Christer Holmberg To: Jonathan Lennox Date: Mon, 24 Sep 2012 21:51:03 +0200 Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: Ac2ahDQOMJqhOA3YTlO85jEENn3nfQACbnhO Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB8@ESESSCMS0356.eemea.ericsson.se> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A0585340 9FF2F9E@ESESSCMS0356. e emea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> , <000001cd9815$d0882190$719864b0$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB1@ESESSCMS0356.eemea.ericsson.se>, <000601cd99bc$5b1e5bb0$115b1310$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB4@ESESSCMS0356.eemea.ericsson.se>, <46F70838-8689-4C1C-9C49-B981B1E2D208@vidyo.com> In-Reply-To: <46F70838-8689-4C1C-9C49-B981B1E2D208@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvre6aXQkBBp8vmlrsX3ye2eLgvlvM FlOXP2axmPypj9WityHcgdWj9dleVo+WI29ZPZYs+cnk8WH+F3aPtmd32ANYo7hsUlJzMstS i/TtErgy9qy9ylrwlLPiXuMhlgbGR+xdjJwcEgImEk2dF1kgbDGJC/fWs3UxcnEICZxilJh+ Zwo7hLOAUeJI7ymgDAcHm4CFRPc/bZAGEQENiYvPPoA1MAvsYpTY9m4GI0iCRUBV4u/EE2BT hQXiJVZsW8oM0ZAgsWvSWkYI20jiwNkTrCA2r0C4xLtXq6GWNfFL9F/7AZbgFLCVaN3dDdbA CHTe91NrmEBsZgFxiVtP5jNBnC0gsWTPeWYIW1Ti5eN/rBD1ohJ32tczQtTrSCzY/YkNwtaW WLbwNTPEYkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFlFaNwbmJmTnq5oV5qUWZycXF+nl5x 6iZGYOQd3PJbdwfjqXMihxilOViUxHm5kvb7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamC0 2fP7sffz/C0tZWnr9zaUr861sc76JtTuoKSkL5h97nOVXqTF9YSfStm9IXm+r6TfJl6+wVfG 7fGnYYuoQ9v8X4uj3/VIpZz5vOv0kXybwikaP6otquR0H6cuFumNzJvD5WUfWr9+5tJs/ykG oVmblWssu1mtz1Tc/OZxW7/V3cbXadaiViWW4oxEQy3mouJEAKGbqCOKAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Mon, 24 Sep 2012 19:55:27 -0000 Hi, >>> Instead, Let us discuss the generic categories of attributes and mentio= n in this draft. >> >> I am not sure I understood. >> >> For sure we will have to discuss how/if attributes are affected, but we = need to have a general idea on how the multiplexing is going to be offered.= Same ports, m=3Dbundle, or something else... > > One of the major benefits of the "pure" m=3Dbundle proposal is that we *d= on't* have to discuss categories of attributes (other than to make recommen= dations to=20 > implementors). The attributes inside each unbundled m=3D line need to be= self-consistent, and the attributes inside the m=3Dbundle line also need t= o be self-consistent,=20 > but there doesn't need to be any standardized mechanism to infer the one = from the others. That is my current understanding also. And, IF we need to define new attributes, we will of course define the usag= e of them from scrath :)=20 For example, the m=3Dbundle draft I'm working on defines a new SDP attribut= e, which maps a PT to a specific media type (audio, video etc), as it canno= t be assumed that the rtpmap attribute always can be used to identity the m= edia type (in most cases it can, though). Regards, Christer= From miguel.a.garcia@ericsson.com Mon Sep 24 13:10:23 2012 Return-Path: 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 3306221F88D6 for ; Mon, 24 Sep 2012 13:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.955 X-Spam-Level: X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 ZC-d6DWNDS7M for ; Mon, 24 Sep 2012 13:10:22 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 147C221F88D5 for ; Mon, 24 Sep 2012 13:10:21 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-35-5060be2cbf25 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 19.DF.17130.C2EB0605; Mon, 24 Sep 2012 22:10:21 +0200 (CEST) Received: from [159.107.48.12] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.1; Mon, 24 Sep 2012 22:10:20 +0200 Message-ID: <5060BE2B.20101@ericsson.com> Date: Mon, 24 Sep 2012 22:10:19 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLJMWRmVeSWpSXmKPExsUyM+Jvra7uvoQAg9nZFu8v6FpMXf6YxeLc p7ssDsweU35vZPVYsuQnk8fdW5eYApijuGxSUnMyy1KL9O0SuDLu7HcsOCZbcaRZsoFxingX IyeHhICJxOF7t1ghbDGJC/fWs3UxcnEICZxilLgw4QwThLOaUeLvyd9AGQ4OXgFNidYGe5AG FgFViTm/n4M1swmYS7Ru3MgOYosKBEuc27iNDcTmFRCUODnzCQuILSIgI7F302ZmEJtZIF7i 3p4LLCAjhQUMJDaeSoQI20pcmHOdBcKWl9j+dg5YuRDQ1sk3lzJPYOSfhWTqLCQts5C0LGBk XsUonJuYmZNebq6XWpSZXFycn6dXnLqJERiEB7f8NtjBuOm+2CFGaQ4WJXFePdX9/kIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYp6q5T3Zfc/Rdm915V+9nU154njiSFzj9f5PGqWO1D8Si PKwaePdxMH+d4HdzVcHLH3/DNsT2vLixetfz+DOW/3xv/4h336251mKvgtLmd3/9lxyf8CjO ykv9a/50tUVy/sdeHLPePW3JDxH25bkRDy8ZZ5f2qHfKne3fp5vX78WybKvLgXN5iUosxRmJ hlrMRcWJADvomNMQAgAA Cc: Flemming Andreasen Subject: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Mon, 24 Sep 2012 20:10:23 -0000 Hi, as an author of draft-ietf-mmusic-sdp-cs The authors were addressing the comments that we got back in February from Flemming. His complete e-mail was this one: http://www.ietf.org/mail-archive/web/mmusic/current/msg09367.html The authors have addressed all the comments, except the first one. We require a bit more of discussion on the list. I reproduce here the comment: 1) The document defines the "E164" 'addrtype' type as well as the "-" 'addrtype' to be used in the "c=" line and wants to register these with IANA. As it turns out, RFC 3108 also defined these, however they never got registered with IANA. While the '-' seems to be defined similarly, the syntax for the "164" differs between the two, which is obviously a problem, not least considering RFC 3108 is Standards Track. Also, for some reason the cs-draft lists RFC 3108 as a normative reference, but it does not provide any normative text for its use. The problem that is not listed here is the definition fo the "E164" 'addrtype' in RFC 3108. I include here the relevant text: E164: If the addressType is E164, the address is expressed as a decimal number with up to 15 digits. For example: c=ATM E164 9738294382 The use of E.164 numbers in the B-ISDN context is defined in ITU E.191. There is a disparity between the ATM forum and the ITU in the use of E.164 numbers for ATM addressing. The ATM forum (e.g., UNI Signaling 4.0) allows only International Format E.164 numbers, while the ITU (e.g., Q.2931) allows private numbering plans. Since the goal of this SDP specification is to interoperate with all bearer signaling protocols, it allows the use of numbers that do not conform to the E.164 International Format. However, to maximize overall consistency, network administrators can restrict the provisioning of numbers to the E.164 International Format. The SDP CS draft indicates that only international E164 number must be used, and adds a '+' sign to indicate the international format of the number. RFC 3108 seems to allow both international and national format, but does not add the '+' sign to indicate that a digit-string means international format. At first glance, one solution could be that the CS draft will use another addrtype, for example, "INTE164", to indicate international E.164 numbers. However, being the CS draft a dependency to 3GPP Release 8 (which was technical frozen in 2009), I think it is not fair to do this last-minute change at this stage. And I will be worried if there are already implementations deployed. I want to stress that the usages of ATM in SDP and CS in SDP do not clash. I mean, the usage is so different that it is hard to foresee an implementation that will use RFC 3108 and SDP CS *at the same time*. So, let me have a proposal that I believe will satisfy both RFC 3108 and the SDP CS draft. The idea is to keep on using the "E164" addrtype in both documents. SDP CS needs to define the E164 number indicating that can convey both international and national numbers. If an international number is used, it is prepended by a '+' sign (as the draft currently says). If a '+' is written, then it is an international format. If a '+' sign is absent then it is up to the implementation to determine the scope of the number (national or international). The lack of '+' sign will only occur in the context of RFC 3108. SDP CS will keep on only using international E.164 numbers, represented with the '+' sign, and will register (as it currently does) the "E164" 'addrtype' with IANA. Is this acceptable? /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From pkyzivat@alum.mit.edu Mon Sep 24 14:16:15 2012 Return-Path: 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 64AD121F8827 for ; Mon, 24 Sep 2012 14:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] 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 A-7RJh8EaHtu for ; Mon, 24 Sep 2012 14:16:14 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9EA21F880C for ; Mon, 24 Sep 2012 14:16:10 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2ytD1k00727AodY539GE3X; Mon, 24 Sep 2012 21:16:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id 39Bb1k0053ZTu2S3f9BbkK; Mon, 24 Sep 2012 21:11:35 +0000 Message-ID: <5060CC6D.5070900@alum.mit.edu> Date: Mon, 24 Sep 2012 17:11:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <5060BE2B.20101@ericsson.com> In-Reply-To: <5060BE2B.20101@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Mon, 24 Sep 2012 21:16:15 -0000 On 9/24/12 4:10 PM, Miguel A. Garcia wrote: > Hi, > > as an author of draft-ietf-mmusic-sdp-cs > > The authors were addressing the comments that we got back in February > from Flemming. His complete e-mail was this one: > > http://www.ietf.org/mail-archive/web/mmusic/current/msg09367.html > > The authors have addressed all the comments, except the first one. We > require a bit more of discussion on the list. I reproduce here the comment: > > 1) The document defines the "E164" 'addrtype' type as well as the "-" > 'addrtype' to be used in the "c=" line and wants to register these with > IANA. As it turns out, RFC 3108 also defined these, however they never > got registered with IANA. While the '-' seems to be defined similarly, > the syntax for the "164" differs between the two, which is obviously a > problem, not least considering RFC 3108 is Standards Track. Also, for > some reason the cs-draft lists RFC 3108 as a normative reference, but it > does not provide any normative text for its use. > > The problem that is not listed here is the definition fo the "E164" > 'addrtype' in RFC 3108. I include here the relevant text: > > E164: If the addressType is E164, the address is expressed as a > decimal number with up to 15 digits. For example: > > c=ATM E164 9738294382 > > The use of E.164 numbers in the B-ISDN context is defined in ITU > E.191. There is a disparity between the ATM forum and the ITU in the > use of E.164 numbers for ATM addressing. The ATM forum (e.g., UNI > Signaling 4.0) allows only International Format E.164 numbers, while > the ITU (e.g., Q.2931) allows private numbering plans. Since the > goal of this SDP specification is to interoperate with all bearer > signaling protocols, it allows the use of numbers that do not conform > to the E.164 International Format. However, to maximize overall > consistency, network administrators can restrict the provisioning of > numbers to the E.164 International Format. This is the first time I have looked at 3108. Based on a quick look, it seems very broken in this regard, and seems a bad model to emulate. The example it gives (c=ATM E164 9738294382) is apparently not an E.164 number. (If it is, then the country code is 97, which is Bahrain, and the remainder of the number doesn't seem consistent with that.) It *appears* to be a US number in New Jersey, without the country code. (Everybody who reads this should give it a call!) If we consider that the example is in error and should have used 19738294382, then it is still ambiguous whether any given number is in E.164 format or is from a private numbering plan. I took a peek at Q.2931 and it passes an address type that distinguishes these, but "C=ATM E164" has no way to do so. It is just broken. > The SDP CS draft indicates that only international E164 number must be > used, and adds a '+' sign to indicate the international format of the > number. RFC 3108 seems to allow both international and national format, > but does not add the '+' sign to indicate that a digit-string means > international format. > > At first glance, one solution could be that the CS draft will use > another addrtype, for example, "INTE164", to indicate international > E.164 numbers. However, being the CS draft a dependency to 3GPP Release > 8 (which was technical frozen in 2009), I think it is not fair to do > this last-minute change at this stage. And I will be worried if there > are already implementations deployed. > > I want to stress that the usages of ATM in SDP and CS in SDP do not > clash. I mean, the usage is so different that it is hard to foresee an > implementation that will use RFC 3108 and SDP CS *at the same time*. > > So, let me have a proposal that I believe will satisfy both RFC 3108 and > the SDP CS draft. > > The idea is to keep on using the "E164" addrtype in both documents. SDP > CS needs to define the E164 number indicating that can convey both > international and national numbers. If an international number is used, > it is prepended by a '+' sign (as the draft currently says). If a '+' is > written, then it is an international format. Seems right. > If a '+' sign is absent > then it is up to the implementation to determine the scope of the number > (national or international). The lack of '+' sign will only occur in the > context of RFC 3108. ISTM that this is still ambiguous. Q.2931 defines - unknown - international number - national number - network specific number - subscriber number - abbreviated number My counter suggestion would be to use tel format - 'telephone-subscriber' syntax as defined in RFC3966. At least that has a real definition. It doesn't cover all the options Q.2931 does, but it covers global (E.164) and local, and a number of qualifiers for local. > SDP CS will keep on only using international E.164 numbers, represented > with the '+' sign, and will register (as it currently does) the "E164" > 'addrtype' with IANA. > > Is this acceptable? It is fine with me that SDP CS will keep using "+". Thanks, Paul From prvs=061451a9e5=aallen@rim.com Mon Sep 24 16:47:37 2012 Return-Path: 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 9954A1F042B for ; Mon, 24 Sep 2012 16:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.903 X-Spam-Level: X-Spam-Status: No, score=-4.903 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 rcYB5fklnNbc for ; Mon, 24 Sep 2012 16:47:36 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id B17A11F041D for ; Mon, 24 Sep 2012 16:47:36 -0700 (PDT) X-AuditID: 0a41282f-b7f196d0000008dc-5f-5060f117db41 Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) by mhs060cnc.rim.net (SBG) with SMTP id 3F.F0.02268.711F0605; Mon, 24 Sep 2012 18:47:35 -0500 (CDT) Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0318.001; Mon, 24 Sep 2012 18:47:35 -0500 From: Andrew Allen To: "Miguel A. Garcia" , mmusic Thread-Topic: [MMUSIC] Issue with E164 numbers in SDP CS draft Thread-Index: AQHNmpCkoKF/QUIk4EaD6lx4jBeI1ZeaKFEw Date: Mon, 24 Sep 2012 23:47:33 +0000 Message-ID: References: <5060BE2B.20101@ericsson.com> In-Reply-To: <5060BE2B.20101@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsXC5Zyvqyv+MSHAYN4+PYv3F3Qt1nxawW4x dfljFgdmjym/N7J6/Pp6lc1jyZKfTAHMUQ2MNkmJJWXBmel5+nY2iXl5+SWJJakKKanFybZK PqnpiTkKAUWZZYnJlQoumcXJOYmZualFSgqZKbZKJkoKBTmJyam5qXkltkqJBQWpeSlKdlwK GMAGqCwzTyE1Lzk/JTMv3VbJM9hf18LC1FLXUMlON6GTJ2P13s3MBaeUK+4ua2ZrYOyT6WLk 5JAQMJG49+4VI4QtJnHh3nq2LkYuDiGBlYwSa5oOM0M4Wxgl+jdPZwGpYhNQllj+ewZYh4hA oMSL0y/BbGYBbYnZd2YxgdjCArYS67v/sUPU2Em8OnUcqt5IYt6xR2A1LAKqEn8f/mQFsXkF PCR2vGkEmy8koCkx7eZWMJtTQEviU9dFZhCbEei676fWMEHsEpe49WQ+E8TVAhJL9pxnhrBF JV4+/scKYStKzNgznxWiXkdiwe5PbDB3Llv4mhlir6DEyZlPWCYwis1CMnYWkpZZSFpmIWlZ wMiyilEwN6PYwMwgOS9ZrygzVy8vtWQTIyh1OGro72B8+97iEKMAB6MSD6/Wo4QAIdbEsuLK 3EOMEhzMSiK8V7qAQrwpiZVVqUX58UWlOanFhxgtgKEykVmKOzkfmNbySuKNDQxQOErivHNE owOEBNKBySc7NbUgtQimlYmDE2Q0l5RIMTCFpBYllpZkxIMSXXwxMNVJNTDuebJS+9blkz1L jm5rzF051Td92tpwq2/6M2paHkc9ulh3oK3s8u6pU8w3bux7sN37//Wnk3bLeGX+XXwhTu9p Ruy61vrAFXdvcFwIPfjzd2H4yT3ywpOZS/QMDDQlD2l8ePNbYsIPs7l+An0tJnsTFBzMHIrb 1iQY/i28kZr+scA9qr+WYRG/EktxRqKhFnNRcSIAeG7ICVEDAAA= Cc: Flemming Andreasen Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Mon, 24 Sep 2012 23:47:37 -0000 I agree. Let's not change the format in CS draft as this has been frozen in 3GPP for= several years and may have already been implemented. > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Miguel A. Garcia > Sent: Monday, September 24, 2012 3:10 PM > To: mmusic > Cc: Flemming Andreasen > Subject: [MMUSIC] Issue with E164 numbers in SDP CS draft > > Hi, > > as an author of draft-ietf-mmusic-sdp-cs > > The authors were addressing the comments that we got back in February > from Flemming. His complete e-mail was this one: > > http://www.ietf.org/mail-archive/web/mmusic/current/msg09367.html > > The authors have addressed all the comments, except the first one. We > require a bit more of discussion on the list. I reproduce here the > comment: > > 1) The document defines the "E164" 'addrtype' type as well as the "-" > 'addrtype' to be used in the "c=3D" line and wants to register these with > IANA. As it turns out, RFC 3108 also defined these, however they never > got registered with IANA. While the '-' seems to be defined similarly, > the syntax for the "164" differs between the two, which is obviously a > problem, not least considering RFC 3108 is Standards Track. Also, for > some reason the cs-draft lists RFC 3108 as a normative reference, but it > does not provide any normative text for its use. > > The problem that is not listed here is the definition fo the "E164" > 'addrtype' in RFC 3108. I include here the relevant text: > > E164: If the addressType is E164, the address is expressed as a > decimal number with up to 15 digits. For example: > > c=3DATM E164 9738294382 > > The use of E.164 numbers in the B-ISDN context is defined in ITU > E.191. There is a disparity between the ATM forum and the ITU in > the > use of E.164 numbers for ATM addressing. The ATM forum (e.g., UNI > Signaling 4.0) allows only International Format E.164 numbers, while > the ITU (e.g., Q.2931) allows private numbering plans. Since the > goal of this SDP specification is to interoperate with all bearer > signaling protocols, it allows the use of numbers that do not > conform > to the E.164 International Format. However, to maximize overall > consistency, network administrators can restrict the provisioning of > numbers to the E.164 International Format. > > > The SDP CS draft indicates that only international E164 number must be > used, and adds a '+' sign to indicate the international format of the > number. RFC 3108 seems to allow both international and national format, > but does not add the '+' sign to indicate that a digit-string means > international format. > > At first glance, one solution could be that the CS draft will use > another > addrtype, for example, "INTE164", to indicate international E.164 > numbers. However, being the CS draft a dependency to 3GPP Release 8 > (which was technical frozen in 2009), I think it is not fair to do this > last-minute change at this stage. And I will be worried if there are > already implementations deployed. > > I want to stress that the usages of ATM in SDP and CS in SDP do not > clash. I mean, the usage is so different that it is hard to foresee an > implementation that will use RFC 3108 and SDP CS *at the same time*. > > So, let me have a proposal that I believe will satisfy both RFC 3108 and > the SDP CS draft. > > The idea is to keep on using the "E164" addrtype in both documents. SDP > CS needs to define the E164 number indicating that can convey both > international and national numbers. If an international number is used, > it is prepended by a '+' sign (as the draft currently says). If a '+' is > written, then it is an international format. If a '+' sign is absent > then > it is up to the implementation to determine the scope of the number > (national or international). The lack of '+' sign will only occur in the > context of RFC 3108. > > SDP CS will keep on only using international E.164 numbers, represented > with the '+' sign, and will register (as it currently does) the "E164" > 'addrtype' with IANA. > > Is this acceptable? > > /Miguel > > > > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From atle.monrad@ericsson.com Tue Sep 25 01:47:16 2012 Return-Path: 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 8E67021F84A6 for ; Tue, 25 Sep 2012 01:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 IxSRQAUlYmss for ; Tue, 25 Sep 2012 01:47:15 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3052721F84A2 for ; Tue, 25 Sep 2012 01:47:15 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-ce-50616f911d39 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9E.DD.25676.19F61605; Tue, 25 Sep 2012 10:47:14 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.2.64]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 25 Sep 2012 10:47:13 +0200 From: Atle Monrad To: Miguel Garcia A , mmusic Date: Tue, 25 Sep 2012 10:47:12 +0200 Thread-Topic: [MMUSIC] Issue with E164 numbers in SDP CS draft Thread-Index: Ac2akKMCgjnZI4hITH6R8XKQp5RcmAAaV0sw Message-ID: <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> References: <5060BE2B.20101@ericsson.com> In-Reply-To: <5060BE2B.20101@ericsson.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvre6k/MQAgwut7BbvL+haTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyvjbd5Kp4LZyRefcNsYGxk0yXYycHBICJhL7 lzxlhbDFJC7cW88GYgsJnGKUuPolqIuRC8hewCjx4/g5RpAEm4COxLmfd8AaRAR8JKY+3grW wCygLTH7ziwmEJtFQFXizuLvYHFhAVuJ9d3/2CHq7SRenTrOCGEbSUxd9BkozsHBKxAuceF4 AcReTYlpN7eygNicAloSn7ouMoOUMArISsxt4oXYJC5x68l8JoiTBSSW7DnPDGGLSrx8/A/s MkYBGYkVW79BXaYjsWD3J7grly18DVbPKyAocXLmE5YJjGKzkIydhaRlFpKWWUhaFjCyrGIU zk3MzEkvN9JLLcpMLi7Oz9MrTt3ECIyag1t+q+5gvHNO5BCjNAeLkjiv9dY9/kIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoYN/KLVc+aznx4ov33LzGm1TX7ONrnqssY7130zEPnwOSQ6UXv 4lUPy8W81f/IVX5ysZh2fpzXh/+dh/ed64vJd1pl/t3/osZ168wPpo8srsxclcngyBzzdrut yWbhyWXXxd++ZJp+ZtmEI2KJtoE+P9KSZTdvenB2/7oDu0uEFXYtbGbiakvdrcRSnJFoqMVc VJwIALLgEbJoAgAA Cc: Flemming Andreasen Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Tue, 25 Sep 2012 08:47:16 -0000 Miguel 3GPP has referred to this draft since Rel-8. Avoidance of last-minute chang= es to the coding would be appreciated. Your proposed way forward seems good to me. Thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Miguel A. Garcia Sent: 24. september 2012 22:10 To: mmusic Cc: Flemming Andreasen Subject: [MMUSIC] Issue with E164 numbers in SDP CS draft Hi, as an author of draft-ietf-mmusic-sdp-cs The authors were addressing the comments that we got back in February from = Flemming. His complete e-mail was this one: http://www.ietf.org/mail-archive/web/mmusic/current/msg09367.html The authors have addressed all the comments, except the first one. We requi= re a bit more of discussion on the list. I reproduce here the comment: 1) The document defines the "E164" 'addrtype' type as well as the "-"=20 'addrtype' to be used in the "c=3D" line and wants to register these with I= ANA. As it turns out, RFC 3108 also defined these, however they never got r= egistered with IANA. While the '-' seems to be defined similarly, the synta= x for the "164" differs between the two, which is obviously a problem, not = least considering RFC 3108 is Standards Track. Also, for some reason the cs= -draft lists RFC 3108 as a normative reference, but it does not provide any= normative text for its use. The problem that is not listed here is the definition fo the "E164"=20 'addrtype' in RFC 3108. I include here the relevant text: E164: If the addressType is E164, the address is expressed as a decimal number with up to 15 digits. For example: c=3DATM E164 9738294382 The use of E.164 numbers in the B-ISDN context is defined in ITU E.191. There is a disparity between the ATM forum and the ITU in the use of E.164 numbers for ATM addressing. The ATM forum (e.g., UNI Signaling 4.0) allows only International Format E.164 numbers, while the ITU (e.g., Q.2931) allows private numbering plans. Since the goal of this SDP specification is to interoperate with all bearer signaling protocols, it allows the use of numbers that do not conform to the E.164 International Format. However, to maximize overall consistency, network administrators can restrict the provisioning of numbers to the E.164 International Format. The SDP CS draft indicates that only international E164 number must be used= , and adds a '+' sign to indicate the international format of the number. R= FC 3108 seems to allow both international and national format, but does not= add the '+' sign to indicate that a digit-string means international forma= t. At first glance, one solution could be that the CS draft will use another a= ddrtype, for example, "INTE164", to indicate international E.164 numbers. H= owever, being the CS draft a dependency to 3GPP Release 8 (which was techni= cal frozen in 2009), I think it is not fair to do this last-minute change a= t this stage. And I will be worried if there are already implementations de= ployed. I want to stress that the usages of ATM in SDP and CS in SDP do not clash. = I mean, the usage is so different that it is hard to foresee an implementat= ion that will use RFC 3108 and SDP CS *at the same time*. So, let me have a proposal that I believe will satisfy both RFC 3108 and th= e SDP CS draft. The idea is to keep on using the "E164" addrtype in both documents. SDP CS = needs to define the E164 number indicating that can convey both internation= al and national numbers. If an international number is used, it is prepende= d by a '+' sign (as the draft currently says). If a '+' is written, then it= is an international format. If a '+' sign is absent then it is up to the i= mplementation to determine the scope of the number (national or internation= al). The lack of '+' sign will only occur in the context of RFC 3108. SDP CS will keep on only using international E.164 numbers, represented wit= h the '+' sign, and will register (as it currently does) the "E164"=20 'addrtype' with IANA. Is this acceptable? /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From atle.monrad@ericsson.com Tue Sep 25 01:57:10 2012 Return-Path: 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 11D4621F88F8 for ; Tue, 25 Sep 2012 01:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 80Zhilfj8BmX for ; Tue, 25 Sep 2012 01:57:09 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE2821F8948 for ; Tue, 25 Sep 2012 01:57:07 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-be-506171e26fa0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A4.40.11467.2E171605; Tue, 25 Sep 2012 10:57:07 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.2.64]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Tue, 25 Sep 2012 10:57:04 +0200 From: Atle Monrad To: Flemming Andreasen , mmusic Date: Tue, 25 Sep 2012 10:57:03 +0200 Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Thread-Index: Ac2aBn62WTRSp4QNSDCu0mXwaicuZQA8+dsQ Message-ID: <7A051DFAA46D0246A82293C7CEF621E9070A0D24A0@ESESSCMS0352.eemea.ericsson.se> References: <5049096F.7080908@cisco.com> <505FD666.5080205@cisco.com> In-Reply-To: <505FD666.5080205@cisco.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: multipart/alternative; boundary="_000_7A051DFAA46D0246A82293C7CEF621E9070A0D24A0ESESSCMS0352e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvre7jwsQAg821FpvOHGOyeH9B12Lq 8scsDsweU35vZPVYsuQnk8eXy5/ZApijuGxSUnMyy1KL9O0SuDL+rtzNVHB7OmPFn6kLGBsY LzQxdjFyckgImEg0ts9jhrDFJC7cW8/WxcjFISRwilFi5ZkjLBDOHEaJY78usYBUsQnoSJz7 eYcVxBYRcJU4svAuE4jNLFApcfj7PTCbRUBVovnZfKB6Dg5hgQCJj8dlQUwRgUCJB/c5IDqN JGbMuckOYvMKhEvMvT0T7AYhoInts/eC2ZwCmhI3Pu1gBWllFJCVmNvEC7FIXOLWk/lMECcL SCzZcx7qfFGJl4//gR3GKCAjsWLrNzaI+nyJ28+PQ60SlDg58wnLBEbRWUhGzUJSNgtJGURc R2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKJybmJmTXm6ol1qUmVxcnJ+nV5y6iREYewe3 /NbdwXjqnMghRmkOFiVxXq6k/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGMMbXp5Tzb82 b2vukweZonHCM8v+dGQtLcwW3njQ2eWq3frqk9fnTDyokj9tZ0vsfrl3fdJ1B6bbLIh6ovvP ui+ovvWuedMpntD10b7l9Ye8t/rtO3rZ6Ijp8cl9U9iVZhR0n/NX2qeZEVFWn8TbFxZx7nO7 48d5DUamkrpFzQ06vHvkuZ5PUGIpzkg01GIuKk4EAPDymJmLAgAA Cc: "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org 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: Tue, 25 Sep 2012 08:57:10 -0000 --_000_7A051DFAA46D0246A82293C7CEF621E9070A0D24A0ESESSCMS0352e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Flemming The draft has been on the 3GPP dependency list since Rel-8. I have reviewed the draft and have no comments. 3GPP would be grateful if the draft could progress in a bundle with draft-i= etf-mmusic-sdp-media-capabilities and draft-ietf-mmusic-sdp-cs as soon as p= ossible. thanks /atle ________________________________ Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management Ericsson ________________________________ From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Flemming Andreasen Sent: 24. september 2012 05:41 To: mmusic Cc: draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.= txt The WGLC for the Miscellaneous Capabilities draft is now over and we will b= e proceeding with a publication request. We did not receive any comments on the draft during the WGLC. If you review= ed the document but did not have any comments on it, please let that the ch= airs now. Thanks -- Flemming On 9/6/12 4:37 PM, Flemming Andreasen wrote: This is to announce a 2 week Working Group Last Call for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt as Proposed Standard. Please review and provide any comments you may have o= n the document by September 21, 2012. Comments should be sent to the docume= nt authors and the MMUSIC WG list. Thanks Flemming Draft Info: This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Miscellanoues Capabilities Negotiation in the Ses= sion Description Protocol (SDP) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Robert R. Gilman Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Pages : 19 Date : 2012-08-27 Abstract: SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line fo= r each session or media). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps= -01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7A051DFAA46D0246A82293C7CEF621E9070A0D24A0ESESSCMS0352e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Flemming
 
The=20 draft has been on the 3GPP dependency list since=20 Rel-8.
 
I have=20 reviewed the draft and have no comments.
 
3GPP would be grateful if the draft could progress in a bundle wit= h=20 draft-ietf-mmusic-sdp-media-capabilities and draft-ietf-mmusic-sdp-cs as so= on as=20 possible.
 
thanks
/atle

________________________________


Atle Monrad
3GPP=20 CT Chairman
Standardization and Regulation,
Group Function Technology= and=20 Portfolio Management=20
Ericsson

 

From: mmusic-bounces@ietf.org=20 [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming=20 Andreasen
Sent: 24. september 2012 05:41
To:=20 mmusic
Cc:=20 draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org
Subject: = Re:=20 [MMUSIC] WGLC for=20 draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt

The WGLC for the Miscellaneous Capabilities draft is now over an= d we=20 will be proceeding with a publication request.

We did not receive a= ny=20 comments on the draft during the WGLC. If you reviewed the document but did= not=20 have any comments on it, please let that the chairs now.

Thanks=20

-- Flemming




On 9/6/12 4:37 PM, Flemming Andreasen=20 wrote:
This is to announce a 2 week Working Group Last = Call=20 for=20

  &nbs= p; =20 draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt

as Proposed Standard. Please review and = provide=20 any comments you may have on the document by September 21, 2012. Comments= =20 should be sent to the document authors and the MMUSIC WG list.


Thanks

     = ; =20 Flemming




Draft=20 Info:
 This draft is a work item=
 of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Miscellanoues Capabilities Negotiation in the Session De=
scription Protocol (SDP)
	Author(s)       : Miguel A. Garcia-Martin
                          Simo Veikkolainen
                          Robert R. Gilman
	Filename        : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
	Pages           : 19
	Date            : 2012-08-27

Abstract:
   SDP has been extended with a capability negotiation mechanism
   framework that allows the endpoints to negotiate transport protocols
   and attributes.  This framework has been extended with a media
   capabilities negotiation mechanism that allows endpoints to negotiate
   additional media-related capabilities.  This negotiation is embedded
   into the widely-used SDP offer/answer procedures.

   This memo extends the SDP capability negotiation framework to allow
   endpoints to negotiate three additional SDP capabilities.  In
   particular, this memo provides a mechanism to negotiate bandwidth
   ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line fo=
r
   each session or media).


The IETF datatracker status page for this draft is:
https://d=
atatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps

There's also a htmlized version available at:
http://tools=
.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01

A diff from the previous version is available at:
ht=
tp://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps-0=
1


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




___=
____________________________________________
mmusic mailing list
mmusic@=
ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--_000_7A051DFAA46D0246A82293C7CEF621E9070A0D24A0ESESSCMS0352e_-- From fandreas@cisco.com Tue Sep 25 09:51:40 2012 Return-Path: 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 EB5A321F885B for ; Tue, 25 Sep 2012 09:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 07hJS4f5Hjib for ; Tue, 25 Sep 2012 09:51:38 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 507FA21F86A5 for ; Tue, 25 Sep 2012 09:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12717; q=dns/txt; s=iport; t=1348591898; x=1349801498; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=6ETxQU1yzG222Cd6GIxgkGDrC7t1g/6wIexE2Yt5ayc=; b=d7s6Rpo4UOMRHsg8Qz5HCUH9gfK/Str13XOTjs3iQR5+lRbpgLBL8izK vdtWwXIhgjc5PrfX6p3bFtIeTBDNrhp+nWvEql7ugmhEq1d6P2x/btJYe ccR/4CPjMv6XYUH40VfFrKQKIDwta+PFssblLYvdJu3VEx2PNJgdfHUeW o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FABbgYVCtJV2a/2dsb2JhbABFgkuJH7J4gQiCIAEBAQQBAQEPAVsGBAEMBAsRBAEBAQkWCAcJAwIBAgEVHwkIBg0BBQIBAQUSB4djC5h6j1aQcYsaGoYoA5Vmjj+BaYMDgUc X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208,217";a="125164578" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 25 Sep 2012 16:51:37 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8PGpajS008416; Tue, 25 Sep 2012 16:51:37 GMT Message-ID: <5061E117.2000804@cisco.com> Date: Tue, 25 Sep 2012 12:51:35 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Atle Monrad References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> Content-Type: multipart/alternative; boundary="------------080407010108000705090303" Cc: mmusic Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Tue, 25 Sep 2012 16:51:40 -0000 This is a multi-part message in MIME format. --------------080407010108000705090303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So it seems we have a way forward here that will work for everybody and allow us to come up with a single E164 IANA registration for both RFC 3108 and SDP-CS, but please note that all Internet Drafts include the following text for a reason: Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." If people do plan on making use of and/or reference to an Internet-Draft, please let the WG and authors know so we can give adequate priority to the work and hence provide a stable reference in the form of an RFC (as has already been done by 3GPP for a couple of other drafts) Thanks -- Flemming (as MMUSIC co-chair) On 9/25/12 4:47 AM, Atle Monrad wrote: > Miguel > > 3GPP has referred to this draft since Rel-8. Avoidance of last-minute changes to the coding would be appreciated. > > Your proposed way forward seems good to me. > > Thanks > /atle > > ________________________________ > > > Atle Monrad > 3GPP CT Chairman > Standardization and Regulation, > Group Function Technology and Portfolio Management > Ericsson > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia > Sent: 24. september 2012 22:10 > To: mmusic > Cc: Flemming Andreasen > Subject: [MMUSIC] Issue with E164 numbers in SDP CS draft > > Hi, > > as an author of draft-ietf-mmusic-sdp-cs > > The authors were addressing the comments that we got back in February from Flemming. His complete e-mail was this one: > > http://www.ietf.org/mail-archive/web/mmusic/current/msg09367.html > > The authors have addressed all the comments, except the first one. We require a bit more of discussion on the list. I reproduce here the comment: > > 1) The document defines the "E164" 'addrtype' type as well as the "-" > 'addrtype' to be used in the "c=" line and wants to register these with IANA. As it turns out, RFC 3108 also defined these, however they never got registered with IANA. While the '-' seems to be defined similarly, the syntax for the "164" differs between the two, which is obviously a problem, not least considering RFC 3108 is Standards Track. Also, for some reason the cs-draft lists RFC 3108 as a normative reference, but it does not provide any normative text for its use. > > The problem that is not listed here is the definition fo the "E164" > 'addrtype' in RFC 3108. I include here the relevant text: > > E164: If the addressType is E164, the address is expressed as a > decimal number with up to 15 digits. For example: > > c=ATM E164 9738294382 > > The use of E.164 numbers in the B-ISDN context is defined in ITU > E.191. There is a disparity between the ATM forum and the ITU in the > use of E.164 numbers for ATM addressing. The ATM forum (e.g., UNI > Signaling 4.0) allows only International Format E.164 numbers, while > the ITU (e.g., Q.2931) allows private numbering plans. Since the > goal of this SDP specification is to interoperate with all bearer > signaling protocols, it allows the use of numbers that do not conform > to the E.164 International Format. However, to maximize overall > consistency, network administrators can restrict the provisioning of > numbers to the E.164 International Format. > > > The SDP CS draft indicates that only international E164 number must be used, and adds a '+' sign to indicate the international format of the number. RFC 3108 seems to allow both international and national format, but does not add the '+' sign to indicate that a digit-string means international format. > > At first glance, one solution could be that the CS draft will use another addrtype, for example, "INTE164", to indicate international E.164 numbers. However, being the CS draft a dependency to 3GPP Release 8 (which was technical frozen in 2009), I think it is not fair to do this last-minute change at this stage. And I will be worried if there are already implementations deployed. > > I want to stress that the usages of ATM in SDP and CS in SDP do not clash. I mean, the usage is so different that it is hard to foresee an implementation that will use RFC 3108 and SDP CS *at the same time*. > > So, let me have a proposal that I believe will satisfy both RFC 3108 and the SDP CS draft. > > The idea is to keep on using the "E164" addrtype in both documents. SDP CS needs to define the E164 number indicating that can convey both international and national numbers. If an international number is used, it is prepended by a '+' sign (as the draft currently says). If a '+' is written, then it is an international format. If a '+' sign is absent then it is up to the implementation to determine the scope of the number (national or international). The lack of '+' sign will only occur in the context of RFC 3108. > > SDP CS will keep on only using international E.164 numbers, represented with the '+' sign, and will register (as it currently does) the "E164" > 'addrtype' with IANA. > > Is this acceptable? > > /Miguel > > > > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > --------------080407010108000705090303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit So it seems we have a way forward here that will work for everybody and allow us to come up with a single E164 IANA registration for both RFC 3108 and SDP-CS, but please note that all Internet Drafts include the following text for a reason:

<quote>
   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
</qutoe>

If people do plan on making use of and/or reference to an Internet-Draft, please let the WG and authors know so we can give adequate priority to the work and hence provide a stable reference in the form of an RFC (as has already been done by 3GPP for a couple of other drafts)

Thanks

-- Flemming  (as MMUSIC co-chair)



On 9/25/12 4:47 AM, Atle Monrad wrote:
Miguel

3GPP has referred to this draft since Rel-8. Avoidance of last-minute changes to the coding would be appreciated.

Your proposed way forward seems good to me.

Thanks
/atle

________________________________ 


Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management 
Ericsson


-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia
Sent: 24. september 2012 22:10
To: mmusic
Cc: Flemming Andreasen
Subject: [MMUSIC] Issue with E164 numbers in SDP CS draft

Hi,

as an author of draft-ietf-mmusic-sdp-cs

The authors were addressing the comments that we got back in February from Flemming. His complete e-mail was this one:

http://www.ietf.org/mail-archive/web/mmusic/current/msg09367.html

The authors have addressed all the comments, except the first one. We require a bit more of discussion on the list. I reproduce here the comment:

1) The document defines the "E164" 'addrtype' type as well as the "-" 
'addrtype' to be used in the "c=" line and wants to register these with IANA. As it turns out, RFC 3108 also defined these, however they never got registered with IANA. While the '-' seems to be defined similarly, the syntax for the "164" differs between the two, which is obviously a problem, not least considering RFC 3108 is Standards Track. Also, for some reason the cs-draft lists RFC 3108 as a normative reference, but it does not provide any normative text for its use.

The problem that is not listed here is the definition fo the "E164" 
'addrtype' in RFC 3108. I include here the relevant text:

    E164: If the addressType is E164, the address is expressed as a
    decimal number  with up to 15 digits.  For example:

         c=ATM E164 9738294382

    The use of E.164 numbers in the B-ISDN context is defined in ITU
    E.191.  There is a disparity between the ATM forum and the ITU in the
    use of E.164 numbers for ATM addressing.  The ATM forum (e.g., UNI
    Signaling 4.0) allows only International Format E.164 numbers, while
    the ITU (e.g., Q.2931) allows private numbering plans.  Since the
    goal of this SDP specification is to interoperate with all bearer
    signaling protocols, it allows the use of numbers that do not conform
    to the E.164 International Format.  However, to maximize overall
    consistency, network administrators can restrict the provisioning of
    numbers to the E.164 International Format.


The SDP CS draft indicates that only international E164 number must be used, and adds a '+' sign to indicate the international format of the number. RFC 3108 seems to allow both international and national format, but does not add the '+' sign to indicate that a digit-string means international format.

At first glance, one solution could be that the CS draft will use another addrtype, for example, "INTE164", to indicate international E.164 numbers. However, being the CS draft a dependency to 3GPP Release 8 (which was technical frozen in 2009), I think it is not fair to do this last-minute change at this stage. And I will be worried if there are already implementations deployed.

I want to stress that the usages of ATM in SDP and CS in SDP do not clash. I mean, the usage is so different that it is hard to foresee an implementation that will use RFC 3108 and SDP CS *at the same time*.

So, let me have a proposal that I believe will satisfy both RFC 3108 and the SDP CS draft.

The idea is to keep on using the "E164" addrtype in both documents. SDP CS needs to define the E164 number indicating that can convey both international and national numbers. If an international number is used, it is prepended by a '+' sign (as the draft currently says). If a '+' is written, then it is an international format. If a '+' sign is absent then it is up to the implementation to determine the scope of the number (national or international). The lack of '+' sign will only occur in the context of RFC 3108.

SDP CS will keep on only using international E.164 numbers, represented with the '+' sign, and will register (as it currently does) the "E164" 
'addrtype' with IANA.

Is this acceptable?

/Miguel




--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
.

--------------080407010108000705090303-- From pkyzivat@alum.mit.edu Tue Sep 25 10:20:19 2012 Return-Path: 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 D9CF921F87EE for ; Tue, 25 Sep 2012 10:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] 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 sfHBYH0u44Qq for ; Tue, 25 Sep 2012 10:20:19 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id EB4C321F882C for ; Tue, 25 Sep 2012 10:20:18 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta02.westchester.pa.mail.comcast.net with comcast id 3P021k0041uE5Es51VLNfG; Tue, 25 Sep 2012 17:20:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id 3VFZ1k00z3ZTu2S3cVFZPG; Tue, 25 Sep 2012 17:15:33 +0000 Message-ID: <5061E6A6.6070507@alum.mit.edu> Date: Tue, 25 Sep 2012 13:15:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com> In-Reply-To: <5061E117.2000804@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Tue, 25 Sep 2012 17:20:20 -0000 On 9/25/12 12:51 PM, Flemming Andreasen wrote: > So it seems we have a way forward here that will work for everybody and > allow us to come up with a single E164 IANA registration for both RFC > 3108 and SDP-CS, What is the single way that works for both? I don't see that without an update to 3108. RFC 3108 doesn't support the '+' and purports to support both global and local without it. But you can't really support both global and local numbers without *some* non-numeric characters. (Unless you go with dial strings, which are themselves not global.) Thanks, Paul > but please note that all Internet Drafts include the > following text for a reason: > > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > > > If people do plan on making use of and/or reference to an > Internet-Draft, please let the WG and authors know so we can give > adequate priority to the work and hence provide a stable reference in > the form of an RFC (as has already been done by 3GPP for a couple of > other drafts) > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > > On 9/25/12 4:47 AM, Atle Monrad wrote: >> Miguel >> >> 3GPP has referred to this draft since Rel-8. Avoidance of last-minute changes to the coding would be appreciated. >> >> Your proposed way forward seems good to me. >> >> Thanks >> /atle >> >> ________________________________ >> >> >> Atle Monrad >> 3GPP CT Chairman >> Standardization and Regulation, >> Group Function Technology and Portfolio Management >> Ericsson >> >> >> -----Original Message----- >> From:mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia >> Sent: 24. september 2012 22:10 >> To: mmusic >> Cc: Flemming Andreasen >> Subject: [MMUSIC] Issue with E164 numbers in SDP CS draft >> >> Hi, >> >> as an author of draft-ietf-mmusic-sdp-cs >> >> The authors were addressing the comments that we got back in February from Flemming. His complete e-mail was this one: >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09367.html >> >> The authors have addressed all the comments, except the first one. We require a bit more of discussion on the list. I reproduce here the comment: >> >> 1) The document defines the "E164" 'addrtype' type as well as the "-" >> 'addrtype' to be used in the "c=" line and wants to register these with IANA. As it turns out, RFC 3108 also defined these, however they never got registered with IANA. While the '-' seems to be defined similarly, the syntax for the "164" differs between the two, which is obviously a problem, not least considering RFC 3108 is Standards Track. Also, for some reason the cs-draft lists RFC 3108 as a normative reference, but it does not provide any normative text for its use. >> >> The problem that is not listed here is the definition fo the "E164" >> 'addrtype' in RFC 3108. I include here the relevant text: >> >> E164: If the addressType is E164, the address is expressed as a >> decimal number with up to 15 digits. For example: >> >> c=ATM E164 9738294382 >> >> The use of E.164 numbers in the B-ISDN context is defined in ITU >> E.191. There is a disparity between the ATM forum and the ITU in the >> use of E.164 numbers for ATM addressing. The ATM forum (e.g., UNI >> Signaling 4.0) allows only International Format E.164 numbers, while >> the ITU (e.g., Q.2931) allows private numbering plans. Since the >> goal of this SDP specification is to interoperate with all bearer >> signaling protocols, it allows the use of numbers that do not conform >> to the E.164 International Format. However, to maximize overall >> consistency, network administrators can restrict the provisioning of >> numbers to the E.164 International Format. >> >> >> The SDP CS draft indicates that only international E164 number must be used, and adds a '+' sign to indicate the international format of the number. RFC 3108 seems to allow both international and national format, but does not add the '+' sign to indicate that a digit-string means international format. >> >> At first glance, one solution could be that the CS draft will use another addrtype, for example, "INTE164", to indicate international E.164 numbers. However, being the CS draft a dependency to 3GPP Release 8 (which was technical frozen in 2009), I think it is not fair to do this last-minute change at this stage. And I will be worried if there are already implementations deployed. >> >> I want to stress that the usages of ATM in SDP and CS in SDP do not clash. I mean, the usage is so different that it is hard to foresee an implementation that will use RFC 3108 and SDP CS *at the same time*. >> >> So, let me have a proposal that I believe will satisfy both RFC 3108 and the SDP CS draft. >> >> The idea is to keep on using the "E164" addrtype in both documents. SDP CS needs to define the E164 number indicating that can convey both international and national numbers. If an international number is used, it is prepended by a '+' sign (as the draft currently says). If a '+' is written, then it is an international format. If a '+' sign is absent then it is up to the implementation to determine the scope of the number (national or international). The lack of '+' sign will only occur in the context of RFC 3108. >> >> SDP CS will keep on only using international E.164 numbers, represented with the '+' sign, and will register (as it currently does) the "E164" >> 'addrtype' with IANA. >> >> Is this acceptable? >> >> /Miguel >> >> >> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >> > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From miguel.a.garcia@ericsson.com Tue Sep 25 11:22:51 2012 Return-Path: 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 2295F21F878A for ; Tue, 25 Sep 2012 11:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.947 X-Spam-Level: X-Spam-Status: No, score=-5.947 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 358frvE4Q7WI for ; Tue, 25 Sep 2012 11:22:50 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDEB21F84D1 for ; Tue, 25 Sep 2012 11:22:49 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-16-5061f677a81f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 88.CC.25676.776F1605; Tue, 25 Sep 2012 20:22:48 +0200 (CEST) Received: from ESESSCMS0364.eemea.ericsson.se ([169.254.1.55]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 25 Sep 2012 20:22:25 +0200 From: Miguel Garcia A To: Paul Kyzivat , "mmusic@ietf.org" Date: Tue, 25 Sep 2012 20:19:06 +0200 Thread-Topic: [MMUSIC] Issue with E164 numbers in SDP CS draft Thread-Index: Ac2bQg0X7hNd+ZW9Q0KuY8H4ZUTSswACDKMO Message-ID: References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>,<5061E6A6.6070507@alum.mit.edu> In-Reply-To: <5061E6A6.6070507@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvrW7Ft8QAg0lvOC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj1eHJ7AVXrCqmHk1qYFyh18XIySEhYCLR 9GUlK4QtJnHh3nq2LkYuDiGBU4wSX+58gXIWMErM2feKvYuRg4MNqGPhXR+QBhEBX4lnj2+z gdgsAqoS01a+YQSxhQVsJdZ3/2OHqLGTeHXqOCOEbSRx5/UasGW8AuESL98ehJq/jVGibcYl sASngI7Exi8NzCA2I9BF30+tYQKxmQXEJW49mc8EcamAxJI955khbFGJl4//sULUi0rcaV/P CFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzCuYmZOenl RnqpRZnJxcX5eXrFqZsYgTFycMtv1R2Md86JHGKU5mBREue13rrHX0ggPbEkNTs1tSC1KL6o NCe1+BAjEwenVAOjTc6f19k2d6/5Ppk9cY2i1kJ1Makrja099/Zn/tjqtS1mf9DS+sY1lqkr D/fqabgwvPbd8c97SkyMZYz+P+8ku6IJ7wtmb/c73s9lY8TmN7/v8B0Zy/WfGRieJmXN4jjZ 3a90IPPk6b6MYuuzSz58C45jtn8177Xh9QS5nJ9NgmEHpPSOPGVRYinOSDTUYi4qTgQAomDU YF8CAAA= Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Tue, 25 Sep 2012 18:22:51 -0000 Paul: The problem, IMHO, lies in RFC 3108, because it allows both national and in= ternational numbering plans without separating the context.=20 With or without the CS draft, RFC 3108 seems to have a problem. In spite of= other problems (the draft fails to register E164 and perhaps some other pa= rameters. As I said before, there is not foresee usage of the E164 number scheme in b= oth RFC 3108 and SDP CS context. So, RFC 3108 can keep on using the mechani= sm they are currently using. The SDP CS draft will register the E164 with I= ANA with the syntax that may optionally include a plus sign. This does not = affect current implementations of RFC 3108. BR, Miguel ________________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Paul K= yzivat [pkyzivat@alum.mit.edu] Sent: Tuesday, September 25, 2012 7:15 PM To: mmusic@ietf.org Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft On 9/25/12 12:51 PM, Flemming Andreasen wrote: > So it seems we have a way forward here that will work for everybody and > allow us to come up with a single E164 IANA registration for both RFC > 3108 and SDP-CS, What is the single way that works for both? I don't see that without an update to 3108. RFC 3108 doesn't support the '+' and purports to support both global and local without it. But you can't really support both global and local numbers without *some* non-numeric characters. (Unless you go with dial strings, which are themselves not global.) Thanks, Paul > but please note that all Internet Drafts include the > following text for a reason: > > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > > > If people do plan on making use of and/or reference to an > Internet-Draft, please let the WG and authors know so we can give > adequate priority to the work and hence provide a stable reference in > the form of an RFC (as has already been done by 3GPP for a couple of > other drafts) > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > > On 9/25/12 4:47 AM, Atle Monrad wrote: >> Miguel >> >> 3GPP has referred to this draft since Rel-8. Avoidance of last-minute ch= anges to the coding would be appreciated. >> >> Your proposed way forward seems good to me. >> >> Thanks >> /atle >> >> ________________________________ >> >> >> Atle Monrad >> 3GPP CT Chairman >> Standardization and Regulation, >> Group Function Technology and Portfolio Management >> Ericsson >> >> >> -----Original Message----- >> From:mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf= Of Miguel A. Garcia >> Sent: 24. september 2012 22:10 >> To: mmusic >> Cc: Flemming Andreasen >> Subject: [MMUSIC] Issue with E164 numbers in SDP CS draft >> >> Hi, >> >> as an author of draft-ietf-mmusic-sdp-cs >> >> The authors were addressing the comments that we got back in February fr= om Flemming. His complete e-mail was this one: >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09367.html >> >> The authors have addressed all the comments, except the first one. We re= quire a bit more of discussion on the list. I reproduce here the comment: >> >> 1) The document defines the "E164" 'addrtype' type as well as the "-" >> 'addrtype' to be used in the "c=3D" line and wants to register these wit= h IANA. As it turns out, RFC 3108 also defined these, however they never go= t registered with IANA. While the '-' seems to be defined similarly, the sy= ntax for the "164" differs between the two, which is obviously a problem, n= ot least considering RFC 3108 is Standards Track. Also, for some reason the= cs-draft lists RFC 3108 as a normative reference, but it does not provide = any normative text for its use. >> >> The problem that is not listed here is the definition fo the "E164" >> 'addrtype' in RFC 3108. I include here the relevant text: >> >> E164: If the addressType is E164, the address is expressed as a >> decimal number with up to 15 digits. For example: >> >> c=3DATM E164 9738294382 >> >> The use of E.164 numbers in the B-ISDN context is defined in ITU >> E.191. There is a disparity between the ATM forum and the ITU in t= he >> use of E.164 numbers for ATM addressing. The ATM forum (e.g., UNI >> Signaling 4.0) allows only International Format E.164 numbers, whil= e >> the ITU (e.g., Q.2931) allows private numbering plans. Since the >> goal of this SDP specification is to interoperate with all bearer >> signaling protocols, it allows the use of numbers that do not confo= rm >> to the E.164 International Format. However, to maximize overall >> consistency, network administrators can restrict the provisioning o= f >> numbers to the E.164 International Format. >> >> >> The SDP CS draft indicates that only international E164 number must be u= sed, and adds a '+' sign to indicate the international format of the number= . RFC 3108 seems to allow both international and national format, but does = not add the '+' sign to indicate that a digit-string means international fo= rmat. >> >> At first glance, one solution could be that the CS draft will use anothe= r addrtype, for example, "INTE164", to indicate international E.164 numbers= . However, being the CS draft a dependency to 3GPP Release 8 (which was tec= hnical frozen in 2009), I think it is not fair to do this last-minute chang= e at this stage. And I will be worried if there are already implementations= deployed. >> >> I want to stress that the usages of ATM in SDP and CS in SDP do not clas= h. I mean, the usage is so different that it is hard to foresee an implemen= tation that will use RFC 3108 and SDP CS *at the same time*. >> >> So, let me have a proposal that I believe will satisfy both RFC 3108 and= the SDP CS draft. >> >> The idea is to keep on using the "E164" addrtype in both documents. SDP = CS needs to define the E164 number indicating that can convey both internat= ional and national numbers. If an international number is used, it is prepe= nded by a '+' sign (as the draft currently says). If a '+' is written, then= it is an international format. If a '+' sign is absent then it is up to th= e implementation to determine the scope of the number (national or internat= ional). The lack of '+' sign will only occur in the context of RFC 3108. >> >> SDP CS will keep on only using international E.164 numbers, represented = with the '+' sign, and will register (as it currently does) the "E164" >> 'addrtype' with IANA. >> >> Is this acceptable? >> >> /Miguel >> >> >> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >> > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Tue Sep 25 13:50:41 2012 Return-Path: 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 9A8BD21F87A3 for ; Tue, 25 Sep 2012 13:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 oxIRuPjyLj+U for ; Tue, 25 Sep 2012 13:50:39 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id D3EE121F879A for ; Tue, 25 Sep 2012 13:50:37 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta05.westchester.pa.mail.comcast.net with comcast id 3WR41k0050QuhwU55Yqh2w; Tue, 25 Sep 2012 20:50:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id 3YlC1k00f3ZTu2S3NYlCGH; Tue, 25 Sep 2012 20:45:13 +0000 Message-ID: <506217F0.3060400@alum.mit.edu> Date: Tue, 25 Sep 2012 16:45:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Miguel Garcia A References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Tue, 25 Sep 2012 20:50:42 -0000 On 9/25/12 2:19 PM, Miguel Garcia A wrote: > Paul: > > The problem, IMHO, lies in RFC 3108, because it allows both national and international numbering plans without separating the context. > > With or without the CS draft, RFC 3108 seems to have a problem. In spite of other problems (the draft fails to register E164 and perhaps some other parameters. > > As I said before, there is not foresee usage of the E164 number scheme in both RFC 3108 and SDP CS context. So, RFC 3108 can keep on using the mechanism they are currently using. The SDP CS draft will register the E164 with IANA with the syntax that may optionally include a plus sign. This does not affect current implementations of RFC 3108. I agree the problem is with 3108. And I have no problem with the SDP CS draft registering E164 with numbers starting with '+'. But I do have a little trouble with this draft registering E164 in a way that permits numbers without the '+'. The problem with doing this is defining what it means - how to interpret the number in that case. Just saying it means "local" without defining what "local" means is not a good thing. So, I see two ways forward: - only define values consisting of '+' and digits. Leave anything more to be done later if anyone cares. - do a complete definition of both global and local numbers. In that case I would suggest referring to 'telephone-subscriber' from RFC3966 rather than trying to start from scratch. Either of these work for me, though I would slightly prefer referencing RFC3966, because it gives a more robust definition. Thanks, Paul From lconroy@insensate.co.uk Tue Sep 25 14:27:13 2012 Return-Path: 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 8110121F867A for ; Tue, 25 Sep 2012 14:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] 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 2iE5jsZfBvyh for ; Tue, 25 Sep 2012 14:27:12 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 4C79121F852C for ; Tue, 25 Sep 2012 14:27:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id AC03C23F59C; Tue, 25 Sep 2012 22:27:10 +0100 (BST) Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83kbqO2bYzpt; Tue, 25 Sep 2012 22:27:09 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTPSA id A835A23F591; Tue, 25 Sep 2012 22:27:09 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <506217F0.3060400@alum.mit.edu> Date: Tue, 25 Sep 2012 22:27:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> To: mmusic@ietf.org X-Mailer: Apple Mail (2.1085) Cc: Paul Kyzivat Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Tue, 25 Sep 2012 21:27:13 -0000 Hi Folks, Me too. Personally, I would STRONGLY prefer that folks pulled the = definition from 3966 (whichever of the two choices you make). We had similar mantras to chant in ENUM, so I feel for the squirming = here. See the last para of RFC4415 section 3 for the appropriate syntax = references to RFC3966 -- yes, you DO need to refer to that, and I'd = suggest normatively. National/Local numbers are not necessarily the same as dial strings (as = Paul has spelt out before, IIRC). I ASSUME that you intend this to be a = number rather than any old dial string (with or without the preceding = '9', with or without a carrier prefix, with or without a trunk "access" = digit, ...). That's why we strongly discouraged anything other than global numbers -- = otherwise you're building in yet another "NAT" problem. See the text in the 2nd para of the intro to RFC6116 for the "anointed" = spec/definition we used for "E.164 number". BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. IIRC, = the '+' comes from 3GPP and from TIA specs. Also, you may want to specify that the "punctuation" that E.164 permits = is excluded (assuming you don't want dashes, commas, dots or spaces in = the middle). all the best, Lawrence =20 On 25 Sep 2012, at 21:45, Paul Kyzivat wrote: > On 9/25/12 2:19 PM, Miguel Garcia A wrote: >> Paul: >>=20 >> The problem, IMHO, lies in RFC 3108, because it allows both national = and international numbering plans without separating the context. >>=20 >> With or without the CS draft, RFC 3108 seems to have a problem. In = spite of other problems (the draft fails to register E164 and perhaps = some other parameters. >>=20 >> As I said before, there is not foresee usage of the E164 number = scheme in both RFC 3108 and SDP CS context. So, RFC 3108 can keep on = using the mechanism they are currently using. The SDP CS draft will = register the E164 with IANA with the syntax that may optionally include = a plus sign. This does not affect current implementations of RFC 3108. >=20 > I agree the problem is with 3108. > And I have no problem with the SDP CS draft registering E164 with = numbers starting with '+'. >=20 > But I do have a little trouble with this draft registering E164 in a = way that permits numbers without the '+'. The problem with doing this is = defining what it means - how to interpret the number in that case. Just = saying it means "local" without defining what "local" means is not a = good thing. >=20 > So, I see two ways forward: >=20 > - only define values consisting of '+' and digits. > Leave anything more to be done later if anyone > cares. >=20 > - do a complete definition of both global and local > numbers. In that case I would suggest referring to > 'telephone-subscriber' from RFC3966 rather than > trying to start from scratch. >=20 > Either of these work for me, though I would slightly prefer = referencing RFC3966, because it gives a more robust definition. >=20 > Thanks, > Paul From pkyzivat@alum.mit.edu Tue Sep 25 14:55:28 2012 Return-Path: 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 AA1F31F0C42 for ; Tue, 25 Sep 2012 14:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 lVSqfasOVEjQ for ; Tue, 25 Sep 2012 14:55:28 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id DE8221F041E for ; Tue, 25 Sep 2012 14:55:27 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id 3Q4U1k00A0Fqzac53ZvXmg; Tue, 25 Sep 2012 21:55:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 3ZqM1k00o3ZTu2S3UZqMm9; Tue, 25 Sep 2012 21:50:21 +0000 Message-ID: <50622723.3060909@alum.mit.edu> Date: Tue, 25 Sep 2012 17:50:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Lawrence Conroy References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> In-Reply-To: <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Tue, 25 Sep 2012 21:55:28 -0000 On 9/25/12 5:27 PM, Lawrence Conroy wrote: > Hi Folks, > Me too. Personally, I would STRONGLY prefer that folks pulled the definition from 3966 (whichever of the two choices you make). > > We had similar mantras to chant in ENUM, so I feel for the squirming here. > > See the last para of RFC4415 section 3 for the appropriate syntax references to RFC3966 -- yes, you DO need to refer to that, and I'd suggest normatively. > National/Local numbers are not necessarily the same as dial strings (as Paul has spelt out before, IIRC). I ASSUME that you intend this to be a number rather than any old dial string (with or without the preceding '9', with or without a carrier prefix, with or without a trunk "access" digit, ...). > That's why we strongly discouraged anything other than global numbers -- otherwise you're building in yet another "NAT" problem. > > See the text in the 2nd para of the intro to RFC6116 for the "anointed" spec/definition we used for "E.164 number". > BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. IIRC, the '+' comes from 3GPP and from TIA specs. RFC3108 *could* be valid without the '+' if it only permitted E.164 (global) numbers. But it claims to support both International Format E.164 numbers and private numbering plans. For that it is invalid because there is no way to distinguish between them. The example appears to be a US number without country code. But I don't know how you would know that. It could be a number in Bahrain. (It seems to be an *invalid* number in Bahrain, but unless you had a dialing plan for the entire world I don't know how you would know that.) > Also, you may want to specify that the "punctuation" that E.164 permits is excluded (assuming you don't want dashes, commas, dots or spaces in the middle). Or you could just allow it. No great shakes either way. Thanks, Paul > all the best, > Lawrence > > > On 25 Sep 2012, at 21:45, Paul Kyzivat wrote: >> On 9/25/12 2:19 PM, Miguel Garcia A wrote: >>> Paul: >>> >>> The problem, IMHO, lies in RFC 3108, because it allows both national and international numbering plans without separating the context. >>> >>> With or without the CS draft, RFC 3108 seems to have a problem. In spite of other problems (the draft fails to register E164 and perhaps some other parameters. >>> >>> As I said before, there is not foresee usage of the E164 number scheme in both RFC 3108 and SDP CS context. So, RFC 3108 can keep on using the mechanism they are currently using. The SDP CS draft will register the E164 with IANA with the syntax that may optionally include a plus sign. This does not affect current implementations of RFC 3108. >> >> I agree the problem is with 3108. >> And I have no problem with the SDP CS draft registering E164 with numbers starting with '+'. >> >> But I do have a little trouble with this draft registering E164 in a way that permits numbers without the '+'. The problem with doing this is defining what it means - how to interpret the number in that case. Just saying it means "local" without defining what "local" means is not a good thing. >> >> So, I see two ways forward: >> >> - only define values consisting of '+' and digits. >> Leave anything more to be done later if anyone >> cares. >> >> - do a complete definition of both global and local >> numbers. In that case I would suggest referring to >> 'telephone-subscriber' from RFC3966 rather than >> trying to start from scratch. >> >> Either of these work for me, though I would slightly prefer referencing RFC3966, because it gives a more robust definition. >> >> Thanks, >> Paul > > From lconroy@insensate.co.uk Tue Sep 25 16:03:54 2012 Return-Path: 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 5B5CF1F0425 for ; Tue, 25 Sep 2012 16:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] 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 5y2lamtRi-ff for ; Tue, 25 Sep 2012 16:03:53 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 4359021F843E for ; Tue, 25 Sep 2012 16:03:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 39DD424004D; Wed, 26 Sep 2012 00:03:51 +0100 (BST) Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+0VPISUmxg6; Wed, 26 Sep 2012 00:03:50 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTPSA id 1F2C7240036; Wed, 26 Sep 2012 00:03:48 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <50622723.3060909@alum.mit.edu> Date: Wed, 26 Sep 2012 00:03:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> <50622723.3060909@alum.mit.edu> To: mmusic@ietf.org X-Mailer: Apple Mail (2.1085) Cc: Paul Kyzivat Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Tue, 25 Sep 2012 23:03:54 -0000 On 25 Sep 2012, at 22:50, Paul Kyzivat wrote: > On 9/25/12 5:27 PM, Lawrence Conroy wrote: >> Hi Folks, >> Me too. Personally, I would STRONGLY prefer that folks pulled the = definition from 3966 (whichever of the two choices you make). >>=20 >> We had similar mantras to chant in ENUM, so I feel for the squirming = here. >>=20 >> See the last para of RFC4415 section 3 for the appropriate syntax = references to RFC3966 -- yes, you DO need to refer to that, and I'd = suggest normatively. >> National/Local numbers are not necessarily the same as dial strings = (as Paul has spelt out before, IIRC). I ASSUME that you intend this to = be a number rather than any old dial string (with or without the = preceding '9', with or without a carrier prefix, with or without a trunk = "access" digit, ...). >> That's why we strongly discouraged anything other than global numbers = -- otherwise you're building in yet another "NAT" problem. >>=20 >> See the text in the 2nd para of the intro to RFC6116 for the = "anointed" spec/definition we used for "E.164 number". >> BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. = IIRC, the '+' comes from 3GPP and from TIA specs. >=20 > RFC3108 *could* be valid without the '+' if it only permitted E.164 = (global) numbers. But it claims to support both International Format = E.164 numbers and private numbering plans. For that it is invalid = because there is no way to distinguish between them. The example appears = to be a US number without country code. But I don't know how you would = know that. It could be a number in Bahrain. (It seems to be an *invalid* = number in Bahrain, but unless you had a dialing plan for the entire = world I don't know how you would know that.) >=20 >> Also, you may want to specify that the "punctuation" that E.164 = permits is excluded (assuming you don't want dashes, commas, dots or = spaces in the middle). >=20 > Or you could just allow it. No great shakes either way. >=20 > Thanks, > Paul >=20 >> all the best, >> Lawrence To which I reply: Hi Paul, folks, Re. 3108 is psychic -- good point, well made. We're wildly agreeing here. All I was saying was that it's not the '+' that makes an E.164 number = ->in International Format<- (E.164 mentions International *and* National numbers [insofar as the ITU = ever deals with national systems] -- it mentions Nationally Significant = Numbers) Trying to deal with both International and National/Local numbers is = **really** hard, and impossible without context. The same discussions came up during development of 3966 -- that's why = there's a phone-context parameter for tel:, with a ["right-truncated"] = International E.164 number [as an alternative to a domainname]). As Paul sure knows, this has been done before. 3966 has extensive = discussion on exactly the concerns Paul has rightly raised (and it's = quite readable :). 3108 seems to have some secret unknown to the rest of us =3D> ignore the = magicians -- these two usages will never coexist without a reassuringly = expensive gateway between these universes. That gateway will have to = deal with context (although I don't want to answer the gateway RFI). =3D> just nail down the meaning of E.164 number ("...in international = format...", preceded by a '+' character), refer normatively to 3966's = syntax, and we're done. Anything more is thrashing over the same ground yet again. atb, Lawrence p.s. intra-number punctuation should be simple, but (in particular, = spaces) has bitten implementations more than once. I recommend applying = cattle-prods to the programmers if they forget.= From pkyzivat@alum.mit.edu Tue Sep 25 21:30:49 2012 Return-Path: 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 1FD2121F8646 for ; Tue, 25 Sep 2012 21:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 0HBdO9JnDIrc for ; Tue, 25 Sep 2012 21:30:48 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 8CECA21F8645 for ; Tue, 25 Sep 2012 21:30:42 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta08.westchester.pa.mail.comcast.net with comcast id 3gWl1k00117dt5G58gWmY5; Wed, 26 Sep 2012 04:30:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id 3gSR1k00W3ZTu2S3ZgSS6R; Wed, 26 Sep 2012 04:26:26 +0000 Message-ID: <506283C5.8050909@alum.mit.edu> Date: Wed, 26 Sep 2012 00:25:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Lawrence Conroy References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> <50622723.3060909@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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, 26 Sep 2012 04:30:49 -0000 I think we are in violent agreement. Just to be clear, there are various ways to reference 3966 and use that in SDP CS. The ones that come to my mind are, when the is E164, require the to be: 1) 'global-phone-digits' from 3966, but excluding 'visual-separator' characters. (This is essentially what is currently specified.) 2) 'global-number' from 3966. 3) 'telephone-subscriber' from 3966. Picking (3) will allow local-numbers with context to understand them. I am inclined to recommend (3) because I can see no reason not to. Quite a lot of thought and discussion went into 3966, so why abandon or reinvent it? Thanks, Paul On 9/25/12 7:03 PM, Lawrence Conroy wrote: > On 25 Sep 2012, at 22:50, Paul Kyzivat wrote: >> On 9/25/12 5:27 PM, Lawrence Conroy wrote: >>> Hi Folks, >>> Me too. Personally, I would STRONGLY prefer that folks pulled the definition from 3966 (whichever of the two choices you make). >>> >>> We had similar mantras to chant in ENUM, so I feel for the squirming here. >>> >>> See the last para of RFC4415 section 3 for the appropriate syntax references to RFC3966 -- yes, you DO need to refer to that, and I'd suggest normatively. >>> National/Local numbers are not necessarily the same as dial strings (as Paul has spelt out before, IIRC). I ASSUME that you intend this to be a number rather than any old dial string (with or without the preceding '9', with or without a carrier prefix, with or without a trunk "access" digit, ...). >>> That's why we strongly discouraged anything other than global numbers -- otherwise you're building in yet another "NAT" problem. >>> >>> See the text in the 2nd para of the intro to RFC6116 for the "anointed" spec/definition we used for "E.164 number". >>> BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. IIRC, the '+' comes from 3GPP and from TIA specs. >> >> RFC3108 *could* be valid without the '+' if it only permitted E.164 (global) numbers. But it claims to support both International Format E.164 numbers and private numbering plans. For that it is invalid because there is no way to distinguish between them. The example appears to be a US number without country code. But I don't know how you would know that. It could be a number in Bahrain. (It seems to be an *invalid* number in Bahrain, but unless you had a dialing plan for the entire world I don't know how you would know that.) >> >>> Also, you may want to specify that the "punctuation" that E.164 permits is excluded (assuming you don't want dashes, commas, dots or spaces in the middle). >> >> Or you could just allow it. No great shakes either way. >> >> Thanks, >> Paul >> >>> all the best, >>> Lawrence > > > To which I reply: > > Hi Paul, folks, > > Re. 3108 is psychic -- good point, well made. > We're wildly agreeing here. > > All I was saying was that it's not the '+' that makes an E.164 number ->in International Format<- > (E.164 mentions International *and* National numbers [insofar as the ITU ever deals with national systems] -- it mentions Nationally Significant Numbers) > > Trying to deal with both International and National/Local numbers is **really** hard, and impossible without context. > The same discussions came up during development of 3966 -- that's why there's a phone-context parameter for tel:, with a ["right-truncated"] International E.164 number [as an alternative to a domainname]). > > As Paul sure knows, this has been done before. 3966 has extensive discussion on exactly the concerns Paul has rightly raised (and it's quite readable :). > > 3108 seems to have some secret unknown to the rest of us => ignore the magicians -- these two usages will never coexist without a reassuringly expensive gateway between these universes. That gateway will have to deal with context (although I don't want to answer the gateway RFI). > > => just nail down the meaning of E.164 number ("...in international format...", preceded by a '+' character), refer normatively to 3966's syntax, and we're done. > Anything more is thrashing over the same ground yet again. > > atb, Lawrence > p.s. intra-number punctuation should be simple, but (in particular, spaces) has bitten implementations more than once. I recommend applying cattle-prods to the programmers if they forget. > From christer.holmberg@ericsson.com Wed Sep 26 00:24:43 2012 Return-Path: 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 8611421F8698 for ; Wed, 26 Sep 2012 00:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 ryy6EoVSO2af for ; Wed, 26 Sep 2012 00:24:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 04B1421F8652 for ; Wed, 26 Sep 2012 00:24:41 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-8f-5062adb86fd3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6F.64.11467.8BDA2605; Wed, 26 Sep 2012 09:24:40 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 26 Sep 2012 09:24:40 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Date: Wed, 26 Sep 2012 09:23:22 +0200 Thread-Topic: Draft new version/working group: draft-westerlund-mmusic-max-ssrc-00 Thread-Index: Ac2bt2dHkvd5ehw8SD2LyY08SqwvQw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A6A2C5D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2C5DESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvre6OtUkBBpObJSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL/3bzEXLJKs2N5+hrmB8YBYFyMnh4SAicSNvs1MELaYxIV7 69m6GLk4hAROMUqs/3uPBcJZwCixc/Zuxi5GDg42AQuJ7n/aIA0iAuoSX/f2MIOEWQRUJfZ2 FYGEhQV8JXYtfskOURIisfrASkYIW09i36+lYDavQLjE1ucTWEBsRqC930+tAbuBWUBc4taT +VD3CEgs2XOeGcIWlXj5+B8rRL2oxJ329YwQ9fkSS6csZ4GYKShxcuYTlgmMQrOQjJqFpGwW kjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilE4NzEzJ73cUC+1KDO5uDg/T684dRMj MBoObvmtu4Px1DmRQ4zSHCxK4rxcSfv9hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDyem/Z dHC98aNJx/8u+P2befHRt4lBYkyv6tnOtf0pX9a4XMx2ibcty8Irzd8lGBiXOvBWiU8/1yfs eFVT+GKaUNVhK14ne2sjxR9POc8fubDs9hJP4dAnktz5119pKTKbRf++dPy0/55+Gf3VNm4q 5m9WbP9yo/OfbP0mwYNTxE6x9Ff+dC9QYinOSDTUYi4qTgQAWW/4hlQCAAA= Subject: [MMUSIC] Draft new version/working group: draft-westerlund-mmusic-max-ssrc-00 X-BeenThere: mmusic@ietf.org 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, 26 Sep 2012 07:24:43 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2C5DESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have submitted a draft, new to MMUSIC: draft-westerlund-mmusic-max-ssrc. The draft SDP entities to, within an m- line, indicate sending and receivin= g capabilities for multiple streams, based on used payload types. Earlier versions of the draft were submitted to AVTCORE. However, we think = MMUSIC is more appropriate, due to the new SDP attributes etc. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2C5DESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi,

 

We have submitted a draft, new to MMUSI= C: draft-westerlund-mmusic-max-ssrc.

 

The draft SDP entities to, within an= m- line, indicate sending and receiving capabilities for multiple streams,= based on used payload types.

 = ;

Earlier versions of the draft were submitte= d to AVTCORE. However, we think MMUSIC is more appropriate, due to the new = SDP attributes etc.

 

Regards,

&nbs= p;

Christer

= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2C5DESESSCMS0356e_-- From miguel.a.garcia@ericsson.com Wed Sep 26 00:31:09 2012 Return-Path: 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 3F80821F87C0 for ; Wed, 26 Sep 2012 00:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 yTfiDPKFErFL for ; Wed, 26 Sep 2012 00:31:08 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2E07C21F87BA for ; Wed, 26 Sep 2012 00:31:07 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-f6-5062af3ad6d0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 52.85.11467.A3FA2605; Wed, 26 Sep 2012 09:31:07 +0200 (CEST) Received: from [159.107.24.224] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.1; Wed, 26 Sep 2012 09:31:06 +0200 Message-ID: <5062AF39.4000804@ericsson.com> Date: Wed, 26 Sep 2012 09:31:05 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> In-Reply-To: <506217F0.3060400@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Vtd6fVKAwf2p7BZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxZf8ZtoJJ4hWvH/5kamDsEOpi5OSQEDCR aPtwmhHCFpO4cG89WxcjF4eQwClGiUmL5zJDOGsYJa6+n8gOUsUroC3ReHcuE4jNIqAqcXJ+ OzOIzSZgLtG6cSNYjahAsMS5jdvYIOoFJU7OfMLSxcjBISKgITFpqxqIySygLnF1cRCIKSxg K3H8SB3EpnlMEp/ufge7h1NAR+LX009gNjNQzYU511kgbHmJ7W/ngG0VEtCUmHxzKfMERsFZ SJbNQtIyC0nLAkbmVYzCuYmZOenlhnqpRZnJxcX5eXrFqZsYgYF6cMtv3R2Mp86JHGKU5mBR EuflStrvLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxwrLilEnLjBSnNipYb2VYuFXv5xr5 fV+eXOOTPxL66dZsqZ5vaeu/HCjpW3SA5elWll+rbKeqfp0lez9TOG/LWTb7yxET6mZuP612 V1NaSt9AyEe5eKHU3B+PXBLbeg25219+++B8+YDXMvtpOx0Njgqxd++wua53n/v7l6MvQz4z rVlo9fq2mBJLcUaioRZzUXEiANoSvpUiAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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, 26 Sep 2012 07:31:09 -0000 Hi Paul: see inline comments. On 25/09/2012 22:45, Paul Kyzivat wrote: > On 9/25/12 2:19 PM, Miguel Garcia A wrote: >> Paul: >> >> The problem, IMHO, lies in RFC 3108, because it allows both national and international numbering plans without separating the context. >> >> With or without the CS draft, RFC 3108 seems to have a problem. In spite of other problems (the draft fails to register E164 and perhaps some other parameters. >> >> As I said before, there is not foresee usage of the E164 number scheme in both RFC 3108 and SDP CS context. So, RFC 3108 can keep on using the mechanism they are currently using. The SDP CS draft will register the E164 with IANA with the syntax that may optionally include a plus sign. This does not affect current implementations of RFC 3108. > > I agree the problem is with 3108. > And I have no problem with the SDP CS draft registering E164 with > numbers starting with '+'. > > But I do have a little trouble with this draft registering E164 in a way > that permits numbers without the '+'. The problem with doing this is > defining what it means - how to interpret the number in that case. Just > saying it means "local" without defining what "local" means is not a > good thing. Notice that "local without defining local" is what is currently in RFC 3108. My proposal is to register E164 allowing international and non-international. The non-international could be used in local environments where there is no change of boundaries. This is like saying that, where both endpoints have agreed on the national boundary, the local representation could be used. This is what RFC 3108 tries to say. > > So, I see two ways forward: > > - only define values consisting of '+' and digits. > Leave anything more to be done later if anyone > cares. This is what the current version of the draft says, and I will be happy to accept it. But I understood Flemming had a problem. > > - do a complete definition of both global and local > numbers. In that case I would suggest referring to > 'telephone-subscriber' from RFC3966 rather than > trying to start from scratch. We looked at it way back in time, and I believe the problem was understanding the a local number with a ";phone-context=foo" will be accepted as a valid parameter for an address in a c= line in SDP. It looks a bit strange, mostly by the presence of the semicolon. Then, the telephone number in 3966 allows the representation of something more than digits, namely "#" and "*", which are not valid digits in E.164 numbers. So, we concluded that RFC 3966 was a good inspiration but not really what we are looking for. BR, Miguel > > Either of these work for me, though I would slightly prefer referencing > RFC3966, because it gives a more robust definition. > > Thanks, > Paul > > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Wed Sep 26 01:22:08 2012 Return-Path: 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 6516721F87A5 for ; Wed, 26 Sep 2012 01:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 jI8CbLAxLsAm for ; Wed, 26 Sep 2012 01:22:07 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EB11F21F8813 for ; Wed, 26 Sep 2012 01:22:06 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-c6-5062bb2c1c3e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AB.94.17130.C2BB2605; Wed, 26 Sep 2012 10:22:04 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 26 Sep 2012 10:22:04 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Date: Wed, 26 Sep 2012 10:22:02 +0200 Thread-Topic: Draft new version/working group: draft-westerlund-mmusic-max-ssrc-00 Thread-Index: Ac2bt2dHkvd5ehw8SD2LyY08SqwvQwACFY2g Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A6A2D17@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A6A2C5D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A6A2C5D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D17ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvra7O7qQAg53v9S2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBkTawt61CveLtvM2MDYqdzFyMkhIWAiseJhAyOELSZx4d56 ti5GLg4hgVOMEn8ufGCHcOYwSizo38jaxcjBwSZgIdH9TxukQURAXeLr3h5mEJtFQFVi36ef TCAlwgLBEg+6eSFKQiS6ft9jhrCNJBr7d4PZvALhEjt3vmMDsYWA7AdHNoDFOQUiJCZumcIC YjMC3fP91BomEJtZQFzi1pP5TBB3Ckgs2XOeGcIWlXj5+B8rRL2oxJ329YwQ9fkS61/eYYHY JShxcuYTlgmMIrOQjJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilE4NzEz J73cXC+1KDO5uDg/T684dRMjMHYObvltsINx032xQ4zSHCxK4rx6qvv9hQTSE0tSs1NTC1KL 4otKc1KLDzEycXBKNTByP4qZVuPxSE7oWWfImr/TeSfY1665v1ilYNeivZFF22vyrp4/E8aZ vDA+buGmDc+kjtaGN+1puen03u7UVgYjgQDVbgE2g8srSr9cK3ww+czNH0//7ErS/L79xCEj Ae1pWzl5njKV/39olKCj0zjf7JD9Hpudky9Mv34oKu7dymwHfgdzg188SizFGYmGWsxFxYkA TX24F2sCAAA= Subject: Re: [MMUSIC] Draft new version/working group: draft-westerlund-mmusic-max-ssrc-00 X-BeenThere: mmusic@ietf.org 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, 26 Sep 2012 08:22:08 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D17ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also, there is an associated IPR disclosure: https://datatracker.ietf.org/i= pr/1639/ Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 26. syyskuuta 2012 10:23 To: mmusic@ietf.org Subject: [MMUSIC] Draft new version/working group: draft-westerlund-mmusic-= max-ssrc-00 Hi, We have submitted a draft, new to MMUSIC: draft-westerlund-mmusic-max-ssrc. The draft SDP entities to, within an m- line, indicate sending and receivin= g capabilities for multiple streams, based on used payload types. Earlier versions of the draft were submitted to AVTCORE. However, we think = MMUSIC is more appropriate, due to the new SDP attributes etc. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D17ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Also, there is an associated IPR disclosure: https://datatracker.ietf.org/ipr/1639/

=  

Regards,

 

Christer

 

<= /body>= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2D17ESESSCMS0356e_-- From pkyzivat@alum.mit.edu Wed Sep 26 07:53:58 2012 Return-Path: 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 9DCDE21F87BA for ; Wed, 26 Sep 2012 07:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 asoC9-saN3qZ for ; Wed, 26 Sep 2012 07:53:58 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 723BF21F87CC for ; Wed, 26 Sep 2012 07:53:57 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta12.westchester.pa.mail.comcast.net with comcast id 3pTT1k0031HzFnQ5Cqu0H0; Wed, 26 Sep 2012 14:54:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id 3qoz1k00j3ZTu2S3aqozvd; Wed, 26 Sep 2012 14:49:00 +0000 Message-ID: <506315D7.9020505@alum.mit.edu> Date: Wed, 26 Sep 2012 10:48:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <5062AF39.4000804@ericsson.com> In-Reply-To: <5062AF39.4000804@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , "mmusic@ietf.org" Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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, 26 Sep 2012 14:53:59 -0000 On 9/26/12 3:31 AM, Miguel A. Garcia wrote: > Hi Paul: > > see inline comments. > > On 25/09/2012 22:45, Paul Kyzivat wrote: >> On 9/25/12 2:19 PM, Miguel Garcia A wrote: >>> Paul: >>> >>> The problem, IMHO, lies in RFC 3108, because it allows both national >>> and international numbering plans without separating the context. >>> >>> With or without the CS draft, RFC 3108 seems to have a problem. In >>> spite of other problems (the draft fails to register E164 and perhaps >>> some other parameters. >>> >>> As I said before, there is not foresee usage of the E164 number >>> scheme in both RFC 3108 and SDP CS context. So, RFC 3108 can keep on >>> using the mechanism they are currently using. The SDP CS draft will >>> register the E164 with IANA with the syntax that may optionally >>> include a plus sign. This does not affect current implementations of >>> RFC 3108. >> >> I agree the problem is with 3108. >> And I have no problem with the SDP CS draft registering E164 with >> numbers starting with '+'. >> >> But I do have a little trouble with this draft registering E164 in a way >> that permits numbers without the '+'. The problem with doing this is >> defining what it means - how to interpret the number in that case. Just >> saying it means "local" without defining what "local" means is not a >> good thing. > > Notice that "local without defining local" is what is currently in RFC > 3108. Yes, I know. :-( > My proposal is to register E164 allowing international and > non-international. You mean those starting with '+' and those that don't right? And those that don't are then really have "undefined" semantics, right? > The non-international could be used in local > environments where there is no change of boundaries. This is like saying > that, where both endpoints have agreed on the national boundary, the > local representation could be used. This is what RFC 3108 tries to say. I don't understand *what* 3108 is *trying* to say. But what it *does* say is ambiguous. And if you try to rationalize it with what you are proposing to register, then all the numbers used in 3108 will be "local" numbers by the definition you register. >> So, I see two ways forward: >> >> - only define values consisting of '+' and digits. >> Leave anything more to be done later if anyone >> cares. > > This is what the current version of the draft says, and I will be happy > to accept it. But I understood Flemming had a problem. Maybe Flemming will weigh in again. >> - do a complete definition of both global and local >> numbers. In that case I would suggest referring to >> 'telephone-subscriber' from RFC3966 rather than >> trying to start from scratch. > > We looked at it way back in time, and I believe the problem was > understanding the a local number with a ";phone-context=foo" will be > accepted as a valid parameter for an address in a c= line in SDP. It > looks a bit strange, mostly by the presence of the semicolon. It may look a bit strange, but SDP allows a lot of strange things. If you look at 4566, *none* of the forms being discussed are consistent with the existing ABNF (for , which currently must be either a or regardless of or . It is unfortunate that 4566 made provision for registering new and values, and even stated that RFCs registering new s must give details of the syntax of the address. But it doesn't say if the syntax can be incompatible with or can only specify subsets of that. Probably the most important part of the c= syntax is that nettype, addrtype, and connection-field are separated by SP, and so perhaps by inference cannot contain SP. As far as I can tell, all of is compatible (or not) with 4566 as 15 digits are. > Then, the telephone number in 3966 allows the representation of > something more than digits, namely "#" and "*", which are not valid > digits in E.164 numbers. While it allows them some places, it doesn't allow them in , which is where E.164 numbers fall. Thanks, Paul > So, we concluded that RFC 3966 was a good inspiration but not really > what we are looking for. > > BR, > > Miguel >> >> Either of these work for me, though I would slightly prefer referencing >> RFC3966, because it gives a more robust definition. >> >> Thanks, >> Paul >> >> > From fandreas@cisco.com Wed Sep 26 13:52:33 2012 Return-Path: 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 04B2121F8589 for ; Wed, 26 Sep 2012 13:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 QGQOuMW8foTn for ; Wed, 26 Sep 2012 13:52:32 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DA5F621F8588 for ; Wed, 26 Sep 2012 13:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1209; q=dns/txt; s=iport; t=1348692752; x=1349902352; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xQ6JRQenrNzrvw9UGo7yD4VzKOY9RvOL1pIiMH6NPXs=; b=WcFnSDLWEh8tA11CjJnyVFEiT+TcWQKL8gQPqPnMfQZWDtAGacYVqqkh 0EWr0XQO90dr3jA715WBAFDLzUTIszlUPItTFQT9DcMscTtWtLk0wEFIX oXliSCYzv/bdWiovQO1iV5tzPwfjmQgQWuuG/2aindOkYORZqP54kuzQ8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJdpY1CtJXG8/2dsb2JhbABFDr5MgQiCIAEBAQMBEgElQAEFCwsOCgkWDwkDAgECAUUGDQEHAQEeh10GmCmgNpEhA5VpjkKBaYIsVw X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="125673905" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 26 Sep 2012 20:52:31 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8QKqUEt023615; Wed, 26 Sep 2012 20:52:31 GMT Message-ID: <50636B0E.8000000@cisco.com> Date: Wed, 26 Sep 2012 16:52:30 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com> <5061E6A6.6070507@alum.mit.edu> In-Reply-To: <5061E6A6.6070507@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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, 26 Sep 2012 20:52:33 -0000 On 9/25/12 1:15 PM, Paul Kyzivat wrote: > On 9/25/12 12:51 PM, Flemming Andreasen wrote: >> So it seems we have a way forward here that will work for everybody and >> allow us to come up with a single E164 IANA registration for both RFC >> 3108 and SDP-CS, > > What is the single way that works for both? Allow omission of the '+' sign for RFC 3108 compliant implementations (and possibly restrict that to ATM network type), but use the '+' prefix everywhere else. > I don't see that without an update to 3108. > > RFC 3108 doesn't support the '+' and purports to support both global > and local without it. But you can't really support both global and > local numbers without *some* non-numeric characters. (Unless you go > with dial strings, which are themselves not global.) > I believe the issue you are bringing up is one that is internal to RFC 3108, which is how do you distinguish between a private and an International number in RFC 3108 ? I agree that's not clear, however that doesn't mean that you should disallow the syntax that has been defined there for international numbers, and which may be present in a number of current implementations. -- Flemming From fandreas@cisco.com Wed Sep 26 13:56:57 2012 Return-Path: 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 5F67521F8540 for ; Wed, 26 Sep 2012 13:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 7FLZOW0zmH3J for ; Wed, 26 Sep 2012 13:56:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C708421F853E for ; Wed, 26 Sep 2012 13:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2402; q=dns/txt; s=iport; t=1348693016; x=1349902616; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fVe8Iha3WvnGFj3WeHOOP8R3TtqHHOOkwBzW9SpNAQo=; b=GvVryQNFuoIwce3oPabenmaTc66GzujIgYuU18owKzwngu/vYHHGN5PY tN14p9f4R8R9b8NBJ0uzSKUczXff8hTdLoFb8/qNMrl25LcXTniLNcCKe zt0JwQTO2Cq1DWWb3c+Hpp7gVnsvCcmFeMeaJk1YfO2yrNiX1jFKsPjx5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFlrY1CtJV2Z/2dsb2JhbABFDr5MgQiCIAEBAQMBAQEBDwElNgsFCwsOCgklDwIWMAYNAQUCAQEeh10GC5geoDAEkSEDlWmOQoFpgixX X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="122674583" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 26 Sep 2012 20:56:56 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8QKutVQ000498; Wed, 26 Sep 2012 20:56:55 GMT Message-ID: <50636C17.203@cisco.com> Date: Wed, 26 Sep 2012 16:56:55 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> In-Reply-To: <506217F0.3060400@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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, 26 Sep 2012 20:56:57 -0000 On 9/25/12 4:45 PM, Paul Kyzivat wrote: > On 9/25/12 2:19 PM, Miguel Garcia A wrote: >> Paul: >> >> The problem, IMHO, lies in RFC 3108, because it allows both national >> and international numbering plans without separating the context. >> >> With or without the CS draft, RFC 3108 seems to have a problem. In >> spite of other problems (the draft fails to register E164 and perhaps >> some other parameters. >> >> As I said before, there is not foresee usage of the E164 number >> scheme in both RFC 3108 and SDP CS context. So, RFC 3108 can keep on >> using the mechanism they are currently using. The SDP CS draft will >> register the E164 with IANA with the syntax that may optionally >> include a plus sign. This does not affect current implementations of >> RFC 3108. > > I agree the problem is with 3108. > And I have no problem with the SDP CS draft registering E164 with > numbers starting with '+'. > The problem is we have a Standards Track RFC that already defined that value with a different format. > But I do have a little trouble with this draft registering E164 in a > way that permits numbers without the '+'. The problem with doing this > is defining what it means - how to interpret the number in that case. > Just saying it means "local" without defining what "local" means is > not a good thing. > It could be either International or Local, and I agree there is lack of adequate syntax definition to make a clear distinction between the two based on the RFC 3108 definition. > So, I see two ways forward: > > - only define values consisting of '+' and digits. > Leave anything more to be done later if anyone > cares. > RFC 3108 cares (and it's Standards Track). > - do a complete definition of both global and local > numbers. In that case I would suggest referring to > 'telephone-subscriber' from RFC3966 rather than > trying to start from scratch. > In an ideal world, I'd agree with that, however neither RFC 3108 nor 3GPP will presumably be happy with this. -- Flemming > Either of these work for me, though I would slightly prefer > referencing RFC3966, because it gives a more robust definition. > > Thanks, > Paul > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From fandreas@cisco.com Wed Sep 26 14:08:25 2012 Return-Path: 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 CFD8D21F845D for ; Wed, 26 Sep 2012 14:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 LDKLtz9Ldn+c for ; Wed, 26 Sep 2012 14:08:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1364E21F8459 for ; Wed, 26 Sep 2012 14:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3332; q=dns/txt; s=iport; t=1348693705; x=1349903305; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oc6zExGcXamW04xAwA0QP6NtUPR0pyvSOuCn0ItqtCg=; b=fxgU8Psvd7yJ6b+syDTyqHM/s6LLqQWmNXw6qZaPVbg/AHuMXtpl7ccv pebtSyX8EOW0QXx7Ld9LJCmbc+0H/lqPiieUi5HG5WEhZYYUnLDh+mUwg W/Iav0FHsYKYTroycPMxZFnvEfxIgx77dGSnSXVXUBad+Xrk8P2NWzSGV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANxtY1CtJXG//2dsb2JhbABFvlqBCIIgAQEBAwEBAQEPASUvBwoBBQsLDgoJFg8JAwIBAgEVMAYNAQUCAQEeh10GC5gVoC8EixiGCQOVaY5CgWmDAw X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="125685147" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 26 Sep 2012 21:08:21 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8QL8Kck019168; Wed, 26 Sep 2012 21:08:20 GMT Message-ID: <50636EC4.4010107@cisco.com> Date: Wed, 26 Sep 2012 17:08:20 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Lawrence Conroy References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> In-Reply-To: <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, Paul Kyzivat Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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, 26 Sep 2012 21:08:26 -0000 Hi Lawrence On 9/25/12 5:27 PM, Lawrence Conroy wrote: > Hi Folks, > Me too. Personally, I would STRONGLY prefer that folks pulled the definition from 3966 (whichever of the two choices you make). > > We had similar mantras to chant in ENUM, so I feel for the squirming here. > > See the last para of RFC4415 section 3 for the appropriate syntax references to RFC3966 -- yes, you DO need to refer to that, and I'd suggest normatively. > National/Local numbers are not necessarily the same as dial strings Agreed. > (as Paul has spelt out before, IIRC). I ASSUME that you intend this to be a number rather than any old dial string (with or without the preceding '9', with or without a carrier prefix, with or without a trunk "access" digit, ...). Agreed. > That's why we strongly discouraged anything other than global numbers -- otherwise you're building in yet another "NAT" problem. > > See the text in the 2nd para of the intro to RFC6116 for the "anointed" spec/definition we used for "E.164 number". > BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. IIRC, the '+' comes from 3GPP and from TIA specs. It's defined in ITU-T Recommendation E.123. > Also, you may want to specify that the "punctuation" that E.164 permits is excluded (assuming you don't want dashes, commas, dots or spaces in the middle). I think that's covered by the ABNF. -- Flemming > all the best, > Lawrence > > > On 25 Sep 2012, at 21:45, Paul Kyzivat wrote: >> On 9/25/12 2:19 PM, Miguel Garcia A wrote: >>> Paul: >>> >>> The problem, IMHO, lies in RFC 3108, because it allows both national and international numbering plans without separating the context. >>> >>> With or without the CS draft, RFC 3108 seems to have a problem. In spite of other problems (the draft fails to register E164 and perhaps some other parameters. >>> >>> As I said before, there is not foresee usage of the E164 number scheme in both RFC 3108 and SDP CS context. So, RFC 3108 can keep on using the mechanism they are currently using. The SDP CS draft will register the E164 with IANA with the syntax that may optionally include a plus sign. This does not affect current implementations of RFC 3108. >> I agree the problem is with 3108. >> And I have no problem with the SDP CS draft registering E164 with numbers starting with '+'. >> >> But I do have a little trouble with this draft registering E164 in a way that permits numbers without the '+'. The problem with doing this is defining what it means - how to interpret the number in that case. Just saying it means "local" without defining what "local" means is not a good thing. >> >> So, I see two ways forward: >> >> - only define values consisting of '+' and digits. >> Leave anything more to be done later if anyone >> cares. >> >> - do a complete definition of both global and local >> numbers. In that case I would suggest referring to >> 'telephone-subscriber' from RFC3966 rather than >> trying to start from scratch. >> >> Either of these work for me, though I would slightly prefer referencing RFC3966, because it gives a more robust definition. >> >> Thanks, >> Paul > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From pkyzivat@alum.mit.edu Wed Sep 26 14:14:54 2012 Return-Path: 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 B5E4521F85D5 for ; Wed, 26 Sep 2012 14:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 K1uaGEcHXgxN for ; Wed, 26 Sep 2012 14:14:54 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 2F19121F85C3 for ; Wed, 26 Sep 2012 14:14:54 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta09.westchester.pa.mail.comcast.net with comcast id 3nPW1k0040vyq2s59xExtL; Wed, 26 Sep 2012 21:14:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id 3xAF1k00e3ZTu2S3RxAFtH; Wed, 26 Sep 2012 21:10:15 +0000 Message-ID: <50636F21.8000203@alum.mit.edu> Date: Wed, 26 Sep 2012 17:09:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Flemming Andreasen References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com> <5061E6A6.6070507@alum.mit.edu> <50636B0E.8000000@cisco.com> In-Reply-To: <50636B0E.8000000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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, 26 Sep 2012 21:14:54 -0000 On 9/26/12 4:52 PM, Flemming Andreasen wrote: > > On 9/25/12 1:15 PM, Paul Kyzivat wrote: >> On 9/25/12 12:51 PM, Flemming Andreasen wrote: >>> So it seems we have a way forward here that will work for everybody and >>> allow us to come up with a single E164 IANA registration for both RFC >>> 3108 and SDP-CS, >> >> What is the single way that works for both? > Allow omission of the '+' sign for RFC 3108 compliant implementations > (and possibly restrict that to ATM network type), but use the '+' prefix > everywhere else. > >> I don't see that without an update to 3108. >> >> RFC 3108 doesn't support the '+' and purports to support both global >> and local without it. But you can't really support both global and >> local numbers without *some* non-numeric characters. (Unless you go >> with dial strings, which are themselves not global.) >> > I believe the issue you are bringing up is one that is internal to RFC > 3108, which is how do you distinguish between a private and an > International number in RFC 3108 ? I agree that's not clear, however > that doesn't mean that you should disallow the syntax that has been > defined there for international numbers, and which may be present in a > number of current implementations. If that is your goal, then I think the right answer is to define addrtype E164 within nettype PSTN, and say nothing about addrtype E164 within nettype ATM. Note that 4566 says: New address types ("addrtype") may be registered with IANA. An address type is only meaningful in the context of a network type, and any registration of an address type MUST specify a registered network type or be submitted along with a network type registration. ... So I see no reason for *this* draft to register E164 for nettype ATM. Then it will be up to somebody else to revise 3108 to deal with its issues and register nettype ATM and addrtype E164 within that. Thanks, Paul From fandreas@cisco.com Wed Sep 26 14:24:42 2012 Return-Path: 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 4E3D721F8552 for ; Wed, 26 Sep 2012 14:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 mMk4+BL6sb2B for ; Wed, 26 Sep 2012 14:24:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6827F21F84B2 for ; Wed, 26 Sep 2012 14:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5489; q=dns/txt; s=iport; t=1348694681; x=1349904281; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=l2AHUKZZLXJ/iXeIyGVkM5iBCqoyE8QWh6F1bOd0rLE=; b=DUNPevVoEV/qxKWs4AtrofI5oihCPVRJsHjnV5YKh0o23LAM6o65izkn KD8xspDR1vvk6R6yJ3fvn04Is4/IwiZ4rqL1UZy3kVdcdapKvkZGobj4I M0gqv30hPusBn35WQsYdJZsHAZgX5MjSFXOJ3v/trycnvAr+cZ9zNDXwd U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA9yY1CtJV2b/2dsb2JhbABFDr5MgQiCIAEBAQQBAQEPARQRLwcLEAsOCgkMGQ8CFjAGDQEFAgEBFweHYwuXfY8akRQEixiCXYMsA5VpjkKBaYIsVw X-IronPort-AV: E=Sophos;i="4.80,492,1344211200"; d="scan'208";a="125715694" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 26 Sep 2012 21:24:41 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8QLOeBs026007; Wed, 26 Sep 2012 21:24:40 GMT Message-ID: <50637298.90506@cisco.com> Date: Wed, 26 Sep 2012 17:24:40 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> <50622723.3060909@alum.mit.edu> <506283C5.8050909@alum.mit.edu> In-Reply-To: <506283C5.8050909@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Conroy , mmusic@ietf.org Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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, 26 Sep 2012 21:24:42 -0000 I tend to agree that option 3 is the technically best one, however please note, that part of the challenge we have here is a) RFC 3108 is a Standards Track RFC that has been out for quote a while with a syntax that differs from what you suggest. b) SDP-CS has been used by 3GPP for quite a while with a syntax that differs from RFC 3108 as well as RFC 3966 (to varying degrees per your note below). The original "compromise" proposal was trying to address the above two points. Do you have any thoughts around other solutions that takes that into account ? Thanks -- Flemming On 9/26/12 12:25 AM, Paul Kyzivat wrote: > I think we are in violent agreement. > > Just to be clear, there are various ways to reference 3966 and use > that in SDP CS. The ones that come to my mind are, when the > is E164, require the to be: > > 1) 'global-phone-digits' from 3966, but excluding 'visual-separator' > characters. (This is essentially what is currently specified.) > > 2) 'global-number' from 3966. > > 3) 'telephone-subscriber' from 3966. > > Picking (3) will allow local-numbers with context to understand them. > > I am inclined to recommend (3) because I can see no reason not to. > Quite a lot of thought and discussion went into 3966, so why abandon > or reinvent it? > > Thanks, > Paul > > On 9/25/12 7:03 PM, Lawrence Conroy wrote: >> On 25 Sep 2012, at 22:50, Paul Kyzivat wrote: >>> On 9/25/12 5:27 PM, Lawrence Conroy wrote: >>>> Hi Folks, >>>> Me too. Personally, I would STRONGLY prefer that folks pulled the >>>> definition from 3966 (whichever of the two choices you make). >>>> >>>> We had similar mantras to chant in ENUM, so I feel for the >>>> squirming here. >>>> >>>> See the last para of RFC4415 section 3 for the appropriate syntax >>>> references to RFC3966 -- yes, you DO need to refer to that, and I'd >>>> suggest normatively. >>>> National/Local numbers are not necessarily the same as dial strings >>>> (as Paul has spelt out before, IIRC). I ASSUME that you intend this >>>> to be a number rather than any old dial string (with or without the >>>> preceding '9', with or without a carrier prefix, with or without a >>>> trunk "access" digit, ...). >>>> That's why we strongly discouraged anything other than global >>>> numbers -- otherwise you're building in yet another "NAT" problem. >>>> >>>> See the text in the 2nd para of the intro to RFC6116 for the >>>> "anointed" spec/definition we used for "E.164 number". >>>> BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. >>>> IIRC, the '+' comes from 3GPP and from TIA specs. >>> >>> RFC3108 *could* be valid without the '+' if it only permitted E.164 >>> (global) numbers. But it claims to support both International Format >>> E.164 numbers and private numbering plans. For that it is invalid >>> because there is no way to distinguish between them. The example >>> appears to be a US number without country code. But I don't know how >>> you would know that. It could be a number in Bahrain. (It seems to >>> be an *invalid* number in Bahrain, but unless you had a dialing plan >>> for the entire world I don't know how you would know that.) >>> >>>> Also, you may want to specify that the "punctuation" that E.164 >>>> permits is excluded (assuming you don't want dashes, commas, dots >>>> or spaces in the middle). >>> >>> Or you could just allow it. No great shakes either way. >>> >>> Thanks, >>> Paul >>> >>>> all the best, >>>> Lawrence >> >> >> To which I reply: >> >> Hi Paul, folks, >> >> Re. 3108 is psychic -- good point, well made. >> We're wildly agreeing here. >> >> All I was saying was that it's not the '+' that makes an E.164 number >> ->in International Format<- >> (E.164 mentions International *and* National numbers [insofar as the >> ITU ever deals with national systems] -- it mentions Nationally >> Significant Numbers) >> >> Trying to deal with both International and National/Local numbers is >> **really** hard, and impossible without context. >> The same discussions came up during development of 3966 -- that's why >> there's a phone-context parameter for tel:, with a >> ["right-truncated"] International E.164 number [as an alternative to >> a domainname]). >> >> As Paul sure knows, this has been done before. 3966 has extensive >> discussion on exactly the concerns Paul has rightly raised (and it's >> quite readable :). >> >> 3108 seems to have some secret unknown to the rest of us => ignore >> the magicians -- these two usages will never coexist without a >> reassuringly expensive gateway between these universes. That gateway >> will have to deal with context (although I don't want to answer the >> gateway RFI). >> >> => just nail down the meaning of E.164 number ("...in international >> format...", preceded by a '+' character), refer normatively to 3966's >> syntax, and we're done. >> Anything more is thrashing over the same ground yet again. >> >> atb, Lawrence >> p.s. intra-number punctuation should be simple, but (in particular, >> spaces) has bitten implementations more than once. I recommend >> applying cattle-prods to the programmers if they forget. >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From fandreas@cisco.com Wed Sep 26 14:38:49 2012 Return-Path: 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 46C8621F850C for ; Wed, 26 Sep 2012 14:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 kaB3Tdfvsgs7 for ; Wed, 26 Sep 2012 14:38:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF2E21F850B for ; Wed, 26 Sep 2012 14:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2831; q=dns/txt; s=iport; t=1348695528; x=1349905128; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zUA0wAF7Y1BOWpxP+lUwPyVfigEG8AiWQbyDLY6uMho=; b=jfOhzmXQ2CIjsP/RoroNyzNH7T40q/DceQvTnhCvyDoWnyAgWKHDASEJ lN4TxW5q7xfdDq9/+bwMriFOL6pV9PMkQQRcnDGrtFf1AWo+nwqV55cF1 PPm0wb1dIjzVmWrKE4xNh70C5KBBCbuDTWNANMOfji8+8c3ATI/Pqv4V2 E=; X-IronPort-AV: E=Sophos;i="4.80,492,1344211200"; d="scan'208";a="125719368" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 26 Sep 2012 21:38:48 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8QLclie020530; Wed, 26 Sep 2012 21:38:47 GMT Message-ID: <506375E7.3060406@cisco.com> Date: Wed, 26 Sep 2012 17:38:47 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com> <5061E6A6.6070507@alum.mit.edu> <50636B0E.8000000@cisco.com> <50636F21.8000203@alum.mit.edu> In-Reply-To: <50636F21.8000203@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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, 26 Sep 2012 21:38:49 -0000 On 9/26/12 5:09 PM, Paul Kyzivat wrote: > On 9/26/12 4:52 PM, Flemming Andreasen wrote: >> >> On 9/25/12 1:15 PM, Paul Kyzivat wrote: >>> On 9/25/12 12:51 PM, Flemming Andreasen wrote: >>>> So it seems we have a way forward here that will work for everybody >>>> and >>>> allow us to come up with a single E164 IANA registration for both RFC >>>> 3108 and SDP-CS, >>> >>> What is the single way that works for both? >> Allow omission of the '+' sign for RFC 3108 compliant implementations >> (and possibly restrict that to ATM network type), but use the '+' prefix >> everywhere else. >> >>> I don't see that without an update to 3108. >>> >>> RFC 3108 doesn't support the '+' and purports to support both global >>> and local without it. But you can't really support both global and >>> local numbers without *some* non-numeric characters. (Unless you go >>> with dial strings, which are themselves not global.) >>> >> I believe the issue you are bringing up is one that is internal to RFC >> 3108, which is how do you distinguish between a private and an >> International number in RFC 3108 ? I agree that's not clear, however >> that doesn't mean that you should disallow the syntax that has been >> defined there for international numbers, and which may be present in a >> number of current implementations. > > If that is your goal, then I think the right answer is to define > addrtype E164 within nettype PSTN, and say nothing about addrtype E164 > within nettype ATM. Note that 4566 says: > > New address types ("addrtype") may be registered with IANA. An > address type is only meaningful in the context of a network type, and > any registration of an address type MUST specify a registered network > type or be submitted along with a network type registration. ... > > So I see no reason for *this* draft to register E164 for nettype ATM. > Ahh - I had indeed missed that, and it appears the IANA registry is not structured this way either (addrtype registration is not associated with a network type). We should get that fixed as part of this. I'll also suggest that for RFC4566bis, we should update the IANA registration procedure to make that clear (MUST always specify a combination of network type and addrtype when registering a new addrtype). With that important clarification in mind, I have no issue with registering "PSTN E164" and always requiring a "+" sign (and we can then discuss separately to what extent we want to conform with RFC 3966 syntax, or just keep the current simple "1*15DIGIT" syntax. > Then it will be up to somebody else to revise 3108 to deal with its > issues and register nettype ATM and addrtype E164 within that. > Sounds good. Thanks Paul -- Flemming > Thanks, > Paul > > > . > From miguel.a.garcia@ericsson.com Wed Sep 26 22:32:09 2012 Return-Path: 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 D710421F853B for ; Wed, 26 Sep 2012 22:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 aPu-9RGfMJWq for ; Wed, 26 Sep 2012 22:32:09 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB2221F8539 for ; Wed, 26 Sep 2012 22:32:08 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-c0-5063e4d6b58c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A1.D0.25676.6D4E3605; Thu, 27 Sep 2012 07:32:06 +0200 (CEST) Received: from [159.107.24.190] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Thu, 27 Sep 2012 07:32:06 +0200 Message-ID: <5063E4D4.3040903@ericsson.com> Date: Thu, 27 Sep 2012 07:32:04 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <5062AF39.4000804@ericsson.com> <506315D7.9020505@alum.mit.edu> In-Reply-To: <506315D7.9020505@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvre61J8kBBv3r9C3eX9C1mLr8MYvF ig0HWB2YPf6+/8DkMeX3RlaPJUt+MgUwR3HZpKTmZJalFunbJXBlPG/8xVqw2aBi19NLbA2M 01S7GDk5JARMJNZ/XssKYYtJXLi3nq2LkYtDSOAUo8SirZOYIJw1jBKt6yczglTxCmhL7P75 G8xmEVCVOHu3gQXEZhMwl2jduJEdxBYVCJY4t3EbG0S9oMTJmU+Aajg4RAQ0JCZtVQMJMwOV vH98nxUkLCxgK3H8SB3EqntMEm/f7WYGqeEU0JG48PwbG0S9rcSFOddZIGx5ie1v54DVCAlo Sky+uZR5AqPgLCTbZiFpmYWkZQEj8ypG4dzEzJz0ciO91KLM5OLi/Dy94tRNjMDgPbjlt+oO xjvnRA4xSnOwKInzWm/d4y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsetHxtu3Z25W5jUx bT4213jh1v+mL5PmMsrKX16xWvLrRs8/j99sO9g01aC2Rs/89xxvDSPlzVur7Ji0N4lf1e5g rFzxvbQnLU9KqOhQ0cTM9rqG/88kvO2L/IR2fm537d/9wnbZ6SM3d4py9LYbdc+dF3gkZ5XA OsPFCqx/vlybdTfa5I1GqRJLcUaioRZzUXEiANwL7AssAgAA Cc: Flemming Andreasen , "mmusic@ietf.org" Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Thu, 27 Sep 2012 05:32:10 -0000 Hi Paul, thanks for your comments, inline answers. On 26/09/2012 16:48, Paul Kyzivat wrote: > On 9/26/12 3:31 AM, Miguel A. Garcia wrote: >> Hi Paul: >> >> see inline comments. >> >> On 25/09/2012 22:45, Paul Kyzivat wrote: >>> On 9/25/12 2:19 PM, Miguel Garcia A wrote: >>>> Paul: >>>> >>>> The problem, IMHO, lies in RFC 3108, because it allows both national >>>> and international numbering plans without separating the context. >>>> >>>> With or without the CS draft, RFC 3108 seems to have a problem. In >>>> spite of other problems (the draft fails to register E164 and perhaps >>>> some other parameters. >>>> >>>> As I said before, there is not foresee usage of the E164 number >>>> scheme in both RFC 3108 and SDP CS context. So, RFC 3108 can keep on >>>> using the mechanism they are currently using. The SDP CS draft will >>>> register the E164 with IANA with the syntax that may optionally >>>> include a plus sign. This does not affect current implementations of >>>> RFC 3108. >>> >>> I agree the problem is with 3108. >>> And I have no problem with the SDP CS draft registering E164 with >>> numbers starting with '+'. >>> >>> But I do have a little trouble with this draft registering E164 in a way >>> that permits numbers without the '+'. The problem with doing this is >>> defining what it means - how to interpret the number in that case. Just >>> saying it means "local" without defining what "local" means is not a >>> good thing. >> >> Notice that "local without defining local" is what is currently in RFC >> 3108. > > Yes, I know. :-( > >> My proposal is to register E164 allowing international and >> non-international. > > You mean those starting with '+' and those that don't right? Exactly > And those that don't are then really have "undefined" semantics, right? Exactly. We can say that documents using the local format should indicate how to get the phone context. > >> The non-international could be used in local >> environments where there is no change of boundaries. This is like saying >> that, where both endpoints have agreed on the national boundary, the >> local representation could be used. This is what RFC 3108 tries to say. > > I don't understand *what* 3108 is *trying* to say. That makes two of us :-) > But what it *does* say is ambiguous. And if you try to rationalize it > with what you are proposing to register, then all the numbers used in > 3108 will be "local" numbers by the definition you register. Yes. But whatever we do is not going to affect existing implementations of RFC 3108. > >>> So, I see two ways forward: >>> >>> - only define values consisting of '+' and digits. >>> Leave anything more to be done later if anyone >>> cares. >> >> This is what the current version of the draft says, and I will be happy >> to accept it. But I understood Flemming had a problem. > > Maybe Flemming will weigh in again. > >>> - do a complete definition of both global and local >>> numbers. In that case I would suggest referring to >>> 'telephone-subscriber' from RFC3966 rather than >>> trying to start from scratch. >> >> We looked at it way back in time, and I believe the problem was >> understanding the a local number with a ";phone-context=foo" will be >> accepted as a valid parameter for an address in a c= line in SDP. It >> looks a bit strange, mostly by the presence of the semicolon. > > It may look a bit strange, but SDP allows a lot of strange things. > > If you look at 4566, *none* of the forms being discussed are consistent > with the existing ABNF (for , which currently must be > either a or regardless of > or . Right, that is RFC 4566. The CS SDP draft extends 4566 by adding an e164-address. This is specified in the ABNF: connection-address /= e164-address / "-" e164-address = "+" 1*15DIGIT ; DIGIT is specified in RFC 5234 > > It is unfortunate that 4566 made provision for registering new > and values, and even stated that RFCs registering new > s must give details of the syntax of the address. But it > doesn't say if the syntax can be incompatible with or > can only specify subsets of that. Probably the most important part of > the c= syntax is that nettype, addrtype, and connection-field are > separated by SP, and so perhaps by inference cannot contain SP. Yeap, that makes sense. > > As far as I can tell, all of is compatible (or > not) with 4566 as 15 digits are. Ok... so your proposal would be that the CS draft defines connection-address like this: connection-address /= telephone-subscriber / "-" ; telephone-susbscriber defined in ; RFC 3966 If we are using the international format, this does not change anything with respect to the existing CS draft. If we are using the national format, a ";phone-context" is required I believe this works for the CS draft. But I don't know how RFC 3108 stays now. Do we have other views? > >> Then, the telephone number in 3966 allows the representation of >> something more than digits, namely "#" and "*", which are not valid >> digits in E.164 numbers. > > While it allows them some places, it doesn't allow them in > , which is where E.164 numbers fall. Oops, I didn't realize about this subtle detail. Yes, a closer look at the syntax revealed what you said. So, then I can go with the proposal of the CS draft referring to RFC 3966. /Miguel > > Thanks, > Paul > >> So, we concluded that RFC 3966 was a good inspiration but not really >> what we are looking for. >> >> BR, >> >> Miguel >>> >>> Either of these work for me, though I would slightly prefer referencing >>> RFC3966, because it gives a more robust definition. >>> >>> Thanks, >>> Paul >>> >>> >> > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Sep 26 22:45:42 2012 Return-Path: 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 D513321F8618 for ; Wed, 26 Sep 2012 22:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 K4b-1SASLK45 for ; Wed, 26 Sep 2012 22:45:42 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5F721F8616 for ; Wed, 26 Sep 2012 22:45:41 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-8f-5063e8040a90 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 29.02.25676.408E3605; Thu, 27 Sep 2012 07:45:40 +0200 (CEST) Received: from [159.107.24.190] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.1; Thu, 27 Sep 2012 07:45:39 +0200 Message-ID: <5063E801.4080402@ericsson.com> Date: Thu, 27 Sep 2012 07:45:37 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> <50622723.3060909@alum.mit.edu> <506283C5.8050909@alum.mit.edu> In-Reply-To: <506283C5.8050909@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+JvrS7Li+QAgzs3+S1mvelhtpi6/DGL xYoNB1gdmD3+vv/A5LFkyU8mj+PTNrIHMEdx2aSk5mSWpRbp2yVwZRw8dJqpYKN6Rf+W84wN jJvkuxg5OCQETCSmPCrsYuQEMsUkLtxbz9bFyMUhJHCKUaJhRT8ThLOGUeLP6mesIFW8AtoS D4+1MIPYLAKqEg0HX7CB2GwC5hKtGzeyg9iiAsES5zZuY4OoF5Q4OfMJC8gyEQENiUlb1UDC zAKhEt9/P2QFCQsL2EocP1IHseoss8SX55PAxnAK6Ehc7DzABFFvK3FhznUWCFteYvvbOWAn CAloSky+uZR5AqPgLCTbZiFpmYWkZQEj8ypG4dzEzJz0ciO91KLM5OLi/Dy94tRNjMDgPbjl t+oOxjvnRA4xSnOwKInzWm/d4y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsTLmkXyOSvS5 v8zL3XWn/go6cbFh8bOPmpaXepf6OjYvDny6aI7Hpe1R+2pLrz6aKKEdKZblcXA+o7T0iq9K TBcWlL+ue3F1dcfm44x7jGyiDOUP/b/6I3XhzH7+LEPGLYbrX3+/mzL1BHPBHM3F0fm7jd99 /ReQFtIWy1Z79PyyD/935IWI9CmxFGckGmoxFxUnAgB6AAaHLAIAAA== Cc: Lawrence Conroy , "mmusic@ietf.org" Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Thu, 27 Sep 2012 05:45:43 -0000 As an author of the document, I can accept option 3 below. This means that the connection-address will be specified in the CS draft as: connection-address /= telephone-subscriber / "-" ; telephone-susbscriber defined in ; RFC 3966 /Miguel On 26/09/2012 6:25, Paul Kyzivat wrote: > I think we are in violent agreement. > > Just to be clear, there are various ways to reference 3966 and use that > in SDP CS. The ones that come to my mind are, when the is > E164, require the to be: > > 1) 'global-phone-digits' from 3966, but excluding 'visual-separator' > characters. (This is essentially what is currently specified.) > > 2) 'global-number' from 3966. > > 3) 'telephone-subscriber' from 3966. > > Picking (3) will allow local-numbers with context to understand them. > > I am inclined to recommend (3) because I can see no reason not to. Quite > a lot of thought and discussion went into 3966, so why abandon or > reinvent it? > > Thanks, > Paul > > On 9/25/12 7:03 PM, Lawrence Conroy wrote: >> On 25 Sep 2012, at 22:50, Paul Kyzivat wrote: >>> On 9/25/12 5:27 PM, Lawrence Conroy wrote: >>>> Hi Folks, >>>> Me too. Personally, I would STRONGLY prefer that folks pulled the definition from 3966 (whichever of the two choices you make). >>>> >>>> We had similar mantras to chant in ENUM, so I feel for the squirming here. >>>> >>>> See the last para of RFC4415 section 3 for the appropriate syntax references to RFC3966 -- yes, you DO need to refer to that, and I'd suggest normatively. >>>> National/Local numbers are not necessarily the same as dial strings (as Paul has spelt out before, IIRC). I ASSUME that you intend this to be a number rather than any old dial string (with or without the preceding '9', with or without a carrier prefix, with or without a trunk "access" digit, ...). >>>> That's why we strongly discouraged anything other than global numbers -- otherwise you're building in yet another "NAT" problem. >>>> >>>> See the text in the 2nd para of the intro to RFC6116 for the "anointed" spec/definition we used for "E.164 number". >>>> BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. IIRC, the '+' comes from 3GPP and from TIA specs. >>> >>> RFC3108 *could* be valid without the '+' if it only permitted E.164 (global) numbers. But it claims to support both International Format E.164 numbers and private numbering plans. For that it is invalid because there is no way to distinguish between them. The example appears to be a US number without country code. But I don't know how you would know that. It could be a number in Bahrain. (It seems to be an *invalid* number in Bahrain, but unless you had a dialing plan for the entire world I don't know how you would know that.) >>> >>>> Also, you may want to specify that the "punctuation" that E.164 permits is excluded (assuming you don't want dashes, commas, dots or spaces in the middle). >>> >>> Or you could just allow it. No great shakes either way. >>> >>> Thanks, >>> Paul >>> >>>> all the best, >>>> Lawrence >> >> >> To which I reply: >> >> Hi Paul, folks, >> >> Re. 3108 is psychic -- good point, well made. >> We're wildly agreeing here. >> >> All I was saying was that it's not the '+' that makes an E.164 number ->in International Format<- >> (E.164 mentions International *and* National numbers [insofar as the ITU ever deals with national systems] -- it mentions Nationally Significant Numbers) >> >> Trying to deal with both International and National/Local numbers is **really** hard, and impossible without context. >> The same discussions came up during development of 3966 -- that's why there's a phone-context parameter for tel:, with a ["right-truncated"] International E.164 number [as an alternative to a domainname]). >> >> As Paul sure knows, this has been done before. 3966 has extensive discussion on exactly the concerns Paul has rightly raised (and it's quite readable :). >> >> 3108 seems to have some secret unknown to the rest of us => ignore the magicians -- these two usages will never coexist without a reassuringly expensive gateway between these universes. That gateway will have to deal with context (although I don't want to answer the gateway RFI). >> >> => just nail down the meaning of E.164 number ("...in international format...", preceded by a '+' character), refer normatively to 3966's syntax, and we're done. >> Anything more is thrashing over the same ground yet again. >> >> atb, Lawrence >> p.s. intra-number punctuation should be simple, but (in particular, spaces) has bitten implementations more than once. I recommend applying cattle-prods to the programmers if they forget. >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From Simo.Veikkolainen@nokia.com Thu Sep 27 01:17:24 2012 Return-Path: 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 107D621F86EC for ; Thu, 27 Sep 2012 01:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UdhR16ETsoPM for ; Thu, 27 Sep 2012 01:17:23 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id A066B21F86E5 for ; Thu, 27 Sep 2012 01:17:22 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8R8H9NC004959; Thu, 27 Sep 2012 11:17:13 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Sep 2012 11:17:09 +0300 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.74]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0309.003; Thu, 27 Sep 2012 10:17:08 +0200 From: To: , Thread-Topic: [MMUSIC] Issue with E164 numbers in SDP CS draft Thread-Index: AQHNmz4OIW/vMmta1kqpjI88gkc0bJebKqgAgAAR0wCAACjvAIAAC5yAgAAGgoCAABR4AIAAWfaAgAGoqoCAAEopIA== Date: Thu, 27 Sep 2012 08:17:08 +0000 Message-ID: References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> <50622723.3060909@alum.mit.edu> <506283C5.8050909@alum.mit.edu> <5063E801.4080402@ericsson.com> In-Reply-To: <5063E801.4080402@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ihsyw/ilCF/14IJX6Cl+hyVRnV0XJS/1KN9U3WhwFU/LLWfRILeVVjn5azLf7X6B+9Pmx1q6gKtZzOVK9bX64cVdpztXQgdRZ9Twc43Xuquy4Lq7eHuji9TaxLnygbCcDqshBwuHCIdIhFktjJQgB89uYy5fmXfCsZjtyklcVcE9oHnuyEPWguwHykDY+kw0PvTJAH7kpBGxXIHgBBbLSynQTsB0G0o+7pFLFNDgyzj7QjowAFsPLR2vWRr2tto5Og== x-originating-ip: [84.231.252.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2012 08:17:10.0022 (UTC) FILETIME=[7D982260:01CD9C88] X-Nokia-AV: Clean Cc: lconroy@insensate.co.uk, mmusic@ietf.org Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Thu, 27 Sep 2012 08:17:24 -0000 See [SV] below. -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext Miguel A. Garcia Sent: 27. syyskuuta 2012 8:46 To: Paul Kyzivat Cc: Lawrence Conroy; mmusic@ietf.org Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft As an author of the document, I can accept option 3 below. This means that the connection-address will be specified in the CS draft as= : connection-address /=3D telephone-subscriber / "-" ; telephone-susbscriber defined in ; RFC 3966 /Miguel [SV] So would this work: - we define the connection-address in SDP CS draft as per Miguel's suggesti= on above - we register the E.164 addrtype with IANA in the SDP CS draft; it will be = in the context of PSTN nettype so it doesn't clash with whatever is specifi= ed (or left unspecified) in RFC3108 - we add text to SDP CS draft that implementations MUST use global-number o= f RFC3966 if a global representation is available; otherwise a local-number= may be used=20 Simo On 26/09/2012 6:25, Paul Kyzivat wrote: > I think we are in violent agreement. > > Just to be clear, there are various ways to reference 3966 and use=20 > that in SDP CS. The ones that come to my mind are, when the =20 > is E164, require the to be: > > 1) 'global-phone-digits' from 3966, but excluding 'visual-separator' > characters. (This is essentially what is currently specified.) > > 2) 'global-number' from 3966. > > 3) 'telephone-subscriber' from 3966. > > Picking (3) will allow local-numbers with context to understand them. > > I am inclined to recommend (3) because I can see no reason not to.=20 > Quite a lot of thought and discussion went into 3966, so why abandon=20 > or reinvent it? > > Thanks, > Paul > > On 9/25/12 7:03 PM, Lawrence Conroy wrote: >> On 25 Sep 2012, at 22:50, Paul Kyzivat wrote: >>> On 9/25/12 5:27 PM, Lawrence Conroy wrote: >>>> Hi Folks, >>>> Me too. Personally, I would STRONGLY prefer that folks pulled the d= efinition from 3966 (whichever of the two choices you make). >>>> >>>> We had similar mantras to chant in ENUM, so I feel for the squirming h= ere. >>>> >>>> See the last para of RFC4415 section 3 for the appropriate syntax refe= rences to RFC3966 -- yes, you DO need to refer to that, and I'd suggest nor= matively. >>>> National/Local numbers are not necessarily the same as dial strings (a= s Paul has spelt out before, IIRC). I ASSUME that you intend this to be a n= umber rather than any old dial string (with or without the preceding '9', w= ith or without a carrier prefix, with or without a trunk "access" digit, ..= .). >>>> That's why we strongly discouraged anything other than global numbers = -- otherwise you're building in yet another "NAT" problem. >>>> >>>> See the text in the 2nd para of the intro to RFC6116 for the "anointed= " spec/definition we used for "E.164 number". >>>> BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. IIR= C, the '+' comes from 3GPP and from TIA specs. >>> >>> RFC3108 *could* be valid without the '+' if it only permitted E.164=20 >>> (global) numbers. But it claims to support both International Format=20 >>> E.164 numbers and private numbering plans. For that it is invalid=20 >>> because there is no way to distinguish between them. The example=20 >>> appears to be a US number without country code. But I don't know how=20 >>> you would know that. It could be a number in Bahrain. (It seems to=20 >>> be an *invalid* number in Bahrain, but unless you had a dialing plan=20 >>> for the entire world I don't know how you would know that.) >>> >>>> Also, you may want to specify that the "punctuation" that E.164 permit= s is excluded (assuming you don't want dashes, commas, dots or spaces in th= e middle). >>> >>> Or you could just allow it. No great shakes either way. >>> >>> Thanks, >>> Paul >>> >>>> all the best, >>>> Lawrence >> >> >> To which I reply: >> >> Hi Paul, folks, >> >> Re. 3108 is psychic -- good point, well made. >> We're wildly agreeing here. >> >> All I was saying was that it's not the '+' that makes an E.164 number=20 >> ->in International Format<- >> (E.164 mentions International *and* National numbers [insofar as the=20 >> ITU ever deals with national systems] -- it mentions Nationally=20 >> Significant Numbers) >> >> Trying to deal with both International and National/Local numbers is **r= eally** hard, and impossible without context. >> The same discussions came up during development of 3966 -- that's why th= ere's a phone-context parameter for tel:, with a ["right-truncated"] Intern= ational E.164 number [as an alternative to a domainname]). >> >> As Paul sure knows, this has been done before. 3966 has extensive discus= sion on exactly the concerns Paul has rightly raised (and it's quite readab= le :). >> >> 3108 seems to have some secret unknown to the rest of us =3D> ignore the= magicians -- these two usages will never coexist without a reassuringly ex= pensive gateway between these universes. That gateway will have to deal wit= h context (although I don't want to answer the gateway RFI). >> >> =3D> just nail down the meaning of E.164 number ("...in international fo= rmat...", preceded by a '+' character), refer normatively to 3966's syntax,= and we're done. >> Anything more is thrashing over the same ground yet again. >> >> atb, Lawrence >> p.s. intra-number punctuation should be simple, but (in particular, spac= es) has bitten implementations more than once. I recommend applying cattle-= prods to the programmers if they forget. >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From miguel.a.garcia@ericsson.com Thu Sep 27 06:16:30 2012 Return-Path: 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 C9F7721F851C for ; Thu, 27 Sep 2012 06:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.24 X-Spam-Level: X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 zFI4KeWmlijY for ; Thu, 27 Sep 2012 06:16:30 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADCE21F851A for ; Thu, 27 Sep 2012 06:16:29 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-6c-506451acef13 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DF.9C.17130.CA154605; Thu, 27 Sep 2012 15:16:28 +0200 (CEST) Received: from [159.107.24.190] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.1; Thu, 27 Sep 2012 15:16:26 +0200 Message-ID: <506451A8.5060207@ericsson.com> Date: Thu, 27 Sep 2012 15:16:24 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic References: <505972DD.3060908@ericsson.com> In-Reply-To: <505972DD.3060908@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvre6awJQAgyc/NS3eX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbH46lfWgnaFilvzF7M3MJ6U7GLk5JAQMJHo WXuEHcIWk7hwbz1bFyMXh5DAKUaJv59+QDlrGCW2z5vOBFLFK6At0XXwDAuIzSKgKtG2uwfM ZhMwl2jduBFskqhAsMS5jdvYIOoFJU7OfAJWIyIgI7F302ZmEJtZIFTi9tHpYLawgK/E1rmH WUFsIaD5Tz+vBbM5BXQk+j5OY4Sot5W4MOc6C4QtL7H97RxmiHpNick3lzJPYBSchWTdLCQt s5C0LGBkXsUonJuYmZNebq6XWpSZXFycn6dXnLqJERiqB7f8NtjBuOm+2CFGaQ4WJXFePdX9 /kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYpwceudz8Z4HE1SKJnzlJEw6uKq1U8WmeIZHw hFNo3uT+0odXnff/uyB4ud1P+s096UuHhNVbCyP/BzF/ygtckst62kHcSNWo3EVBJKj/msBO 7XtrZ//+tq1/H4vCGe72YO0Al+dM/cKP/11xZZQ8eIDDZOKyxb1x8msmpbXOT7TmNL5x8r6i EktxRqKhFnNRcSIAYU/WiyMCAAA= Cc: Flemming Andreasen , Ari Keranen Subject: Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections X-BeenThere: mmusic@ietf.org 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: Thu, 27 Sep 2012 13:16:30 -0000 Let me try to conclude this poll. We have seen a significant amount of people leaning towards option b. I reproduce hereby the selected option: b) Create a revision of ICE (obsoleting RFC 5245), but only addressing bug fixing and opening hooks to extensions, with the idea that extensions won't need to violate 5245bis. Additionally, document each extension in a separate RFC. Extensions will depend and refer to the 5245bis draft. Then there were some comments indicating that we can go one step further and make ICE independent of the SDP Offer/answer, and document the SDP offer/answer for ICE in a different document. So, we should work with the assumption that there will be a kind of ICE framework, and the usages and extensions to it, of which, the SDP O/A usage will be one. To do this work, the chairs have been looking for a volunteer who has enough spare cycles and expertise to drive this work. We have recruited Ari Keranen to edit ICE-bis according to what we just described. Let's welcome Ari on board and thank him for committing to this effort. Due to other Ari's commitments and the current schedule, we expect the first version of 5245bis to be available after the IETF meeting in Atlanta. /Miguel On 19/09/2012 9:23, Miguel A. Garcia wrote: > Hi all, > > This mail relates to ICE [RFC 5245]. > > In the past few months, we have seen a number of documents that are > trying to improve the usage of ICE in different ways. The list of > documents include at least the following drafts: > > - draft-keranen-mmusic-ice-address-selection-01 > - draft-petithuguenin-mmusic-ice-attributes-level-03 > - draft-wing-mmusic-ice-mobility-01 > - draft-elwell-mmusic-ice-updated-offer-02 > > There is, in addition, a long discussion in the RTCWEB mailing list > about "trickle ICE", and a couple of other ICE-related drafts > and discussions in RTCWEB. > > Most likely, we can categorize these documents in two big classes: > > a) Documents that identify underspecified areas or errors in the spec, > which are often driven by implementation experience > > b) Documents that update or extend ICE with new functionality, such as > "tricke ICE" (see e.g. the e-mail thread at > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html) . > Such documents may involve normative updates to the ICE specification or > they may simply be ICE extensions.". > > Assuming that we would get consensus to adopt some or all of these > documents as work to proceed on, the MMUSIC chairs and RAI ADs would > like to get some sense of how should we aim at documenting it. Below > are some options, please comment on them or add alternatives. > > a) Create a revision of ICE (i.e., a document what will obsolete RFC > 5245), including all the extensions and corrections that > we want to choose from the list. This sounds like a big effort in > time, and presumably will create a big spec. We should make sure that > people have enough cycles to devote to this activity. > > b) Create a revision of ICE (obsoleting RFC 5245), but only addressing > bug fixing and opening hooks to extensions, with the idea that > extensions won't need to violate 5245bis. Additionally, document each > extension in a separate RFC. Extensions will depend and refer to the > 5245bis draft. > > c) Leave the current ICE core spec as is. Document each extension > separately (referring to 5245). Create open or more documents listing > bug fixes and corrections (will also update RFC 5245). > > Needless to say, at this point in time, there is no decision as for > which of the ICE-related drafts will proceed or not. We are just > trying to get consensus of how to document ICE-related drafts, and in > particular if the WG believes we should do a revision of RFC 5245. If so, > we also need to hear who is willing to work on such a revision. > > Now, it is your time to express your opinion. > > Kindly regards, > > Flemming and Miguel. > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Thu Sep 27 06:23:50 2012 Return-Path: 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 126CA21F853E for ; Thu, 27 Sep 2012 06:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.24 X-Spam-Level: X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 NMnfJyjFtJRc for ; Thu, 27 Sep 2012 06:23:49 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1B35D21F8526 for ; Thu, 27 Sep 2012 06:23:48 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-51-50645363764e Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E9.E1.25676.36354605; Thu, 27 Sep 2012 15:23:47 +0200 (CEST) Received: from [159.107.24.190] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.1; Thu, 27 Sep 2012 15:23:47 +0200 Message-ID: <50645362.60100@ericsson.com> Date: Thu, 27 Sep 2012 15:23:46 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Simo.Veikkolainen@nokia.com" References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> <50622723.3060909@alum.mit.edu> <506283C5.8050909@alum.mit.edu> <5063E801.4080402@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+JvrW5ycEqAweb3Chaz3vQwW0xd/pjF YsWGA6wW5z7dZXFg8fj7/gOTx5IlP5k8jk/byO5x99YlpgCWKC6blNSczLLUIn27BK6MhiMz GAuWc1U0/zrC3sB4l72LkYNDQsBE4sENiS5GTiBTTOLCvfVsXYxcHEICpxglpv5ZzAjhrGGU 6D25kxWkgVdAU2LzrHoQk0VAVWL/5ByQXjYBc4nWjRvZQWxRgWCJcxu3sYHYvAKCEidnPmEB sUUE7CUe3N8LNpJZYBKjxLx5e5lA5ggL2EocP1IHsWoni8TaXX/AGjgFIiQu7dkBNpQZqObC nOssELa8xPa3c5hBbCGgcybfXMo8gVFwFpJ9s5C0zELSsoCReRWjcG5iZk56uZFealFmcnFx fp5eceomRmBAH9zyW3UH451zIocYpTlYlMR5rbfu8RcSSE8sSc1OTS1ILYovKs1JLT7EyMTB KdXAqCTovmT37X2f2tf5CLRV60TuNJgR5jQjsGUuz8KoG1dnJy92WnJ/z+pyC7fp8c136499 v60RVdnnMDvh1vsaphfXJ3bt5XzQG7Ve4Ul2/7pdyz73s1w8VBUQmi3l5C5afGrHQ8OUdQVH Dr5i3X5M3H/lvd2NGZfvT9jnZG3e+fzhqtU7Xq/341ZiKc5INNRiLipOBAAFTRgUNgIAAA== Cc: "lconroy@insensate.co.uk" , "mmusic@ietf.org" , "pkyzivat@alum.mit.edu" Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Thu, 27 Sep 2012 13:23:50 -0000 On 27/09/2012 10:17, Simo.Veikkolainen@nokia.com wrote: > See [SV] below. > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Miguel A. Garcia > Sent: 27. syyskuuta 2012 8:46 > To: Paul Kyzivat > Cc: Lawrence Conroy; mmusic@ietf.org > Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft > > As an author of the document, I can accept option 3 below. > > This means that the connection-address will be specified in the CS draft as: > > connection-address /= telephone-subscriber / "-" > ; telephone-susbscriber defined in > ; RFC 3966 > > > /Miguel > > [SV] So would this work: > - we define the connection-address in SDP CS draft as per Miguel's suggestion above > - we register the E.164 addrtype with IANA in the SDP CS draft; it will be in the context of PSTN nettype so it doesn't clash with whatever is specified (or left unspecified) in RFC3108 > - we add text to SDP CS draft that implementations MUST use global-number of RFC3966 if a global representation is available; otherwise a local-number may be used > > Simo > > Yes, that is the current proposal. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From keith.drage@alcatel-lucent.com Thu Sep 27 06:45:08 2012 Return-Path: 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 6A5E121F850C for ; Thu, 27 Sep 2012 06:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 UD6awvwDNTPv for ; Thu, 27 Sep 2012 06:45:07 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 019EF21F8518 for ; Thu, 27 Sep 2012 06:45:06 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8RDikwV013427 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Sep 2012 15:44:55 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 27 Sep 2012 15:44:48 +0200 From: "DRAGE, Keith (Keith)" To: "Simo.Veikkolainen@nokia.com" , "Miguel.A.Garcia@ericsson.com" , "pkyzivat@alum.mit.edu" Date: Thu, 27 Sep 2012 15:44:47 +0200 Thread-Topic: [MMUSIC] Issue with E164 numbers in SDP CS draft Thread-Index: AQHNmz4OIW/vMmta1kqpjI88gkc0bJebKqgAgAAR0wCAACjvAIAAC5yAgAAGgoCAABR4AIAAWfaAgAGoqoCAAEopIIAAWEgg Message-ID: References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> <50622723.3060909@alum.mit.edu> <506283C5.8050909@alum.mit.edu> <5063E801.4080402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US 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.84 Cc: "lconroy@insensate.co.uk" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Thu, 27 Sep 2012 13:45:08 -0000 To add a few thoughts to the debate: RFC 3108 seems to define a general structure for the c=3D line c=3D
But then every sentence beyond that seems to give requirements that only ap= ply with the is ATM. So at least to me, where the is PSTN, no additional constrain= ts apply directly from RFC 3108 unless we say exactly how they do so. Moreo= ver, we can ignore RFC 3108 beyond the general structure if we wish to do s= o. I would support a structure that is always + followed by digits.=20 I would note that E.164 does not include additional characters. That is int= roduced (like the "+") by E.123 which is there for the textual representati= on of E.164 numbers. Further that does not use "-" within numbers which is = an americanism. I do not particularly like the idea of adding such additional characters to= the number (beyond the +) - I would prefer to see a straight digit string,= which would be the the characters extracted from, or entered into, the rel= ated PSTN signaling, which does not include such characters. So a specification that merely says "+" followed by digits as represented b= y the international telecommunication number as defined in E.164 would be s= ufficient for me. If we follow RFC 3966, then it would have to be limited to global numbers. = RFC 3966 is then inconsistent, because the text says it follows the rules o= f E.164, and then the ABNF defines visual separators, which are not defined= in E.164. Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Simo.Veikkolainen@nokia.com > Sent: 27 September 2012 09:17 > To: Miguel.A.Garcia@ericsson.com; pkyzivat@alum.mit.edu > Cc: lconroy@insensate.co.uk; mmusic@ietf.org > Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft >=20 > See [SV] below. >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of ext Miguel A. Garcia > Sent: 27. syyskuuta 2012 8:46 > To: Paul Kyzivat > Cc: Lawrence Conroy; mmusic@ietf.org > Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft >=20 > As an author of the document, I can accept option 3 below. >=20 > This means that the connection-address will be specified in the CS draft > as: >=20 > connection-address /=3D telephone-subscriber / "-" > ; telephone-susbscriber defined in > ; RFC 3966 >=20 >=20 > /Miguel >=20 > [SV] So would this work: > - we define the connection-address in SDP CS draft as per Miguel's > suggestion above > - we register the E.164 addrtype with IANA in the SDP CS draft; it will b= e > in the context of PSTN nettype so it doesn't clash with whatever is > specified (or left unspecified) in RFC3108 > - we add text to SDP CS draft that implementations MUST use global-number > of RFC3966 if a global representation is available; otherwise a local- > number may be used >=20 > Simo >=20 >=20 > On 26/09/2012 6:25, Paul Kyzivat wrote: > > I think we are in violent agreement. > > > > Just to be clear, there are various ways to reference 3966 and use > > that in SDP CS. The ones that come to my mind are, when the > > is E164, require the to be: > > > > 1) 'global-phone-digits' from 3966, but excluding 'visual-separator' > > characters. (This is essentially what is currently specified.) > > > > 2) 'global-number' from 3966. > > > > 3) 'telephone-subscriber' from 3966. > > > > Picking (3) will allow local-numbers with context to understand them. > > > > I am inclined to recommend (3) because I can see no reason not to. > > Quite a lot of thought and discussion went into 3966, so why abandon > > or reinvent it? > > > > Thanks, > > Paul > > > > On 9/25/12 7:03 PM, Lawrence Conroy wrote: > >> On 25 Sep 2012, at 22:50, Paul Kyzivat wrote: > >>> On 9/25/12 5:27 PM, Lawrence Conroy wrote: > >>>> Hi Folks, > >>>> Me too. Personally, I would STRONGLY prefer that folks pulled the > definition from 3966 (whichever of the two choices you make). > >>>> > >>>> We had similar mantras to chant in ENUM, so I feel for the squirming > here. > >>>> > >>>> See the last para of RFC4415 section 3 for the appropriate syntax > references to RFC3966 -- yes, you DO need to refer to that, and I'd > suggest normatively. > >>>> National/Local numbers are not necessarily the same as dial strings > (as Paul has spelt out before, IIRC). I ASSUME that you intend this to be > a number rather than any old dial string (with or without the preceding > '9', with or without a carrier prefix, with or without a trunk "access" > digit, ...). > >>>> That's why we strongly discouraged anything other than global number= s > -- otherwise you're building in yet another "NAT" problem. > >>>> > >>>> See the text in the 2nd para of the intro to RFC6116 for the > "anointed" spec/definition we used for "E.164 number". > >>>> BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. > IIRC, the '+' comes from 3GPP and from TIA specs. > >>> > >>> RFC3108 *could* be valid without the '+' if it only permitted E.164 > >>> (global) numbers. But it claims to support both International Format > >>> E.164 numbers and private numbering plans. For that it is invalid > >>> because there is no way to distinguish between them. The example > >>> appears to be a US number without country code. But I don't know how > >>> you would know that. It could be a number in Bahrain. (It seems to > >>> be an *invalid* number in Bahrain, but unless you had a dialing plan > >>> for the entire world I don't know how you would know that.) > >>> > >>>> Also, you may want to specify that the "punctuation" that E.164 > permits is excluded (assuming you don't want dashes, commas, dots or > spaces in the middle). > >>> > >>> Or you could just allow it. No great shakes either way. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> all the best, > >>>> Lawrence > >> > >> > >> To which I reply: > >> > >> Hi Paul, folks, > >> > >> Re. 3108 is psychic -- good point, well made. > >> We're wildly agreeing here. > >> > >> All I was saying was that it's not the '+' that makes an E.164 number > >> ->in International Format<- > >> (E.164 mentions International *and* National numbers [insofar as the > >> ITU ever deals with national systems] -- it mentions Nationally > >> Significant Numbers) > >> > >> Trying to deal with both International and National/Local numbers is > **really** hard, and impossible without context. > >> The same discussions came up during development of 3966 -- that's why > there's a phone-context parameter for tel:, with a ["right-truncated"] > International E.164 number [as an alternative to a domainname]). > >> > >> As Paul sure knows, this has been done before. 3966 has extensive > discussion on exactly the concerns Paul has rightly raised (and it's quit= e > readable :). > >> > >> 3108 seems to have some secret unknown to the rest of us =3D> ignore t= he > magicians -- these two usages will never coexist without a reassuringly > expensive gateway between these universes. That gateway will have to deal > with context (although I don't want to answer the gateway RFI). > >> > >> =3D> just nail down the meaning of E.164 number ("...in international > format...", preceded by a '+' character), refer normatively to 3966's > syntax, and we're done. > >> Anything more is thrashing over the same ground yet again. > >> > >> atb, Lawrence > >> p.s. intra-number punctuation should be simple, but (in particular, > spaces) has bitten implementations more than once. I recommend applying > cattle-prods to the programmers if they forget. > >> > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From partha@parthasarathi.co.in Thu Sep 27 10:43:41 2012 Return-Path: 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 372E621F85AA for ; Thu, 27 Sep 2012 10:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_16=0.6] 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 lZzYC12lxWqO for ; Thu, 27 Sep 2012 10:43:40 -0700 (PDT) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [70.87.28.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1C38A21F8522 for ; Thu, 27 Sep 2012 10:43:40 -0700 (PDT) Received: from userPC (unknown [122.178.223.93]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id 272B73E2047; Thu, 27 Sep 2012 17:43:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1348767819; bh=6Ux16p7FlQy5OOVq0pe/63tMFA4YrJi7sGyc0B0J/pQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hUd0CMTXSDMXkeONZs8n1iRqz/kfs9bTigaaF+1qDEWO4963gzbbx8bOV0SX6jlbP QsTRYlh2VIARtYdnz/SguK5M+epZEVwGuTCfWLuz6QS8kmvWlbMKtRutd/DiaQBfa3 WFRmoJkSVB8RSyKoDbM+/BSLk3u+Y9i2jOLuauXY= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Lishitao'" , "'Ejzak, Richard P \(Richard\)'" , References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A0585340 9FF2F9E@ESESSCMS0356 . e emea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> , <000001cd9815$d0882190$719864b0$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB1@ESESSCMS0356.eemea.ericsson.se>, <000601cd99bc$5b1e5bb0$115b1310$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB4@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 27 Sep 2012 23:13:27 +0530 Message-ID: <000001cd9cd7$9e2f15c0$da8d4140$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNhCqlaaUGA1cGxUKRtxpeaPyBCJeRfUuAgAAC7ICAAATRgIAAAGmAgABXUICAAAH/AIAAD7YAgAAD/QCAAOLngIAANkgAgAAGWYCAAAZdAIAAIryAgAADuQCAAOzj0IAA9jxggAAP5uyAAzJQoIAAKHiQgAYW7SA= Content-Language: en-us X-CTCH-Spam: Suspect X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0209.5064904B.00EB, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Thu, 27 Sep 2012 17:43:41 -0000 Hi Christer, Please read inline. Thanks Partha -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, September 24, 2012 2:07 AM To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)'; mmusic@ietf.org Subject: RE: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Hi, >IIUC, The same port offer may be rejected by answerer irrespective of >"m=bundle" or "a=group:BUNDLE" as it is not just new SDP syntax >but also, the same port offer may have impact in other layers like RTP >in answerer side implementation. The bundling of the different media >in the same port is not guaranteed to negotiate in the answer side with >"m=bundle" mechanism. The point is that answerer will reject in case the >same port offer is not accepted in the specific implementation. If the m=bundle proposal, you don't have to use the same ports. You can assign a separate port for the m=bundle media description. I could not understand your explanation here. Please explain how the separate port for m=bundle solves the problem of answerer which does not want to have the same port for its multiple media types. >Apart from this, The individual attribute behavior for bundle has to be >defined somewhere irrespective of "m=bundle" or "a=group:BUNDLE". Say ptime >attribute applies for the audio codecs only or applies for video codecs >as well in the bundle has to be defined. I'm not see much advantage with >"m=bundle" here. It is already possible to specify attribute values for individual SSRCs. We could do something similar for media types if we want. In case of using the same port in all "m" line using group attributes, the specific attributes values works does not need any update >Instead, Let us discuss the generic categories of attributes and mention in this draft. I am not sure I understood. Paul mentions about some of the categories of the attributes in http://www.ietf.org/mail-archive/web/mmusic/current/msg09467.html. The contention for same port in "m" line mechanism is that "those that are summed across all the bundled media sections". Those issues shall be fixed by the semantic representation. Say bandwidth parameter in bundle group is the sum of all the bandwidth in the specific bundle group. For sure we will have to discuss how/if attributes are affected, but we need to have a general idea on how the multiplexing is going to be offered. Same ports, m=bundle, or something else... So, again, if you have any ideas on how to do it I'd like to hear them :) Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, September 21, 2012 10:57 PM To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)'; mmusic@ietf.org Subject: RE: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Hi, >I agree with Cullen & others that m=bundle does not have consensus. We need >more discussion and analysis. The current Bundle syntax is designed in a way >to reuse lot of existing SDP mechanism (Syntax & Semantics). If possible, >let us try to fix the open issue with the current mechanism before proceeding >with m=bundle approach. Feel free to provide input on how you think we can solve that issue :) Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Lishitao Sent: Friday, September 21, 2012 7:21 AM To: Christer Holmberg; Ejzak, Richard P (Richard); mmusic@ietf.org Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Friday, September 21, 2012 3:32 AM > To: Ejzak, Richard P (Richard); mmusic@ietf.org > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for > bundled session > > Hi, > > >>> m=bundle requires significant extensions to the syntax and also a near > >>> doubling in the size of the SDP. It is harder to specify allowed > >>> combinations of codecs and other options that are normally associated > >>> with a single m line. > >> > >> Please give an example. > > > > To specify two types of audio flows with very different characteristics I would > normally have separate media lines with separate codec lists and attributes. > One may require DTMF and the other silence suppression in addition to the > selected (but different) > > codecs. We need to keep this characteristic. We also need a way of > specifying bandwidth per (old) media line, which is already supported using > separate media lines but requires that something new be defined for m=bundle. > What about RTCP > > characteristics? We certainly want to specify them per (old) media line. > > > > I understand that this can be done with m=bundle, but it requires new syntax. > Why bother if we have something that can work? > > I am not sure it requires new syntax, if you e.g. can use the ssrc attribute in > order to map attributes to specific flows. I would suggest that put the m=bundle proposal in a separate new personal draft or in the annex of the existing working draft, and make a comparison for this proposal and the existing proposal. That will make it more clear. For the existing proposal, I believe that people are not totally against, although it has some issues. (the m=bundle proposal also has some issues). Regards shitao _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic== From pkyzivat@alum.mit.edu Thu Sep 27 12:37:12 2012 Return-Path: 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 2957121F8698 for ; Thu, 27 Sep 2012 12:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 MzQF1Xaxw37q for ; Thu, 27 Sep 2012 12:37:11 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id CC64921F8694 for ; Thu, 27 Sep 2012 12:37:10 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id 4Dml1k0011swQuc51KdEDY; Thu, 27 Sep 2012 19:37:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id 4KZo1k00E3ZTu2S3bKZo3d; Thu, 27 Sep 2012 19:33:48 +0000 Message-ID: <5064A9B9.7060401@alum.mit.edu> Date: Thu, 27 Sep 2012 15:32:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> <50622723.3060909@alum.mit.edu> <506283C5.8050909@alum.mit.edu> <5063E801.4080402@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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: Thu, 27 Sep 2012 19:37:12 -0000 On 9/27/12 9:44 AM, DRAGE, Keith (Keith) wrote: > To add a few thoughts to the debate: > > RFC 3108 seems to define a general structure for the c= line > > c=
> > But then every sentence beyond that seems to give requirements that only apply with the is ATM. > > So at least to me, where the is PSTN, no additional constraints apply directly from RFC 3108 unless we say exactly how they do so. Moreover, we can ignore RFC 3108 beyond the general structure if we wish to do so. > > I would support a structure that is always + followed by digits. > > I would note that E.164 does not include additional characters. That is introduced (like the "+") by E.123 which is there for the textual representation of E.164 numbers. Further that does not use "-" within numbers which is an americanism. > > I do not particularly like the idea of adding such additional characters to the number (beyond the +) - I would prefer to see a straight digit string, which would be the the characters extracted from, or entered into, the related PSTN signaling, which does not include such characters. I don't have any particular issue with excluding characters, other than concern with how to specify that. IMO it is preferable to reference syntax defined in 3966 rather than respecify it. It is hard to do that and still exclude the visual-separators. If need be it can probably be done informally in English. > So a specification that merely says "+" followed by digits as represented by the international telecommunication number as defined in E.164 would be sufficient for me. Perhaps that would do, if there is an explicit goal to be that restrictive. That is equivalent to specifying that it must match from 3966, except the latter permits visual-separators. Is there a concern here about allowing the more general representation of ? If so, what is the concern? The ones I can think of are: - more complex syntax to parse While true, it's not rocket science. So is this a real concern? Also it should be possible to parse a subset and ignore/reject the rest. More on this later. - possibility that the caller may not understand or know how to use parameters on a global number. A simple answer here is that if you don't understand the parameters then a CS bearer can't be established. If you don't understand *any* parameters, then you may give up on the CS bearer as soon as you encounter a ";" without needing to parse the rest. - possibility that the caller may not understand or be able to call a local number Same as above. If you don't support local numbers then give up. - backward compatibility with deployments of early drafts (You know my opinion of this as an argument.) I see one issue above, but it isn't really a *new* issue - it exists even as the draft is now written: If the offerer is elected to be the active party, but is unable to make a call to the number provided, then the answerer doesn't realize what the problem is. There is no discussion of this point, or what should be done to recover from it. For instance, this could occur if the number provided is valid but not callable by the caller. (E.g. because the caller's service doesn't include international calling.) Local numbers, or global numbers with parameters, provide other ways that the caller may not be able to call the number. But they fall into the same category of issue. > If we follow RFC 3966, then it would have to be limited to global numbers. RFC 3966 is then inconsistent, because the text says it follows the rules of E.164, and then the ABNF defines visual separators, which are not defined in E.164. Why would it *have* to be limited to global numbers? Thanks, Paul > Keith > > > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Simo.Veikkolainen@nokia.com >> Sent: 27 September 2012 09:17 >> To: Miguel.A.Garcia@ericsson.com; pkyzivat@alum.mit.edu >> Cc: lconroy@insensate.co.uk; mmusic@ietf.org >> Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft >> >> See [SV] below. >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of ext Miguel A. Garcia >> Sent: 27. syyskuuta 2012 8:46 >> To: Paul Kyzivat >> Cc: Lawrence Conroy; mmusic@ietf.org >> Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft >> >> As an author of the document, I can accept option 3 below. >> >> This means that the connection-address will be specified in the CS draft >> as: >> >> connection-address /= telephone-subscriber / "-" >> ; telephone-susbscriber defined in >> ; RFC 3966 >> >> >> /Miguel >> >> [SV] So would this work: >> - we define the connection-address in SDP CS draft as per Miguel's >> suggestion above >> - we register the E.164 addrtype with IANA in the SDP CS draft; it will be >> in the context of PSTN nettype so it doesn't clash with whatever is >> specified (or left unspecified) in RFC3108 >> - we add text to SDP CS draft that implementations MUST use global-number >> of RFC3966 if a global representation is available; otherwise a local- >> number may be used >> >> Simo >> >> >> On 26/09/2012 6:25, Paul Kyzivat wrote: >>> I think we are in violent agreement. >>> >>> Just to be clear, there are various ways to reference 3966 and use >>> that in SDP CS. The ones that come to my mind are, when the >>> is E164, require the to be: >>> >>> 1) 'global-phone-digits' from 3966, but excluding 'visual-separator' >>> characters. (This is essentially what is currently specified.) >>> >>> 2) 'global-number' from 3966. >>> >>> 3) 'telephone-subscriber' from 3966. >>> >>> Picking (3) will allow local-numbers with context to understand them. >>> >>> I am inclined to recommend (3) because I can see no reason not to. >>> Quite a lot of thought and discussion went into 3966, so why abandon >>> or reinvent it? >>> >>> Thanks, >>> Paul >>> >>> On 9/25/12 7:03 PM, Lawrence Conroy wrote: >>>> On 25 Sep 2012, at 22:50, Paul Kyzivat wrote: >>>>> On 9/25/12 5:27 PM, Lawrence Conroy wrote: >>>>>> Hi Folks, >>>>>> Me too. Personally, I would STRONGLY prefer that folks pulled the >> definition from 3966 (whichever of the two choices you make). >>>>>> >>>>>> We had similar mantras to chant in ENUM, so I feel for the squirming >> here. >>>>>> >>>>>> See the last para of RFC4415 section 3 for the appropriate syntax >> references to RFC3966 -- yes, you DO need to refer to that, and I'd >> suggest normatively. >>>>>> National/Local numbers are not necessarily the same as dial strings >> (as Paul has spelt out before, IIRC). I ASSUME that you intend this to be >> a number rather than any old dial string (with or without the preceding >> '9', with or without a carrier prefix, with or without a trunk "access" >> digit, ...). >>>>>> That's why we strongly discouraged anything other than global numbers >> -- otherwise you're building in yet another "NAT" problem. >>>>>> >>>>>> See the text in the 2nd para of the intro to RFC6116 for the >> "anointed" spec/definition we used for "E.164 number". >>>>>> BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. >> IIRC, the '+' comes from 3GPP and from TIA specs. >>>>> >>>>> RFC3108 *could* be valid without the '+' if it only permitted E.164 >>>>> (global) numbers. But it claims to support both International Format >>>>> E.164 numbers and private numbering plans. For that it is invalid >>>>> because there is no way to distinguish between them. The example >>>>> appears to be a US number without country code. But I don't know how >>>>> you would know that. It could be a number in Bahrain. (It seems to >>>>> be an *invalid* number in Bahrain, but unless you had a dialing plan >>>>> for the entire world I don't know how you would know that.) >>>>> >>>>>> Also, you may want to specify that the "punctuation" that E.164 >> permits is excluded (assuming you don't want dashes, commas, dots or >> spaces in the middle). >>>>> >>>>> Or you could just allow it. No great shakes either way. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> all the best, >>>>>> Lawrence >>>> >>>> >>>> To which I reply: >>>> >>>> Hi Paul, folks, >>>> >>>> Re. 3108 is psychic -- good point, well made. >>>> We're wildly agreeing here. >>>> >>>> All I was saying was that it's not the '+' that makes an E.164 number >>>> ->in International Format<- >>>> (E.164 mentions International *and* National numbers [insofar as the >>>> ITU ever deals with national systems] -- it mentions Nationally >>>> Significant Numbers) >>>> >>>> Trying to deal with both International and National/Local numbers is >> **really** hard, and impossible without context. >>>> The same discussions came up during development of 3966 -- that's why >> there's a phone-context parameter for tel:, with a ["right-truncated"] >> International E.164 number [as an alternative to a domainname]). >>>> >>>> As Paul sure knows, this has been done before. 3966 has extensive >> discussion on exactly the concerns Paul has rightly raised (and it's quite >> readable :). >>>> >>>> 3108 seems to have some secret unknown to the rest of us => ignore the >> magicians -- these two usages will never coexist without a reassuringly >> expensive gateway between these universes. That gateway will have to deal >> with context (although I don't want to answer the gateway RFI). >>>> >>>> => just nail down the meaning of E.164 number ("...in international >> format...", preceded by a '+' character), refer normatively to 3966's >> syntax, and we're done. >>>> Anything more is thrashing over the same ground yet again. >>>> >>>> atb, Lawrence >>>> p.s. intra-number punctuation should be simple, but (in particular, >> spaces) has bitten implementations more than once. I recommend applying >> cattle-prods to the programmers if they forget. >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From miguel.a.garcia@ericsson.com Thu Sep 27 23:23:18 2012 Return-Path: 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 57CA521F846E for ; Thu, 27 Sep 2012 23:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 Gj-0amge3x+a for ; Thu, 27 Sep 2012 23:23:17 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A925021F8456 for ; Thu, 27 Sep 2012 23:23:16 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-9c-50654252e40e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 49.A2.17130.25245605; Fri, 28 Sep 2012 08:23:15 +0200 (CEST) Received: from [164.48.161.175] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.1; Fri, 28 Sep 2012 08:23:14 +0200 Message-ID: <5065424F.9030000@ericsson.com> Date: Fri, 28 Sep 2012 08:23:11 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <5060BE2B.20101@ericsson.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D249B@ESESSCMS0352.eemea.ericsson.se> <5061E117.2000804@cisco.com>, <5061E6A6.6070507@alum.mit.edu> <506217F0.3060400@alum.mit.edu> <57FF3CA6-4D31-4702-9F95-173808DD70FE@insensate.co.uk> <50622723.3060909@alum.mit.edu> <506283C5.8050909@alum.mit.edu> <5063E801.4080402@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+JvrW6wU2qAQVsTm8XTxrOMFrPe9DBb TF3+mMVixYYDrBbnPt1lcWD1aH22l9Xj7/sPTB5Llvxk8jg+bSO7x91bl5gCWKO4bFJSczLL Uov07RK4MqYc/sRUcMqzYvmybuYGxh3WXYycHBICJhK7pjWwQNhiEhfurWfrYuTiEBI4xShx 4TqIwwnkrGGUWPZEFsTmFdCW+LqyjamLkYODRUBV4vmvIpAwm4C5ROvGjewgtqhAsMS5jdvY IMoFJU7OfAI2X0TAWuLV4y1g85kFLjFKnJ0xmQ1kjrCArcTxI3UQe7tZJVY2LGQFiXMKxEn8 /gA2kxmo5MKc6ywQtrzE9rdzmCFO05SYfHMp8wRGwVlI1s1C0jILScsCRuZVjMK5iZk56eXm eqlFmcnFxfl5esWpmxiBQX5wy2+DHYyb7osdYpTmYFES59VT3e8vJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgXGFJmutqjFDxYa62oVW7VJ6DPGLs9Wub5BUEM7vWtyc/03wxM3FvUxb2Vb0 vI/+a3nLboOfdBWbVJXdZZXZk5TcJsa4G8ZMOMDkuWP3I/6pcikHViwSWX3wH9+U/4Gza/6X yW4J2fRL+nrYMvkfRxomyc98oCG/6+cs/g0MFtH2FpZHVr5LvKXEUpyRaKjFXFScCAD+BQaz QAIAAA== Cc: "lconroy@insensate.co.uk" , "mmusic@ietf.org" , "pkyzivat@alum.mit.edu" Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft X-BeenThere: mmusic@ietf.org 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, 28 Sep 2012 06:23:18 -0000 Hi Keith, thanks for jumping into the discussion. See inline comments. On 27/09/2012 15:44, DRAGE, Keith (Keith) wrote: > To add a few thoughts to the debate: > > RFC 3108 seems to define a general structure for the c= line > > c=
> > But then every sentence beyond that seems to give requirements that > only apply with the is ATM. > > So at least to me, where the is PSTN, no additional > constraints apply directly from RFC 3108 unless we say exactly how > they do so. Moreover, we can ignore RFC 3108 beyond the general > structure if we wish to do so. > Agreed > I would support a structure that is always + followed by digits. > > I would note that E.164 does not include additional characters. That > is introduced (like the "+") by E.123 which is there for the textual > representation of E.164 numbers. Further that does not use "-" within > numbers which is an americanism. > > I do not particularly like the idea of adding such additional > characters to the number (beyond the +) - I would prefer to see a > straight digit string, which would be the the characters extracted > from, or entered into, the related PSTN signaling, which does not > include such characters. > > So a specification that merely says "+" followed by digits as > represented by the international telecommunication number as defined > in E.164 would be sufficient for me. > > If we follow RFC 3966, then it would have to be limited to global > numbers. RFC 3966 is then inconsistent, because the text says it > follows the rules of E.164, and then the ABNF defines visual > separators, which are not defined in E.164. So, if we refer to RFC 3966, then we ought to allow visual separators, which are already part of the specification. These visual separators include the following characters: "-" / "." / "(" / ")" Which might be ok when an E.164 number is represented for a human consumption. However, in the CS description draft this is supposed to be consumed by the endpoint. Additionally, the possibility of having visual separators in an E.164 number will break existing implementations. My conclusion: if we refer to RFC 3966, but then we need to remove local numbers and visual separators, there is no point in adding such dependency. I prefer to refer the e164 address for this draft as a plus sign and a collection of digits. BR, Miguel > > Keith > > > >> -----Original Message----- From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org] On Behalf Of >> Simo.Veikkolainen@nokia.com Sent: 27 September 2012 09:17 To: >> Miguel.A.Garcia@ericsson.com; pkyzivat@alum.mit.edu Cc: >> lconroy@insensate.co.uk; mmusic@ietf.org Subject: Re: [MMUSIC] Issue >> with E164 numbers in SDP CS draft >> >> See [SV] below. >> >> -----Original Message----- From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Miguel A. Garcia >> Sent: 27. syyskuuta 2012 8:46 To: Paul Kyzivat Cc: Lawrence Conroy; >> mmusic@ietf.org Subject: Re: [MMUSIC] Issue with E164 numbers in SDP >> CS draft >> >> As an author of the document, I can accept option 3 below. >> >> This means that the connection-address will be specified in the CS >> draft as: >> >> connection-address /= telephone-subscriber / "-" ; >> telephone-susbscriber defined in ; RFC 3966 >> >> >> /Miguel >> >> [SV] So would this work: - we define the connection-address in SDP >> CS draft as per Miguel's suggestion above - we register the E.164 >> addrtype with IANA in the SDP CS draft; it will be in the context of >> PSTN nettype so it doesn't clash with whatever is specified (or left >> unspecified) in RFC3108 - we add text to SDP CS draft that >> implementations MUST use global-number of RFC3966 if a global >> representation is available; otherwise a local- number may be used >> >> Simo >> >> >> On 26/09/2012 6:25, Paul Kyzivat wrote: >>> I think we are in violent agreement. >>> >>> Just to be clear, there are various ways to reference 3966 and >>> use that in SDP CS. The ones that come to my mind are, when the >>> is E164, require the to be: >>> >>> 1) 'global-phone-digits' from 3966, but excluding >>> 'visual-separator' characters. (This is essentially what is >>> currently specified.) >>> >>> 2) 'global-number' from 3966. >>> >>> 3) 'telephone-subscriber' from 3966. >>> >>> Picking (3) will allow local-numbers with context to understand >>> them. >>> >>> I am inclined to recommend (3) because I can see no reason not >>> to. Quite a lot of thought and discussion went into 3966, so why >>> abandon or reinvent it? >>> >>> Thanks, Paul >>> >>> On 9/25/12 7:03 PM, Lawrence Conroy wrote: >>>> On 25 Sep 2012, at 22:50, Paul Kyzivat wrote: >>>>> On 9/25/12 5:27 PM, Lawrence Conroy wrote: >>>>>> Hi Folks, Me too. Personally, I would STRONGLY prefer that >>>>>> folks pulled the >> definition from 3966 (whichever of the two choices you make). >>>>>> >>>>>> We had similar mantras to chant in ENUM, so I feel for the >>>>>> squirming >> here. >>>>>> >>>>>> See the last para of RFC4415 section 3 for the appropriate >>>>>> syntax >> references to RFC3966 -- yes, you DO need to refer to that, and I'd >> suggest normatively. >>>>>> National/Local numbers are not necessarily the same as dial >>>>>> strings >> (as Paul has spelt out before, IIRC). I ASSUME that you intend this >> to be a number rather than any old dial string (with or without the >> preceding '9', with or without a carrier prefix, with or without a >> trunk "access" digit, ...). >>>>>> That's why we strongly discouraged anything other than >>>>>> global numbers >> -- otherwise you're building in yet another "NAT" problem. >>>>>> >>>>>> See the text in the 2nd para of the intro to RFC6116 for >>>>>> the >> "anointed" spec/definition we used for "E.164 number". >>>>>> BTW, E.164 doesn't include the '+', which is why RFC3108 is >>>>>> valid. >> IIRC, the '+' comes from 3GPP and from TIA specs. >>>>> >>>>> RFC3108 *could* be valid without the '+' if it only permitted >>>>> E.164 (global) numbers. But it claims to support both >>>>> International Format E.164 numbers and private numbering >>>>> plans. For that it is invalid because there is no way to >>>>> distinguish between them. The example appears to be a US >>>>> number without country code. But I don't know how you would >>>>> know that. It could be a number in Bahrain. (It seems to be an >>>>> *invalid* number in Bahrain, but unless you had a dialing >>>>> plan for the entire world I don't know how you would know >>>>> that.) >>>>> >>>>>> Also, you may want to specify that the "punctuation" that >>>>>> E.164 >> permits is excluded (assuming you don't want dashes, commas, dots >> or spaces in the middle). >>>>> >>>>> Or you could just allow it. No great shakes either way. >>>>> >>>>> Thanks, Paul >>>>> >>>>>> all the best, Lawrence >>>> >>>> >>>> To which I reply: >>>> >>>> Hi Paul, folks, >>>> >>>> Re. 3108 is psychic -- good point, well made. We're wildly >>>> agreeing here. >>>> >>>> All I was saying was that it's not the '+' that makes an E.164 >>>> number ->in International Format<- (E.164 mentions International >>>> *and* National numbers [insofar as the ITU ever deals with >>>> national systems] -- it mentions Nationally Significant >>>> Numbers) >>>> >>>> Trying to deal with both International and National/Local >>>> numbers is >> **really** hard, and impossible without context. >>>> The same discussions came up during development of 3966 -- >>>> that's why >> there's a phone-context parameter for tel:, with a >> ["right-truncated"] International E.164 number [as an alternative to >> a domainname]). >>>> >>>> As Paul sure knows, this has been done before. 3966 has >>>> extensive >> discussion on exactly the concerns Paul has rightly raised (and it's >> quite readable :). >>>> >>>> 3108 seems to have some secret unknown to the rest of us => >>>> ignore the >> magicians -- these two usages will never coexist without a >> reassuringly expensive gateway between these universes. That gateway >> will have to deal with context (although I don't want to answer the >> gateway RFI). >>>> >>>> => just nail down the meaning of E.164 number ("...in >>>> international >> format...", preceded by a '+' character), refer normatively to >> 3966's syntax, and we're done. >>>> Anything more is thrashing over the same ground yet again. >>>> >>>> atb, Lawrence p.s. intra-number punctuation should be simple, >>>> but (in particular, >> spaces) has bitten implementations more than once. I recommend >> applying cattle-prods to the programmers if they forget. >>>> >>> >>> _______________________________________________ mmusic mailing >>> list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain >> _______________________________________________ mmusic mailing list >> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ mmusic mailing list >> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Fri Sep 28 02:20:12 2012 Return-Path: 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 4BF7821F855E for ; Fri, 28 Sep 2012 02:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.343 X-Spam-Level: X-Spam-Status: No, score=-3.343 tagged_above=-999 required=5 tests=[AWL=-2.694, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 Vs9rTxSPCygR for ; Fri, 28 Sep 2012 02:20:07 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id AF47621F851C for ; Fri, 28 Sep 2012 02:20:06 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-51-50656bc5aee9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 41.12.17130.5CB65605; Fri, 28 Sep 2012 11:20:05 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 28 Sep 2012 11:20:04 +0200 From: Christer Holmberg To: Parthasarathi R , 'Lishitao' , "'Ejzak, Richard P (Richard)'" , "mmusic@ietf.org" Date: Fri, 28 Sep 2012 11:20:03 +0200 Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session Thread-Index: AQHNhCqlaaUGA1cGxUKRtxpeaPyBCJeRfUuAgAAC7ICAAATRgIAAAGmAgABXUICAAAH/AIAAD7YAgAAD/QCAAOLngIAANkgAgAAGWYCAAAZdAIAAIryAgAADuQCAAOzj0IAA9jxggAAP5uyAAzJQoIAAKHiQgAYW7SCAAQaqMA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A6FA5A4@ESESSCMS0356.eemea.ericsson.se> References: <50222D44.5040105@alvestrand.no> <502258CA.5030009@alvestrand.no> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A0585340 9FF2F9E@ESESSCMS0356 . e emea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> , <000001cd9815$d0882190$719864b0$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB1@ESESSCMS0356.eemea.ericsson.se>, <000601cd99bc$5b1e5bb0$115b1310$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB4@ESESSCMS0356.eemea.ericsson.se> <000001cd9cd7$9e2f15c0$da8d4140$@co.in> In-Reply-To: <000001cd9cd7$9e2f15c0$da8d4140$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvre7R7NQAg527RCwO7rvFbDF1+WMW i8mf+lgtehvCHVg8Wp/tZfVoOfKW1WPJkp9MHh/mf2EPYInisklJzcksSy3St0vgyuhfeJKx oFOvonHmYqYGxg2qXYycHBICJhL3zy1mhLDFJC7cW8/WxcjFISRwilHi4Oy7TCAJIYE5jBKz u4q6GDk42AQsJLr/aYPUiAjsY5RouraIGaSGRUBV4tmRpawgtrBAvMSKbUvB4iICCRK7Jq1l hGjYxSix9981FpAEr0C4RM/7WawQC77zSVzoLgSxOYEuWj6ziR3EZgS66PupNWBHMAuIS9x6 Mp8J4lIBiSV7zjND2KISLx//Y4WoF5W4076eEaJeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUC o+gsJGNnIWmZhaRlFpKWBYwsqxiFcxMzc9LLzfVSizKTi4vz8/SKUzcxAmPp4JbfBjsYN90X O8QozcGiJM6rp7rfX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjydMBThViBevz3TLut/Dd EvJMeKE3w/7n+tSSZ5s+/ZnvM0VWuc2rw1U+pEqT9/25/skNR5/4ardE/0zfPvd27Ky6a5EK d69Fevuue/qpPktoQTVLMnsV39Gl6U0NveovKiw2+DMtXvBa89cLfwOXB7MC3V1ain8qhcwx Dzs4T1fyUe7yjYxKLMUZiYZazEXFiQDVwqhdcwIAAA== Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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, 28 Sep 2012 09:20:12 -0000 Hi, >>IIUC, The same port offer may be rejected by answerer irrespective of=20 >>"m=3Dbundle" or "a=3Dgroup:BUNDLE" as it is not just new SDP syntax but=20 >>also, the same port offer may have impact in other layers like RTP in=20 >>answerer side implementation. The bundling of the different media in=20 >>the same port is not guaranteed to negotiate in the answer side with=20 >>"m=3Dbundle" mechanism. The point is that answerer will reject in case=20 >>the same port offer is not accepted in the specific implementation. > >If the m=3Dbundle proposal, you don't have to use the same ports. You can = assign a separate port for the m=3Dbundle media description. > > I could not understand your explanation here. Please explain how = the separate port for m=3Dbundle solves the problem of answerer which does = not want to have the same port for its multiple media types. If the answerer does not want to do multiplexing, or does not support multi= plexing, it sets the m=3D bundle port to zero, and uses the separate m=3Dau= dio/video ports. >>Apart from this, The individual attribute behavior for bundle has to be=20 >>defined somewhere irrespective of "m=3Dbundle" or "a=3Dgroup:BUNDLE". Say= =20 >>ptime attribute applies for the audio codecs only or applies for video=20 >>codecs as well in the bundle has to be defined. I'm not see much=20 >>advantage with "m=3Dbundle" here. > >It is already possible to specify attribute values for individual SSRCs. W= e could do something similar for media types if we want. > > In case of using the same port in all "m" line using group attrib= utes, the specific attributes values works does not need any update Yes, but people have raised issues with using the same port in all "m" line= s - that's why we've suggested the m=3Dbundle solution. >>Instead, Let us discuss the generic categories of attributes and mention = in this draft. > > I am not sure I understood. > > Paul mentions about some of the categories of the attributes in = http://www.ietf.org/mail-archive/web/mmusic/current/msg09467.html. The cont= ention for same port in "m" line mechanism is that "those that are summed a= cross all the=20 > bundled media sections". Those issues shall be fixed by the semantic repr= esentation. Say bandwidth parameter in bundle group is the sum of all the b= andwidth in the specific bundle group. =20 Yes. But, again, I don't think the attributes have been the main issue. The= issue have been using the same port in multiple m- lines in the first plac= e. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, September 21, 2012 10:57 PM To: Parthasarathi R; 'Lishitao'; 'Ejzak, Richard P (Richard)'; mmusic@ietf.= org Subject: RE: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line f= or bundled session Hi, >I agree with Cullen & others that m=3Dbundle does not have consensus. We=20 >need more discussion and analysis. The current Bundle syntax is=20 >designed in a way >to reuse lot of existing SDP mechanism (Syntax & Semantics). If=20 >possible, let us try to fix the open issue with the current mechanism=20 >before proceeding >with m=3Dbundle approach. Feel free to provide input on how you think we can solve that issue :) Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Lishitao Sent: Friday, September 21, 2012 7:21 AM To: Christer Holmberg; Ejzak, Richard P (Richard); mmusic@ietf.org Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line f= or bundled session > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Christer Holmberg > Sent: Friday, September 21, 2012 3:32 AM > To: Ejzak, Richard P (Richard); mmusic@ietf.org > Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit=20 > m-line for > bundled session > > Hi, > > >>> m=3Dbundle requires significant extensions to the syntax and also a=20 > >>> near doubling in the size of the SDP. It is harder to specify=20 > >>> allowed combinations of codecs and other options that are normally=20 > >>> associated with a single m line. > >> > >> Please give an example. > > > > To specify two types of audio flows with very different=20 > > characteristics I would > normally have separate media lines with separate codec lists and attributes. > One may require DTMF and the other silence suppression in addition to=20 > the selected (but different) > > codecs. We need to keep this characteristic. We also need a way of > specifying bandwidth per (old) media line, which is already supported using > separate media lines but requires that something new be defined for m=3Dbundle. > What about RTCP > > characteristics? We certainly want to specify them per (old) media line. > > > > I understand that this can be done with m=3Dbundle, but it requires=20 > > new syntax. > Why bother if we have something that can work? > > I am not sure it requires new syntax, if you e.g. can use the ssrc attribute in > order to map attributes to specific flows. I would suggest that put the m=3Dbundle proposal in a separate new personal= draft or in the annex of the existing working draft, and make a comparison= for this proposal and the existing proposal. That will make it more clear. For the existing proposal, I believe that people are not totally against, a= lthough it has some issues. (the m=3Dbundle proposal also has some issues). Regards shitao _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic=3D=3D From fandreas@cisco.com Fri Sep 28 06:16:09 2012 Return-Path: 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 6077521F85A8; Fri, 28 Sep 2012 06:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.565 X-Spam-Level: X-Spam-Status: No, score=-10.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 GGgwuEH4f839; Fri, 28 Sep 2012 06:16:08 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6B68721F859A; Fri, 28 Sep 2012 06:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4933; q=dns/txt; s=iport; t=1348838168; x=1350047768; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=VPKxToHGv0Fx2fqaZmeOu7QbFOuDYiBge51NGwhKTmE=; b=bfxssXHh0lG1arSIzbSv6wMNpmcPJWzadIULhO4+tr2JDUYVV+3jhYMC 6cgr2nDZyy1ZiB14qh3dU243vipKJegRPcGF6zbq8Kq6Ip+6kOI6RDxMO zwFnImVd7A0ADoM9Wp0TxseXTBNP1jaVxOvz+vYiOqgVn4cLIYCmC5qu4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAE2iZVCtJXHA/2dsb2JhbABFi2qyJoEIgiABAQEEEgFlAQwEDw0DAQIKFg8JAwIBAgE7AggGAQwBBQIBAR6HYwuXZaAqixiGJwOVaYEVjS2BaYMD X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208,217";a="126353757" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 28 Sep 2012 13:16:08 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8SDG6dB029467; Fri, 28 Sep 2012 13:16:07 GMT Message-ID: <5065A316.4010503@cisco.com> Date: Fri, 28 Sep 2012 09:16:06 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic , "avtext@ietf.org" References: <505188C7.1080805@ericsson.com> In-Reply-To: <505188C7.1080805@ericsson.com> X-Forwarded-Message-Id: <505188C7.1080805@ericsson.com> Content-Type: multipart/alternative; boundary="------------090006080205080205050206" Cc: draft-begen-mmusic-temporal-interleaving@tools.ietf.org, draft-begen-mmusic-redundancy-grouping@tools.ietf.org, draft-ietf-avtext-rtp-duplication@tools.ietf.org Subject: [MMUSIC] Fwd: WG Poll for consensus on duplicated streams X-BeenThere: mmusic@ietf.org 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, 28 Sep 2012 13:16:09 -0000 This is a multi-part message in MIME format. --------------090006080205080205050206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit MMUSIC and AVTEXT folks It is our understanding that AVTEXT is conducting work that depends on the below two drafts, and hence MMUSIC is considering adopting them as WG items. The MMUSIC chairs issued a WG poll for adoption of the drafts, however we have not received much feedback on this. Please take a minute to indicate if you are in favor of (or against) adopting these drafts as MMUSIC WG items. Thanks -- Flemming & Miguel (MMUSIC co-chairs). -------- Original Message -------- Subject: WG Poll for consensus on duplicated streams Date: Thu, 13 Sep 2012 09:18:31 +0200 From: Miguel A. Garcia To: mmusic , Flemming Andreasen At the last IETF meeting we had presentation of two drafts, both related to the expression of duplicated streams in SDP. We noticed there was support to progress these drafts. These drafts are complementary to work going on in AVTEXT, where there is a normative dependency. These are the documents: http://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ http://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/ We would like to poll the working group for adopting these two documents as WG items, once we get approved milestones. Please indicate whether you support or not this new work within the next 5 working days. Flemming and Miguel (co-chairs). /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain . --------------090006080205080205050206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MMUSIC and AVTEXT folks

It is our understanding that AVTEXT is conducting work that depends on the below two drafts, and hence MMUSIC is considering adopting them as WG items. The MMUSIC chairs issued a WG poll for adoption of the drafts, however we have not received much feedback on this. Please take a minute to indicate if you are in favor of (or against) adopting these drafts as MMUSIC WG items.

Thanks

-- Flemming & Miguel (MMUSIC co-chairs).


-------- Original Message --------
Subject: WG Poll for consensus on duplicated streams
Date: Thu, 13 Sep 2012 09:18:31 +0200
From: Miguel A. Garcia <Miguel.A.Garcia@ericsson.com>
To: mmusic <mmusic@ietf.org>, Flemming Andreasen <fandreas@cisco.com> 


At the last IETF meeting we had presentation of two drafts, both
related to the expression of duplicated streams in SDP. We noticed
there was support to progress these drafts. These drafts are
complementary to work going on in AVTEXT, where there is a normative
dependency.

These are the documents:

http://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/
http://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/

We would like to poll the working group for adopting these two
documents as WG items, once we get approved milestones.

Please indicate whether you support or not this new work within the
next 5 working days.

Flemming and Miguel (co-chairs).

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

.



--------------090006080205080205050206-- From csp@csperkins.org Fri Sep 28 06:57:28 2012 Return-Path: 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 DDECF21F85A2 for ; Fri, 28 Sep 2012 06:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=1.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 Skght8XdTccd for ; Fri, 28 Sep 2012 06:57:28 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1100A21F859A for ; Fri, 28 Sep 2012 06:57:28 -0700 (PDT) Received: from [130.209.247.112] (helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1THb3K-0003A8-Bk; Fri, 28 Sep 2012 14:56:26 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_3831B45A-F586-404E-ACE6-09EA263ADBE7" From: Colin Perkins In-Reply-To: <5065A316.4010503@cisco.com> Date: Fri, 28 Sep 2012 14:56:25 +0100 Message-Id: <805AA23C-8A81-4B3C-9DA8-614EB4A1D516@csperkins.org> References: <505188C7.1080805@ericsson.com> <5065A316.4010503@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -6 X-Mythic-Debug: Threshold = On = Cc: mmusic Subject: Re: [MMUSIC] WG Poll for consensus on duplicated streams X-BeenThere: mmusic@ietf.org 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, 28 Sep 2012 13:57:29 -0000 --Apple-Mail=_3831B45A-F586-404E-ACE6-09EA263ADBE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Flemming, We need these to support our rtp-duplication draft, so I'm in favour. Colin On 28 Sep 2012, at 14:16, Flemming Andreasen wrote: > MMUSIC and AVTEXT folks >=20 > It is our understanding that AVTEXT is conducting work that depends on = the below two drafts, and hence MMUSIC is considering adopting them as = WG items. The MMUSIC chairs issued a WG poll for adoption of the drafts, = however we have not received much feedback on this. Please take a minute = to indicate if you are in favor of (or against) adopting these drafts as = MMUSIC WG items.=20 >=20 > Thanks=20 >=20 > -- Flemming & Miguel (MMUSIC co-chairs).=20 >=20 >=20 > -------- Original Message -------- > Subject: WG Poll for consensus on duplicated streams > Date: Thu, 13 Sep 2012 09:18:31 +0200 > From: Miguel A. Garcia > To: mmusic , Flemming Andreasen = >=20 > At the last IETF meeting we had presentation of two drafts, both > related to the expression of duplicated streams in SDP. We noticed > there was support to progress these drafts. These drafts are > complementary to work going on in AVTEXT, where there is a normative > dependency. >=20 > These are the documents: >=20 > = http://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ > = http://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/ >=20 > We would like to poll the working group for adopting these two > documents as WG items, once we get approved milestones. >=20 > Please indicate whether you support or not this new work within the > next 5 working days. >=20 > Flemming and Miguel (co-chairs). >=20 > /Miguel > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_3831B45A-F586-404E-ACE6-09EA263ADBE7 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Flemming,

We need these to support our rtp-duplication draft, so I'm in favour.

Colin


On 28 Sep 2012, at 14:16, Flemming Andreasen wrote:
MMUSIC and AVTEXT folks

It is our understanding that AVTEXT is conducting work that depends on the below two drafts, and hence MMUSIC is considering adopting them as WG items. The MMUSIC chairs issued a WG poll for adoption of the drafts, however we have not received much feedback on this. Please take a minute to indicate if you are in favor of (or against) adopting these drafts as MMUSIC WG items.

Thanks

-- Flemming & Miguel (MMUSIC co-chairs).


-------- Original Message --------
Subject: WG Poll for consensus on duplicated streams
Date: Thu, 13 Sep 2012 09:18:31 +0200
From: Miguel A. Garcia <Miguel.A.Garcia@ericsson.com>
To: mmusic <mmusic@ietf.org>, Flemming Andreasen <fandreas@cisco.com> 


At the last IETF meeting we had presentation of two drafts, both
related to the expression of duplicated streams in SDP. We noticed
there was support to progress these drafts. These drafts are
complementary to work going on in AVTEXT, where there is a normative
dependency.

These are the documents:

http://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/
http://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/

We would like to poll the working group for adopting these two
documents as WG items, once we get approved milestones.

Please indicate whether you support or not this new work within the
next 5 working days.

Flemming and Miguel (co-chairs).

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
-- 
Colin Perkins



--Apple-Mail=_3831B45A-F586-404E-ACE6-09EA263ADBE7-- From fluffy@cisco.com Fri Sep 28 07:36:59 2012 Return-Path: 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 3A20D21F8613; Fri, 28 Sep 2012 07:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 a9y3IHxfDLGA; Fri, 28 Sep 2012 07:36:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8DA21F8610; Fri, 28 Sep 2012 07:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1976; q=dns/txt; s=iport; t=1348843018; x=1350052618; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=r5kzzzYEZPXLxqiMjdDROWL61GlNmQzPGkNheS46zY4=; b=KU33J1bdnka3RsaTNuT0ekK990nKM/zLdApij1xUyPX6WHfOb2j/vm3H 06+rNk8bAqDWmisc+l6rpT/M5784G+C66mt+msdr5huo0XKiJmw4bXkxF 7z0espLsO3okmJk01MQtSdiYFD0gyJ/yzpSWR7k9mEWemBEn3ATRPSKzO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADG1ZVCtJXG+/2dsb2JhbABFvg6BCIIgAQEBAwEBAQEPAVsLBQcEAgEIEQMBAi8nCx0IAgQBDQUih10GC5dsoCyLGIVHYAOII41GgRWNLYFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="126161810" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 28 Sep 2012 14:36:55 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8SEataO022793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Sep 2012 14:36:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Fri, 28 Sep 2012 09:36:55 -0500 From: "Cullen Jennings (fluffy)" To: mmusic , "avtext@ietf.org" Thread-Topic: [MMUSIC] WG Poll for consensus on duplicated streams Thread-Index: AQHNnYa0f/mVMI4BXkeZfMxNX63+bA== Date: Fri, 28 Sep 2012 14:36:54 +0000 Message-ID: References: <505188C7.1080805@ericsson.com> <5065A316.4010503@cisco.com> In-Reply-To: <5065A316.4010503@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19216.004 x-tm-as-result: No--43.176900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5C7B28271F685A4E9901869148B305EF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-begen-mmusic-temporal-interleaving@tools.ietf.org" , "draft-begen-mmusic-redundancy-grouping@tools.ietf.org" , "draft-ietf-avtext-rtp-duplication@tools.ietf.org" Subject: Re: [MMUSIC] WG Poll for consensus on duplicated streams X-BeenThere: mmusic@ietf.org 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, 28 Sep 2012 14:36:59 -0000 I'm in favor of adopting these. They are simple and solve the problem. On Sep 28, 2012, at 7:16 AM, Flemming Andreasen wrote: > MMUSIC and AVTEXT folks >=20 > It is our understanding that AVTEXT is conducting work that depends on th= e below two drafts, and hence MMUSIC is considering adopting them as WG ite= ms. The MMUSIC chairs issued a WG poll for adoption of the drafts, however = we have not received much feedback on this. Please take a minute to indicat= e if you are in favor of (or against) adopting these drafts as MMUSIC WG it= ems.=20 >=20 > Thanks=20 >=20 > -- Flemming & Miguel (MMUSIC co-chairs).=20 >=20 >=20 > -------- Original Message -------- > Subject: WG Poll for consensus on duplicated streams > Date: Thu, 13 Sep 2012 09:18:31 +0200 > From: Miguel A. Garcia > To: mmusic , Flemming Andreasen >=20 > At the last IETF meeting we had presentation of two drafts, both > related to the expression of duplicated streams in SDP. We noticed > there was support to progress these drafts. These drafts are > complementary to work going on in AVTEXT, where there is a normative > dependency. >=20 > These are the documents: >=20 >=20 > http://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ > http://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/ >=20 >=20 > We would like to poll the working group for adopting these two > documents as WG items, once we get approved milestones. >=20 > Please indicate whether you support or not this new work within the > next 5 working days. >=20 > Flemming and Miguel (co-chairs). >=20 > /Miguel > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain >=20 > . >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Fri Sep 28 07:38:30 2012 Return-Path: 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 1B71021F8476 for ; Fri, 28 Sep 2012 07:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.466 X-Spam-Level: X-Spam-Status: No, score=-110.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 rViUSAEcA2BI for ; Fri, 28 Sep 2012 07:38:29 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2B36521F846F for ; Fri, 28 Sep 2012 07:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4595; q=dns/txt; s=iport; t=1348843109; x=1350052709; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v+j/JaG5ZlIfVBEa417dCjkyLKtW6hVF1GlMi6GS5OY=; b=H5kmi2oYUbIDDDADM/Rji2eey0SiiSkFturTqXiC4CfvZtlatgYzlGmD 1BmQyn5z+vp1c7xjHEqqe9qq8v49ONgwIlX0RZtj/QXA/Aqi5ZBJzpWpL cIx7xRJbylsQ9RZkB217ICpgyyd4NBzMwXakkYen9yoDw0LluyjxfmJXM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADG1ZVCtJXHA/2dsb2JhbAA7Cr4OgQiCIAEBAQMBAQEBDwEnMQMLBQsCAQgYHhAnCyUCBA4FCRmHXQYLl2ygLIsYEAqFLWADlWmOQoFpgmeBYzQ X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="126382681" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 28 Sep 2012 14:38:28 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8SEcSla032014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Sep 2012 14:38:28 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 09:38:28 -0500 From: "Cullen Jennings (fluffy)" To: "Miguel A. Garcia" Thread-Topic: [MMUSIC] Poll for path on ICE extensions and updates/corrections Thread-Index: AQHNnYbseSeIiXneQkWkn5ST/JrUog== Date: Fri, 28 Sep 2012 14:38:28 +0000 Message-ID: References: <505972DD.3060908@ericsson.com> <506451A8.5060207@ericsson.com> In-Reply-To: <506451A8.5060207@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19216.004 x-tm-as-result: No--52.028100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <40840D6BD857294D8057BF358670D079@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , Ari Keranen , mmusic Subject: Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections X-BeenThere: mmusic@ietf.org 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, 28 Sep 2012 14:38:30 -0000 I like this plan and thank you Ari.=20 On Sep 27, 2012, at 7:16 AM, Miguel A. Garcia wrote: > Let me try to conclude this poll. >=20 > We have seen a significant amount of people leaning towards option b. I r= eproduce hereby the selected option: >=20 > b) Create a revision of ICE (obsoleting RFC 5245), but only addressing > bug fixing and opening hooks to extensions, with the idea that > extensions won't need to violate 5245bis. Additionally, document each > extension in a separate RFC. Extensions will depend and refer to the > 5245bis draft. >=20 >=20 > Then there were some comments indicating that we can go one step further = and make ICE independent of the SDP Offer/answer, and document the SDP offe= r/answer for ICE in a different document. >=20 > So, we should work with the assumption that there will be a kind of ICE f= ramework, and the usages and extensions to it, of which, the SDP O/A usage = will be one. >=20 > To do this work, the chairs have been looking for a volunteer who has eno= ugh spare cycles and expertise to drive this work. We have recruited Ari Ke= ranen to edit ICE-bis according to what we just described. >=20 > Let's welcome Ari on board and thank him for committing to this effort. >=20 > Due to other Ari's commitments and the current schedule, we expect the fi= rst version of 5245bis to be available after the IETF meeting in Atlanta. >=20 >=20 > /Miguel >=20 >=20 >=20 > On 19/09/2012 9:23, Miguel A. Garcia wrote: >> Hi all, >>=20 >> This mail relates to ICE [RFC 5245]. >>=20 >> In the past few months, we have seen a number of documents that are >> trying to improve the usage of ICE in different ways. The list of >> documents include at least the following drafts: >>=20 >> - draft-keranen-mmusic-ice-address-selection-01 >> - draft-petithuguenin-mmusic-ice-attributes-level-03 >> - draft-wing-mmusic-ice-mobility-01 >> - draft-elwell-mmusic-ice-updated-offer-02 >>=20 >> There is, in addition, a long discussion in the RTCWEB mailing list >> about "trickle ICE", and a couple of other ICE-related drafts >> and discussions in RTCWEB. >>=20 >> Most likely, we can categorize these documents in two big classes: >>=20 >> a) Documents that identify underspecified areas or errors in the spec, >> which are often driven by implementation experience >>=20 >> b) Documents that update or extend ICE with new functionality, such as >> "tricke ICE" (see e.g. the e-mail thread at >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html) . >> Such documents may involve normative updates to the ICE specification or >> they may simply be ICE extensions.". >>=20 >> Assuming that we would get consensus to adopt some or all of these >> documents as work to proceed on, the MMUSIC chairs and RAI ADs would >> like to get some sense of how should we aim at documenting it. Below >> are some options, please comment on them or add alternatives. >>=20 >> a) Create a revision of ICE (i.e., a document what will obsolete RFC >> 5245), including all the extensions and corrections that >> we want to choose from the list. This sounds like a big effort in >> time, and presumably will create a big spec. We should make sure that >> people have enough cycles to devote to this activity. >>=20 >> b) Create a revision of ICE (obsoleting RFC 5245), but only addressing >> bug fixing and opening hooks to extensions, with the idea that >> extensions won't need to violate 5245bis. Additionally, document each >> extension in a separate RFC. Extensions will depend and refer to the >> 5245bis draft. >>=20 >> c) Leave the current ICE core spec as is. Document each extension >> separately (referring to 5245). Create open or more documents listing >> bug fixes and corrections (will also update RFC 5245). >>=20 >> Needless to say, at this point in time, there is no decision as for >> which of the ICE-related drafts will proceed or not. We are just >> trying to get consensus of how to document ICE-related drafts, and in >> particular if the WG believes we should do a revision of RFC 5245. If so= , >> we also need to hear who is willing to work on such a revision. >>=20 >> Now, it is your time to express your opinion. >>=20 >> Kindly regards, >>=20 >> Flemming and Miguel. >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Fri Sep 28 07:47:20 2012 Return-Path: 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 ACD8B21F8628 for ; Fri, 28 Sep 2012 07:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 pJW8Cdz6Yliw for ; Fri, 28 Sep 2012 07:47:20 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E07E921F84BF for ; Fri, 28 Sep 2012 07:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2915; q=dns/txt; s=iport; t=1348843640; x=1350053240; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KA28R2PNV9vAGVSx4leJQBOcfep28Sfk8CZ/bi5e/YU=; b=ZZ5A2YkcG0ooTCxDhm9QUFYEQbmr9uxOIk7ODm8kUfxJXOZ43g4AA86i xejOplmzrZMZ+E2FvVxPQHrsHgumwoBuSbZVgt8N4tq0b/FUsMAVOpEBN VaH/WJb4+/t3YK7KDsix7svxXUSjw963Rj9+1+hiW6kKyC4XQp7hDEB+n w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJa3ZVCtJV2c/2dsb2JhbABFvg6BCIIgAQEBAwEBAQEPAQpRCwULAgEIRicLJQIEDgUJGYddBguXdaAtixiFR2ADiCONRoEVjS2BaYJnghc X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="126165730" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 28 Sep 2012 14:47:19 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8SElJKc032375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Sep 2012 14:47:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 09:47:18 -0500 From: "Cullen Jennings (fluffy)" To: mmusic WG Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Thread-Index: AQHNnYgoPhU3mgiCxkWI0jnahkNycg== Date: Fri, 28 Sep 2012 14:47:18 +0000 Message-ID: <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com> References: <5049096F.7080908@cisco.com> In-Reply-To: <5049096F.7080908@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19216.004 x-tm-as-result: No--48.647000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <282499678C56C746A1E668DFD8A1D6DA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org 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, 28 Sep 2012 14:47:20 -0000 Major comment=20 I think the title stuff should be split out to a separate draft. The main r= eason is that you might want to build a dvicd that supported title but did = not supper the others and still be able to say what you were doing was RFC = X. For example, the RTC Web folks may want to use this. Given the Title is meant to be human readable, I think it needs to be exten= ded to have normal i18n support.=20 Cullen On Sep 6, 2012, at 2:37 PM, Flemming Andreasen wrote: > This is to announce a 2 week Working Group Last Call for=20 >=20 > draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt=20 >=20 > as Proposed Standard. Please review and provide any comments you may have= on the document by September 21, 2012. Comments should be sent to the docu= ment authors and the MMUSIC WG list.=20 >=20 >=20 > Thanks=20 >=20 > Flemming >=20 >=20 >=20 >=20 > Draft Info: > This draft is a work item of the Multiparty Multimedia Session Control W= orking Group of the IETF. >=20 > Title : Miscellanoues Capabilities Negotiation in the Session = Description Protocol (SDP) > Author(s) : Miguel A. Garcia-Martin > Simo Veikkolainen > Robert R. Gilman > Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt > Pages : 19 > Date : 2012-08-27 >=20 > Abstract: > SDP has been extended with a capability negotiation mechanism > framework that allows the endpoints to negotiate transport protocols > and attributes. This framework has been extended with a media > capabilities negotiation mechanism that allows endpoints to negotiate > additional media-related capabilities. This negotiation is embedded > into the widely-used SDP offer/answer procedures. >=20 > This memo extends the SDP capability negotiation framework to allow > endpoints to negotiate three additional SDP capabilities. In > particular, this memo provides a mechanism to negotiate bandwidth > ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line = for > each session or media). >=20 >=20 > The IETF datatracker status page for this draft is: >=20 > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps >=20 >=20 > There's also a htmlized version available at: >=20 > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 >=20 >=20 > A diff from the previous version is available at: >=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-ca= ps-01 >=20 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: >=20 > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From atle.monrad@ericsson.com Fri Sep 28 08:02:30 2012 Return-Path: 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 4E04221F8658 for ; Fri, 28 Sep 2012 08:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 JZiPm2GicAgk for ; Fri, 28 Sep 2012 08:02:28 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9785E21F8620 for ; Fri, 28 Sep 2012 08:02:27 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-7c-5065bc02a7ef Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E3.F3.11467.20CB5605; Fri, 28 Sep 2012 17:02:26 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.2.64]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 28 Sep 2012 17:02:26 +0200 From: Atle Monrad To: "Cullen Jennings (fluffy)" , mmusic WG Date: Fri, 28 Sep 2012 17:02:25 +0200 Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Thread-Index: AQHNnYgoPhU3mgiCxkWI0jnahkNycpef1stw Message-ID: <7A051DFAA46D0246A82293C7CEF621E9070A0D27D0@ESESSCMS0352.eemea.ericsson.se> References: <5049096F.7080908@cisco.com> <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com> In-Reply-To: <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvrS7TntQAg+OPlSw2nTnGZPH+gq5F x2Q2i6nLH7M4sHhM+b2R1WPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgyuj7rV3QIlfx6/g7 xgbGJ+JdjJwcEgImEovezmOGsMUkLtxbz9bFyMUhJHCKUeLlilesEM4CRokpTXvYQarYBHQk zv28A5Tg4BAR8JN4vK8GpIZZYCOjRPe6a2CTWARUJRomLmQBqREWCJCYvkUbojxQ4tgZJZAK EQEjiS/Xm9lAbF6BcInWp31MILaQQLTElp2zGUFsTgFbidV/foBNYRSQlZjbxAsSZhYQl7j1 ZD4TxMkCEkv2nIc6X1Ti5eN/rCA2o4CMxIqt39gg6nUkFuz+BGVrSyxb+JoZYq2gxMmZT1gm MIrNQjJ2FpKWWUhaZiFpWcDIsopRODcxMye93FAvtSgzubg4P0+vOHUTIzCeDm75rbuD8dQ5 kUOM0hwsSuK8XEn7/YUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwxr/TMLVZPTNA77bsd6bK 6k/ia2cb34soeLhw5fzfm5w3KH82m5iXLatUdlZJ94L6l9WPWPtkIqQ7pNLCIipz+Q+G/M46 bLRS83qkfqpJzatl7/PVc1YYNF2/We9/0mJyUeLpsh7RiRvf9onfUz5YqBpT+mh14rUbtrfc q/7PFLP6n98wfZm0EktxRqKhFnNRcSIAgiqHN3UCAAA= Cc: "Flemming Andreasen \(fandreas\)" , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org 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, 28 Sep 2012 15:02:30 -0000 Hi Is it really necessary to chop the draft up in pieces because others may wa= nt to use just parts of it?=20 I find it more constuctive to finish this draft as is and let other be able= to build on and refer to the RFC if and when possible. /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Cullen Jennings (fluffy) Sent: 28. september 2012 16:47 To: mmusic WG Cc: Flemming Andreasen (fandreas); draft-ietf-mmusic-sdp-miscellaneous-caps= @tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.= txt Major comment=20 I think the title stuff should be split out to a separate draft. The main r= eason is that you might want to build a dvicd that supported title but did = not supper the others and still be able to say what you were doing was RFC = X. For example, the RTC Web folks may want to use this. Given the Title is meant to be human readable, I think it needs to be exten= ded to have normal i18n support.=20 Cullen On Sep 6, 2012, at 2:37 PM, Flemming Andreasen wrote: > This is to announce a 2 week Working Group Last Call for >=20 > draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >=20 > as Proposed Standard. Please review and provide any comments you may have= on the document by September 21, 2012. Comments should be sent to the docu= ment authors and the MMUSIC WG list.=20 >=20 >=20 > Thanks >=20 > Flemming >=20 >=20 >=20 >=20 > Draft Info: > This draft is a work item of the Multiparty Multimedia Session Control W= orking Group of the IETF. >=20 > Title : Miscellanoues Capabilities Negotiation in the Session = Description Protocol (SDP) > Author(s) : Miguel A. Garcia-Martin > Simo Veikkolainen > Robert R. Gilman > Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt > Pages : 19 > Date : 2012-08-27 >=20 > Abstract: > SDP has been extended with a capability negotiation mechanism > framework that allows the endpoints to negotiate transport protocols > and attributes. This framework has been extended with a media > capabilities negotiation mechanism that allows endpoints to negotiate > additional media-related capabilities. This negotiation is embedded > into the widely-used SDP offer/answer procedures. >=20 > This memo extends the SDP capability negotiation framework to allow > endpoints to negotiate three additional SDP capabilities. In > particular, this memo provides a mechanism to negotiate bandwidth > ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line = for > each session or media). >=20 >=20 > The IETF datatracker status page for this draft is: >=20 > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-c > aps >=20 >=20 > There's also a htmlized version available at: >=20 > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 >=20 >=20 > A diff from the previous version is available at: >=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-c > aps-01 >=20 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: >=20 > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From daveoran@orandom.net Fri Sep 28 09:01:07 2012 Return-Path: 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 534EC21F8516; Fri, 28 Sep 2012 09:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 xE9PHU-5-ezY; Fri, 28 Sep 2012 09:01:06 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2001:470:d:21b:3c00::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7B121F8471; Fri, 28 Sep 2012 09:01:06 -0700 (PDT) Received: from stealth-10-32-245-146.cisco.com (c-66-31-41-8.hsd1.ma.comcast.net [66.31.41.8]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id q8SG16cj008491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Sep 2012 09:01:08 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: David R Oran In-Reply-To: Date: Fri, 28 Sep 2012 12:00:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <97905CD5-CDAE-4D08-AF5B-941C5F4DC703@orandom.net> References: <505188C7.1080805@ericsson.com> <5065A316.4010503@cisco.com> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1498) X-Mailman-Approved-At: Fri, 28 Sep 2012 10:13:50 -0700 Cc: "draft-begen-mmusic-temporal-interleaving@tools.ietf.org" , "draft-begen-mmusic-redundancy-grouping@tools.ietf.org" , "avtext@ietf.org" , mmusic , "draft-ietf-avtext-rtp-duplication@tools.ietf.org" Subject: Re: [MMUSIC] [avtext] WG Poll for consensus on duplicated streams X-BeenThere: mmusic@ietf.org 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, 28 Sep 2012 16:01:07 -0000 +1 DaveO On Sep 28, 2012, at 10:36 AM, "Cullen Jennings (fluffy)" = wrote: >=20 > I'm in favor of adopting these. They are simple and solve the problem. >=20 >=20 > On Sep 28, 2012, at 7:16 AM, Flemming Andreasen = wrote: >=20 >> MMUSIC and AVTEXT folks >>=20 >> It is our understanding that AVTEXT is conducting work that depends = on the below two drafts, and hence MMUSIC is considering adopting them = as WG items. The MMUSIC chairs issued a WG poll for adoption of the = drafts, however we have not received much feedback on this. Please take = a minute to indicate if you are in favor of (or against) adopting these = drafts as MMUSIC WG items.=20 >>=20 >> Thanks=20 >>=20 >> -- Flemming & Miguel (MMUSIC co-chairs).=20 >>=20 >>=20 >> -------- Original Message -------- >> Subject: WG Poll for consensus on duplicated streams >> Date: Thu, 13 Sep 2012 09:18:31 +0200 >> From: Miguel A. Garcia >> To: mmusic , Flemming Andreasen = >>=20 >> At the last IETF meeting we had presentation of two drafts, both >> related to the expression of duplicated streams in SDP. We noticed >> there was support to progress these drafts. These drafts are >> complementary to work going on in AVTEXT, where there is a normative >> dependency. >>=20 >> These are the documents: >>=20 >>=20 >> = http://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ >> = http://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/ >>=20 >>=20 >> We would like to poll the working group for adopting these two >> documents as WG items, once we get approved milestones. >>=20 >> Please indicate whether you support or not this new work within the >> next 5 working days. >>=20 >> Flemming and Miguel (co-chairs). >>=20 >> /Miguel >> --=20 >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >>=20 >> . >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From dwing@cisco.com Fri Sep 28 10:58:40 2012 Return-Path: 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 2C41521F8475 for ; Fri, 28 Sep 2012 10:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 ZLXZQx6mRTid for ; Fri, 28 Sep 2012 10:58:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7C17321F8459 for ; Fri, 28 Sep 2012 10:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1295; q=dns/txt; s=iport; t=1348855119; x=1350064719; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=Ya2TGIevY3n0K76H9T3nutd99rRwnA9AciJ5tEIUYCs=; b=GCYnNccyH8j/SbFX7ZDNZ5GQ2CL/1cSQRtMGwrgsI1M8o5UmRBSiVWDH OthNe5FKQ3jDtBFoph0CoALraEEc5ZfF9tbXChaqYEgFXg+a7rjlIhrBi WqTBpTg+kV2vZfjra53Gsd6zpk5MisljWyrI5LZpejIDhxXZJ1hD2HTpn w=; X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="126491375" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 28 Sep 2012 17:58:38 +0000 Received: from dwingWS ([10.32.240.194]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8SHwbLN010695; Fri, 28 Sep 2012 17:58:38 GMT From: "Dan Wing" To: "'Miguel A. Garcia'" , "'mmusic'" , "'Flemming Andreasen'" References: <505188C7.1080805@ericsson.com> In-Reply-To: <505188C7.1080805@ericsson.com> Date: Fri, 28 Sep 2012 10:58:37 -0700 Message-ID: <07b701cd9da2$e331ffe0$a995ffa0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2Rf/57kOa54ehtQXGGB5DlfLb+FwMIrl8g Content-Language: en-us Subject: Re: [MMUSIC] WG Poll for consensus on duplicated streams X-BeenThere: mmusic@ietf.org 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, 28 Sep 2012 17:58:40 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Miguel A. Garcia > Sent: Thursday, September 13, 2012 12:19 AM > To: mmusic; Flemming Andreasen > Subject: [MMUSIC] WG Poll for consensus on duplicated streams > > At the last IETF meeting we had presentation of two drafts, both > related to the expression of duplicated streams in SDP. We noticed > there was support to progress these drafts. These drafts are > complementary to work going on in AVTEXT, where there is a normative > dependency. > > These are the documents: > > http://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ > http://datatracker.ietf.org/doc/draft-begen-mmusic-temporal- > interleaving/ > > We would like to poll the working group for adopting these two > documents as WG items, once we get approved milestones. I support adopting both documents. -d > Please indicate whether you support or not this new work within the > next 5 working days. > > Flemming and Miguel (co-chairs). > > /Miguel > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From vsingh.ietf@gmail.com Fri Sep 28 16:46:57 2012 Return-Path: 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 8C0DC21F859B for ; Fri, 28 Sep 2012 16:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 WoKuriS-jBXk for ; Fri, 28 Sep 2012 16:46:56 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC63421F849A for ; Fri, 28 Sep 2012 16:46:56 -0700 (PDT) Received: by danh15 with SMTP id h15so817839dan.31 for ; Fri, 28 Sep 2012 16:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type; bh=Unw7RRtZcIPOis8xZFeOdT4WYE0ZVZzLk7ZuDCPf588=; b=W5enRWd5hE78+slfIkwOEIQp/ww048ejShasr4cdi7ZuvZZli1U1tTB9hEL9noGceg v0hYPvBFmkTExTkWkvjYVCxbS5VHL3z56XMxUhcD/9UCY2uzMBD72zZF9bzkMIz6/CHv joDWGoSqE2qG6IPVsUtUQO9OKe90SzSOleKyLpxR/YB3gJs1uqtBuYkw61IIfSbulniE DwEXCNS24PUtt/GbEnDn0+GJNLgGpBPrQXpyTA+9ZlIOdckPq1L3VXPKkAeH8kmH9obv 85pCVGORHiAlW5RryQOMwDNNkAI6KIkYvIGA9W73f/zT5LHduw3LVm7SKq/c1HA8yv5G vI0Q== Received: by 10.68.189.69 with SMTP id gg5mr24006348pbc.36.1348876016085; Fri, 28 Sep 2012 16:46:56 -0700 (PDT) References: <505188C7.1080805@ericsson.com> <5065A316.4010503@cisco.com> <805AA23C-8A81-4B3C-9DA8-614EB4A1D516@csperkins.org> From: Varun Singh Mime-Version: 1.0 (1.0) In-Reply-To: <805AA23C-8A81-4B3C-9DA8-614EB4A1D516@csperkins.org> Date: Sat, 29 Sep 2012 02:46:53 +0300 Message-ID: <8732738426762856648@unknownmsgid> To: mmusic Content-Type: multipart/alternative; boundary=e89a8ff1bfb2c8eb5c04cacbab6f Cc: Flemming Andreasen Subject: Re: [MMUSIC] WG Poll for consensus on duplicated streams X-BeenThere: mmusic@ietf.org 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, 28 Sep 2012 23:46:57 -0000 --e89a8ff1bfb2c8eb5c04cacbab6f Content-Type: text/plain; charset=ISO-8859-1 I'm in favor as well for adopting these drafts. Regards, Varun ---- http://www.netlab.tkk.fi/~varun On 28.9.2012, at 16.57, Colin Perkins wrote: Flemming, We need these to support our rtp-duplication draft, so I'm in favour. Colin On 28 Sep 2012, at 14:16, Flemming Andreasen wrote: MMUSIC and AVTEXT folks It is our understanding that AVTEXT is conducting work that depends on the below two drafts, and hence MMUSIC is considering adopting them as WG items. The MMUSIC chairs issued a WG poll for adoption of the drafts, however we have not received much feedback on this. Please take a minute to indicate if you are in favor of (or against) adopting these drafts as MMUSIC WG items. Thanks -- Flemming & Miguel (MMUSIC co-chairs). -------- Original Message -------- Subject: WG Poll for consensus on duplicated streams Date: Thu, 13 Sep 2012 09:18:31 +0200 From: Miguel A. Garcia To: mmusic , Flemming Andreasen At the last IETF meeting we had presentation of two drafts, both related to the expression of duplicated streams in SDP. We noticed there was support to progress these drafts. These drafts are complementary to work going on in AVTEXT, where there is a normative dependency. These are the documents: http://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/http://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/ We would like to poll the working group for adopting these two documents as WG items, once we get approved milestones. Please indicate whether you support or not this new work within the next 5 working days. Flemming and Miguel (co-chairs). /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --e89a8ff1bfb2c8eb5c04cacbab6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm in favor as well for adopt= ing these drafts.=A0

Regards,
Varun

On 28.9.2012, at 16.57, Colin Perki= ns <csp@csperkins.org> wrote= :

Flemming,

We ne= ed these to support our rtp-duplication draft, so I'm in favour.
<= div>
Colin


On 28 Sep 2= 012, at 14:16, Flemming Andreasen wrote:
=20 =20
MMUSIC and AVTEXT folks

It is our understanding that AVTEXT is conducting work that depends on the below two drafts, and hence MMUSIC is considering adopting them as WG items. The MMUSIC chairs issued a WG poll for adoption of the drafts, however we have not received much feedback on this. Please take a minute to indicate if you are in favor of (or against) adopting these drafts as MMUSIC WG items.

Thanks

-- Flemming & Miguel (MMUSIC co-chairs).


-------- Original Message --------
Subject: WG Poll for consensus on duplicated streams
Date: Thu, 13 Sep 2012 09:18:31 +0200
From: Miguel A. Garcia <Miguel.A.Garcia@ericsson.com><= /a>
To: mmusic <mmusic@ietf.org>, Flemming Andreasen <fandreas@cisco.com> 


At the last IETF meeting we had presentation of two drafts, both
related to the expression of duplicated streams in SDP. We noticed
there was support to progress these drafts. These drafts are
complementary to work going on in AVTEXT, where there is a normative
dependency.

These are the documents:

http://datatracker.ietf.org/doc/dr=
aft-begen-mmusic-redundancy-grouping/
http://datatracker.ietf.org/doc/=
draft-begen-mmusic-temporal-interleaving/

We would like to poll the working group for adopting these two
documents as WG items, once we get approved milestones.

Please indicate whether you support or not this new work within the
next 5 working days.

Flemming and Miguel (co-chairs).

/Miguel
--=20
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
--=A0
Colin Perkins



_________= ______________________________________
mmusic mailing list<= /span>
mmusic@ietf.org
https://www.= ietf.org/mailman/listinfo/mmusic
--e89a8ff1bfb2c8eb5c04cacbab6f-- From miguel.a.garcia@ericsson.com Sat Sep 29 00:35:02 2012 Return-Path: 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 03FDD21F851B for ; Sat, 29 Sep 2012 00:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 nTEXgva3iZCa for ; Sat, 29 Sep 2012 00:35:01 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BAA1B21F84EA for ; Sat, 29 Sep 2012 00:35:00 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-19-5066a4a2f2e9 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 55.46.25676.2A4A6605; Sat, 29 Sep 2012 09:34:59 +0200 (CEST) Received: from [164.48.161.175] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.1; Sat, 29 Sep 2012 09:34:57 +0200 Message-ID: <5066A49F.2040002@ericsson.com> Date: Sat, 29 Sep 2012 09:34:55 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Atle Monrad References: <5049096F.7080908@cisco.com> <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D27D0@ESESSCMS0352.eemea.ericsson.se> In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E9070A0D27D0@ESESSCMS0352.eemea.ericsson.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvre7iJWkBBjuesFtsOnOMyeL9BV2L jslsFlOXP2ZxYPGY8nsjq8eSJT+ZPL5c/swWwBzFZZOSmpNZllqkb5fAlbHiTmrBJ6WK8zs6 2RsYz0t3MXJySAiYSCz+8J8NwhaTuHBvPZDNxSEkcIpR4vnP3ewQzhpGiYN734BV8QpoS3Q2 3GQBsVkEVCUm7J/GCmKzCZhLtG7cyA5iiwoES5zbuA2qXlDi5MwnYPUiAloSrV17mECGMgs0 Mkk07uwGKuLgEBbwk3j+ORti2VJGiX2P1zKBNHAKREg82doONohZwFbiwpzrLBC2vMT2t3OY QWwhAU2JyTeXMk9gFJyFZN8sJC2zkLQsYGRexSicm5iZk15upJdalJlcXJyfp1ecuokRGMYH t/xW3cF455zIIUZpDhYlcV7rrXv8hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDunmZRWbrE 4N0W7ZCOBRa3xH+dTLn5Sv7Ij9+mla1zmc/5/3GQem6vYPzh8IRlMVX2FaW34jhdNp5K9uOy fLi3RojB3izm2DV51VaNKt2EkCnNuV+Zrwi7P3pbXPGt+21i1HbWwL703YfuHDpfflFBSp9l YoXHLPbDFm/XrnDIP++2rOFBzyclluKMREMt5qLiRACpiByDMQIAAA== Cc: "Cullen Jennings \(fluffy\)" , "Flemming Andreasen \(fandreas\)" , mmusic WG , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org 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: Sat, 29 Sep 2012 07:35:02 -0000 Cullen, The draft is written as an independent collection of "objects". This is avoid having three separate drafts. It is possible to refer to parts of this draft. For example, I believe 3GPP only needs the connection data capability, but not the others, and still they are fine with this draft. Couldn't the same principle be applied by RTCweb? /Miguel On 28/09/2012 17:02, Atle Monrad wrote: > Hi > > Is it really necessary to chop the draft up in pieces because others may want to use just parts of it? > > I find it more constuctive to finish this draft as is and let other be able to build on and refer to the RFC if and when possible. > > /atle > > ________________________________ > > > Atle Monrad > 3GPP CT Chairman > Standardization and Regulation, > Group Function Technology and Portfolio Management > Ericsson > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy) > Sent: 28. september 2012 16:47 > To: mmusic WG > Cc: Flemming Andreasen (fandreas); draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org > Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt > > > Major comment > > I think the title stuff should be split out to a separate draft. The main reason is that you might want to build a dvicd that supported title but did not supper the others and still be able to say what you were doing was RFC X. For example, the RTC Web folks may want to use this. > > Given the Title is meant to be human readable, I think it needs to be extended to have normal i18n support. > > Cullen > > > > On Sep 6, 2012, at 2:37 PM, Flemming Andreasen wrote: > >> This is to announce a 2 week Working Group Last Call for >> >> draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >> >> as Proposed Standard. Please review and provide any comments you may have on the document by September 21, 2012. Comments should be sent to the document authors and the MMUSIC WG list. >> >> >> Thanks >> >> Flemming >> >> >> >> >> Draft Info: >> This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. >> >> Title : Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP) >> Author(s) : Miguel A. Garcia-Martin >> Simo Veikkolainen >> Robert R. Gilman >> Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >> Pages : 19 >> Date : 2012-08-27 >> >> Abstract: >> SDP has been extended with a capability negotiation mechanism >> framework that allows the endpoints to negotiate transport protocols >> and attributes. This framework has been extended with a media >> capabilities negotiation mechanism that allows endpoints to negotiate >> additional media-related capabilities. This negotiation is embedded >> into the widely-used SDP offer/answer procedures. >> >> This memo extends the SDP capability negotiation framework to allow >> endpoints to negotiate three additional SDP capabilities. In >> particular, this memo provides a mechanism to negotiate bandwidth >> ('b=' line), connection data ('c=' line), and titles ('i=' line for >> each session or media). >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-c >> aps >> >> >> There's also a htmlized version available at: >> >> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 >> >> >> A diff from the previous version is available at: >> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-c >> aps-01 >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ari.keranen@nomadiclab.com Sun Sep 30 14:33:37 2012 Return-Path: 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 BD4D521F84DF for ; Sun, 30 Sep 2012 14:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 aMwlyDTl9G1r for ; Sun, 30 Sep 2012 14:33:36 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEB821F84CE for ; Sun, 30 Sep 2012 14:33:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 50FFE4E6EE; Mon, 1 Oct 2012 00:33:31 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjFS1nE4Vz7b; Mon, 1 Oct 2012 00:33:28 +0300 (EEST) Received: from as-macbook-air.p-661hnu-f1 (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 4AEFE4E6E8; Mon, 1 Oct 2012 00:33:28 +0300 (EEST) Message-ID: <5068BAAA.6070400@nomadiclab.com> Date: Mon, 01 Oct 2012 00:33:30 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" , "Miguel A. Garcia" , mmusic References: <505972DD.3060908@ericsson.com> <506451A8.5060207@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Flemming Andreasen \(fandreas\)" , Ari Keranen Subject: Re: [MMUSIC] Poll for path on ICE extensions and updates/corrections X-BeenThere: mmusic@ietf.org 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: Sun, 30 Sep 2012 21:33:37 -0000 Thanks Cullen and Miguel. Everyone, now is a good time to start thinking and discussing what are the bugs we want to fix and what kind of extension hooks are needed for ICE. The current drafts provide a good starting point for that, but probably there are other issues worth taking into consideration too. I will be out of office without e-mail access for the next 4 weeks, but looking forward to discuss these issues with you all at Atlanta. Cheers, Ari On 9/28/12 5:38 PM, Cullen Jennings (fluffy) wrote: > > I like this plan and thank you Ari. > > > > On Sep 27, 2012, at 7:16 AM, Miguel A. Garcia wrote: > >> Let me try to conclude this poll. >> >> We have seen a significant amount of people leaning towards option b. I reproduce hereby the selected option: >> >> b) Create a revision of ICE (obsoleting RFC 5245), but only addressing >> bug fixing and opening hooks to extensions, with the idea that >> extensions won't need to violate 5245bis. Additionally, document each >> extension in a separate RFC. Extensions will depend and refer to the >> 5245bis draft. >> >> >> Then there were some comments indicating that we can go one step further and make ICE independent of the SDP Offer/answer, and document the SDP offer/answer for ICE in a different document. >> >> So, we should work with the assumption that there will be a kind of ICE framework, and the usages and extensions to it, of which, the SDP O/A usage will be one. >> >> To do this work, the chairs have been looking for a volunteer who has enough spare cycles and expertise to drive this work. We have recruited Ari Keranen to edit ICE-bis according to what we just described. >> >> Let's welcome Ari on board and thank him for committing to this effort. >> >> Due to other Ari's commitments and the current schedule, we expect the first version of 5245bis to be available after the IETF meeting in Atlanta. >> >> >> /Miguel >> >> >> >> On 19/09/2012 9:23, Miguel A. Garcia wrote: >>> Hi all, >>> >>> This mail relates to ICE [RFC 5245]. >>> >>> In the past few months, we have seen a number of documents that are >>> trying to improve the usage of ICE in different ways. The list of >>> documents include at least the following drafts: >>> >>> - draft-keranen-mmusic-ice-address-selection-01 >>> - draft-petithuguenin-mmusic-ice-attributes-level-03 >>> - draft-wing-mmusic-ice-mobility-01 >>> - draft-elwell-mmusic-ice-updated-offer-02 >>> >>> There is, in addition, a long discussion in the RTCWEB mailing list >>> about "trickle ICE", and a couple of other ICE-related drafts >>> and discussions in RTCWEB. >>> >>> Most likely, we can categorize these documents in two big classes: >>> >>> a) Documents that identify underspecified areas or errors in the spec, >>> which are often driven by implementation experience >>> >>> b) Documents that update or extend ICE with new functionality, such as >>> "tricke ICE" (see e.g. the e-mail thread at >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html) . >>> Such documents may involve normative updates to the ICE specification or >>> they may simply be ICE extensions.". >>> >>> Assuming that we would get consensus to adopt some or all of these >>> documents as work to proceed on, the MMUSIC chairs and RAI ADs would >>> like to get some sense of how should we aim at documenting it. Below >>> are some options, please comment on them or add alternatives. >>> >>> a) Create a revision of ICE (i.e., a document what will obsolete RFC >>> 5245), including all the extensions and corrections that >>> we want to choose from the list. This sounds like a big effort in >>> time, and presumably will create a big spec. We should make sure that >>> people have enough cycles to devote to this activity. >>> >>> b) Create a revision of ICE (obsoleting RFC 5245), but only addressing >>> bug fixing and opening hooks to extensions, with the idea that >>> extensions won't need to violate 5245bis. Additionally, document each >>> extension in a separate RFC. Extensions will depend and refer to the >>> 5245bis draft. >>> >>> c) Leave the current ICE core spec as is. Document each extension >>> separately (referring to 5245). Create open or more documents listing >>> bug fixes and corrections (will also update RFC 5245). >>> >>> Needless to say, at this point in time, there is no decision as for >>> which of the ICE-related drafts will proceed or not. We are just >>> trying to get consensus of how to document ICE-related drafts, and in >>> particular if the WG believes we should do a revision of RFC 5245. If so, >>> we also need to hear who is willing to work on such a revision. >>> >>> Now, it is your time to express your opinion. >>> >>> Kindly regards, >>> >>> Flemming and Miguel. >>> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >