From fluffy@cisco.com Sun Aug 1 06:51:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48CC53A6895 for ; Sun, 1 Aug 2010 06:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.496 X-Spam-Level: X-Spam-Status: No, score=-110.496 tagged_above=-999 required=5 tests=[AWL=0.102, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FyhdxO6-EMu for ; Sun, 1 Aug 2010 06:51:03 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 196BA3A69E6 for ; Sun, 1 Aug 2010 06:50:47 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGcYVUyrR7H+/2dsb2JhbACBQ55ScaMqmX6CcBMIgi4EhBaEaQ X-IronPort-AV: E=Sophos;i="4.55,298,1278288000"; d="scan'208,217";a="566946019" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 01 Aug 2010 13:51:13 +0000 Received: from [10.21.75.26] ([10.21.75.26]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o71DpCDF000750 for ; Sun, 1 Aug 2010 13:51:13 GMT From: Cullen Jennings Content-Type: multipart/alternative; boundary=Apple-Mail-1--431721495 Date: Sun, 1 Aug 2010 06:51:12 -0700 References: To: "dispatch@ietf.org list" Message-Id: <1470087F-2978-478A-A186-34255CBB499E@cisco.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [dispatch] Fwd: [New-work] New ITU-T Study Group 16 Question: "Telepresence systems" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 13:51:05 -0000 --Apple-Mail-1--431721495 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 FWI ...=20 Begin forwarded message: > From: > Date: August 1, 2010 5:16:19 AM PDT > To: > Subject: [New-work] New ITU-T Study Group 16 Question: "Telepresence = systems" >=20 > At its 19-30 July 2010 meeting, ITU-T Study Group 16 agreed to the = creation of a new Question entitled =93Telepresence systems=94: >=20 > New ITU-T Study Group 16 Question 5/16: Telepresence systems >=20 > 1. Motivation=20 > Telepresence represents an important evolution of the = videoconferencing market. This trend is expected to accelerate, as = mainstream video applications begin to offer telepresence features. = Many products exist today that, although they are based on IETF SIP and = ITU-T H.323 protocols, lack interoperability due to proprietary = extensions needed to these base protocols to offer a user-rich = experience. >=20 > The increased penetration of broadband communications and higher user = awareness of video applications, coupled with financial and = environmental gains brought by remote collaboration tools have brought a = boost to applications such as telepresence. This makes it important = that standardized solutions be developed to ensure multi-vendor = interoperability on a global basis. >=20 > 2. Question=20 > Study items to be considered include, but are not limited to: >=20 > Definition and scope of telepresence systems > Functions and service requirements for interoperable telepresence = systems > Standardizing the means for full interworking between telepresence = systems, including means facilitating the coherent presentation of = multiple audio and video streams =96 allowing remote participants to be = rendered at their true size for their apparent distance, maintaining = correct eye contact, gesticular cues, and simultaneously providing = spatial audio that is consistent with the video presentation, as well as = taking into account the meeting environment to provide a more immersive = experience. > Standardizing the means for interworking between current telepresence = systems and other systems, including the legacy telephone network and = advanced multimedia systems, through additions to ITU-T H.246 and other = Recommendations as necessary. > Considerations on how to further enhance telepresence systems to = mitigate negative impact on climate change and to encourage a positive = impact reducing greenhouse gas (GHG) emissions. > 3. Tasks=20 > Tasks include but are not limited to: >=20 > Define services and functions to support interoperability of current = generation telepresence systems using existing protocols such as ITU-T = H.323 and SIP. > Identify modification and/or extensions needed in existing protocols = to support telepresence, in coordination with other standardization = bodies, forums and consortia, as needed. > Modify and/or extend existing protocols under the ITU-T SG 16 = responsibility to enable interoperable telepresence systems (in = particular, Recommendations of the ITU-T H.300 series). > Identify methods for exchange of meeting environment information in = order to allow adaptation between unlike telepresence system = environments. > Provide guidelines to achieve the required user experience for = telepresence systems (such as methods to achieve eye contact, same = lighting environments in separate rooms, audio levels, and echo = cancellation). > Identify requirements for media codecs, taking into account needs for = scalability, multiple views, multiple audio channels, and mixing of = media streams including efficient compressed digital to compressed = digital processing. > Enable interoperable telecoms/ICT accessibility features in = telepresence systems. > Identify requirements towards second-generation telepresence systems. > Consider the role of control systems in telepresence systems. > 4. Relationships=20 > Recommendations:=20 > H. series and relevant F/G/T-series=20 > Questions:=20 > Q1/16 (Multimedia systems and terminals), Q2/16 (H.323 systems), Q3/16 = (Multimedia Gateways), Q4/16 (QoS), Q6/16 (Visual Coding), Q7/16 = (Systems and coordination aspects of media coding), Q10/16 (Speech and = audio coding and related software tools), Q12/16 (AMS), Q13/16 (IPTV), = Q16/16 (Speech enhancement functions in signal processing network = equipment), Q18/16 (Interaction aspects of signal processing network = equipment), Q22/16 (Multimedia applications and services), Q26/16 = (Accessibility to Multimedia Systems and Services) >=20 > Study Groups: >=20 > ITU-T Study Groups: 5 (Environment and Climate Change), 9 (cable, = video quality), 11 (signalling), 12 (QoS, QoE, Quality assessment = methodologies), 13 (NGN, future networks), 17 (Security, languages) > ITU-R Study Group 6 (Broadcasting) > ITU-D Study Group 2 > Standardization bodies, forums and consortia: >=20 > ISO/IEC JTC 1/SC 29 "Coding of audio, picture, multimedia and = hypermedia information" > International Multimedia Teleconferencing Consortium (IMTC) for = interoperability aspects and enhancements to existing Recommendations > IETF Real-time Applications and Infrastructure (RAI) for IETF-defined = protocols > Unified Communications Interoperability Forum (UCIF) for = interoperability aspects between enterprises, service providers, and = consumer clouds. >=20 > _______________________________________________ > New-work mailing list > New-work@ietf.org > https://www.ietf.org/mailman/listinfo/new-work Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-1--431721495 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Date: August 1, 2010 5:16:19 AM PDT
To: <new-work@ietf.org>
Subject: [New-work] New = ITU-T Study Group 16 Question: "Telepresence = systems"

At its 19-30 July 2010 meeting, ITU-T Study Group 16 agreed to = the creation of a new Question entitled =93Telepresence = systems=94:

New ITU-T Study Group 16 Question 5/16:  = Telepresence systems

1. Motivation
Telepresence = represents an important evolution of the videoconferencing market. This = trend is expected to accelerate, as mainstream video applications begin = to offer telepresence features.  Many products exist today that, = although they are based on IETF SIP and ITU-T H.323 protocols, lack = interoperability due to proprietary extensions needed to these base = protocols to offer a user-rich experience.

The increased penetration = of broadband communications and higher user awareness of video = applications, coupled with financial and environmental gains brought by = remote collaboration tools have brought a boost to applications such as = telepresence.  This makes it important that standardized solutions = be developed to ensure multi-vendor interoperability on a global = basis.

2. Question
Study items to = be considered include, but are not limited to:

    • Definition and = scope of telepresence systems
    • Functions and = service requirements for interoperable telepresence = systems
    • Standardizing = the means for full interworking between telepresence systems, including = means facilitating the coherent presentation of multiple audio and video = streams =96 allowing remote participants to be rendered at their true = size for their apparent distance, maintaining correct eye contact, = gesticular cues, and simultaneously providing spatial audio that is = consistent with the video presentation, as well as taking into account = the meeting environment to provide a more immersive = experience.
    • Standardizing = the means for interworking between current telepresence systems and = other systems, including the legacy telephone network and advanced = multimedia systems, through additions to ITU-T H.246 and other = Recommendations as necessary.
    • Considerations = on how to further enhance telepresence systems to mitigate negative = impact on climate change and to encourage a positive impact reducing = greenhouse gas (GHG) emissions.

3. Tasks
Tasks include = but are not limited to:

    • Define services = and functions to support interoperability of current generation = telepresence systems using existing protocols such as ITU-T H.323 and = SIP.
    • Identify = modification and/or extensions needed in existing protocols to support = telepresence, in coordination with other standardization bodies, forums = and consortia, as needed.
    • Modify and/or = extend existing protocols under the ITU-T SG 16 responsibility to enable = interoperable telepresence systems (in particular, Recommendations of = the ITU-T H.300 series).
    • Identify methods = for exchange of meeting environment information in order to allow = adaptation between unlike telepresence system = environments.
    • Provide = guidelines to achieve the required user experience for telepresence = systems (such as methods to achieve eye contact, same lighting = environments in separate rooms, audio levels, and echo = cancellation).
    • Identify = requirements for media codecs, taking into account needs for = scalability, multiple views, multiple audio channels, and mixing of = media streams including efficient compressed digital to compressed = digital processing.
    • Enable = interoperable telecoms/ICT accessibility features in telepresence = systems.
    • Identify = requirements towards second-generation telepresence = systems.
    • Consider the = role of control systems in telepresence systems.

4. Relationships
Recommendations:
H. series and = relevant F/G/T-series
Questions:
Q1/16 = (Multimedia systems and terminals), Q2/16 (H.323 systems), = Q3/16 (Multimedia Gateways), Q4/16 (QoS), Q6/16 (Visual = Coding), Q7/16 (Systems and coordination aspects of media = coding), Q10/16 (Speech and audio coding and related software = tools), Q12/16 (AMS), Q13/16 (IPTV), Q16/16 (Speech = enhancement functions in signal processing network equipment), = Q18/16 (Interaction aspects of signal processing network = equipment), Q22/16 (Multimedia applications and services), = Q26/16 (Accessibility to Multimedia Systems and = Services)

Study Groups:

    • ITU-T Study = Groups: 5 (Environment and = Climate Change), 9 = (cable, video = quality), 11 (signalling), 12 (QoS, QoE, Quality = assessment methodologies), 13 = (NGN, future = networks), 17 (Security, languages)
    • ITU-R Study = Group 6 (Broadcasting)
    • ITU-D Study = Group 2

Standardization bodies, forums and consortia:

    • ISO/IEC JTC 1/SC = 29 "Coding of audio, picture, = multimedia and hypermedia information"
    • International = Multimedia Teleconferencing Consortium (IMTC) for interoperability = aspects and enhancements to existing Recommendations
    • IETF Real-time = Applications and Infrastructure (RAI) for IETF-defined = protocols
    • Unified = Communications Interoperability Forum (UCIF) for interoperability = aspects between enterprises, service providers, and consumer = clouds.

_______________________________________________
New-work mailing = list
New-work@ietf.org
https://www.iet= f.org/mailman/listinfo/new-work


Cullen Jennings
For = corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

= --Apple-Mail-1--431721495-- From adie@radvision.com Sun Aug 1 21:47:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C7B3A6AB8 for ; Sun, 1 Aug 2010 21:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXav2IntHAYO for ; Sun, 1 Aug 2010 21:47:30 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 4C6B93A6AB6 for ; Sun, 1 Aug 2010 21:47:30 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id o724ludU027603 for dispatch@ietf.org; Mon, 2 Aug 2010 07:47:56 +0300 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id o724luIM027597 for ; Mon, 2 Aug 2010 07:47:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB31FD.DFF0A94D" Date: Mon, 2 Aug 2010 07:47:55 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: please remove me from mailing list Thread-Index: Acsx/d+AUl67H2vYSfiDiwotUW2MAQ== From: "Adi Shachar(Even-Tzur)" To: Subject: [dispatch] please remove me from mailing list X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 04:47:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB31FD.DFF0A94D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 thanks, Adi. =20 ------_=_NextPart_001_01CB31FD.DFF0A94D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

thanks,

Adi.

 

------_=_NextPart_001_01CB31FD.DFF0A94D-- From fluffy@cisco.com Mon Aug 2 15:34:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E95D3A689E for ; Mon, 2 Aug 2010 15:34:36 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDrS4A9b+Of2 for ; Mon, 2 Aug 2010 15:34:26 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C9A163A6C4D for ; Mon, 2 Aug 2010 15:34:15 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD7kVkyrR7H+/2dsb2JhbACgA3GqNptQgwMIgi4EhBaEaQ X-IronPort-AV: E=Sophos;i="4.55,305,1278288000"; d="scan'208";a="348533895" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 02 Aug 2010 22:34:25 +0000 Received: from sjc-vpn5-532.cisco.com (sjc-vpn5-532.cisco.com [10.21.90.20]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o72MYOWV020513; Mon, 2 Aug 2010 22:34:25 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Mon, 2 Aug 2010 15:34:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1081) Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 22:34:46 -0000 I would find it more useful to scope it by what is being correlated than = what the many use cases for various correlations might be. One of the = problems with saying the use is troubleshooting is that just about = anything is useful for troubleshooting in some case. I have no = objections to this proposed working group doing what the type of = correlation the SIP REC WG needs but I have no idea what that is - I = suspect this would not meet the needs as far as I understand them.=20 On Jul 30, 2010, at 24:46 , Elwell, John wrote: > Can somebody please remind me why this is scoped only for = troubleshooting. For example, in SIPREC, we anticipate a need for a = Session Recording Server to be able to correlate two recorded sessions = from different Session Recording Clients. For example, if a customer = call is transferred from one agent to a second agent, the two agents = might be using different Session Recording Clients to send media to the = Session Recording Server. What would be the barrier to using session ID = for this case? Is it just the lack of guaranteed uniqueness, or are = there other factors? >=20 > John >=20 >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Victor Pascual Avila >> Sent: 29 July 2010 23:50 >> To: Cullen Jennings >> Cc: dispatch@ietf.org list >> Subject: Re: [dispatch] Proposal for Session ID charter >>=20 >> I like it >>=20 >> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings >> wrote: >>>=20 >>> I tried to write a proposal that I think reflects what the >> proponents of this WG want. Here's my stab at it. >>>=20 >>> ------------------ >>>=20 >>>=20 >>> Troubleshooting SIP networks can be improved by correlating >> messaging across several devices. This working group will >> define a correlation identifier to be used for the >> troubleshooting and the for correlation of logging >> information from different SIP devices in the network. >>>=20 >>> Sip transactions are often triggered by another SIP >> transaction. Two transactions are in the same "session" if >> one was triggered by the other due to redirection, REFER >> processing, retargeting, or forwarding on a B2BUA. This >> working group will define a correlation identifier that >> identifies all the transactions in the same session. The >> scope of the identifier pertains to the SIP signaling layer >> only, and not media. For example, several UA participating >> in a conference call may be receiving the same media but >> would not be in the same session. >>>=20 >>> The design of the correlation identifier needs to take into >> account the issue of not revealing the topology of network. >> The mechanism should be applicable for Proxies, UAs, PBXs, >> SBCs, Application Servers, Softswitches, Phones, and Gateways. >>>=20 >>> This working group will coordinate with other relevant >> working groups and area including Ops, and sipcore. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>=20 >>=20 >>=20 >> -- >> Victor Pascual =C1vila >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From gonzalo.camarillo@ericsson.com Tue Aug 3 01:30:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C903A6924 for ; Tue, 3 Aug 2010 01:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.662 X-Spam-Level: X-Spam-Status: No, score=-105.662 tagged_above=-999 required=5 tests=[AWL=0.937, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av3nczVOfSWh for ; Tue, 3 Aug 2010 01:30:12 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4DF9F3A67AE for ; Tue, 3 Aug 2010 01:30:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-25-4c57d3a6c56d Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F9.BF.10125.7A3D75C4; Tue, 3 Aug 2010 10:30:31 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Aug 2010 10:30:30 +0200 Received: from [131.160.126.136] ([131.160.126.136]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Aug 2010 10:30:30 +0200 Message-ID: <4C57D3A5.8040608@ericsson.com> Date: Tue, 03 Aug 2010 11:30:29 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "R.Jesske@telekom.de" References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2010 08:30:30.0720 (UTC) FILETIME=[22297400:01CB32E6] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 08:30:20 -0000 Hi, to be clear, process-wise if DISPATCH decides this work should be done, I can AD sponsor it. The decision on whether or not this work should be done needs to be made by DISPATCH... and that is what Roland is asking about. Cheers, Gonzalo On 30/07/2010 11:53 AM, R.Jesske@telekom.de wrote: > Dear all, > The drafts for the "Reason header in Responses" > > _http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-responses-01_ > > > _http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses-02_ > > Where discussed over the last coupe of months. The interest of people > was not enthusiastic but it was there. > > So now I would like to ask the group how to proceed. Is there enough > interest that we proceed with this drafts within dispatch as a Working > Group Item. > > Or have the people the feeling that I should go for an individual draft, > where Gonzalo offered me to sponsor it. > > Opinions? > > Thank you and Best Regards > > Roland > > From christer.holmberg@ericsson.com Tue Aug 3 01:53:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAD53A698E for ; Tue, 3 Aug 2010 01:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.135 X-Spam-Level: X-Spam-Status: No, score=-4.135 tagged_above=-999 required=5 tests=[AWL=-1.536, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grA1P9hNDdO2 for ; Tue, 3 Aug 2010 01:53:49 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2BD063A69F4 for ; Tue, 3 Aug 2010 01:53:49 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-3b-4c57d938451d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A3.FE.06895.839D75C4; Tue, 3 Aug 2010 10:54:16 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 3 Aug 2010 10:54:16 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 3 Aug 2010 10:54:16 +0200 From: Christer Holmberg To: Gonzalo Camarillo , "R.Jesske@telekom.de" Date: Tue, 3 Aug 2010 10:54:15 +0200 Thread-Topic: [dispatch] How to proceed with "Reason in responses" Thread-Index: Acsy5i9W3/1VxiVdQ9WNKee7+wy67QAAx8TQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850CA473@ESESSCMS0356.eemea.ericsson.se> References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> <4C57D3A5.8040608@ericsson.com> In-Reply-To: <4C57D3A5.8040608@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: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 08:53:50 -0000 Hi, I definately think this work needs to be done. Who makes it, and who sponsors it, I don't have any strong opinons about :) Regards, Christer =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 3. elokuuta 2010 11:30 > To: R.Jesske@telekom.de > Cc: dispatch@ietf.org > Subject: Re: [dispatch] How to proceed with "Reason in responses" >=20 > Hi, >=20 > to be clear, process-wise if DISPATCH decides this work=20 > should be done, I can AD sponsor it. The decision on whether=20 > or not this work should be done needs to be made by=20 > DISPATCH... and that is what Roland is asking about. >=20 > Cheers, >=20 > Gonzalo >=20 > On 30/07/2010 11:53 AM, R.Jesske@telekom.de wrote: > > Dear all, > > The drafts for the "Reason header in Responses" > >=20 > >=20 > _http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-respon > > ses-01_ > >=20 > >=20 > >=20 > _http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses- > > 02_ > >=20 > > Where discussed over the last coupe of months. The interest=20 > of people=20 > > was not enthusiastic but it was there. > >=20 > > So now I would like to ask the group how to proceed. Is=20 > there enough=20 > > interest that we proceed with this drafts within dispatch=20 > as a Working=20 > > Group Item. > >=20 > > Or have the people the feeling that I should go for an individual=20 > > draft, where Gonzalo offered me to sponsor it. > >=20 > > Opinions? > >=20 > > Thank you and Best Regards > >=20 > > Roland > >=20 > >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From HKaplan@acmepacket.com Tue Aug 3 02:37:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7302F3A686B for ; Tue, 3 Aug 2010 02:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnfmfTxev2Q5 for ; Tue, 3 Aug 2010 02:37:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6D38C3A69F9 for ; Tue, 3 Aug 2010 02:37:14 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 3 Aug 2010 05:33:54 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 3 Aug 2010 05:33:54 -0400 From: Hadriel Kaplan To: Christer Holmberg , Gonzalo Camarillo , "R.Jesske@telekom.de" Date: Tue, 3 Aug 2010 05:33:52 -0400 Thread-Topic: [dispatch] How to proceed with "Reason in responses" Thread-Index: Acsy5i9W3/1VxiVdQ9WNKee7+wy67QAAx8TQAAFcRBA= Message-ID: <430FC6BDED356B4C8498F634416644A9269420F0AC@mail> References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> <4C57D3A5.8040608@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05850CA473@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850CA473@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: "dispatch@ietf.org" Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 09:37:37 -0000 +1 =20 (and the requirements draft should be merged into the solution, instead of = being two separate drafts) -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Tuesday, August 03, 2010 4:54 AM >=20 > Hi, > I definately think this work needs to be done. >=20 > Who makes it, and who sponsors it, I don't have any strong opinons > about :) > Regards, > Christer >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > > Sent: 3. elokuuta 2010 11:30 > > To: R.Jesske@telekom.de > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] How to proceed with "Reason in responses" > > > > Hi, > > > > to be clear, process-wise if DISPATCH decides this work > > should be done, I can AD sponsor it. The decision on whether > > or not this work should be done needs to be made by > > DISPATCH... and that is what Roland is asking about. > > > > Cheers, > > > > Gonzalo > > > > On 30/07/2010 11:53 AM, R.Jesske@telekom.de wrote: > > > Dear all, > > > The drafts for the "Reason header in Responses" > > > > > > > > _http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-respon > > > ses-01_ > > > > > > > > > > > _http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses- > > > 02_ > > > > > > Where discussed over the last coupe of months. The interest > > of people > > > was not enthusiastic but it was there. > > > > > > So now I would like to ask the group how to proceed. Is > > there enough > > > interest that we proceed with this drafts within dispatch > > as a Working > > > Group Item. > > > > > > Or have the people the feeling that I should go for an individual > > > draft, where Gonzalo offered me to sponsor it. > > > > > > Opinions? > > > > > > Thank you and Best Regards > > > > > > Roland > > > From laura.liess.dt@googlemail.com Tue Aug 3 02:43:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61AB3A69E9 for ; Tue, 3 Aug 2010 02:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hycmWCymLmce for ; Tue, 3 Aug 2010 02:43:05 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9E7AE3A6926 for ; Tue, 3 Aug 2010 02:43:04 -0700 (PDT) Received: by wyb40 with SMTP id 40so4428020wyb.31 for ; Tue, 03 Aug 2010 02:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=1xtZej1XFRDqozkAehVQg1DKKFKw6kFX/KaTMVaoe44=; b=JbAvqgKWJHfbn5T4NBDcHPFrCZOT3P4l+Icj4ZEtasPvZUPU4z+bT9GmCwyQMT6eS2 DukpD1tm0rCU3gRRATV5ekGIL3z8eIm+6QpXJQPjCZ9pt9leZjiBvuUw6ej1ljc6Du4x bqjrmqwrFvWBcvH4Mzqg2K68N7kgf1pcFt53Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nRhXGAIPb9gNCsrDwA8RWQMHl4s+6vl3CTdfKbz81Ky0hACsNYPFz2ZeCIALAuAKon lD+kQOnyEr01IrhDoCH/xMRZY97Quf4dFby8Mnu1wHH7HxhPnRhRp5ri05Oyo2awYGQo D6gbRxkSYJ5zykHAKURfz4VfhKKUfQm1FqOl4= MIME-Version: 1.0 Received: by 10.227.72.149 with SMTP id m21mr5960970wbj.217.1280828612367; Tue, 03 Aug 2010 02:43:32 -0700 (PDT) Received: by 10.216.152.104 with HTTP; Tue, 3 Aug 2010 02:43:32 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A9269420F0AC@mail> References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> <4C57D3A5.8040608@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05850CA473@ESESSCMS0356.eemea.ericsson.se> <430FC6BDED356B4C8498F634416644A9269420F0AC@mail> Date: Tue, 3 Aug 2010 11:43:32 +0200 Message-ID: From: Laura Liess To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Cc: "dispatch@ietf.org" , Gonzalo Camarillo , "R.Jesske@telekom.de" Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 09:43:06 -0000 +1 Laura 2010/8/3 Hadriel Kaplan : > > +1 > > (and the requirements draft should be merged into the solution, instead of being two separate drafts) > > -hadriel > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Christer Holmberg >> Sent: Tuesday, August 03, 2010 4:54 AM >> >> Hi, >> I definately think this work needs to be done. >> >> Who makes it, and who sponsors it, I don't have any strong opinons >> about :) >> Regards, >> Christer >> >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org >> > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> > Sent: 3. elokuuta 2010 11:30 >> > To: R.Jesske@telekom.de >> > Cc: dispatch@ietf.org >> > Subject: Re: [dispatch] How to proceed with "Reason in responses" >> > >> > Hi, >> > >> > to be clear, process-wise if DISPATCH decides this work >> > should be done, I can AD sponsor it. The decision on whether >> > or not this work should be done needs to be made by >> > DISPATCH... and that is what Roland is asking about. >> > >> > Cheers, >> > >> > Gonzalo >> > >> > On 30/07/2010 11:53 AM, R.Jesske@telekom.de wrote: >> > > Dear all, >> > > The drafts for the "Reason header in Responses" >> > > >> > > >> > _http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-respon >> > > ses-01_ >> > > >> > > >> > > >> > _http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses- >> > > 02_ >> > > >> > > Where discussed over the last coupe of months. The interest >> > of people >> > > was not enthusiastic but it was there. >> > > >> > > So now I would like to ask the group how to proceed. Is >> > there enough >> > > interest that we proceed with this drafts within dispatch >> > as a Working >> > > Group Item. >> > > >> > > Or have the people the feeling that I should go for an individual >> > > draft, where Gonzalo offered me to sponsor it. >> > > >> > > Opinions? >> > > >> > > Thank you and Best Regards >> > > >> > > Roland >> > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From thomas.belling@nsn.com Tue Aug 3 04:54:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A723A6A15 for ; Tue, 3 Aug 2010 04:54:02 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqyHqBHG1npA for ; Tue, 3 Aug 2010 04:54:01 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 45ADB3A69F2 for ; Tue, 3 Aug 2010 04:54:01 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o73BsOwl014676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Aug 2010 13:54:24 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o73BsNfs018277; Tue, 3 Aug 2010 13:54:23 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 13:54:23 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Aug 2010 13:54:21 +0200 Message-ID: <744A66DF31B5B34EA8B08BBD8187A722021D7E5D@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] How to proceed with "Reason in responses" Thread-Index: Acsy8FtXjYkTzf6zRHeIR3hih/eaTgAEinZQ References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de><4C57D3A5.8040608@ericsson.com><7F2072F1E0DE894DA4B517B93C6A05850CA473@ESESSCMS0356.eemea.ericsson.se><430FC6BDED356B4C8498F634416644A9269420F0AC@mail> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Laura Liess" , "Hadriel Kaplan" X-OriginalArrivalTime: 03 Aug 2010 11:54:23.0723 (UTC) FILETIME=[9D9993B0:01CB3302] Cc: dispatch@ietf.org, Gonzalo Camarillo , R.Jesske@telekom.de Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 11:54:02 -0000 +1 Thomas ----------------------------------=20 Dr. Thomas Belling=20 3GPP Standardisation Nokia Siemens Networks=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Laura Liess Sent: Tuesday, August 03, 2010 11:44 AM To: Hadriel Kaplan Cc: dispatch@ietf.org; Gonzalo Camarillo; R.Jesske@telekom.de Subject: Re: [dispatch] How to proceed with "Reason in responses" +1 Laura 2010/8/3 Hadriel Kaplan : > > +1 > > (and the requirements draft should be merged into the solution,=20 > instead of being two separate drafts) > > -hadriel > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Christer Holmberg >> Sent: Tuesday, August 03, 2010 4:54 AM >> >> Hi, >> I definately think this work needs to be done. >> >> Who makes it, and who sponsors it, I don't have any strong opinons=20 >> about :) Regards, Christer >> >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org >> > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> > Sent: 3. elokuuta 2010 11:30 >> > To: R.Jesske@telekom.de >> > Cc: dispatch@ietf.org >> > Subject: Re: [dispatch] How to proceed with "Reason in responses" >> > >> > Hi, >> > >> > to be clear, process-wise if DISPATCH decides this work should be=20 >> > done, I can AD sponsor it. The decision on whether or not this work >> > should be done needs to be made by DISPATCH... and that is what=20 >> > Roland is asking about. >> > >> > Cheers, >> > >> > Gonzalo >> > >> > On 30/07/2010 11:53 AM, R.Jesske@telekom.de wrote: >> > > Dear all, >> > > The drafts for the "Reason header in Responses" >> > > >> > > >> > _http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-res >> > pon >> > > ses-01_ >> > > >> > > >> > > >> > _http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-respons >> > es- >> > > 02_ >> > > >> > > Where discussed over the last coupe of months. The interest >> > of people >> > > was not enthusiastic but it was there. >> > > >> > > So now I would like to ask the group how to proceed. Is >> > there enough >> > > interest that we proceed with this drafts within dispatch >> > as a Working >> > > Group Item. >> > > >> > > Or have the people the feeling that I should go for an individual >> > > draft, where Gonzalo offered me to sponsor it. >> > > >> > > Opinions? >> > > >> > > Thank you and Best Regards >> > > >> > > Roland >> > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From christian.1.schmidt@nsn.com Tue Aug 3 05:30:40 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073AF3A681D for ; Tue, 3 Aug 2010 05:30:40 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkJxsoCxp+8l for ; Tue, 3 Aug 2010 05:30:34 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id E96E93A69B6 for ; Tue, 3 Aug 2010 05:30:33 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o73CUsE5012193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Aug 2010 14:30:54 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o73CUs3v032646; Tue, 3 Aug 2010 14:30:54 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 14:30:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Aug 2010 14:30:53 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] How to proceed with "Reason in responses" Thread-Index: Acsy8FtsBCWQLrTkS7aZXQiqhtAu+QAF0ApQ References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de><4C57D3A5.8040608@ericsson.com><7F2072F1E0DE894DA4B517B93C6A05850CA473@ESESSCMS0356.eemea.ericsson.se><430FC6BDED356B4C8498F634416644A9269420F0AC@mail> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext Laura Liess" , "Hadriel Kaplan" X-OriginalArrivalTime: 03 Aug 2010 12:30:54.0505 (UTC) FILETIME=[B7686190:01CB3307] Cc: dispatch@ietf.org, Gonzalo Camarillo , R.Jesske@telekom.de Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 12:30:40 -0000 +1 I would like to support this work as well Christian -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Laura Liess Sent: Tuesday, August 03, 2010 11:44 AM To: Hadriel Kaplan Cc: dispatch@ietf.org; Gonzalo Camarillo; R.Jesske@telekom.de Subject: Re: [dispatch] How to proceed with "Reason in responses" +1 Laura 2010/8/3 Hadriel Kaplan : > > +1 > > (and the requirements draft should be merged into the solution, instead of being two separate drafts) > > -hadriel > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Christer Holmberg >> Sent: Tuesday, August 03, 2010 4:54 AM >> >> Hi, >> I definately think this work needs to be done. >> >> Who makes it, and who sponsors it, I don't have any strong opinons >> about :) >> Regards, >> Christer >> >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org >> > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> > Sent: 3. elokuuta 2010 11:30 >> > To: R.Jesske@telekom.de >> > Cc: dispatch@ietf.org >> > Subject: Re: [dispatch] How to proceed with "Reason in responses" >> > >> > Hi, >> > >> > to be clear, process-wise if DISPATCH decides this work >> > should be done, I can AD sponsor it. The decision on whether >> > or not this work should be done needs to be made by >> > DISPATCH... and that is what Roland is asking about. >> > >> > Cheers, >> > >> > Gonzalo >> > >> > On 30/07/2010 11:53 AM, R.Jesske@telekom.de wrote: >> > > Dear all, >> > > The drafts for the "Reason header in Responses" >> > > >> > > >> > _http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-respon >> > > ses-01_ >> > > >> > > >> > > >> > _http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses- >> > > 02_ >> > > >> > > Where discussed over the last coupe of months. The interest >> > of people >> > > was not enthusiastic but it was there. >> > > >> > > So now I would like to ask the group how to proceed. Is >> > there enough >> > > interest that we proceed with this drafts within dispatch >> > as a Working >> > > Group Item. >> > > >> > > Or have the people the feeling that I should go for an individual >> > > draft, where Gonzalo offered me to sponsor it. >> > > >> > > Opinions? >> > > >> > > Thank you and Best Regards >> > > >> > > Roland >> > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From enrico.marocco@telecomitalia.it Tue Aug 3 05:56:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8941E3A6827 for ; Tue, 3 Aug 2010 05:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.37 X-Spam-Level: X-Spam-Status: No, score=0.37 tagged_above=-999 required=5 tests=[AWL=1.089, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIgl2BXKnPTq for ; Tue, 3 Aug 2010 05:56:12 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 010B23A63C9 for ; Tue, 3 Aug 2010 05:56:12 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 3 Aug 2010 14:56:38 +0200 Received: from [163.162.173.9] (163.162.173.9) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 3 Aug 2010 14:56:38 +0200 Message-ID: <4C58125A.5070201@telecomitalia.it> Date: Tue, 3 Aug 2010 14:58:02 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> <4C57D3A5.8040608@ericsson.com> In-Reply-To: <4C57D3A5.8040608@ericsson.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000407070602090505020305" Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 12:56:13 -0000 --------------ms000407070602090505020305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable The problem this work provides a fix for is very real and service=20 providers interoperating with PSTN really need to have it fixed. Since=20 the solution is pretty simple, AD sponsorship seems the best way to go=20 to me. Enrico On 08/03/2010 10:30 AM, Gonzalo Camarillo wrote: > Hi, > > to be clear, process-wise if DISPATCH decides this work should be done,= > I can AD sponsor it. The decision on whether or not this work should be= > done needs to be made by DISPATCH... and that is what Roland is asking > about. > > Cheers, > > Gonzalo > > On 30/07/2010 11:53 AM, R.Jesske@telekom.de wrote: >> Dear all, >> The drafts for the "Reason header in Responses" >> >> _http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-respon= ses-01_ >> >> >> _http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses-= 02_ >> >> Where discussed over the last coupe of months. The interest of people >> was not enthusiastic but it was there. >> >> So now I would like to ask the group how to proceed. Is there enough >> interest that we proceed with this drafts within dispatch as a Working= >> Group Item. >> >> Or have the people the feeling that I should go for an individual draf= t, >> where Gonzalo offered me to sponsor it. >> >> Opinions? >> >> Thank you and Best Regards >> >> Roland >> >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------ms000407070602090505020305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwODAz MTI1ODAzWjAjBgkqhkiG9w0BCQQxFgQU7DNWTzR/lq+mPT3yeeJrfw0mOIMwXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBACvFyr/0LiBBaKjSIwFu 4bZS9IemUCaNxie8nMmxZC7jVI0oDwyZn2zDFODW2hDPf7S1d300QoPK4WuMoUWl8kOV/zUZ CMuxlGumx8RBkq7FMHrlP3vvzwkxmwz91lBbxLEZ+EOC7JY4/IS/jutdF99chyr5MVJ0i06n o9RVMp4qQkZnCu+Yw7NIXlEVrRjed+yFyFk2EWbf/0Q2Gj/h0huQ2Hj7lk15Q6I6Ur8yKatT yWYaBPYrnRkiphenQNmvcbrun+8wl8MgwVIVOij6dKlX1zLI6ICNIRGhrhRjZzL6ER8YS7Uo apRoTn65qL8h3rvoSyu+KGTrEFqCaOKeFhsAAAAAAAA= --------------ms000407070602090505020305-- From gao.yang2@zte.com.cn Tue Aug 3 19:37:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BC583A6B90 for ; Tue, 3 Aug 2010 19:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.174 X-Spam-Level: X-Spam-Status: No, score=-100.174 tagged_above=-999 required=5 tests=[AWL=1.664, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAVLmeEdCthV for ; Tue, 3 Aug 2010 19:37:28 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 040433A6B81 for ; Tue, 3 Aug 2010 19:37:27 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 3510992332426; Wed, 4 Aug 2010 10:37:04 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 79973.992332426; Wed, 4 Aug 2010 10:37:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o742b5ue000465 for ; Wed, 4 Aug 2010 10:37:06 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: dispatch@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 4 Aug 2010 10:35:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-08-04 10:37:02, Serialize complete at 2010-08-04 10:37:02 Content-Type: multipart/alternative; boundary="=_alternative 000E48BD48257775_=" X-MAIL: mse2.zte.com.cn o742b5ue000465 Subject: [dispatch] Could someone tell me how about the SBC BEHAVE BOF and next step for it? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 02:37:29 -0000 This is a multipart message in MIME format. --=_alternative 000E48BD48257775_= Content-Type: text/plain; charset="US-ASCII" I had no time for the Holand's meeting. But I'd like to know how about the SBC BEHAVE BOF and next step for it. Could someone tell me? Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000E48BD48257775_= Content-Type: text/html; charset="US-ASCII"
I had no time for the Holand's meeting. But I'd like to know how about the SBC BEHAVE BOF and next step for it.

Could someone tell me?

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000E48BD48257775_=-- From pkyzivat@cisco.com Wed Aug 4 08:40:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76DD23A6C4D for ; Wed, 4 Aug 2010 08:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.5 X-Spam-Level: X-Spam-Status: No, score=-10.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zqQH5QawQqo for ; Wed, 4 Aug 2010 08:40:19 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AACF33A6C09 for ; Wed, 4 Aug 2010 08:39:43 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,315,1278288000"; d="scan'208";a="143256855" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 04 Aug 2010 15:40:05 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o74Fe5b1027963; Wed, 4 Aug 2010 15:40:05 GMT Message-ID: <4C5989D5.9070302@cisco.com> Date: Wed, 04 Aug 2010 11:40:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Cullen Jennings References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:40:20 -0000 Cullen, Cullen Jennings wrote: > I would find it more useful to scope it by what is being correlated than what the many use cases for various correlations might be. One of the problems with saying the use is troubleshooting is that just about anything is useful for troubleshooting in some case. I have no objections to this proposed working group doing what the type of correlation the SIP REC WG needs but I have no idea what that is - I suspect this would not meet the needs as far as I understand them. I share the concern about ambiguity of "troubleshooting". But I don't see how picking what is to be correlated is the starting point. ISTM that the use cases provide the info to decide which dialogs should be correlated and which should not. Use cases for widely varying purposes can end up being complementary in this regard. But of course there most likely will still be a need to throw some use cases "out of the boat" if they require incompatible correlations. Thanks, Paul > On Jul 30, 2010, at 24:46 , Elwell, John wrote: > >> Can somebody please remind me why this is scoped only for troubleshooting. For example, in SIPREC, we anticipate a need for a Session Recording Server to be able to correlate two recorded sessions from different Session Recording Clients. For example, if a customer call is transferred from one agent to a second agent, the two agents might be using different Session Recording Clients to send media to the Session Recording Server. What would be the barrier to using session ID for this case? Is it just the lack of guaranteed uniqueness, or are there other factors? >> >> John >> >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Victor Pascual Avila >>> Sent: 29 July 2010 23:50 >>> To: Cullen Jennings >>> Cc: dispatch@ietf.org list >>> Subject: Re: [dispatch] Proposal for Session ID charter >>> >>> I like it >>> >>> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings >>> wrote: >>>> I tried to write a proposal that I think reflects what the >>> proponents of this WG want. Here's my stab at it. >>>> ------------------ >>>> >>>> >>>> Troubleshooting SIP networks can be improved by correlating >>> messaging across several devices. This working group will >>> define a correlation identifier to be used for the >>> troubleshooting and the for correlation of logging >>> information from different SIP devices in the network. >>>> Sip transactions are often triggered by another SIP >>> transaction. Two transactions are in the same "session" if >>> one was triggered by the other due to redirection, REFER >>> processing, retargeting, or forwarding on a B2BUA. This >>> working group will define a correlation identifier that >>> identifies all the transactions in the same session. The >>> scope of the identifier pertains to the SIP signaling layer >>> only, and not media. For example, several UA participating >>> in a conference call may be receiving the same media but >>> would not be in the same session. >>>> The design of the correlation identifier needs to take into >>> account the issue of not revealing the topology of network. >>> The mechanism should be applicable for Proxies, UAs, PBXs, >>> SBCs, Application Servers, Softswitches, Phones, and Gateways. >>>> This working group will coordinate with other relevant >>> working groups and area including Ops, and sipcore. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> >>> >>> -- >>> Victor Pascual Ávila >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Wed Aug 4 12:35:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3EA3A688A for ; Wed, 4 Aug 2010 12:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VioitfqmaGBi for ; Wed, 4 Aug 2010 12:35:39 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id AAAA23A699C for ; Wed, 4 Aug 2010 12:34:51 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIZdWUxAZnwM/2dsb2JhbACgKHGpe5tQgnKCSQSJIg X-IronPort-AV: E=Sophos;i="4.55,317,1278288000"; d="scan'208";a="143412744" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 04 Aug 2010 19:35:21 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o74JZLII029638; Wed, 4 Aug 2010 19:35:21 GMT Message-ID: <4C59C0F6.4070909@cisco.com> Date: Wed, 04 Aug 2010 15:35:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A92694002808@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A92694002808@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 19:35:42 -0000 Hadriel, After thinking further about this... I think we could *start* with one very common use case - a linear chain of dialogs connected by B2BUAs. There are multiple uses for an identifier linking all of those. Certainly we can call out the use in troubleshooting *specific* problems with such a case. I think it would be useful to have that in the charter. But the charter should be more open ended than that. Specifically, I think it should call for the WG to identify other use cases that the resulting mechanism will address. Two categories of use cases: - other applications besides "troubleshooting" with the same id is useful. (E.g. recording) - other dialog relationships that should also get a common id, such as the transfer cases. One constraint would be that the mechanism uniquely define the mechanism for deciding when two dialogs get the same id and when they do not. Another is that the basic case identified in the charter be included. So the things that would happen in the WG would be: - gather use cases - for each use case, identify the dialog correlation algorithm required - identify any incompatible use cases - exclude incompatible use cases from consideration until those that remain have compatible dialog correlation requirements - specify a mechanism that meets all the remaining use cases Thanks, Paul Hadriel Kaplan wrote: > Howdy, > One of the objections to the currently proposed SIPSCOTCH charter is on how one knows whether to use the same session-id or not - i.e., what defines the same higher layer session. > > In particular, the following paragraph of the charter: > "The definition of a higher-layer "session" of the same "message-flow" is not defined by SIP when it involves a B2BUA, and is difficult to normatively define in practice. For the purposes of this WG charter's scope, two or more dialogs of a B2BUA are correlated under any conditions where correlation might aid troubleshooting, by identifying them as belonging to the same higher-level session. Any solution documents from this working group may expand or constrain the scope of their mechanism's correlation, if the working group so decides." > > This objection was also raised on the DISPATCH mailing list thread starting here: > http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html > > > I believe the available options to handle this issue are: > > 1) Defer it to the new WG's solution doc to specify. > > 2) Try to articulate rules in the charter for when two messages/dialogs are part of the same "session". This was actually attempted in a previous incarnation of the charter, in an email thread starting here: > http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html > > 3) Instead of defining "rules", try to enumerate examples/use-cases which are and are-not in scope to be the same session. > > Any comments/preferences? > > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From john.elwell@siemens-enterprise.com Thu Aug 5 12:24:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19AD23A680A for ; Thu, 5 Aug 2010 12:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGKeaCTonVnM for ; Thu, 5 Aug 2010 12:24:29 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8BC333A67ED for ; Thu, 5 Aug 2010 12:24:29 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1083963; Thu, 5 Aug 2010 21:24:58 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id C914923F0278; Thu, 5 Aug 2010 21:24:58 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 5 Aug 2010 21:24:58 +0200 From: "Elwell, John" To: Hadriel Kaplan , Christer Holmberg , Gonzalo Camarillo , "R.Jesske@telekom.de" Date: Thu, 5 Aug 2010 21:24:57 +0200 Thread-Topic: [dispatch] How to proceed with "Reason in responses" Thread-Index: Acsy5i9W3/1VxiVdQ9WNKee7+wy67QAAx8TQAAFcRBAAeUVogA== Message-ID: References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> <4C57D3A5.8040608@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05850CA473@ESESSCMS0356.eemea.ericsson.se> <430FC6BDED356B4C8498F634416644A9269420F0AC@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A9269420F0AC@mail> 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: "dispatch@ietf.org" Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 19:24:31 -0000 +1, with preference for a single document. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 03 August 2010 10:34 > To: Christer Holmberg; Gonzalo Camarillo; R.Jesske@telekom.de > Cc: dispatch@ietf.org > Subject: Re: [dispatch] How to proceed with "Reason in responses" >=20 >=20 > +1 =20 >=20 > (and the requirements draft should be merged into the=20 > solution, instead of being two separate drafts) >=20 > -hadriel >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > Sent: Tuesday, August 03, 2010 4:54 AM > >=20 > > Hi, > > I definately think this work needs to be done. > >=20 > > Who makes it, and who sponsors it, I don't have any strong opinons > > about :) > > Regards, > > Christer > >=20 > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > > > Sent: 3. elokuuta 2010 11:30 > > > To: R.Jesske@telekom.de > > > Cc: dispatch@ietf.org > > > Subject: Re: [dispatch] How to proceed with "Reason in responses" > > > > > > Hi, > > > > > > to be clear, process-wise if DISPATCH decides this work > > > should be done, I can AD sponsor it. The decision on whether > > > or not this work should be done needs to be made by > > > DISPATCH... and that is what Roland is asking about. > > > > > > Cheers, > > > > > > Gonzalo > > > > > > On 30/07/2010 11:53 AM, R.Jesske@telekom.de wrote: > > > > Dear all, > > > > The drafts for the "Reason header in Responses" > > > > > > > > > > >=20 > _http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-respon > > > > ses-01_ > > > > > > > > > > > > > > >=20 > _http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses- > > > > 02_ > > > > > > > > Where discussed over the last coupe of months. The interest > > > of people > > > > was not enthusiastic but it was there. > > > > > > > > So now I would like to ask the group how to proceed. Is > > > there enough > > > > interest that we proceed with this drafts within dispatch > > > as a Working > > > > Group Item. > > > > > > > > Or have the people the feeling that I should go for an=20 > individual > > > > draft, where Gonzalo offered me to sponsor it. > > > > > > > > Opinions? > > > > > > > > Thank you and Best Regards > > > > > > > > Roland > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From dworley@avaya.com Fri Aug 6 11:18:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8C13A67D0 for ; Fri, 6 Aug 2010 11:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fv+O2TDyDBqT for ; Fri, 6 Aug 2010 11:18:26 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id EF66F3A685E for ; Fri, 6 Aug 2010 11:18:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,330,1278302400"; d="scan'208";a="28635024" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 06 Aug 2010 14:18:46 -0400 X-IronPort-AV: E=Sophos;i="4.55,330,1278302400"; d="scan'208";a="498138605" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Aug 2010 14:18:46 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 6 Aug 2010 14:18:45 -0400 From: "WORLEY, Dale R (Dale)" To: "R.Jesske@telekom.de" , "dispatch@ietf.org" Date: Fri, 6 Aug 2010 14:14:33 -0400 Thread-Topic: How to proceed with "Reason in responses" Thread-Index: AcsvxLG33Qx1SAb3S4+kcH5O0IhTtwFzoaed Message-ID: References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> 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 Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 18:18:27 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of R.= Jesske@telekom.de [R.Jesske@telekom.de] Where discussed over the last coupe of months. The interest of people was n= ot enthusiastic but it was there. So now I would like to ask the group how to proceed. Is there enough intere= st that we proceed with this drafts within dispatch as a Working Group Item= . Or have the people the feeling that I should go for an individual draft, wh= ere Gonzalo offered me to sponsor it. ________________________________________ Definitely this should go forward. But I think that this needs to be a standards-track RFC in order to be a no= rmative extension of RFC 3326 (specification of the Reason header). Otherwise, given that this work is not controversial (e.g., many of us did = not initially realize that an RFC was needed), it would be more efficient t= o submit it as an individual draft. Dale From andrew.hutton@siemens-enterprise.com Fri Aug 6 13:21:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF653A6918 for ; Fri, 6 Aug 2010 13:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.717, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxvu65WgFEiZ for ; Fri, 6 Aug 2010 13:21:24 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DAC103A67ED for ; Fri, 6 Aug 2010 13:21:23 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1097558; Fri, 6 Aug 2010 22:21:54 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 4B3821EB82B4; Fri, 6 Aug 2010 22:21:54 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 6 Aug 2010 22:21:54 +0200 From: "Hutton, Andrew" To: Gonzalo Camarillo , "R.Jesske@telekom.de" Date: Fri, 6 Aug 2010 22:21:53 +0200 Thread-Topic: [dispatch] How to proceed with "Reason in responses" Thread-Index: Acsy5i9/0HDdxEe4Q22MuPYvXG+5jACvmnzQ Message-ID: <101C6067BEC68246B0C3F6843BCCC1E307CA6DA8CF@MCHP058A.global-ad.net> References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> <4C57D3A5.8040608@ericsson.com> In-Reply-To: <4C57D3A5.8040608@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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 20:21:25 -0000 Hi, I believe this work needs to be done and preferable as one RFC (I.e. merge = requirements and solution ). Whether it is AD sponsored or a WG document I don't have a strong view. Regards Andy > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 03 August 2010 09:30 > To: R.Jesske@telekom.de > Cc: dispatch@ietf.org > Subject: Re: [dispatch] How to proceed with "Reason in responses" >=20 > Hi, >=20 > to be clear, process-wise if DISPATCH decides this work=20 > should be done, > I can AD sponsor it. The decision on whether or not this work=20 > should be > done needs to be made by DISPATCH... and that is what Roland is asking > about. >=20 > Cheers, >=20 > Gonzalo >=20 > On 30/07/2010 11:53 AM, R.Jesske@telekom.de wrote: > > Dear all, > > The drafts for the "Reason header in Responses" > >=20 > >=20 > _http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-i > n-responses-01_ > >=20 > >=20 > >=20 > _http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-re > sponses-02_ > >=20 > > Where discussed over the last coupe of months. The interest=20 > of people > > was not enthusiastic but it was there. > >=20 > > So now I would like to ask the group how to proceed. Is there enough > > interest that we proceed with this drafts within dispatch=20 > as a Working > > Group Item. > >=20 > > Or have the people the feeling that I should go for an=20 > individual draft, > > where Gonzalo offered me to sponsor it. > >=20 > > Opinions? > >=20 > > Thank you and Best Regards > >=20 > > Roland > >=20 > >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From shida@ntt-at.com Mon Aug 9 00:55:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D2B3A68F1 for ; Mon, 9 Aug 2010 00:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubh4hkefUXrg for ; Mon, 9 Aug 2010 00:55:15 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [64.5.50.11]) by core3.amsl.com (Postfix) with SMTP id 4A7BB3A677D for ; Mon, 9 Aug 2010 00:55:15 -0700 (PDT) Received: (qmail 12627 invoked from network); 9 Aug 2010 08:06:31 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway06.websitewelcome.com with SMTP; 9 Aug 2010 08:06:31 -0000 Received: from [125.195.67.162] (port=63497 helo=[192.168.1.5]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1OiND0-0002Ux-Rn; Mon, 09 Aug 2010 02:55:47 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4C58125A.5070201@telecomitalia.it> Date: Mon, 9 Aug 2010 16:55:46 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> <4C57D3A5.8040608@ericsson.com> <4C58125A.5070201@telecomitalia.it> To: Enrico Marocco X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: dispatch@ietf.org Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 07:55:16 -0000 We too as a service provider needs this draft. I don't see much point in creating a WG for this draft,=20 so I agree with Enrico that having it progressed as AD=20 sponsored is the way to go.=20 Lastly, I would rather see single document=20 (merging req/solution), as some mentioned than two. Regards Shida On Aug 3, 2010, at 9:58 PM, Enrico Marocco wrote: > The problem this work provides a fix for is very real and service = providers interoperating with PSTN really need to have it fixed. Since = the solution is pretty simple, AD sponsorship seems the best way to go = to me. >=20 > Enrico >=20 > On 08/03/2010 10:30 AM, Gonzalo Camarillo wrote: >> Hi, >>=20 >> to be clear, process-wise if DISPATCH decides this work should be = done, >> I can AD sponsor it. The decision on whether or not this work should = be >> done needs to be made by DISPATCH... and that is what Roland is = asking >> about. >>=20 >> Cheers, >>=20 >> Gonzalo >>=20 >> On 30/07/2010 11:53 AM, R.Jesske@telekom.de wrote: >>> Dear all, >>> The drafts for the "Reason header in Responses" >>>=20 >>> = _http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-responses-= 01_ >>>=20 >>>=20 >>> = _http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses-02_ >>>=20 >>> Where discussed over the last coupe of months. The interest of = people >>> was not enthusiastic but it was there. >>>=20 >>> So now I would like to ask the group how to proceed. Is there enough >>> interest that we proceed with this drafts within dispatch as a = Working >>> Group Item. >>>=20 >>> Or have the people the feeling that I should go for an individual = draft, >>> where Gonzalo offered me to sponsor it. >>>=20 >>> Opinions? >>>=20 >>> Thank you and Best Regards >>>=20 >>> Roland >>>=20 >>>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From christer.holmberg@ericsson.com Mon Aug 9 02:34:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D08F3A688E for ; Mon, 9 Aug 2010 02:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wpe4q3xprnkH for ; Mon, 9 Aug 2010 02:34:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CD90E3A6862 for ; Mon, 9 Aug 2010 02:34:37 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-39-4c5fcbcebd8d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 74.05.06895.ECBCF5C4; Mon, 9 Aug 2010 11:35:10 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 9 Aug 2010 11:35:10 +0200 From: Christer Holmberg To: Shida Schubert , Enrico Marocco Date: Mon, 9 Aug 2010 11:35:09 +0200 Thread-Topic: [dispatch] How to proceed with "Reason in responses" Thread-Index: Acs3mE75RmGAyVnjTUuSiuPtOw091wADcQKQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A058511153D@ESESSCMS0356.eemea.ericsson.se> References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> <4C57D3A5.8040608@ericsson.com> <4C58125A.5070201@telecomitalia.it> 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-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 09:34:39 -0000 Hi, I agree. If it can't be done within an existing WG I would vote for AD spon= sored. Regards, Christer=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Shida Schubert > Sent: 9. elokuuta 2010 10:56 > To: Enrico Marocco > Cc: dispatch@ietf.org > Subject: Re: [dispatch] How to proceed with "Reason in responses" >=20 >=20 > We too as a service provider needs this draft. >=20 > I don't see much point in creating a WG for this draft, so I=20 > agree with Enrico that having it progressed as AD sponsored=20 > is the way to go.=20 >=20 > Lastly, I would rather see single document (merging=20 > req/solution), as some mentioned than two. >=20 > Regards > Shida >=20 > On Aug 3, 2010, at 9:58 PM, Enrico Marocco wrote: >=20 > > The problem this work provides a fix for is very real and=20 > service providers interoperating with PSTN really need to=20 > have it fixed. Since the solution is pretty simple, AD=20 > sponsorship seems the best way to go to me. > >=20 > > Enrico > >=20 > > On 08/03/2010 10:30 AM, Gonzalo Camarillo wrote: > >> Hi, > >>=20 > >> to be clear, process-wise if DISPATCH decides this work should be=20 > >> done, I can AD sponsor it. The decision on whether or not=20 > this work=20 > >> should be done needs to be made by DISPATCH... and that is what=20 > >> Roland is asking about. > >>=20 > >> Cheers, > >>=20 > >> Gonzalo > >>=20 > >> On 30/07/2010 11:53 AM, R.Jesske@telekom.de wrote: > >>> Dear all, > >>> The drafts for the "Reason header in Responses" > >>>=20 > >>>=20 > _http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-resp > >>> onses-01_ > >>>=20 > >>>=20 > >>>=20 > _http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-response > >>> s-02_ > >>>=20 > >>> Where discussed over the last coupe of months. The interest of=20 > >>> people was not enthusiastic but it was there. > >>>=20 > >>> So now I would like to ask the group how to proceed. Is=20 > there enough=20 > >>> interest that we proceed with this drafts within dispatch as a=20 > >>> Working Group Item. > >>>=20 > >>> Or have the people the feeling that I should go for an individual=20 > >>> draft, where Gonzalo offered me to sponsor it. > >>>=20 > >>> Opinions? > >>>=20 > >>> Thank you and Best Regards > >>>=20 > >>> Roland > >>>=20 > >>>=20 > >>=20 > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From R.Jesske@telekom.de Tue Aug 10 07:07:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061D93A69BB for ; Tue, 10 Aug 2010 07:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7DQoDVKNkMy for ; Tue, 10 Aug 2010 07:07:54 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 854D03A697A for ; Tue, 10 Aug 2010 07:07:54 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 10 Aug 2010 16:08:07 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 16:08:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Aug 2010 16:08:04 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4067448FF@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] How to proceed with "Reason in responses" Thread-Index: Acsy5i9W3/1VxiVdQ9WNKee7+wy67QAAx8TQAAFcRBAAeUVogADv5Vzw References: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de><4C57D3A5.8040608@ericsson.com><7F2072F1E0DE894DA4B517B93C6A05850CA473@ESESSCMS0356.eemea.ericsson.se> <430FC6BDED356B4C8498F634416644A9269420F0AC@mail> From: To: , , , X-OriginalArrivalTime: 10 Aug 2010 14:08:06.0833 (UTC) FILETIME=[74A34210:01CB3895] Cc: dispatch@ietf.org Subject: Re: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 14:07:56 -0000 Dear all, Thank you for the feedback. I have no problem in merging again the = requirements with the procedures, but it must be clear that everybody is = OK with this. After IETF 76 it was asked to split the document before going ahead. Best Regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Gesendet: Donnerstag, 5. August 2010 21:25 An: Hadriel Kaplan; Christer Holmberg; Gonzalo Camarillo; Jesske, Roland Cc: dispatch@ietf.org Betreff: RE: [dispatch] How to proceed with "Reason in responses" +1, with preference for a single document. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 03 August 2010 10:34 > To: Christer Holmberg; Gonzalo Camarillo; R.Jesske@telekom.de > Cc: dispatch@ietf.org > Subject: Re: [dispatch] How to proceed with "Reason in responses" >=20 >=20 > +1 =20 >=20 > (and the requirements draft should be merged into the=20 > solution, instead of being two separate drafts) >=20 > -hadriel >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > Sent: Tuesday, August 03, 2010 4:54 AM > >=20 > > Hi, > > I definately think this work needs to be done. > >=20 > > Who makes it, and who sponsors it, I don't have any strong opinons > > about :) > > Regards, > > Christer > >=20 > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > > > Sent: 3. elokuuta 2010 11:30 > > > To: R.Jesske@telekom.de > > > Cc: dispatch@ietf.org > > > Subject: Re: [dispatch] How to proceed with "Reason in responses" > > > > > > Hi, > > > > > > to be clear, process-wise if DISPATCH decides this work > > > should be done, I can AD sponsor it. The decision on whether > > > or not this work should be done needs to be made by > > > DISPATCH... and that is what Roland is asking about. > > > > > > Cheers, > > > > > > Gonzalo > > > > > > On 30/07/2010 11:53 AM, R.Jesske@telekom.de wrote: > > > > Dear all, > > > > The drafts for the "Reason header in Responses" > > > > > > > > > > >=20 > _http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-respon > > > > ses-01_ > > > > > > > > > > > > > > >=20 > _http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses- > > > > 02_ > > > > > > > > Where discussed over the last coupe of months. The interest > > > of people > > > > was not enthusiastic but it was there. > > > > > > > > So now I would like to ask the group how to proceed. Is > > > there enough > > > > interest that we proceed with this drafts within dispatch > > > as a Working > > > > Group Item. > > > > > > > > Or have the people the feeling that I should go for an=20 > individual > > > > draft, where Gonzalo offered me to sponsor it. > > > > > > > > Opinions? > > > > > > > > Thank you and Best Regards > > > > > > > > Roland > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From partr@cisco.com Tue Aug 10 18:34:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD62C3A68AE for ; Tue, 10 Aug 2010 18:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.198 X-Spam-Level: X-Spam-Status: No, score=-9.198 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbsjQA-3aqJJ for ; Tue, 10 Aug 2010 18:34:22 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 303E63A67B2 for ; Tue, 10 Aug 2010 18:34:22 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: Usecases.txt : 4153 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4FAF6bYUxAaMHG/2dsb2JhbACBRJ4NYXGiCZtSgnCCSgSEJIdx X-IronPort-AV: E=Sophos;i="4.55,350,1278288000"; d="txt'?scan'208,217";a="271789120" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2010 01:34:56 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7B1YtBn017138; Wed, 11 Aug 2010 01:34:55 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Aug 2010 07:04:54 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB38F5.66A01C60" Date: Wed, 11 Aug 2010 07:04:55 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvzxBsafq1F/F2TyimIJKjLTIAkgADQTWQAABlmWACRNMNFA== References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> From: "Parthasarathi R (partr)" To: "Parthasarathi R (partr)" , "Hadriel Kaplan" , "Paul Kyzivat (pkyzivat)" , "Peter Musgrave" X-OriginalArrivalTime: 11 Aug 2010 01:34:54.0973 (UTC) FILETIME=[669A6AD0:01CB38F5] Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 01:34:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB38F5.66A01C60 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB38F5.66A01C60" ------_=_NextPart_002_01CB38F5.66A01C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hadriel, =20 I attached the use case which illustrates the session-id change during = mid-dialog. As a individual use case, the use case is used for transfer = based on "Re-INVITE" mechanism. The use case is useful for creating the = complex supplementary services when use case is used as service = primitive. This use case is deployed by B2BUA in Service Provider = softswitches and Enterprise PBXs. The use case does not propose any = solution but it just indicates the problem in creating the session-id. = Even in case session-id is used for troubleshooting only, the session-id = has to be generic enough to handle this use case. Please let me know = your thought on this. =20 I'll add more usecases based on the response for this mail. =20 Thanks Partha ________________________________ From: dispatch-bounces@ietf.org on behalf of Parthasarathi R (partr) Sent: Fri 7/30/2010 5:47 PM To: Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter Hadriel, Instead working with solution in mind, Shall we start with the usecases document. The usecase document will help us to decide whether the single header or multiple header required. It will help to identify the generic session-id if one exists. The usecase requirement will be very useful as we are talking about the complex dialog scenarios which involves set of B2BUA. As I mentioned in the earlier mail thread, I'll come up with the usecase document as a starting point, add more relevant usecases and we will brainstorm whether the usecases are relevant for the session id or not. Please let me know your opinion on the same. Thanks Partha -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Friday, July 30, 2010 5:14 PM To: Paul Kyzivat (pkyzivat); Peter Musgrave Cc: dispatch@ietf.org list Subject: Re: [dispatch] Proposal for Session ID charter > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, July 30, 2010 6:08 AM > > 2) Other applications that require correlation of some class of > related dialogs for some purpose other than troubleshooting > are driven away, and so must define yet another header and id > for their own purposes. I know adding more headers sucks. But that may be the safest thing. -hadriel _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------_=_NextPart_002_01CB38F5.66A01C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Proposal for Session ID = charter=0A= =0A= =0A= =0A=
=0A=
=0A=
=0A=
=0A=

Hadriel,

=0A=

 

=0A=

I attached = the use case which illustrates the session-id change during mid-dialog. = As a individual use case, the use case is used for transfer based = on "Re-INVITE" mechanism. The use case is useful for creating the = complex supplementary services when use case is used as service = primitive. This use case is deployed by B2BUA in = Service Provider softswitches and Enterprise PBXs. The use = case does not propose any solution but it just indicates the = problem in creating the session-id. Even in case session-id = is used for troubleshooting only, the session-id has to be = generic enough to handle this use case.  Please let me know = your thought on this.

=0A=

 

=0A=

I'll add = more usecases based on the response for this mail.

=0A=

 

=0A=

Thanks

=0A=

Partha

=0A=
=0A= From: dispatch-bounces@ietf.org on = behalf of Parthasarathi R (partr)
Sent: Fri 7/30/2010 5:47 = PM
To: Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter = Musgrave
Cc: dispatch@ietf.org
Subject: Re: = [dispatch] Proposal for Session ID = charter

=0A=
=0A=

Hadriel,

Instead working with solution in mind, = Shall we start with the usecases
document. The usecase document will = help us to decide whether the single
header or multiple header = required. It will help to identify the generic
session-id if one = exists. The usecase requirement will be very useful as
we are talking = about the complex dialog scenarios which involves set = of
B2BUA.

As I mentioned in the earlier mail thread, I'll come = up with the usecase
document as a starting point, add more relevant = usecases and we will
brainstorm whether the usecases are relevant for = the session id or not.
Please let me know your opinion on the = same.

Thanks
Partha

-----Original Message-----
From: = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.or= g] On
Behalf Of Hadriel Kaplan
Sent: Friday, July 30, 2010 = 5:14 PM
To: Paul Kyzivat (pkyzivat); Peter Musgrave
Cc: = dispatch@ietf.org list
Subject: Re: [dispatch] Proposal for Session = ID charter



> -----Original Message-----
> From: = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.or= g] On
> Behalf Of Paul Kyzivat
> Sent: Friday, July 30, = 2010 6:08 AM
>
> 2) Other applications that require = correlation of some class of
>     related = dialogs for some purpose other than = troubleshooting
>     are driven away, and so = must define yet another header and id
>     = for their own purposes.

I know adding more headers sucks.  = But that may be the safest = thing.

-hadriel
_______________________________________________=
dispatch mailing list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch
____________________________________= ___________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch

------_=_NextPart_002_01CB38F5.66A01C60-- ------_=_NextPart_001_01CB38F5.66A01C60 Content-Type: text/plain; name="Usecases.txt" Content-Transfer-Encoding: base64 Content-Description: Usecases.txt Content-Disposition: attachment; filename="Usecases.txt" DQpVc2VjYXNlIDE6IE1pZC1kaWFsb2cgc2Vzc2lvbiBpZCBjaGFuZ2UNCg0KVGhlIHVzZWNhc2Ug aWxsdXN0cmF0ZXMgYSBzZXJ2aWNlIHByaW1pdGl2ZSB3aGljaCBzaGFsbCBiZSB1c2VkIGZvciBh dHRlbmRlZCBjYWxsIHRyYW5zZmVyIGFuZCBvdGhlciBjb3VwbGUgb2YgU0lQIGJhc2VkIGNhbGwg c2VydmljZXMuIFRoZSBjYWxsZmxvdyBpcyBhcyBmb2xsb3dzOg0KDQoxKSBBbGljZSBjYWxscyBC b2INCjIpIEFsaWNlIHB1dCBCb2Igb24gSG9sZA0KMykgQWxpY2UgY2FsbHMgQ2Fyb2wNCjQpIEFs aWNlIHB1dCBjYXJvbCBvbiBIb2xkDQo1KSBBbGljZSBjb21wbGV0ZSB0aGUgdHJhbnNmZXIgYmV0 d2VlbiBCb2IgYW5kIENhcm9sLg0KDQpUaGUgY2FsbGZsb3cgaW5jbHVkZXMgdHdvIEIyQlVBJ3Mg bmFtZWx5IEIyQlVBMSAmIEIyQlVBMi4gQjJCVUEgb3BlcmF0ZXMgaW4gM1BDQyBtb2RlLiBFYWNo IGRpYWxvZyBpcyBjcmVhdGVkIHdpdGggSU5WSVRFLzIwMC9BQ0sgc2VxdWVuY2UuIEluIHRoZSBi ZWxvdyBkaWFncmFtcywgZGlhbG9nLWlkIGlzIHJlcHJlc2VudGVkIGJ5ICJEIiwgc2Vzc2lvbi1p ZCBpcyByZXByZXNlbnRlZCBieSAiUyIgYW5kIGFsc28sIHRoZSBzaWduYWxpbmcgZm9yIHNlc3Np b24gSG9sZCBpcyBub3Qgc2hvd24gZXhwbGljaXRseSBpbiB0aGUgZGlhZ3JhbS4NCg0KDQogQWxp Y2UgICAgICAgICAgQjJCVUExICAgICAgICAgICAgQjJCVUEyICAgICAgICAgICAgICBCb2IgICAg ICAgICAgICAgQ2Fyb2wgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgIHwNCiB8LS1JTlYoRDEvUzEpLS0tLT58LS1JTlYoRDIvUzEp LS0tLT58LS1JTlYoRDMvUzEpLS0tLT58ICAgICAgICAgICAgICAgIHwNCiB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg IHwNCiB8PC0yMDAoRDEvUzEpLS0tLS18PC0yMDAoRDIvUzEpLS0tLS18PC0yMDAoRDMvUzEpLS0t LS18ICAgICAgICAgICAgICAgIHwNCiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiB8LS0tQUNLKEQxL1MxKS0t LT58LS1BQ0soRDIvUzEpLS0tLT58LS1BQ0soRDMvUzEpLS0tLT58ICAgICAgICAgICAgICAgIHwN CiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgIHwNCiB8PD09QWxpY2UgUHV0IEJvYiBvbiBIb2xkIChSRS1JTlYvMjAw L0FDSyBTMSk9PT09PT09PiB8ICAgICAgICAgICAgICAgIHwgICAgICAgDQogfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICB8DQogfC0tSU5WKEQ0L3MyKS0tLS0+fC0tSU5WKEQ1L1MyKS0tLS0+fC0tSU5WKEQ2L1MyKS0t LS0tLS0tLS0tLS0tLS0tLS0tLT58DQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8IA0KIHw8LTIwMChENC9TMikt LS0tLXw8LTIwMChENS9zMiktLS0tLXw8LTIwMChENi9TMiktLS0tLS0tLS0tLS0tLS0tLS0tLS0t fA0KIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgfA0KIHwtLUFDSyhENC9TMiktLS0tPnwtLUFDSyhENS9TMiktLS0t PnwtLUFDSyhENi9zMiktLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KIHwgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0K IHw8PT09PT09PT09PUFsaWNlIHB1dCBDYXJvbCBvbiBIb2xkIChSRS1JTlYvMjAwL0FDSyBTMik9 PT09PT09PT09PT09PiAgfA0KIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KIHwgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAg DQogfC0tUkVGRVIvMjAwKEQxKS0+fCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICB8ICANCiB8PC1OT1RJRlkvMjAwKEQxKS18ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiB8ICAgICAgICAgICAgICAg ICB8LS0tUmUtSU5WKEQyL1M/KS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgIHwN CiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgIHwNCiB8ICAgICAgICAgICAgICAgICB8LS0tUmUtSU5WKEQ1L1M/KS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgDQogfCAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQog fCAgICAgICAgICAgICAgICAgfDwtLTIwMChEMi9TPyktLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCAg ICAgICAgICAgICAgICB8DQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogfCAgICAgICAgICAgICAgICAgfDwt LTIwMChENS9TPyktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQogfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICB8DQogfCAgICAgICAgICAgICAgICAgfC0tLUFDSyhEMi9TPyktLS0tLS0tLS0t LS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgICB8DQogfCAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogfCAgICAg ICAgICAgICAgICAgfC0tLUFDSyhENS9TPyktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLT58DQogfDwtTk9USUZZLzIwMChEMSktfCAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogfDwtQllFLzIw MChENC9TMiktfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICB8DQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICB8DQogfC1CWUUvMjAwKEQxL1MxKS0+fCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8IA0KIHwgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgfA0KDQoxKSBTZXNzaW9uIGlkIDEgaXMgY3JlYXRlZCBmb3IgQWxpY2UgYW5kIEJvYiBzZXNz aW9uDQoNCjIpIFNlc3Npb24gaWQgMiBpcyBjcmVhdGVkIGZvciBBbGljZSBhbmQgY2Fyb2wgc2Vz c2lvbg0KDQozKSBBZnRlciB0aGUgdHJhbnNmZXIsIHdoYXQgaXMgdGhlIHNlc3Npb24gaWQgYmV0 d2VlbiBCb2IgYW5kIGNhcm9sPw0KDQpJbiB0aGUgYWJvdmUgY2FsbGZsb3csIGZpbmFsIHNlc3Np b24gaXMgZXN0YWJsaXNoZWQgYmV0d2VlbiBCb0IgYW5kIGNhcm9sIHVzaW5nIFJlLUlOVklURSBt ZWNoYW5pc20gaW4gQjJCVUExLiBGcm9tIHRoZSBCMkJVQTIgcGVyc3BlY3RpdmUsIEQyIGFuZCBE NSBhcmUgZGlmZmVyZW50IGRpYWxvZyBhbmQgYXJlIG5vdCBjb3JyZWxhdGVkIHVudGlsIG90aGVy d2lzZSB0aGUgY29tbW9uIHNlc3Npb24gaWQgZXhpc3RzIGJldHdlZW4gRDIgJiBENSBhZnRlciB0 aGUgY2FsbCB0cmFuc2Zlci4gV2l0aG91dCBjaGFuZ2luZyBzZXNzaW9uLWlkIGluIHRoZSBtaWQt ZGlhbG9nLCBpcyBpdCBwb3NzaWJsZSB0byBoYXZlIHRoZSBjb3JyZWxhdGlvbj8NCg== ------_=_NextPart_001_01CB38F5.66A01C60-- From john.elwell@siemens-enterprise.com Wed Aug 11 00:33:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4BCB3A6A25 for ; Wed, 11 Aug 2010 00:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.768 X-Spam-Level: X-Spam-Status: No, score=-102.768 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJTQozkTray7 for ; Wed, 11 Aug 2010 00:33:37 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8BD8F3A6A20 for ; Wed, 11 Aug 2010 00:33:37 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1132443; Wed, 11 Aug 2010 09:34:12 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 35AAC23F0278; Wed, 11 Aug 2010 09:34:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 11 Aug 2010 09:34:12 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , Hadriel Kaplan , "Paul Kyzivat (pkyzivat)" , Peter Musgrave Date: Wed, 11 Aug 2010 09:34:10 +0200 Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvzxBsafq1F/F2TyimIJKjLTIAkgADQTWQAABlmWACRNMNFAANh4Qw Message-ID: References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> 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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 07:33:38 -0000 Partha, I see the point you are making, which sounds reasonable, although I think t= he diagram is confusing because separate dialog D2 starts off between B2BUA= 1 and B2BUA2, but suddenly changes to being between B2BUA1 and Bob. Likewis= e D5 changes its scope. John =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi=20 > R (partr) > Sent: 11 August 2010 02:35 > To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat=20 > (pkyzivat); Peter Musgrave > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Proposal for Session ID charter >=20 > Hadriel, >=20 > =20 >=20 > I attached the use case which illustrates the session-id=20 > change during mid-dialog. As a individual use case, the use=20 > case is used for transfer based on "Re-INVITE" mechanism. The=20 > use case is useful for creating the complex supplementary=20 > services when use case is used as service primitive. This use=20 > case is deployed by B2BUA in Service Provider softswitches=20 > and Enterprise PBXs. The use case does not propose any=20 > solution but it just indicates the problem in creating the=20 > session-id. Even in case session-id is used for=20 > troubleshooting only, the session-id has to be generic enough=20 > to handle this use case. Please let me know your thought on this. >=20 > =20 >=20 > I'll add more usecases based on the response for this mail. >=20 > =20 >=20 > Thanks >=20 > Partha >=20 > ________________________________ >=20 > From: dispatch-bounces@ietf.org on behalf of Parthasarathi R (partr) > Sent: Fri 7/30/2010 5:47 PM > To: Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Proposal for Session ID charter >=20 >=20 >=20 > Hadriel, >=20 > Instead working with solution in mind, Shall we start with=20 > the usecases > document. The usecase document will help us to decide whether=20 > the single > header or multiple header required. It will help to identify=20 > the generic > session-id if one exists. The usecase requirement will be=20 > very useful as > we are talking about the complex dialog scenarios which=20 > involves set of > B2BUA. >=20 > As I mentioned in the earlier mail thread, I'll come up with=20 > the usecase > document as a starting point, add more relevant usecases and we will > brainstorm whether the usecases are relevant for the session=20 > id or not. > Please let me know your opinion on the same. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Friday, July 30, 2010 5:14 PM > To: Paul Kyzivat (pkyzivat); Peter Musgrave > Cc: dispatch@ietf.org list > Subject: Re: [dispatch] Proposal for Session ID charter >=20 >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Friday, July 30, 2010 6:08 AM > > > > 2) Other applications that require correlation of some class of > > related dialogs for some purpose other than troubleshooting > > are driven away, and so must define yet another header and id > > for their own purposes. >=20 > I know adding more headers sucks. But that may be the safest thing. >=20 > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 > = From partr@cisco.com Wed Aug 11 02:18:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6279B3A6A38 for ; Wed, 11 Aug 2010 02:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.897 X-Spam-Level: X-Spam-Status: No, score=-9.897 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH4B2a9zQ-x9 for ; Wed, 11 Aug 2010 02:18:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 219643A6982 for ; Wed, 11 Aug 2010 02:18:35 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: Usecases.txt : 4153 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFsIYkxAaMHG/2dsb2JhbACgO3GfRJtWgnCCSgSEKod+ X-IronPort-AV: E=Sophos;i="4.55,352,1278288000"; d="txt'?scan'208";a="571776581" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 11 Aug 2010 09:19:02 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7B9IQAs012790; Wed, 11 Aug 2010 09:19:01 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Aug 2010 14:49:00 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB3936.3B837DF6" Date: Wed, 11 Aug 2010 14:48:58 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvzxBsafq1F/F2TyimIJKjLTIAkgADQTWQAABlmWACRNMNFAANh4QwAAOR2WA= References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Hadriel Kaplan" , "Paul Kyzivat (pkyzivat)" , "Peter Musgrave" X-OriginalArrivalTime: 11 Aug 2010 09:19:00.0028 (UTC) FILETIME=[3B8C9FC0:01CB3936] Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 09:18:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3936.3B837DF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, Thanks for accepting the use case and also for pointing out the flaw in it. As you already guess, D2 & D5 is between B2BUA1 and B2BUA2, D3 is between B2BUA2 and Bob, D6 is between B2BUA2 and Carol. I updated the use case and attached with this mail for avoiding the confusion. The focus of the use case is to show that session-id may change during the mid-dialog. Thanks Partha=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Wednesday, August 11, 2010 1:04 PM To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave Cc: dispatch@ietf.org Subject: RE: [dispatch] Proposal for Session ID charter Partha, I see the point you are making, which sounds reasonable, although I think the diagram is confusing because separate dialog D2 starts off between B2BUA1 and B2BUA2, but suddenly changes to being between B2BUA1 and Bob. Likewise D5 changes its scope. John =20 > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R=20 > (partr) > Sent: 11 August 2010 02:35 > To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat);=20 > Peter Musgrave > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Proposal for Session ID charter >=20 > Hadriel, >=20 > =20 >=20 > I attached the use case which illustrates the session-id change during > mid-dialog. As a individual use case, the use case is used for=20 > transfer based on "Re-INVITE" mechanism. The use case is useful for=20 > creating the complex supplementary services when use case is used as=20 > service primitive. This use case is deployed by B2BUA in Service=20 > Provider softswitches and Enterprise PBXs. The use case does not=20 > propose any solution but it just indicates the problem in creating the > session-id. Even in case session-id is used for troubleshooting only,=20 > the session-id has to be generic enough to handle this use case. =20 > Please let me know your thought on this. >=20 > =20 >=20 > I'll add more usecases based on the response for this mail. >=20 > =20 >=20 > Thanks >=20 > Partha >=20 > ________________________________ >=20 > From: dispatch-bounces@ietf.org on behalf of Parthasarathi R (partr) > Sent: Fri 7/30/2010 5:47 PM > To: Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Proposal for Session ID charter >=20 >=20 >=20 > Hadriel, >=20 > Instead working with solution in mind, Shall we start with the=20 > usecases document. The usecase document will help us to decide whether > the single header or multiple header required. It will help to=20 > identify the generic session-id if one exists. The usecase requirement > will be very useful as we are talking about the complex dialog=20 > scenarios which involves set of B2BUA. >=20 > As I mentioned in the earlier mail thread, I'll come up with the=20 > usecase document as a starting point, add more relevant usecases and=20 > we will brainstorm whether the usecases are relevant for the session=20 > id or not. > Please let me know your opinion on the same. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Hadriel Kaplan > Sent: Friday, July 30, 2010 5:14 PM > To: Paul Kyzivat (pkyzivat); Peter Musgrave > Cc: dispatch@ietf.org list > Subject: Re: [dispatch] Proposal for Session ID charter >=20 >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Friday, July 30, 2010 6:08 AM > > > > 2) Other applications that require correlation of some class of > > related dialogs for some purpose other than troubleshooting > > are driven away, and so must define yet another header and id > > for their own purposes. >=20 > I know adding more headers sucks. But that may be the safest thing. >=20 > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 >=20 ------_=_NextPart_001_01CB3936.3B837DF6 Content-Type: text/plain; name="Usecases.txt" Content-Transfer-Encoding: base64 Content-Description: Usecases.txt Content-Disposition: attachment; filename="Usecases.txt" DQpVc2VjYXNlIDE6IE1pZC1kaWFsb2cgc2Vzc2lvbiBpZCBjaGFuZ2UNCg0KVGhlIHVzZWNhc2Ug aWxsdXN0cmF0ZXMgYSBzZXJ2aWNlIHByaW1pdGl2ZSB3aGljaCBzaGFsbCBiZSB1c2VkIGZvciBh dHRlbmRlZCBjYWxsIHRyYW5zZmVyIGFuZCBvdGhlciBjb3VwbGUgb2YgU0lQIGJhc2VkIGNhbGwg c2VydmljZXMuIFRoZSBjYWxsZmxvdyBpcyBhcyBmb2xsb3dzOg0KDQoxKSBBbGljZSBjYWxscyBC b2INCjIpIEFsaWNlIHB1dCBCb2Igb24gSG9sZA0KMykgQWxpY2UgY2FsbHMgQ2Fyb2wNCjQpIEFs aWNlIHB1dCBjYXJvbCBvbiBIb2xkDQo1KSBBbGljZSBjb21wbGV0ZSB0aGUgdHJhbnNmZXIgYmV0 d2VlbiBCb2IgYW5kIENhcm9sLg0KDQpUaGUgY2FsbGZsb3cgaW5jbHVkZXMgdHdvIEIyQlVBJ3Mg bmFtZWx5IEIyQlVBMSAmIEIyQlVBMi4gQjJCVUEgb3BlcmF0ZXMgaW4gM1BDQyBtb2RlLiBFYWNo IGRpYWxvZyBpcyBjcmVhdGVkIHdpdGggSU5WSVRFLzIwMC9BQ0sgc2VxdWVuY2UuIEluIHRoZSBi ZWxvdyBkaWFncmFtcywgZGlhbG9nLWlkIGlzIHJlcHJlc2VudGVkIGJ5ICJEIiwgc2Vzc2lvbi1p ZCBpcyByZXByZXNlbnRlZCBieSAiUyIgYW5kIGFsc28sIHRoZSBzaWduYWxpbmcgZm9yIHNlc3Np b24gSG9sZCBpcyBub3Qgc2hvd24gZXhwbGljaXRseSBpbiB0aGUgZGlhZ3JhbS4NCg0KDQogQWxp Y2UgICAgICAgICAgQjJCVUExICAgICAgICAgICAgQjJCVUEyICAgICAgICAgICAgICBCb2IgICAg ICAgICAgICAgQ2Fyb2wgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgIHwNCiB8LS1JTlYoRDEvUzEpLS0tLT58LS1JTlYoRDIvUzEp LS0tLT58LS1JTlYoRDMvUzEpLS0tLT58ICAgICAgICAgICAgICAgIHwNCiB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg IHwNCiB8PC0yMDAoRDEvUzEpLS0tLS18PC0yMDAoRDIvUzEpLS0tLS18PC0yMDAoRDMvUzEpLS0t LS18ICAgICAgICAgICAgICAgIHwNCiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiB8LS0tQUNLKEQxL1MxKS0t LT58LS1BQ0soRDIvUzEpLS0tLT58LS1BQ0soRDMvUzEpLS0tLT58ICAgICAgICAgICAgICAgIHwN CiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgIHwNCiB8PD09QWxpY2UgUHV0IEJvYiBvbiBIb2xkIChSRS1JTlYvMjAw L0FDSyBTMSk9PT09PT09PiB8ICAgICAgICAgICAgICAgIHwgICAgICAgDQogfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICB8DQogfC0tSU5WKEQ0L3MyKS0tLS0+fC0tSU5WKEQ1L1MyKS0tLS0+fC0tSU5WKEQ2L1MyKS0t LS0tLS0tLS0tLS0tLS0tLS0tLT58DQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8IA0KIHw8LTIwMChENC9TMikt LS0tLXw8LTIwMChENS9zMiktLS0tLXw8LTIwMChENi9TMiktLS0tLS0tLS0tLS0tLS0tLS0tLS0t fA0KIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgfA0KIHwtLUFDSyhENC9TMiktLS0tPnwtLUFDSyhENS9TMiktLS0t PnwtLUFDSyhENi9zMiktLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KIHwgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0K IHw8PT09PT09PT09PUFsaWNlIHB1dCBDYXJvbCBvbiBIb2xkIChSRS1JTlYvMjAwL0FDSyBTMik9 PT09PT09PT09PT09PiAgfA0KIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KIHwgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAg DQogfC0tUkVGRVIvMjAwKEQxKS0+fCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICB8ICANCiB8PC1OT1RJRlkvMjAwKEQxKS18ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiB8ICAgICAgICAgICAgICAg ICB8LS1SZS1JTlYoRDIvUz8pLT58LS1SZS1JTlYoRDMvUz8pLT58ICAgICAgICAgICAgICAgIHwN CiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgIHwNCiB8ICAgICAgICAgICAgICAgICB8LS1SZS1JTlYoRDUvUz8pLT58 LS1SZS1JTlYoRDYvUz8pLS0tLS0tLS0tLS0tLS0tLS0tPnwgDQogfCAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQog fCAgICAgICAgICAgICAgICAgfDwtLTIwMChEMi9TPyktLS0tfDwtMjAwKEQzL1M/KS0tLS0tfCAg ICAgICAgICAgICAgICB8DQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogfCAgICAgICAgICAgICAgICAgfDwt LTIwMChENS9TPyktLS0tfDwtMjAwKEQ2L1M/KS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQogfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICB8DQogfCAgICAgICAgICAgICAgICAgfC0tLUFDSyhEMi9TPyktLS0+fC0tQUNL KEQzL1M/KS0tLS0+fCAgICAgICAgICAgICAgICB8DQogfCAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogfCAgICAg ICAgICAgICAgICAgfC0tLUFDSyhENS9TPyktLS0tfC0tQUNLKEQ2L1M/KS0tLS0tLS0tLS0tLS0t LS0tLS0tLT58DQogfDwtTk9USUZZLzIwMChEMSktfCAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogfDwtQllFLzIw MChENC9TMiktfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICB8DQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICB8DQogfC1CWUUvMjAwKEQxL1MxKS0+fCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8IA0KIHwgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgfA0KDQoxKSBTZXNzaW9uIGlkIDEgaXMgY3JlYXRlZCBmb3IgQWxpY2UgYW5kIEJvYiBzZXNz aW9uDQoNCjIpIFNlc3Npb24gaWQgMiBpcyBjcmVhdGVkIGZvciBBbGljZSBhbmQgY2Fyb2wgc2Vz c2lvbg0KDQozKSBBZnRlciB0aGUgdHJhbnNmZXIsIHdoYXQgaXMgdGhlIHNlc3Npb24gaWQgYmV0 d2VlbiBCb2IgYW5kIGNhcm9sPw0KDQpJbiB0aGUgYWJvdmUgY2FsbGZsb3csIGZpbmFsIHNlc3Np b24gaXMgZXN0YWJsaXNoZWQgYmV0d2VlbiBCb0IgYW5kIGNhcm9sIHVzaW5nIFJlLUlOVklURSBt ZWNoYW5pc20gaW4gQjJCVUExLiBGcm9tIHRoZSBCMkJVQTIgcGVyc3BlY3RpdmUsIEQyIGFuZCBE NSBhcmUgZGlmZmVyZW50IGRpYWxvZyBhbmQgYXJlIG5vdCBjb3JyZWxhdGVkIHVudGlsIG90aGVy d2lzZSB0aGUgY29tbW9uIHNlc3Npb24gaWQgZXhpc3RzIGJldHdlZW4gRDIgJiBENSBhZnRlciB0 aGUgY2FsbCB0cmFuc2Zlci4gV2l0aG91dCBjaGFuZ2luZyBzZXNzaW9uLWlkIGluIHRoZSBtaWQt ZGlhbG9nLCBpcyBpdCBwb3NzaWJsZSB0byBoYXZlIHRoZSBjb3JyZWxhdGlvbj8NCg== ------_=_NextPart_001_01CB3936.3B837DF6-- From peter.musgrave@magorcorp.com Wed Aug 11 12:45:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F9A3A67D1 for ; Wed, 11 Aug 2010 12:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.071 X-Spam-Level: X-Spam-Status: No, score=-102.071 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRU0sbxOtyvG for ; Wed, 11 Aug 2010 12:45:56 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 1F4FE3A65A5 for ; Wed, 11 Aug 2010 12:45:55 -0700 (PDT) Received: by qyk1 with SMTP id 1so4852139qyk.10 for ; Wed, 11 Aug 2010 12:46:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.159 with SMTP id j31mr9962153qci.212.1281555991964; Wed, 11 Aug 2010 12:46:31 -0700 (PDT) Received: by 10.229.219.8 with HTTP; Wed, 11 Aug 2010 12:46:31 -0700 (PDT) In-Reply-To: References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> <4C528B89.5090906@cisco.com> <4C52A46E.1070305@cisco.com> <430FC6BDED356B4C8498F634416644A92694002E6A@mail> Date: Wed, 11 Aug 2010 15:46:31 -0400 Message-ID: From: Peter Musgrave To: "Parthasarathi R (partr)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 19:45:57 -0000 Hi, I agree use cases like this are useful. I think they are covered by the part of the charter which indicates that the specific behaviour under REFER will be defined. It may not be what is ideal for every scenario - but the behaviour will be predictable. I think the main issue w.r.t the charter is whether siprec needs something like session-id (and if that something requires dialog correlation - which the current session-id does not claim to provide). The path forward to me seems to be 1) go down the dialog correlation rabbit hole - or - 2) re-label this into something more representative of it's purpose (i.e. Debug-Tag:) and keep the scope narrow. Peter On Wed, Aug 11, 2010 at 5:18 AM, Parthasarathi R (partr) wrote: > John, > > Thanks for accepting the use case and also for pointing out the flaw in > it. As you already guess, D2 & D5 is between B2BUA1 and B2BUA2, D3 is > between B2BUA2 and Bob, D6 is between B2BUA2 and Carol. I updated the > use case and attached with this mail for avoiding the confusion. > > The focus of the use case is to show that session-id may change during > the mid-dialog. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, August 11, 2010 1:04 PM > To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat); > Peter Musgrave > Cc: dispatch@ietf.org > Subject: RE: [dispatch] Proposal for Session ID charter > > Partha, > > I see the point you are making, which sounds reasonable, although I > think the diagram is confusing because separate dialog D2 starts off > between B2BUA1 and B2BUA2, but suddenly changes to being between B2BUA1 > and Bob. Likewise D5 changes its scope. > > John > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R >> (partr) >> Sent: 11 August 2010 02:35 >> To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat); >> Peter Musgrave >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Proposal for Session ID charter >> >> Hadriel, >> >> >> >> I attached the use case which illustrates the session-id change during > >> mid-dialog. As a individual use case, the use case is used for >> transfer based on "Re-INVITE" mechanism. The use case is useful for >> creating the complex supplementary services when use case is used as >> service primitive. This use case is deployed by B2BUA in Service >> Provider softswitches and Enterprise PBXs. The use case does not >> propose any solution but it just indicates the problem in creating the > >> session-id. Even in case session-id is used for troubleshooting only, >> the session-id has to be generic enough to handle this use case. >> Please let me know your thought on this. >> >> >> >> I'll add more usecases based on the response for this mail. >> >> >> >> Thanks >> >> Partha >> >> ________________________________ >> >> From: dispatch-bounces@ietf.org on behalf of Parthasarathi R (partr) >> Sent: Fri 7/30/2010 5:47 PM >> To: Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Proposal for Session ID charter >> >> >> >> Hadriel, >> >> Instead working with solution in mind, Shall we start with the >> usecases document. The usecase document will help us to decide whether > >> the single header or multiple header required. It will help to >> identify the generic session-id if one exists. The usecase requirement > >> will be very useful as we are talking about the complex dialog >> scenarios which involves set of B2BUA. >> >> As I mentioned in the earlier mail thread, I'll come up with the >> usecase document as a starting point, add more relevant usecases and >> we will brainstorm whether the usecases are relevant for the session >> id or not. >> Please let me know your opinion on the same. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Hadriel Kaplan >> Sent: Friday, July 30, 2010 5:14 PM >> To: Paul Kyzivat (pkyzivat); Peter Musgrave >> Cc: dispatch@ietf.org list >> Subject: Re: [dispatch] Proposal for Session ID charter >> >> >> >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On >> > Behalf Of Paul Kyzivat >> > Sent: Friday, July 30, 2010 6:08 AM >> > >> > 2) Other applications that require correlation of some class of >> > =A0 =A0 related dialogs for some purpose other than troubleshooting >> > =A0 =A0 are driven away, and so must define yet another header and id >> > =A0 =A0 for their own purposes. >> >> I know adding more headers sucks. =A0But that may be the safest thing. >> >> -hadriel >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> > From vkg@bell-labs.com Wed Aug 11 14:19:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D36D3A6879 for ; Wed, 11 Aug 2010 14:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duFDjR0cHDwD for ; Wed, 11 Aug 2010 14:19:42 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 3BC5E3A6823 for ; Wed, 11 Aug 2010 14:19:41 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o7BLKGeG026130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Aug 2010 16:20:16 -0500 (CDT) Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o7BLKGvH012819 for ; Wed, 11 Aug 2010 16:20:16 -0500 (CDT) Message-ID: <4C631483.2010809@bell-labs.com> Date: Wed, 11 Aug 2010 16:22:11 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100720 Fedora/3.0.6-1.fc12 Thunderbird/3.0.6 MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [dispatch] CUSS WG logistics X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 21:19:43 -0000 Folks: The Call control UUI Service for SIP (CUSS) working group is all but chartered. The final version of the charter is being socialized with the IESG and essentially awaiting approval by the sponsoring AD (who happens to be on vacation right now.) The mailing list for the WG have been created; if you have not subscribed to it, please do so by going to https://www.ietf.org/mailman/listinfo/cuss Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From partr@cisco.com Wed Aug 11 22:56:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8313A695A for ; Wed, 11 Aug 2010 22:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.941 X-Spam-Level: X-Spam-Status: No, score=-9.941 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzy11uoizGHS for ; Wed, 11 Aug 2010 22:56:11 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4136C3A67A7 for ; Wed, 11 Aug 2010 22:56:11 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: Siprec-usecases.txt : 2431 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJIpY0xAaMHG/2dsb2JhbACgOXGedZtEgnCCSgSEKod+ X-IronPort-AV: E=Sophos;i="4.55,356,1278288000"; d="txt'?scan'208";a="351417897" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2010 05:56:46 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7C5uich018046; Thu, 12 Aug 2010 05:56:45 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Aug 2010 11:26:05 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB39E3.0D99CBA9" Date: Thu, 12 Aug 2010 11:26:04 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: Acs5je8Y/qt7tJTgRLau5RNcym+AaAANpRYg References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> From: "Parthasarathi R (partr)" To: "Peter Musgrave" X-OriginalArrivalTime: 12 Aug 2010 05:56:05.0639 (UTC) FILETIME=[0D760970:01CB39E3] Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 05:56:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB39E3.0D99CBA9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Peter/all, Thanks for accepting that usecases are useful for this discussion. The = mentioned usecase is not about REFER in B2BUA1, but it is about = Re-INVITE changing the session-id between two B2BUAs. From B2BUA2 = perspective, it does not have any intelligence that REFER received in = B2BUA1. The same RE-INVITE session-id scenario may occurs in B2BUA2 due = to some other trigger. The current Hadriel's session-id solution does = not cover this. I wish that usecase document has to be considered as one = of the work item for this charter to identify which are all the usecases = will be covered by the proposed session-id charter. The main issue is whether the charter is applicable only for = troubleshooting or it is the new SIP infrastructure which shall be used = for different purpose depends upon the application. In case session-id = is possible for the mentioned usecase, session-id shall be used for = session loopback identification in B2BUA2 with the combination of other = SIP parameters. Without session-id in SIP message, it is not possible to = identify the session loopback for all the usecases today.=20 The other way to look at SIP loopback detection in B2BUA/SBC using = session-id is as follows: The session loopback detection mechanism in = B2BUA/SBC avoids the complicated troubleshooting of loop callflows in = B2BUA SIP networks. I'm interested in hearing your and others opinion = here. =20 I attached the mail thread by John Elwell which indicates the session-id = usage in SIPREC. I also attached one of the possible callflow for the = same. SIPREC is yet to define the callflows, so the callflow may change. = Thanks Partha =20 -----Original Message----- From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 Sent: Thursday, August 12, 2010 1:17 AM To: Parthasarathi R (partr) Cc: Elwell, John; Hadriel Kaplan; Paul Kyzivat (pkyzivat); = dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter Hi, I agree use cases like this are useful. I think they are covered by the = part of the charter which indicates that the specific behaviour under = REFER will be defined. It may not be what is ideal for every scenario - = but the behaviour will be predictable. I think the main issue w.r.t the charter is whether siprec needs = something like session-id (and if that something requires dialog = correlation - which the current session-id does not claim to provide). The path forward to me seems to be 1) go down the dialog correlation rabbit hole - or - 2) re-label this into something more representative of it's purpose = (i.e. Debug-Tag:) and keep the scope narrow. Peter On Wed, Aug 11, 2010 at 5:18 AM, Parthasarathi R (partr) = wrote: > John, > > Thanks for accepting the use case and also for pointing out the flaw=20 > in it. As you already guess, D2 & D5 is between B2BUA1 and B2BUA2, D3=20 > is between B2BUA2 and Bob, D6 is between B2BUA2 and Carol. I updated=20 > the use case and attached with this mail for avoiding the confusion. > > The focus of the use case is to show that session-id may change during = > the mid-dialog. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, August 11, 2010 1:04 PM > To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat);=20 > Peter Musgrave > Cc: dispatch@ietf.org > Subject: RE: [dispatch] Proposal for Session ID charter > > Partha, > > I see the point you are making, which sounds reasonable, although I=20 > think the diagram is confusing because separate dialog D2 starts off=20 > between B2BUA1 and B2BUA2, but suddenly changes to being between=20 > B2BUA1 and Bob. Likewise D5 changes its scope. > > John > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R >> (partr) >> Sent: 11 August 2010 02:35 >> To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat); = >> Peter Musgrave >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Proposal for Session ID charter >> >> Hadriel, >> >> >> >> I attached the use case which illustrates the session-id change=20 >> during > >> mid-dialog. As a individual use case, the use case is used for=20 >> transfer based on "Re-INVITE" mechanism. The use case is useful for=20 >> creating the complex supplementary services when use case is used as=20 >> service primitive. This use case is deployed by B2BUA in Service=20 >> Provider softswitches and Enterprise PBXs. The use case does not=20 >> propose any solution but it just indicates the problem in creating=20 >> the > >> session-id. Even in case session-id is used for troubleshooting only, = >> the session-id has to be generic enough to handle this use case. >> Please let me know your thought on this. >> >> >> >> I'll add more usecases based on the response for this mail. >> >> >> >> Thanks >> >> Partha >> >> ________________________________ >> >> From: dispatch-bounces@ietf.org on behalf of Parthasarathi R (partr) >> Sent: Fri 7/30/2010 5:47 PM >> To: Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Proposal for Session ID charter >> >> >> >> Hadriel, >> >> Instead working with solution in mind, Shall we start with the=20 >> usecases document. The usecase document will help us to decide=20 >> whether > >> the single header or multiple header required. It will help to=20 >> identify the generic session-id if one exists. The usecase=20 >> requirement > >> will be very useful as we are talking about the complex dialog=20 >> scenarios which involves set of B2BUA. >> >> As I mentioned in the earlier mail thread, I'll come up with the=20 >> usecase document as a starting point, add more relevant usecases and=20 >> we will brainstorm whether the usecases are relevant for the session=20 >> id or not. >> Please let me know your opinion on the same. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = >> Behalf Of Hadriel Kaplan >> Sent: Friday, July 30, 2010 5:14 PM >> To: Paul Kyzivat (pkyzivat); Peter Musgrave >> Cc: dispatch@ietf.org list >> Subject: Re: [dispatch] Proposal for Session ID charter >> >> >> >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On >> > Behalf Of Paul Kyzivat >> > Sent: Friday, July 30, 2010 6:08 AM >> > >> > 2) Other applications that require correlation of some class of >> > =A0 =A0 related dialogs for some purpose other than troubleshooting >> > =A0 =A0 are driven away, and so must define yet another header and = id >> > =A0 =A0 for their own purposes. >> >> I know adding more headers sucks. =A0But that may be the safest = thing. >> >> -hadriel >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> > ------_=_NextPart_001_01CB39E3.0D99CBA9 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from xbh-bgl-411.cisco.com ([72.163.129.201]) by xmb-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 14:18:57 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from xbh-rcd-202.cisco.com ([72.163.62.201]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 14:18:57 +0530 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 03:48:54 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 05 Aug 2010 08:48:53 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o758mqNq001637; Thu, 5 Aug 2010 08:48:53 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-f.cisco.com with ESMTP; 05 Aug 2010 08:48:52 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273EA3A68D8; Thu, 5 Aug 2010 01:48:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B203A69B9 for ; Thu, 5 Aug 2010 01:48:20 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsNCV+0KYWsD for ; Thu, 5 Aug 2010 01:48:19 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D43CE3A6829 for ; Thu, 5 Aug 2010 01:48:18 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1076574; Thu, 5 Aug 2010 10:48:47 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C54C21EB82AB; Thu, 5 Aug 2010 10:48:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 5 Aug 2010 10:48:47 +0200 Content-class: urn:content-classes:message Subject: Re: [siprec] Session-id proposal in DISPATCH Date: Thu, 5 Aug 2010 14:18:46 +0530 Message-ID: In-Reply-To: <4C598B67.80906@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Session-id proposal in DISPATCH Thread-Index: Acsz7EBMS5K0KeTQSuWeeSRzqcX0dQAit/IA References: <4C598B67.80906@cisco.com> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Elwell, John" Sender: To: "Paul Kyzivat (pkyzivat)" Cc: In fact there are at least two cases where there are multiple RSs for a = single CS (in its broader sense). 1. Where there is a single SRC, which has time-separated RSs to the SRS = (because recording is stopped and started again). This should not be a = problem, because presumably the single SRC could provide appropriate = metadata to correlate the two RSs as belonging to the same CS. 2. Where there are different SRCs, each with an RS to the SRS - these = can be simultaneous, overlapping or time-separated). This is the case = where some form of session-id might help. However, it is quite difficult to write requirements for case 2, because = of getting agreement on the precise circumstances in which two SIP = dialogs at different entities can be considered to be the same CS. = Features such as attended transfer, unattended transfer, local = conferencing, centralized conferencing, shared appearance bridging, = etc., can all be involved, and these can be implemented in different = ways (end-to-end, 3PCC). Getting agreement on exactly how a mediating = SIP entity (UA/B2BUA) should behave in ensuring that appropriate SIP = dialogs are given the same session-id and that others are given a = different session-id sounds like it could be a nightmare. Furthermore, = the mediating SIP entity might not be SIPREC-compliant, and therefore = would not be obliged to support whatever session-id mechanism SIPREC = might mandate. For example, consider the case where there is an SRC at an agent's UA = (or at a B2BUA serving the agent), and an SRC at a supervisor's UA (or = at a B2BUA serving the supervisor). The agent's UA transfers a call = (unattended) to the supervisor by sending a REFER request to the remote = UA (say a PSTN gateway). If that remote UA does not support whatever = session-id mechanism SIPREC requires, it might not be possible to = achieve correlation. So I have doubts whether we are in a position to specify precise = requirements in a form that would solve case 2 in the vast majority of = situations. In the absence of a session-id usable for this purpose, we = are back to the SRS using heuristics (e.g., recording start/stop times, = caller ID, CCUS content, etc..) to correlate two CSs from different = SRCs. John (as individual) > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 04 August 2010 16:47 > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] Session-id proposal in DISPATCH >=20 > To follow up on this we need to get some homework done here=20 > in siprec,=20 > to know what correlations we need help with. >=20 > I think session-id is not needed for siprec in those cases where a=20 > single SRC is managing an RC. It can then provide all the needed=20 > correlation data itself. >=20 > ISTM the case where session-id is useful is when there are=20 > multiple RS=20 > that involve a single CS (in the loose sense, since we don't=20 > yet have a=20 > clear def of CS.) Then it may be up to the SRS to recognize the=20 > correlation, so session-id could be useful. >=20 > I don't think we (yet) have enough facts to turn that need into=20 > requirements on session-id. >=20 > Thanks, > Paul >=20 > Elwell, John wrote: > > DISPATCH is considering a proposed charter for a WG to=20 > specify a session-id header field for correlating dialogs=20 > belonging to the same session across B2BUAs. At present, it=20 > is being specified only for troubleshooting purposes. > >=20 > > During some of the discussions in SIPREC, I have sensed=20 > that there may be a need for correlating recordings that=20 > derive from the same communication session. If so, I don't=20 > know whether reuse of the proposed session-id would be a=20 > candidate solution. The present scoping of the session-id=20 > charter, whilst not necessarily preventing its reuse for=20 > SIPREC purposes, may not be adequate, depending on exact=20 > requirements from SIPREC. Thus we may end up defining yet=20 > another mechanism for correlation, where a single mechanism,=20 > adequately scoped, would have sufficed. > >=20 > > I would urge anyone who expects the session-id charter to=20 > deliver a solution suitable for SIPREC use to engage in=20 > discussions on the DISPATCH list, e.g., in the following thread: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg02426.html > >=20 > > The SIPREC list can, of course, be used to discuss SIPREC=20 > requirements in this area, but please do not cross-post. Use: > > - the SIPREC list to discuss requirements for correlation; > > - the DISPATCH list to influence the Session-ID charter,=20 > based on requirements from SIPREC. > >=20 > > John > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CB39E3.0D99CBA9 Content-Type: text/plain; name="Siprec-usecases.txt" Content-Transfer-Encoding: base64 Content-Description: Siprec-usecases.txt Content-Disposition: attachment; filename="Siprec-usecases.txt" VXNlY2FzZSAyOiBTZXNzaW9uLWlkIHVzYWdlIGluIERpc3RyaWJ1dGVkIFNSQyB3aXRoIFNpbmds ZSBTUlMgKEpvaG4gRWx3ZWxsIFNJUFJFQyBjYWxsZmxvdykNCg0KTXVsdGlwbGUgU2Vzc2lvbiBS ZWNvcmRpbmcgY2xpZW50IChTUkMpIG1heSBiZSB1c2VkIGZvciByZWNvcmRpbmcgdGhlIHNpbmds ZSBjb21tdW5pY2F0aW9uIHNlc3Npb24gdG8gdGhlIHNhbWUgU2Vzc2lvbiBSZWNvcmRpbmcgU2Vy dmVyIChTUlMpLiBNdWx0aXBsZSBTUkMgYXJlIGNvbm5lY3RlZCB0aHJvdWdoIEIyQlVBLiBUaGlz IGRlcGxveW1lbnQgbm9ybWFsbHkgY29tZXMgd2hlbiB0aGUgZW5kcG9pbnQgcGVyZm9ybXMgdGhl IHVuaWRpcmVjdGlvbmFsIG1lZGlhIHJlY29yZGluZyAoVHggcmVjb3JkaW5nIG9ubHkpIGluc3Rl YWQgb2YgYmlkaXJlY3Rpb25hbCByZWNvcmRpbmcgKFR4L1J4IHJlY29yZGluZykuIFNSUyBoYXMg dG8gbWVyZ2UgYm90aCB0aGUgZGlhbG9ncyBiYXNlZCBvbiB0aGUgcmVjZWl2ZWQgbWV0YWRhdGEu IA0KDQpUb3BvbG9neToNCg0KICAgICAgICAgICAgIFNSQzEtLS0tLUIyQlVBLS0tLVNSQzItLS0t LS1TUlMNCiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIA0KICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkIyQlVBIG9wZXJhdGVzIGluIDNQQ0MgbW9k ZS4gRWFjaCBkaWFsb2cgaXMgY3JlYXRlZCB3aXRoIElOVklURS8yMDAvQUNLIHNlcXVlbmNlLiBJ biB0aGUgYmVsb3cgZGlhZ3JhbSwgZGlhbG9nLWlkIGlzIHJlcHJlc2VudGVkIGJ5ICJEIiwgc2Vz c2lvbi1pZCBpcyByZXByZXNlbnRlZCBieSAiUyIgYW5kIG1ldGFkYXRhIHVuaXF1ZSAoc2Vzc2lv bikgaWQgYnkgIk1TIi4NCg0KVGhlIENhbGxmbG93IGlzIGFzIGZvbGxvd3M6DQoNCjEpIFNSQzEg ZXN0YWJsaXNoZXMgc2Vzc2lvbiB0byBTUkMyIHRocm91Z2ggQjJCVUENCjIpIFNSQzEgJiBTUkMy IGluaXRpYXRlcyByZWNvcmRpbmcgdG93YXJkcyBTUlMNCg0KICANCiBTUkMxICAgICAgICAgICAg QjJCVUEgICAgICAgICAgICAgU1JDMiAgICAgICAgICAgICAgIFNSUyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgDQog fC0tSU5WKEQxL1MxKS0tLS0+fC0tSU5WKEQyL1MxKS0tLS0+fCAgICAgICAgICAgICAgICAgfCAg ICANCiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICB8DQogfC1JTlYoRDMvUzIvTVMxKS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0+fA0KIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgIHwNCiB8PC0yMDAoRDEvUzEpLS0tLS18PC0yMDAoRDIvUzEpLS0tLS18ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgDQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg fC1JTlYoRDQvUzMvTVMxKS0+fA0KIHwtLUFDSyhEMS9TMSktLS0tPnwtLUFDSyhEMi9TMSktLS0t PnwgICAgICAgICAgICAgICAgIHwNCiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICB8DQogfDwtMjAwKEQzL1MyL01TMSktLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tfCANCiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICB8DQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgfDwtMjAwKEQ0L1MzL01TMSktfA0KIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgIHwNCiB8LS1BQ0soRDMvUzIvTVMxKS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgfA0KIHwgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgIHwtQUNLKEQ0L1MzL01TMSktPnwNCg0KSW4gdGhlIGFib3ZlIGRpYWdyYW0sIFNS QzEgYW5kIFNSQzIgaGF2ZSBubyB1bmlxdWUtaWQgZm9yIHRoZSBzZXNzaW9uIGFzIHRoZSBjYWxs LWlkIHdpbGwgYmUgb3ZlcnJpZGRlbiBieSBCMkJVQS4gSW4gY2FzZSBzZXNzaW9uIGlkIGV4aXN0 IGJldHdlZW4gU1JDMSBhbmQgU1JDMiBkdXJpbmcgdGhlIGNhbGwgZXN0YWJsaXNobWVudCwgU1JD MSBhbmQgU1JDMiB3aWxsIHBhc3MgdGhlIHNlc3Npb24taWQgKFMxKSBpbiB0aGUgbWV0YWRhdGEg dG93YXJkcyBTUlMgZm9yIHRoZSBsYXRlciByZXRyaWV2YWwuIA== ------_=_NextPart_001_01CB39E3.0D99CBA9-- From ingemar.s.johansson@ericsson.com Thu Aug 12 04:57:40 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73E973A6890 for ; Thu, 12 Aug 2010 04:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.472 X-Spam-Level: X-Spam-Status: No, score=-5.472 tagged_above=-999 required=5 tests=[AWL=1.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23zLnyvknKNW for ; Thu, 12 Aug 2010 04:57:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 29D6F3A6359 for ; Thu, 12 Aug 2010 04:57:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-86-4c63e1d7d2a2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 22.1E.10125.7D1E36C4; Thu, 12 Aug 2010 13:58:15 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 12 Aug 2010 13:58:12 +0200 Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.96]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 12 Aug 2010 13:58:05 +0200 From: Ingemar Johansson S To: "dispatch@ietf.org" Date: Thu, 12 Aug 2010 13:58:05 +0200 Thread-Topic: Work on Teleprecense Thread-Index: Acs6FZ8+7GTYrUSzQ6mbdIRvh4ZXgw== Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Work on Teleprecense X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 11:57:40 -0000 Hi Things got quiet after the Ad hoc on Teleprecense. Is there any separate ma= iling list created for this ? /Ingemar=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D INGEMAR JOHANSSON M.Sc.=20 Senior Research Engineer=20 Ericsson AB Multimedia Technologies Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com=20 Visit http://labs.ericsson.com ! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D From tme@americafree.tv Thu Aug 12 05:13:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FBD13A68E4 for ; Thu, 12 Aug 2010 05:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dhnn4jVOmjpb for ; Thu, 12 Aug 2010 05:13:01 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id E31423A6866 for ; Thu, 12 Aug 2010 05:13:00 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id B35D085E0CEF; Thu, 12 Aug 2010 08:13:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Marshall Eubanks In-Reply-To: Date: Thu, 12 Aug 2010 08:13:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ingemar Johansson S X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] Work on Teleprecense X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:13:02 -0000 On Aug 12, 2010, at 7:58 AM, Ingemar Johansson S wrote: > Hi >=20 > Things got quiet after the Ad hoc on Teleprecense. Is there any = separate mailing list created for this ? I believe that one should be set one up.=20 Allyn and the chairs - can you set up a mailing list ? (I can help if = you need it.) Marshall >=20 > /Ingemar=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > INGEMAR JOHANSSON M.Sc.=20 > Senior Research Engineer=20 >=20 > Ericsson AB > Multimedia Technologies > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com=20 > Visit http://labs.ericsson.com ! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From mary.ietf.barnes@gmail.com Thu Aug 12 08:00:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0EE3A68D8 for ; Thu, 12 Aug 2010 08:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9SKerF4Mo2V for ; Thu, 12 Aug 2010 08:00:03 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 02F893A67B5 for ; Thu, 12 Aug 2010 08:00:02 -0700 (PDT) Received: by gyg8 with SMTP id 8so515582gyg.31 for ; Thu, 12 Aug 2010 08:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9hR5RZtd6NkwJGvmBH6DFnkI0YzGrB1uLA3AeKow9n8=; b=g8lfSSWJ8H9RIjL+nFFpvy8Xly3AE1KZdxhBLInz90+/IKUUjGN0H62CHr09EDIgJ9 ANAQq+0Q+wdBtj6A3AFYjPmnrmHde2lV4yKZfy+7kFmUsFiN7U1MCofMNMDjJbhsqACg 9bnXmwZR9Och3ToLffJpLoNnvrpJ91qFyWl4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DogsNmUpAy8kdzYRnia+IRAEH8CvIZUm5X0kVRW9FlZpELNm7338qPSfU1l8QjMVop E7H7J1X+kjMu0GBGEs88xYNh81lUkbER32AdUAKI8pju9aUMbLnyNw8iuLYu2BriVKly IqBM4oxfTVRDNz6FYgqGIFh8cZNsrDGQGGqFc= MIME-Version: 1.0 Received: by 10.100.112.3 with SMTP id k3mr292417anc.39.1281625239540; Thu, 12 Aug 2010 08:00:39 -0700 (PDT) Received: by 10.100.16.23 with HTTP; Thu, 12 Aug 2010 08:00:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Aug 2010 10:00:39 -0500 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: multipart/alternative; boundary=0016e644b84e2353cb048da1a114 Cc: Ingemar Johansson S , DISPATCH list Subject: Re: [dispatch] Work on Teleprecense X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 15:00:04 -0000 --0016e644b84e2353cb048da1a114 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Definitely a separate mailing list would be useful for discussing the technical issues and working on the deliverables. However, the charter discussion needs to take place on the DISPATCH WG mailing list. And, really= , that's the priority right now. Although, there is nothing that precludes folks working on the documents (e.g., use cases) while the charter is being worked. Thanks, Mary DISPATCH WG co-chair On Thu, Aug 12, 2010 at 7:13 AM, Marshall Eubanks wrote= : > > On Aug 12, 2010, at 7:58 AM, Ingemar Johansson S wrote: > > > Hi > > > > Things got quiet after the Ad hoc on Teleprecense. Is there any separat= e > mailing list created for this ? > > I believe that one should be set one up. > > Allyn and the chairs - can you set up a mailing list ? (I can help if you > need it.) > > Marshall > > > > > /Ingemar > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > INGEMAR JOHANSSON M.Sc. > > Senior Research Engineer > > > > Ericsson AB > > Multimedia Technologies > > Labratoriegr=E4nd 11 > > 971 28, Lule=E5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > Visit http://labs.ericsson.com ! > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0016e644b84e2353cb048da1a114 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Definitely a separate mailing list would be useful for discussing the techn= ical issues and working on the deliverables. However, the charter discussio= n needs to take place on the DISPATCH WG mailing list. And, really, that= 9;s the priority right now. =A0Although, there is nothing that precludes fo= lks working on the documents (e.g., use cases) while the charter is being w= orked.=A0

Thanks,
Mary
DISPATCH WG co-chair
On Thu, Aug 12, 2010 at 7:13 AM, Marshall Euban= ks <tme@americaf= ree.tv> wrote:

On Aug 12, 2010, at 7:58 AM, Ingemar Johansson S wrote:

> Hi
>
> Things got quiet after the Ad hoc on Teleprecense. Is there any separa= te mailing list created for this ?

I believe that one should be set one up.

Allyn and the chairs - can you set up a mailing list ? (I can help if you n= eed it.)

Marshall

>
> /Ingemar
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> INGEMAR JOHANSSON =A0M.Sc.
> Senior Research Engineer
>
> Ericsson AB
> Multimedia Technologies
> Labratoriegr=E4nd 11
> 971 28, Lule=E5, Sweden
> Phone +46-1071 43042
> SMS/MMS +46-73 078 3289
> ingemar.s.johansso= n@ericsson.com
> www.ericsson.com=
> Visit http://la= bs.ericsson.com !
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0016e644b84e2353cb048da1a114-- From peter.musgrave@magorcorp.com Thu Aug 12 08:12:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A0F3A68D8 for ; Thu, 12 Aug 2010 08:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.021 X-Spam-Level: X-Spam-Status: No, score=-102.021 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdBcbcdNFoXN for ; Thu, 12 Aug 2010 08:12:03 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 754E43A68CE for ; Thu, 12 Aug 2010 08:12:03 -0700 (PDT) Received: by eyb7 with SMTP id 7so771791eyb.31 for ; Thu, 12 Aug 2010 08:12:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.20.139 with SMTP id p11mr1644193wep.94.1281625959642; Thu, 12 Aug 2010 08:12:39 -0700 (PDT) Received: by 10.216.156.83 with HTTP; Thu, 12 Aug 2010 08:12:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Aug 2010 11:12:39 -0400 Message-ID: From: Peter Musgrave To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ingemar Johansson S , DISPATCH list Subject: Re: [dispatch] Work on Teleprecense X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 15:12:05 -0000 I concur. Mary, if possible can you provide an "as-chair" point-form list of the issues from Maastricht and the AdHoc as they relate to the charter (or ask for a volunteer to do so)? I think it would help us all re-focus on the issues. I recall seeing enough willing workers in Maastrichct w.r.t. this activity - so hopefully we can get a charter done and get going. Thanks, Peter Musgrave On Thu, Aug 12, 2010 at 11:00 AM, Mary Barnes wrote: > Definitely a separate mailing list would be useful for discussing the > technical issues and working on the deliverables. However, the charter > discussion needs to take place on the DISPATCH WG mailing list. And, real= ly, > that's the priority right now. =A0Although, there is nothing that preclud= es > folks working on the documents (e.g., use cases) while the charter is bei= ng > worked. > Thanks, > Mary > DISPATCH WG co-chair > > On Thu, Aug 12, 2010 at 7:13 AM, Marshall Eubanks > wrote: >> >> On Aug 12, 2010, at 7:58 AM, Ingemar Johansson S wrote: >> >> > Hi >> > >> > Things got quiet after the Ad hoc on Teleprecense. Is there any separa= te >> > mailing list created for this ? >> >> I believe that one should be set one up. >> >> Allyn and the chairs - can you set up a mailing list ? (I can help if yo= u >> need it.) >> >> Marshall >> >> > >> > /Ingemar >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > INGEMAR JOHANSSON =A0M.Sc. >> > Senior Research Engineer >> > >> > Ericsson AB >> > Multimedia Technologies >> > Labratoriegr=E4nd 11 >> > 971 28, Lule=E5, Sweden >> > Phone +46-1071 43042 >> > SMS/MMS +46-73 078 3289 >> > ingemar.s.johansson@ericsson.com >> > www.ericsson.com >> > Visit http://labs.ericsson.com ! >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> > >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From allyn@cisco.com Thu Aug 12 11:46:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E793A6867 for ; Thu, 12 Aug 2010 11:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.274 X-Spam-Level: X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpsrMr+y3MtJ for ; Thu, 12 Aug 2010 11:46:22 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8C72A3A679F for ; Thu, 12 Aug 2010 11:46:22 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAveY0yrR7H+/2dsb2JhbACgNnGia5tUAoU4BIQuiA0 X-IronPort-AV: E=Sophos;i="4.55,359,1278288000"; d="scan'208";a="171243192" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 12 Aug 2010 18:46:59 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7CIkxq1007729; Thu, 12 Aug 2010 18:46:59 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Aug 2010 11:46:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Aug 2010 11:46:58 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Work on Telepresence - name Thread-Index: Acs6FZ8+7GTYrUSzQ6mbdIRvh4ZXgwAOLNtA References: From: "Allyn Romanow (allyn)" To: "Ingemar Johansson S" , X-OriginalArrivalTime: 12 Aug 2010 18:46:59.0821 (UTC) FILETIME=[BF1A19D0:01CB3A4E] Subject: Re: [dispatch] Work on Telepresence - name X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 18:46:23 -0000 Hi, Actually I was about to set up a mailing list a bit ago and realized we = don't have a name. Here are some suggestions: MUSCAT: MUlti-Stream Control Applied to Telepresence CLUE ControLling mUltiple streams for TElepresence MUSCLE: MUltiple Stream Control for teLepesencE SCULPTS: Semantic Control for mULtiPLe Telepesence Streams CULTS: Controlling mUltipLe Telepesence Streams I prefer MUSCAT among these, but maybe someone can come up with = something better. Thanks, Allyn -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Ingemar Johansson S Sent: Thursday, August 12, 2010 4:58 AM To: dispatch@ietf.org Subject: [dispatch] Work on Teleprecense Hi Things got quiet after the Ad hoc on Teleprecense. Is there any separate = mailing list created for this ? /Ingemar=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D INGEMAR JOHANSSON M.Sc.=20 Senior Research Engineer=20 Ericsson AB Multimedia Technologies Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com=20 Visit http://labs.ericsson.com ! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From allyn@cisco.com Thu Aug 12 11:51:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37EEB28C123 for ; Thu, 12 Aug 2010 11:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.339 X-Spam-Level: X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw92WB6OoCnq for ; Thu, 12 Aug 2010 11:51:16 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 151563A67EF for ; Thu, 12 Aug 2010 11:51:16 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK7fY0yrRN+J/2dsb2JhbACgNnGiYptUAoU4BIQuiA0 X-IronPort-AV: E=Sophos;i="4.55,359,1278288000"; d="scan'208";a="572573854" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 12 Aug 2010 18:51:53 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7CIprcG025148; Thu, 12 Aug 2010 18:51:53 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Aug 2010 11:51:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Aug 2010 11:51:48 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18EB@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Work on Telepresence Thread-Index: Acs6MNP50Nk+5kGxShyw8DaYLjguHgAHfrpg References: From: "Allyn Romanow (allyn)" To: "Peter Musgrave" , "Mary Barnes" X-OriginalArrivalTime: 12 Aug 2010 18:51:49.0657 (UTC) FILETIME=[6BDB9090:01CB3A4F] Cc: Ingemar Johansson S , DISPATCH list Subject: Re: [dispatch] Work on Telepresence X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 18:51:20 -0000 Hi Peter, Good points. Cullen and Mary are helping revise the charter in light of = the meetings in Maastricht, and we'll put up a new version for = discussion very shortly - couple of days. The main issue from the discussions was the concern that the charter as = written was too broad and not specified sufficiently. It didn't rule out = enough. As Mary noted, the charter will be on this dispatch list, but work on = framework, use cases, etc. can be on a new mailing list - soon as we = decide on a name :) Best, Allyn -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Peter Musgrave Sent: Thursday, August 12, 2010 8:13 AM To: Mary Barnes Cc: Ingemar Johansson S; DISPATCH list Subject: Re: [dispatch] Work on Teleprecense I concur. Mary, if possible can you provide an "as-chair" point-form list of the issues from Maastricht and the AdHoc as they relate to the charter (or ask for a volunteer to do so)? I think it would help us all re-focus on the issues. I recall seeing enough willing workers in Maastrichct w.r.t. this activity - so hopefully we can get a charter done and get going. Thanks, Peter Musgrave On Thu, Aug 12, 2010 at 11:00 AM, Mary Barnes wrote: > Definitely a separate mailing list would be useful for discussing the > technical issues and working on the deliverables. However, the charter > discussion needs to take place on the DISPATCH WG mailing list. And, = really, > that's the priority right now. =A0Although, there is nothing that = precludes > folks working on the documents (e.g., use cases) while the charter is = being > worked. > Thanks, > Mary > DISPATCH WG co-chair > > On Thu, Aug 12, 2010 at 7:13 AM, Marshall Eubanks > wrote: >> >> On Aug 12, 2010, at 7:58 AM, Ingemar Johansson S wrote: >> >> > Hi >> > >> > Things got quiet after the Ad hoc on Teleprecense. Is there any = separate >> > mailing list created for this ? >> >> I believe that one should be set one up. >> >> Allyn and the chairs - can you set up a mailing list ? (I can help if = you >> need it.) >> >> Marshall >> >> > >> > /Ingemar >> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >> > INGEMAR JOHANSSON =A0M.Sc. >> > Senior Research Engineer >> > >> > Ericsson AB >> > Multimedia Technologies >> > Labratoriegr=E4nd 11 >> > 971 28, Lule=E5, Sweden >> > Phone +46-1071 43042 >> > SMS/MMS +46-73 078 3289 >> > ingemar.s.johansson@ericsson.com >> > www.ericsson.com >> > Visit http://labs.ericsson.com ! >> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> > >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Thu Aug 12 11:53:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204003A67EF for ; Thu, 12 Aug 2010 11:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QShs6-Lp0b30 for ; Thu, 12 Aug 2010 11:53:25 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id D18F43A68B7 for ; Thu, 12 Aug 2010 11:53:24 -0700 (PDT) Received: by ywa8 with SMTP id 8so631292ywa.31 for ; Thu, 12 Aug 2010 11:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=j05xAtzKmaxAJvBh/owdrIkszjb6WmCtndTa/GekiQM=; b=Rbgns5hW3khxUN2iVr5oFFzHcX+khUeWSrQm8QJMYkCzD97O0+P+QT33R3Vzjara/9 I2+Nq5Lb6LAc4HUv88Sd+zjpB6J9kUy0k7Q016sbxMjEaOyQ0iWrfAJUQyFtIjyDD8VK nyd5QkWLiE3spjYu9ogolN+UR4xE5jE9rZG+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DxF6R/+taafvTZrkAquXrz02eRyD8q9dhn4lmfxw1v++jtQGelG6fwUMu2Z6nCeNV+ BMKJ8XpdA/mlJ2XkjTScUfbR16nvVozZua/4F/Ker6FwECCcFdW6Q/0GtB2UJWYigILC n/o6Ja8bf5E6nvjiQ4jUeoDktaLZR74Gox6jE= MIME-Version: 1.0 Received: by 10.231.80.213 with SMTP id u21mr280947ibk.173.1281639241439; Thu, 12 Aug 2010 11:54:01 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Thu, 12 Aug 2010 11:54:01 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.com> Date: Thu, 12 Aug 2010 13:54:01 -0500 Message-ID: From: Mary Barnes To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=0015176f0f34b76502048da4e318 Cc: Ingemar Johansson S , dispatch@ietf.org Subject: Re: [dispatch] Work on Telepresence - name X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 18:53:26 -0000 --0015176f0f34b76502048da4e318 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You don't really need the exact WG name to start a non-WG mailing list. As far as the proposed WG name, MUSCAT keeps with the recent drinks/alcohol theme, I personally like CLUE. My guess is that CULTS wouldn't go over too much better than LSD ;) Just as an FYI, there are updates to the charter underway right now and the plan is to post the updated charter for community feedback early next week. Thanks, Mary. On Thu, Aug 12, 2010 at 1:46 PM, Allyn Romanow (allyn) wro= te: > Hi, > Actually I was about to set up a mailing list a bit ago and realized we > don't have a name. > > Here are some suggestions: > > MUSCAT: MUlti-Stream Control Applied to Telepresence > CLUE ControLling mUltiple streams for TElepresence > MUSCLE: MUltiple Stream Control for teLepesencE > SCULPTS: Semantic Control for mULtiPLe Telepesence Streams > CULTS: Controlling mUltipLe Telepesence Streams > > I prefer MUSCAT among these, but maybe someone can come up with something > better. > > Thanks, > Allyn > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Ingemar Johansson S > Sent: Thursday, August 12, 2010 4:58 AM > To: dispatch@ietf.org > Subject: [dispatch] Work on Teleprecense > > Hi > > Things got quiet after the Ad hoc on Teleprecense. Is there any separate > mailing list created for this ? > > /Ingemar > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > INGEMAR JOHANSSON M.Sc. > Senior Research Engineer > > Ericsson AB > Multimedia Technologies > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > Visit http://labs.ericsson.com ! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0015176f0f34b76502048da4e318 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You don't really need the exact WG name to start a non-WG mailing list.= =A0

As far as the proposed WG name, MUSCAT keeps with t= he recent drinks/alcohol theme, I personally like CLUE. My guess is that CU= LTS wouldn't go over too much better than LSD ;)=A0

Just as an FYI, there are updates to the charter underway ri= ght now and the plan is to post the updated charter for community feedback = early next week. =A0

Thanks,
Mary.=A0
On Thu, Aug 12, 2010 at 1:46 PM, Allyn Roman= ow (allyn) <allyn@c= isco.com> wrote:
Hi,
Actually I was about to set up a mailing list a bit ago and realized we don= 't have a name.

Here are some suggestions:

MUSCAT: MUlti-Stream Control Applied to Telepresence
CLUE ControLling mUltiple streams for TElepresence
MUSCLE: MUltiple Stream Control for teLepesencE
SCULPTS: Semantic Control for mULtiPLe Telepesence Streams
CULTS: Controlling mUltipLe Telepesence Streams

I prefer MUSCAT among these, but maybe someone can come up with something b= etter.

Thanks,
Allyn

-----Original Message-----
From: dispatch-bounces@ietf.or= g [mailto:dispatch-bounces= @ietf.org] On Behalf Of Ingemar Johansson S
Sent: Thursday, August 12, 2010 4:58 AM
To: dispatch@ietf.org
Subject: [dispatch] Work on Teleprecense

Hi

Things got quiet after the Ad hoc on Teleprecense. Is there any separate ma= iling list created for this ?

/Ingemar
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
INGEMAR JOHANSSON =A0M.Sc.
Senior Research Engineer

Ericsson AB
Multimedia Technologies
Labratoriegr=E4nd 11
971 28, Lule=E5, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@eri= csson.com
www.ericsson.com<= br> Visit http://labs.er= icsson.com !
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--0015176f0f34b76502048da4e318-- From alex@vidyo.com Thu Aug 12 17:15:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB99A3A69F9 for ; Thu, 12 Aug 2010 17:15:27 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj3VJHatl6AJ for ; Thu, 12 Aug 2010 17:15:26 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 456BB3A657C for ; Thu, 12 Aug 2010 17:15:25 -0700 (PDT) Received: from BH015.mail.lan ([10.110.21.115]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Aug 2010 20:15:30 -0400 Received: from HUB015.mail.lan ([10.110.17.15]) by BH015.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Aug 2010 20:15:30 -0400 Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Thu, 12 Aug 2010 20:15:29 -0400 From: Alex Eleftheriadis To: Mary Barnes Date: Thu, 12 Aug 2010 20:15:59 -0400 Thread-Topic: [dispatch] Work on Telepresence - name Thread-Index: Acs6fJUk3tZhYaw8RRyewi6P9grMIg== Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.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: multipart/alternative; boundary="_000_E7BD5F0428BA4D9A9067048D022CEEBBvidyocom_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Aug 2010 00:15:30.0200 (UTC) FILETIME=[A3674180:01CB3A7C] Cc: Ingemar Johansson S , "dispatch@ietf.org" Subject: Re: [dispatch] Work on Telepresence - name X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 00:15:28 -0000 --_000_E7BD5F0428BA4D9A9067048D022CEEBBvidyocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Although MUSCAT tastes great, CLUE sounds better! --Alex On Aug 12, 2010, at 9:54 PM, Mary Barnes wrote: You don't really need the exact WG name to start a non-WG mailing list. As far as the proposed WG name, MUSCAT keeps with the recent drinks/alcohol= theme, I personally like CLUE. My guess is that CULTS wouldn't go over too= much better than LSD ;) Just as an FYI, there are updates to the charter underway right now and the= plan is to post the updated charter for community feedback early next week= . Thanks, Mary. On Thu, Aug 12, 2010 at 1:46 PM, Allyn Romanow (allyn) > wrote: Hi, Actually I was about to set up a mailing list a bit ago and realized we don= 't have a name. Here are some suggestions: MUSCAT: MUlti-Stream Control Applied to Telepresence CLUE ControLling mUltiple streams for TElepresence MUSCLE: MUltiple Stream Control for teLepesencE SCULPTS: Semantic Control for mULtiPLe Telepesence Streams CULTS: Controlling mUltipLe Telepesence Streams I prefer MUSCAT among these, but maybe someone can come up with something b= etter. Thanks, Allyn -----Original Message----- From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of In= gemar Johansson S Sent: Thursday, August 12, 2010 4:58 AM To: dispatch@ietf.org Subject: [dispatch] Work on Teleprecense Hi Things got quiet after the Ad hoc on Teleprecense. Is there any separate ma= iling list created for this ? /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D INGEMAR JOHANSSON M.Sc. Senior Research Engineer Ericsson AB Multimedia Technologies Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com Visit http://labs.ericsson.com ! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_E7BD5F0428BA4D9A9067048D022CEEBBvidyocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Although MUSCAT tastes gre= at, CLUE sounds better!

--Alex 

On Aug = 12, 2010, at 9:54 PM, Mary Barnes wrote:

You don't really need the exact WG nam= e to start a non-WG mailing list.  

As far as the p= roposed WG name, MUSCAT keeps with the recent drinks/alcohol theme, I perso= nally like CLUE. My guess is that CULTS wouldn't go over too much better th= an LSD ;) 

Just as an FYI, there are updates to the charter underway ri= ght now and the plan is to post the updated charter for community feedback = early next week.  

Thanks,
Mary.&nb= sp;

On Thu, Aug 12, 2010 at 1:46 PM, Allyn Roman= ow (allyn) <allyn@c= isco.com> wrote:
Hi,
Actually I was about to set up a mailing list a bit ago and realized we don= 't have a name.

Here are some suggestions:

MUSCAT: MUlti-Stream Control Applied to Telepresence
CLUE ControLling mUltiple streams for TElepresence
MUSCLE: MUltiple Stream Control for teLepesencE
SCULPTS: Semantic Control for mULtiPLe Telepesence Streams
CULTS: Controlling mUltipLe Telepesence Streams

I prefer MUSCAT among these, but maybe someone can come up with something b= etter.

Thanks,
Allyn

-----Original Message-----
From: dispatch-bounces@ietf.or= g [mailto:dispatch-bounces= @ietf.org] On Behalf Of Ingemar Johansson S
Sent: Thursday, August 12, 2010 4:58 AM
To: dispatch@ietf.org
Subject: [dispatch] Work on Teleprecense

Hi

Things got quiet after the Ad hoc on Teleprecense. Is there any separate ma= iling list created for this ?

/Ingemar
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
INGEMAR JOHANSSON  M.Sc.
Senior Research Engineer

Ericsson AB
Multimedia Technologies
Labratoriegr=E4nd 11
971 28, Lule=E5, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@eri= csson.com
www.ericsson.com=
Visit http://labs.e= ricsson.com !
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.= ietf.org/mailman/listinfo/dispatch

= --_000_E7BD5F0428BA4D9A9067048D022CEEBBvidyocom_-- From tme@americafree.tv Thu Aug 12 18:48:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F633A6958 for ; Thu, 12 Aug 2010 18:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA3x9FfmczaK for ; Thu, 12 Aug 2010 18:48:52 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 12ECA3A6927 for ; Thu, 12 Aug 2010 18:48:52 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 9FF6E85F662E; Thu, 12 Aug 2010 21:49:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Marshall Eubanks In-Reply-To: Date: Thu, 12 Aug 2010 21:49:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3E258CB7-9E91-497A-A646-8A3169F7C0B6@americafree.tv> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.com> To: Alex Eleftheriadis X-Mailer: Apple Mail (2.1081) Cc: Ingemar Johansson S , "dispatch@ietf.org" Subject: Re: [dispatch] Work on Telepresence - name X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 01:48:53 -0000 I personally like MUSCAT. Marshall On Aug 12, 2010, at 8:15 PM, Alex Eleftheriadis wrote: > Although MUSCAT tastes great, CLUE sounds better! >=20 > --Alex=20 >=20 > On Aug 12, 2010, at 9:54 PM, Mary Barnes wrote: >=20 >> You don't really need the exact WG name to start a non-WG mailing = list. =20 >>=20 >> As far as the proposed WG name, MUSCAT keeps with the recent = drinks/alcohol theme, I personally like CLUE. My guess is that CULTS = wouldn't go over too much better than LSD ;)=20 >>=20 >> Just as an FYI, there are updates to the charter underway right now = and the plan is to post the updated charter for community feedback early = next week. =20 >>=20 >> Thanks, >> Mary.=20 >>=20 >> On Thu, Aug 12, 2010 at 1:46 PM, Allyn Romanow (allyn) = wrote: >> Hi, >> Actually I was about to set up a mailing list a bit ago and realized = we don't have a name. >>=20 >> Here are some suggestions: >>=20 >> MUSCAT: MUlti-Stream Control Applied to Telepresence >> CLUE ControLling mUltiple streams for TElepresence >> MUSCLE: MUltiple Stream Control for teLepesencE >> SCULPTS: Semantic Control for mULtiPLe Telepesence Streams >> CULTS: Controlling mUltipLe Telepesence Streams >>=20 >> I prefer MUSCAT among these, but maybe someone can come up with = something better. >>=20 >> Thanks, >> Allyn >>=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Ingemar Johansson S >> Sent: Thursday, August 12, 2010 4:58 AM >> To: dispatch@ietf.org >> Subject: [dispatch] Work on Teleprecense >>=20 >> Hi >>=20 >> Things got quiet after the Ad hoc on Teleprecense. Is there any = separate mailing list created for this ? >>=20 >> /Ingemar >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> INGEMAR JOHANSSON M.Sc. >> Senior Research Engineer >>=20 >> Ericsson AB >> Multimedia Technologies >> Labratoriegr=E4nd 11 >> 971 28, Lule=E5, Sweden >> Phone +46-1071 43042 >> SMS/MMS +46-73 078 3289 >> ingemar.s.johansson@ericsson.com >> www.ericsson.com >> Visit http://labs.ericsson.com ! >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Thu Aug 12 21:37:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134743A68AF; Thu, 12 Aug 2010 21:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=0.990, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h--Sn3epMqC4; Thu, 12 Aug 2010 21:37:01 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 7F4BD3A6886; Thu, 12 Aug 2010 21:37:01 -0700 (PDT) Received: from sydney (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o7D4bV4m017262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Aug 2010 00:37:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1281674257; bh=41p4n7EoAm5q58j8ClmAAJf2n2K4EamqWo3tDar8IIk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=AMOC93eGcjBYEu4hnchhkAzDKfcIoLjDQvBvUV5XD3cHokaF6AtuDcVvrgELF92S/ zjjZ7Owu64dYfurH+cvdfNWbGrIjAeDbf/IizM0bynVC49hfPxsqgwnWB3JIVstkM4 BVgKKvB+ZPnRcTfygHfKaInT837YdMmY9NJiMUwg= From: "Paul E. Jones" To: "'Cullen Jennings'" , Date: Fri, 13 Aug 2010 00:36:41 -0400 Message-ID: <007e01cb3aa1$23d1d190$6b7574b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acs6oSBLpTeEBoJnS/2FMd8r9uxzBg== Content-language: en-us Cc: sip-ops@ietf.org, 'Hadriel Kaplan' Subject: Re: [dispatch] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 04:37:03 -0000 Cullen, Thanks for the suggestion. All, Please see the note below. We're seeking advice on how to proceed with the subject draft. Paul > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, August 12, 2010 11:44 PM > To: Paul E. Jones > Cc: sip-ops@ietf.org; Hadriel Kaplan > Subject: Re: [sip-ops] SIP OPTIONS "ping" > > > I think you discuss how to move forward with this draft on dispatch > mailing list given that's the point of that list is help with problems > like this. > > On Aug 11, 2010, at 22:14 , Paul E. Jones wrote: > > > Folks, > > > > Gonzalo and I produced an Internet Draft aiming at trying to bring some > consistency to the way in which SIP user agents implement an OPTIONS > "ping" procedure. It seems that a very large number of vendors do this, > but unfortunately, there seems to be little consistency. > > > > Initially, we positioned the document as a standards track RFC, since > this essentially builds on RFC 3261. However, there was some pushback > from folks in the IETF for a variety of reasons, not the least of which is > the fact that there is no working group chartered to do the work. We > don't feel this one draft warrants the creation of a working group. > > > > So, we've got three options we can consider: > > 1) Forge ahead outside of a working group > > 2) Change the status of the draft to Informational > > 3) Forget about the draft and let every SIP device do it the way > they want, throwing hope of consistency out the window > > > > (Yeah, you can tell I prefer not to go for the third option.) > > > > In any case, I'd like to get feedback from the on the SIP operators and > SIP implementers lists. Do you think it's worth trying to address this > issue? If so, which option do you think we should pursue? > > > > Note that we're certainly open to feedback on the draft. I'd prefer it > to have a few more "MUST" statements in the text, rather than "SHOULD". > But, we need to find that right balance: > > http://tools.ietf.org/html/draft-jones-sip-options-ping > > > > Paul > > > > _______________________________________________ > > sip-ops mailing list > > sip-ops@ietf.org > > https://www.ietf.org/mailman/listinfo/sip-ops > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > From ingemar.s.johansson@ericsson.com Fri Aug 13 01:33:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C4E3A68C8 for ; Fri, 13 Aug 2010 01:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.575 X-Spam-Level: X-Spam-Status: No, score=-5.575 tagged_above=-999 required=5 tests=[AWL=1.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3gtUH9dUv+I for ; Fri, 13 Aug 2010 01:33:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 052353A6893 for ; Fri, 13 Aug 2010 01:33:44 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-de-4c65038c93c2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.C6.10125.C83056C4; Fri, 13 Aug 2010 10:34:20 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.96]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 13 Aug 2010 10:34:20 +0200 From: Ingemar Johansson S To: "Allyn Romanow (allyn)" , "dispatch@ietf.org" Date: Fri, 13 Aug 2010 10:34:19 +0200 Thread-Topic: [dispatch] Work on Telepresence - name Thread-Index: Acs6FZ8+7GTYrUSzQ6mbdIRvh4ZXgwAOLNtAABxQ/9A= Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Work on Telepresence - name X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 08:33:46 -0000 Hi I don't have any good names to suggest.=20 However I want to raise one topic that increased the temperature at he AdHo= c meeting somewhat.=20 My understanding of the term asymmetry is that it seems like people have di= fferent minds of what it means.=20 One interpretation is that it involves a a different number of (almost) equ= ally lage screens in the conference rooms, the main point is that the scree= ns are big enough to make people look their natural size.=20 Another interpretation is that this aso involves an asymmetry in the rendei= ng capabilities. As an example many hand held cellphones today are capable = of encoding 720p video (or more). The rendering capabilities are limitied t= hough. This means that often in makes sense to only send a CIF encoded vide= o stream to the cell phone. The other patries may however sit behind large = screens. The latter introduces an element that can be seen as a mix of "full grade" = teleprecense and teleconferencing and I do believe that it should be includ= ed in the workitem as it includes what one can refer to as the mobile offic= e. Already today there are (already standardized or in the pipe) signaling = mechanisms that make these cases possible, see for instance the SDPCapNeg a= nd the image attribute work in MMUSIC. Regards Ingemar =20 > -----Original Message----- > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 > Sent: den 12 augusti 2010 20:47 > To: Ingemar Johansson S; dispatch@ietf.org > Subject: RE: [dispatch] Work on Telepresence - name >=20 > Hi, > Actually I was about to set up a mailing list a bit ago and=20 > realized we don't have a name. >=20 > Here are some suggestions: >=20 > MUSCAT: MUlti-Stream Control Applied to Telepresence CLUE=20 > ControLling mUltiple streams for TElepresence > MUSCLE: MUltiple Stream Control for teLepesencE > SCULPTS: Semantic Control for mULtiPLe Telepesence Streams > CULTS: Controlling mUltipLe Telepesence Streams >=20 > I prefer MUSCAT among these, but maybe someone can come up=20 > with something better. >=20 > Thanks, > Allyn >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Ingemar Johansson S > Sent: Thursday, August 12, 2010 4:58 AM > To: dispatch@ietf.org > Subject: [dispatch] Work on Teleprecense >=20 > Hi >=20 > Things got quiet after the Ad hoc on Teleprecense. Is there=20 > any separate mailing list created for this ? >=20 > /Ingemar > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > INGEMAR JOHANSSON M.Sc.=20 > Senior Research Engineer=20 >=20 > Ericsson AB > Multimedia Technologies > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > Visit http://labs.ericsson.com ! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From tme@americafree.tv Fri Aug 13 01:56:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11CC53A6951 for ; Fri, 13 Aug 2010 01:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gmuuXtkaNRQ for ; Fri, 13 Aug 2010 01:56:11 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id DB0253A6830 for ; Fri, 13 Aug 2010 01:56:10 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 9EFD7860316F; Fri, 13 Aug 2010 04:56:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Marshall Eubanks In-Reply-To: Date: Fri, 13 Aug 2010 04:56:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49F4DB44-AA83-4409-969C-D965D1632654@americafree.tv> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.com> To: Ingemar Johansson S X-Mailer: Apple Mail (2.1081) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Work on Telepresence - name X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 08:56:12 -0000 On Aug 13, 2010, at 4:34 AM, Ingemar Johansson S wrote: > Hi >=20 > I don't have any good names to suggest.=20 >=20 > However I want to raise one topic that increased the temperature at he = AdHoc meeting somewhat.=20 > My understanding of the term asymmetry is that it seems like people = have different minds of what it means. This is from my text for the charter : While there is some debate about the exact meaning of telepresence, a = reasonable definition of immersive telepresence is a system engineered = to make local and remote participants feel that they are in the same = room at the same time. ----- Does that seem OK ? Regards Marshall > =20 >=20 > One interpretation is that it involves a a different number of = (almost) equally lage screens in the conference rooms, the main point is = that the screens are big enough to make people look their natural size.=20= >=20 > Another interpretation is that this aso involves an asymmetry in the = rendeing capabilities. As an example many hand held cellphones today are = capable of encoding 720p video (or more). The rendering capabilities are = limitied though. This means that often in makes sense to only send a CIF = encoded video stream to the cell phone. The other patries may however = sit behind large screens. > The latter introduces an element that can be seen as a mix of "full = grade" teleprecense and teleconferencing and I do believe that it should = be included in the workitem as it includes what one can refer to as the = mobile office. Already today there are (already standardized or in the = pipe) signaling mechanisms that make these cases possible, see for = instance the SDPCapNeg and the image attribute work in MMUSIC. >=20 >=20 > Regards > Ingemar >=20 >=20 >> -----Original Message----- >> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 >> Sent: den 12 augusti 2010 20:47 >> To: Ingemar Johansson S; dispatch@ietf.org >> Subject: RE: [dispatch] Work on Telepresence - name >>=20 >> Hi, >> Actually I was about to set up a mailing list a bit ago and=20 >> realized we don't have a name. >>=20 >> Here are some suggestions: >>=20 >> MUSCAT: MUlti-Stream Control Applied to Telepresence CLUE=20 >> ControLling mUltiple streams for TElepresence >> MUSCLE: MUltiple Stream Control for teLepesencE >> SCULPTS: Semantic Control for mULtiPLe Telepesence Streams >> CULTS: Controlling mUltipLe Telepesence Streams >>=20 >> I prefer MUSCAT among these, but maybe someone can come up=20 >> with something better. >>=20 >> Thanks, >> Allyn >>=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org=20 >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Ingemar Johansson S >> Sent: Thursday, August 12, 2010 4:58 AM >> To: dispatch@ietf.org >> Subject: [dispatch] Work on Teleprecense >>=20 >> Hi >>=20 >> Things got quiet after the Ad hoc on Teleprecense. Is there=20 >> any separate mailing list created for this ? >>=20 >> /Ingemar >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> INGEMAR JOHANSSON M.Sc.=20 >> Senior Research Engineer=20 >>=20 >> Ericsson AB >> Multimedia Technologies >> Labratoriegr=E4nd 11 >> 971 28, Lule=E5, Sweden >> Phone +46-1071 43042 >> SMS/MMS +46-73 078 3289 >> ingemar.s.johansson@ericsson.com >> www.ericsson.com >> Visit http://labs.ericsson.com ! >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From stephen.botzko@gmail.com Fri Aug 13 03:44:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE243A68D3 for ; Fri, 13 Aug 2010 03:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z6vmsUU41GE for ; Fri, 13 Aug 2010 03:44:00 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 9D2133A698F for ; Fri, 13 Aug 2010 03:44:00 -0700 (PDT) Received: by qwc9 with SMTP id 9so2889810qwc.31 for ; Fri, 13 Aug 2010 03:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=EDCxTqThujHpEguRFBEwlVybhig0MGFu2HPHdZPachY=; b=Txj2m8mR23MUe3PpW4AAlvfAkz6P125RphTqM2IjlRPNX96e9HJmwATU29JLWMP6uX WTwlemDpGc4woAR8E+PV6etq7xDszR+toIevYMSrG8njNoDU3S9no+5VJVtYR1/2UB/A 0/JF5BQNWj525hsfKiGO/QpadtRgp+NJNCv1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MtBCGpJ4AbNsZuTthjtwzCeR7ov8cihLH6O30Z2ZE/wNmo0AQvl7RvZGmV3rQggUgx Oea8Hv++6o0FWWVeJZAwsUK6jZqAvsGVVVgQzjbpIQbvcl71cJAIB02ne5f/7mHGO4ok d32qKyYqJY+5Owwz4/5rb8rxVHnCAT3NtCQ5o= MIME-Version: 1.0 Received: by 10.229.131.160 with SMTP id x32mr1055790qcs.203.1281696277483; Fri, 13 Aug 2010 03:44:37 -0700 (PDT) Received: by 10.229.2.14 with HTTP; Fri, 13 Aug 2010 03:44:37 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.com> Date: Fri, 13 Aug 2010 06:44:37 -0400 Message-ID: From: stephen botzko To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=0015175763e25451b1048db22ba8 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Work on Telepresence - name X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 10:44:02 -0000 --0015175763e25451b1048db22ba8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We agree that Interoperability needs to be established in both of your examples. I am not sure why this is arising in the context of the charter discussion, since the word "asymmetry" does not appear in the charter text at all. The text itself makes no statement as to how the receiving system might differ from the sending system. Also, I would not have guessed that "Mobile Office" really meant "cellphone" if I saw it in a charter statement. I think it is already understood that telepresence systems need to interoperate with ordinary SIP devices - if that needs to be clarified in the charter, that is fine. But I don't think we need work items for every particular SIP device out there. Regards Stephen Botzko On Fri, Aug 13, 2010 at 4:34 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > I don't have any good names to suggest. > > However I want to raise one topic that increased the temperature at he > AdHoc meeting somewhat. > My understanding of the term asymmetry is that it seems like people have > different minds of what it means. > > One interpretation is that it involves a a different number of (almost) > equally lage screens in the conference rooms, the main point is that the > screens are big enough to make people look their natural size. > > Another interpretation is that this aso involves an asymmetry in the > rendeing capabilities. As an example many hand held cellphones today are > capable of encoding 720p video (or more). The rendering capabilities are > limitied though. This means that often in makes sense to only send a CIF > encoded video stream to the cell phone. The other patries may however sit > behind large screens. > The latter introduces an element that can be seen as a mix of "full grade= " > teleprecense and teleconferencing and I do believe that it should be > included in the workitem as it includes what one can refer to as the mobi= le > office. Already today there are (already standardized or in the pipe) > signaling mechanisms that make these cases possible, see for instance the > SDPCapNeg and the image attribute work in MMUSIC. > > > Regards > Ingemar > > > > -----Original Message----- > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > Sent: den 12 augusti 2010 20:47 > > To: Ingemar Johansson S; dispatch@ietf.org > > Subject: RE: [dispatch] Work on Telepresence - name > > > > Hi, > > Actually I was about to set up a mailing list a bit ago and > > realized we don't have a name. > > > > Here are some suggestions: > > > > MUSCAT: MUlti-Stream Control Applied to Telepresence CLUE > > ControLling mUltiple streams for TElepresence > > MUSCLE: MUltiple Stream Control for teLepesencE > > SCULPTS: Semantic Control for mULtiPLe Telepesence Streams > > CULTS: Controlling mUltipLe Telepesence Streams > > > > I prefer MUSCAT among these, but maybe someone can come up > > with something better. > > > > Thanks, > > Allyn > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Ingemar Johansson S > > Sent: Thursday, August 12, 2010 4:58 AM > > To: dispatch@ietf.org > > Subject: [dispatch] Work on Teleprecense > > > > Hi > > > > Things got quiet after the Ad hoc on Teleprecense. Is there > > any separate mailing list created for this ? > > > > /Ingemar > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > INGEMAR JOHANSSON M.Sc. > > Senior Research Engineer > > > > Ericsson AB > > Multimedia Technologies > > Labratoriegr=E4nd 11 > > 971 28, Lule=E5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > Visit http://labs.ericsson.com ! > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0015175763e25451b1048db22ba8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We agree that Interoperability needs to be established in both of your exam= ples.=A0

I am not sure why this is arising in the context of the c= harter discussion, since the word "asymmetry" does not appear in = the charter text at all.=A0 The text itself makes no statement as to how th= e receiving system might differ from the sending system.

Also,=A0 I would not have guessed that "Mobile Office" really= meant "cellphone" if I saw it in a charter statement.

I t= hink it is already understood that telepresence systems need to=20 interoperate with ordinary SIP devices - if that needs to be clarified in t= he charter, that is fine.=A0 But I don't think we need work items for e= very particular SIP device out there.

Regards
Stephen Botzko



On Fri, Aug 13, 2010 at 4:34 AM, Ingemar Joh= ansson S <ingemar.s.johansson@ericsson.com> w= rote:
Hi

I don't have any good names to suggest.

However I want to raise one topic that increased the temperature at he AdHo= c meeting somewhat.
My understanding of the term asymmetry is that it seems like people have di= fferent minds of what it means.

One interpretation is that it involves a a different number of (almost) equ= ally lage screens in the conference rooms, the main point is that the scree= ns are big enough to make people look their natural size.

Another interpretation is that this aso involves an asymmetry in the rendei= ng capabilities. As an example many hand held cellphones today are capable = of encoding 720p video (or more). The rendering capabilities are limitied t= hough. This means that often in makes sense to only send a CIF encoded vide= o stream to the cell phone. The other patries may however sit behind large = screens.
The latter introduces an element that can be seen as a mix of "full gr= ade" teleprecense and teleconferencing and I do believe that it should= be included in the workitem as it includes what one can refer to as the mo= bile office. Already today there are (already standardized or in the pipe) = signaling mechanisms that make these cases possible, see for instance the S= DPCapNeg and the image attribute work in MMUSIC.


Regards
Ingemar


> -----Original Message-----
> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
> Sent: den 12 augusti 2010 20:47
> To: Ingemar Johansson S; dispatch@ietf.org
> Subject: RE: [dispatch] Work on Telepresence - name
>
> Hi,
> Actually I was about to set up a mailing list a bit ago and
> realized we don't have a name.
>
> Here are some suggestions:
>
> MUSCAT: MUlti-Stream Control Applied to Telepresence CLUE
> ControLling mUltiple streams for TElepresence
> MUSCLE: MUltiple Stream Control for teLepesencE
> SCULPTS: Semantic Control for mULtiPLe Telepesence Streams
> CULTS: Controlling mUltipLe Telepesence Streams
>
> I prefer MUSCAT among these, but maybe someone can come up
> with something better.
>
> Thanks,
> Allyn
>
> -----Original Message-----
> From: d= ispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Ingemar Johansson S
> Sent: Thursday, August 12, 2010 4:58 AM
> To: dispatch@ie= tf.org
> Subject: [dispatch] Work on Teleprecense
>
> Hi
>
> Things got quiet after the Ad hoc on Teleprecense. Is there
> any separate mailing list created for this ?
>
> /Ingemar
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> INGEMAR JOHANSSON =A0M.Sc.
> Senior Research Engineer
>
> Ericsson AB
> Multimedia Technologies
> Labratoriegr=E4nd 11
> 971 28, Lule=E5, Sweden
> Phone +46-1071 43042
> SMS/MMS +46-73 078 3289
> = ingemar.s.johansson@ericsson.com
> www.ericsson.com=
> Visit http://la= bs.ericsson.com !
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
>
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--0015175763e25451b1048db22ba8-- From mary.ietf.barnes@gmail.com Fri Aug 13 09:36:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083593A67FC; Fri, 13 Aug 2010 09:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUs5Gh7c-3-u; Fri, 13 Aug 2010 09:36:56 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 9D8BF3A6407; Fri, 13 Aug 2010 09:36:56 -0700 (PDT) Received: by gwaa18 with SMTP id a18so1214331gwa.31 for ; Fri, 13 Aug 2010 09:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=HLg5hObcl4xkjheOTLQNTuzI2ab0Y1ZvBYnAn9GihbE=; b=qc1y6VovOZWq9HjsUIqQN0mYoE1l1n+WykXmvf6xPRWalHr/KWRnXfmgaj6Lth3JV7 m8DoQ01HUNM/hhxG5tknJtGxT7KXqMzUexoDLJx061g02RhWXcoETW6+PTSMsAl11UUl Ov0LnexDuaHf+aON8hnvHTw497ESnqeGhyD3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ERTmnjE3YaOW3v15+0eXQZ9tWnPeqQQXDcWsdaTcMUfDeN6ugPM1fwVatQHOJlWVbU F+OblsMRsuPUfjCTXrWIbyyZtquoqSXbcLXa86LFPe2fPhqYO1RFHmWvPW2utls7JurP CjK6YDFJy1wg8CP1UiOf84JU4WfzMmKoY44Ag= MIME-Version: 1.0 Received: by 10.150.11.12 with SMTP id 12mr2337113ybk.101.1281717452541; Fri, 13 Aug 2010 09:37:32 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Fri, 13 Aug 2010 09:37:32 -0700 (PDT) Date: Fri, 13 Aug 2010 11:37:32 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=000e0cd6aca27610c7048db719a2 Cc: rai@ietf.org, rai-ads@tools.ietf.org Subject: [dispatch] Reminder: DISPATCH deadlines for IETF-79 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 16:36:58 -0000 --000e0cd6aca27610c7048db719a2 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Just a reminder that the first deadline for IETF-79 for the DISPATCH WG topics is two weeks from Monday. Regards, Mary. On Thu, Jul 29, 2010 at 10:20 AM, Mary Barnes wrote: > Hi folks, > > The following summarizes the deadlines for topics for DISPATCH for IETF-79: > > * August 30, 2010. Cutoff date to notify the chairs/DISPATCH WG of > plans to submit a proposal. [Two weeks prior to BoF proposal deadline] > > * Sept. 6, 2010. Cutoff for charter proposals for topics. [One week prior > to BoF proposal deadline] > > > * Sept. 20, 2010. Topics that are to be the focus of IETF-79 are announced. > [One week before deadline to request WG slots] > > * Oct. 18th, 2010. -00 draft deadline. > > * Oct. 25th, 2010. Draft deadline. > > These deadlines have been published on the DISPATCH WG wiki page: > http://trac.tools.ietf.org/wg/dispatch/trac/wiki > > Note that these dates are closer to the end of the meeting than those for > IETF-78 because there is just over 3 months between the end of IETF-78 and > beginning of IETF-79 (versus the 4 months we had between this meeting and > Anaheim). > > Note that registration and WG/Bof scheduling for IETF-79 starts on August > 9th: > http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF79 > > DISPATCH sets the first deadline such that it's still possible to request a > BoF for topics that may be wider in scope and require broader community > review. The deadlines for BoFs are set by the leadership so that there is > time to consider BoFs in the scheduling. Also, as Gonzalo noted in a > separate email, WGs need to have a draft charter at the time they request a > WG slot. Further information on the motivation for the DISPATCH planning > model is provided in the wiki. > > Regards, > Mary > DISPATCH WG co-chair > > --000e0cd6aca27610c7048db719a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,=A0

Just a reminder that the first deadline for I= ETF-79 for the DISPATCH WG topics is two weeks from Monday. =A0
<= br>
Regards,
Mary.=A0

On Thu, Jul 29, 2010 at 10:20 AM, Mary Barnes <mary.ietf.barnes@gmail.com><= /span> wrote:
Hi folks,

The following summarizes the deadlines for topics for DISPATCH for IETF-79:=
<= br>
* August 30, 2010. Cutoff date to no= tify the chairs/DISPATCH WG of
=A0=A0plans to submit a proposal. [Two we= eks prior to BoF proposal deadline]

* Sept. 6, 2010. Cutoff for charter proposals for topics. [One we= ek prior to BoF proposal deadline]


* Sept. 20, 2010. Topics that are to be the focus of IETF-79 are=A0anno= unced.
=A0=A0[One week before deadline= to request WG=A0slots]

* Oct. 18th, 2010. -00 draft deadline.

* Oct. 25th, 2010. Draft = deadline.

These deadlines have been published on the DISPATCH WG wik= i page:
http://trac.tools.ietf.org/= wg/dispatch/trac/wiki=A0

Note that these dates are closer to the end of t= he meeting than those for IETF-78 =A0because there is just over 3 months be= tween the end of IETF-78 and beginning of IETF-79 (versus the 4 months we h= ad between this meeting and Anaheim).=A0
=A0
Note that registration and WG/Bof scheduling for IETF-79 = starts on August 9th:

DISPATCH sets the first deadline such that it's stil= l possible to request a BoF for topics that may be wider in scope and requi= re broader community review. =A0The deadlines for BoFs are set by the leade= rship so that there is time to consider BoFs in the scheduling. Also, as Go= nzalo noted in a separate email, WGs need to have a draft charter at the ti= me they request a WG slot. =A0Further information on the motivation for the= DISPATCH planning model =A0is provided in the wiki.

Regards,
Mary
DISPATCH WG co-chair


--000e0cd6aca27610c7048db719a2-- From mary.ietf.barnes@gmail.com Fri Aug 13 13:40:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D58B3A6A34 for ; Fri, 13 Aug 2010 13:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0SSFPMbchm1 for ; Fri, 13 Aug 2010 13:40:07 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B62C83A6A8C for ; Fri, 13 Aug 2010 13:39:38 -0700 (PDT) Received: by iwn3 with SMTP id 3so183873iwn.31 for ; Fri, 13 Aug 2010 13:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=a73iUBNWDNvEoRRG96OLjFGkvga/3zbZrDQpM9cZUpg=; b=P2sLYsZwWcG6HrumK8oz3/O1xOjvnjrDgtU75JySDrI5vj7pBVMhqQNZ+jrRfytsu0 HqxKjE3JWPu2ZUDSwHvzIXdtkMTPu6DLZdwWXgXYSkH5FoUhi+VEGX7et5bq3fOUVrye Slg4Pvn4DoKcldgrhGBV/ase9c3A50zwhhQHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ss3U2dTRfYgrLgCT83qF/FyDJqiadx+UyUD3dv4H/81bteAkB9cH1JmozuuC2oidMz pP905BDBn0t+zinUAHw9MgcHUjMyTjaJVwLC661iNrqAHb91TluIhVJuwmej27EuOV94 en7lj7hF7dzhxevcFaUSlT6VdajEvPwxJxh4w= MIME-Version: 1.0 Received: by 10.231.30.134 with SMTP id u6mr2124221ibc.121.1281731986676; Fri, 13 Aug 2010 13:39:46 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Fri, 13 Aug 2010 13:39:46 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18EB@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18EB@xmb-sjc-221.amer.cisco.com> Date: Fri, 13 Aug 2010 15:39:46 -0500 Message-ID: From: Mary Barnes To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=000325579d92c35ec5048dba7b26 Cc: Ingemar Johansson S , DISPATCH list Subject: Re: [dispatch] Work on Telepresence X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 20:40:12 -0000 --000325579d92c35ec5048dba7b26 Content-Type: text/plain; charset=ISO-8859-1 In addition, the issues raised will be documented in the minutes that we should be getting out very soon. Until that happens, you can find the raw notes on the supplemental DISPATCH website on Softarmor: http://www.softarmor.com/dispatch/IETF78/ Thanks, Mary. On Thu, Aug 12, 2010 at 1:51 PM, Allyn Romanow (allyn) wrote: > Hi Peter, > > Good points. Cullen and Mary are helping revise the charter in light of the > meetings in Maastricht, and we'll put up a new version for discussion very > shortly - couple of days. > > The main issue from the discussions was the concern that the charter as > written was too broad and not specified sufficiently. It didn't rule out > enough. > > As Mary noted, the charter will be on this dispatch list, but work on > framework, use cases, etc. can be on a new mailing list - soon as we decide > on a name :) > > Best, > Allyn > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Peter Musgrave > Sent: Thursday, August 12, 2010 8:13 AM > To: Mary Barnes > Cc: Ingemar Johansson S; DISPATCH list > Subject: Re: [dispatch] Work on Teleprecense > > I concur. > > Mary, if possible can you provide an "as-chair" point-form list of the > issues from Maastricht and the AdHoc as they relate to the charter (or > ask for a volunteer to do so)? > > I think it would help us all re-focus on the issues. I recall seeing > enough willing workers in Maastrichct w.r.t. this activity - so > hopefully we can get a charter done and get going. > > Thanks, > > Peter Musgrave > > --000325579d92c35ec5048dba7b26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In addition, the issues raised will be documented in the minutes that we sh= ould be getting out very soon. =A0Until that happens, you can find the raw = notes on the supplemental DISPATCH website on Softarmor:

Thanks,
Mary.=A0

On Thu, Aug 12, 2010 at 1:51 PM, Allyn Romanow (allyn) <allyn@cisco.co= m> wrote:
Hi Peter,

Good points. Cullen and Mary are helping revise the charter in light of the= meetings in Maastricht, and we'll put up a new version for discussion = very shortly - couple of days.

The main issue from the discussions was the concern that the charter as wri= tten was too broad and not specified sufficiently. It didn't rule out e= nough.

As Mary noted, the charter will be on this dispatch list, but work on frame= work, use cases, etc. can be on a new mailing list - soon as we decide on a= name :)

Best,
Allyn

-----Original Message-----
From: dispat= ch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Musgr= ave
Sent: Thursday, August 12, 2010 8:13 AM
To: Mary Barnes
Cc: Ingemar Johansson S; DISPATCH list
Subject: Re: [dispatch] Work on Teleprecense

I concur.

Mary, if possible can you provide an "as-chair" point-form list o= f the
issues from Maastricht and the AdHoc as they relate to the charter (or
ask for a volunteer to do so)?

I think it would help us all re-focus on the issues. I recall seeing
enough willing workers in Maastrichct w.r.t. this activity - so
hopefully we can get a charter done and get going.

Thanks,

Peter Musgrave

--000325579d92c35ec5048dba7b26-- From hisham.khartabil@gmail.com Sun Aug 15 22:58:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94673A682F for ; Sun, 15 Aug 2010 22:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.184 X-Spam-Level: X-Spam-Status: No, score=-102.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_I_LETTER=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQb4bzP24Cds for ; Sun, 15 Aug 2010 22:58:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id CBF003A6819 for ; Sun, 15 Aug 2010 22:58:37 -0700 (PDT) Received: by qwc9 with SMTP id 9so5099544qwc.31 for ; Sun, 15 Aug 2010 22:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=w+B+hxC8wJacHUiv/xeTxm2lxGCUA5V/AMuyoqG9cVc=; b=KqjwVt07dLVjhkgpF8its9cDBjjOSK52C+LWZe2LS2prviClGcUEqr6LUbp5nOMeLP F4u6VeuqbJQyqO5yMCIUN1CNDjl4+gA3qmu2E8i8LMn+VEaEwHbMUkG3nsteRgBSj4Qe 9Ox4p7kDwSXDbR8Te+gBJLRzfmBb6nkPFGCyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=L+gS90PhRvT/1bl5HteGAWRX/fuGtPjfhQCPFYIYEyp8NqwbqYj8mbPOheb+xPOtcB VJDGhVLsqbPnDrSb5wLNKppoEH2v3t/+5AEbjTTYuLwEsfVngAHzksA5xvM+w+6+GDP7 J3e36s63U3VK6uo9el+XBD5YV3YpmxRqgNchU= MIME-Version: 1.0 Received: by 10.224.98.81 with SMTP id p17mr2935286qan.290.1281938353241; Sun, 15 Aug 2010 22:59:13 -0700 (PDT) Received: by 10.224.74.8 with HTTP; Sun, 15 Aug 2010 22:59:13 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.com> Date: Mon, 16 Aug 2010 15:59:13 +1000 Message-ID: From: Hisham Khartabil To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=00c09f89923e2b3e97048dea88e1 Cc: Ingemar Johansson S , dispatch@ietf.org Subject: Re: [dispatch] Work on Telepresence - name X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 05:58:39 -0000 --00c09f89923e2b3e97048dea88e1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I like T-52 :) Yes, it is a drink (http://www.drinkswap.com/t-52.htm) It is also an Teleprinter invented by za Germans for communicating typed messages (http://en.wikipedia.org/wiki/Siemens_and_Halske_T52) And telepresence companies are releasing 52" screen products. 5 2 could also stand for the 5th and 2nd letter of the alphabet spelling Enabling Bridling (I think bridling can mean control). If you don't like it, then T-BOMB is also a drink: Telepresence - BOMB :) Hisham On 13 August 2010 04:46, Allyn Romanow (allyn) wrote: > Hi, > Actually I was about to set up a mailing list a bit ago and realized we > don't have a name. > > Here are some suggestions: > > MUSCAT: MUlti-Stream Control Applied to Telepresence > CLUE ControLling mUltiple streams for TElepresence > MUSCLE: MUltiple Stream Control for teLepesencE > SCULPTS: Semantic Control for mULtiPLe Telepesence Streams > CULTS: Controlling mUltipLe Telepesence Streams > > I prefer MUSCAT among these, but maybe someone can come up with something > better. > > Thanks, > Allynt > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Ingemar Johansson S > Sent: Thursday, August 12, 2010 4:58 AM > To: dispatch@ietf.org > Subject: [dispatch] Work on Teleprecense > > Hi > > Things got quiet after the Ad hoc on Teleprecense. Is there any separate > mailing list created for this ? > > /Ingemar > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > INGEMAR JOHANSSON M.Sc. > Senior Research Engineer > > Ericsson AB > Multimedia Technologies > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > Visit http://labs.ericsson.com ! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00c09f89923e2b3e97048dea88e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I like T-52 :)

Yes, it is a drink (http://www.drinkswap.com/t-52.htm)
It is also an Telepr= inter invented by za Germans for communicating typed messages=A0 (http://en.wikipedi= a.org/wiki/Siemens_and_Halske_T52)
And telepresence companies are releasing 52" screen products.

5= 2 could also stand for the 5th and 2nd letter of the alphabet spelling Ena= bling Bridling (I think bridling can mean control).

If you don't= like it, then T-BOMB is also a drink: Telepresence - BOMB :)


Hisham

On 13 August 2010 04:46, A= llyn Romanow (allyn) <allyn@cisco.com> wrote:
Hi,
Actually I was about to set up a mailing list a bit ago and realized we don= 't have a name.

Here are some suggestions:

MUSCAT: MUlti-Stream Control Applied to Telepresence
CLUE ControLling mUltiple streams for TElepresence
MUSCLE: MUltiple Stream Control for teLepesencE
SCULPTS: Semantic Control for mULtiPLe Telepesence Streams
CULTS: Controlling mUltipLe Telepesence Streams

I prefer MUSCAT among these, but maybe someone can come up with something b= etter.

Thanks,
Allynt

-----Original Message-----
From: dispatch-bounces@ietf.or= g [mailto:dispatch-bounces= @ietf.org] On Behalf Of Ingemar Johansson S
Sent: Thursday, August 12, 2010 4:58 AM
To: dispatch@ietf.org
Subject: [dispatch] Work on Teleprecense

Hi

Things got quiet after the Ad hoc on Teleprecense. Is there any separate ma= iling list created for this ?

/Ingemar
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
INGEMAR JOHANSSON =A0M.Sc.
Senior Research Engineer

Ericsson AB
Multimedia Technologies
Labratoriegr=E4nd 11
971 28, Lule=E5, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@eri= csson.com
www.ericsson.com<= br> Visit http://labs.er= icsson.com !
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--00c09f89923e2b3e97048dea88e1-- From paulej@packetizer.com Mon Aug 16 06:17:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54CB23A681E; Mon, 16 Aug 2010 06:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7fv0jMSOlwZ; Mon, 16 Aug 2010 06:17:42 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id C75CD3A688E; Mon, 16 Aug 2010 06:17:41 -0700 (PDT) Received: from sydney (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o7GDHx6Y014122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Aug 2010 09:18:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1281964686; bh=7VdJc4HB6XEmHJkTJwC0KQJ3x6yT4Ssmjp8PlfTa1EU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=J09ayVr78hLC/D2k6PHDO22wdCizkEcVNVCv7c48TJAwYHq7aQrsToVyoXpuMGtW7 L6cIwJ4krd3onEHjp8IMrIntguiAmZn//iXL73tl7BxZga6cwXKhAhi1ZIbXORiubb 9LE6kpZcEUUuj/TBdqcraubtz3c8v6HToIVhMdJY= From: "Paul E. Jones" To: "'marius zbihlei'" References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> In-Reply-To: <4C690C38.6010804@1and1.ro> Date: Mon, 16 Aug 2010 09:17:03 -0400 Message-ID: <012901cb3d45$5544c880$ffce5980$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ7YPXf2shkdXst8Oeg2uiqnTvIBAJGarLckXGTVKA= Content-language: en-us Cc: sip-ops@ietf.org, dispatch@ietf.org, 'Hadriel Kaplan' , sip-implementors@lists.cs.columbia.edu Subject: Re: [dispatch] [Sip-implementors] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 13:17:43 -0000 Marius, It is certainly true that we were focused entirely on out-of-dialog OPTIONS messages when we wrote the draft. I'm certainly not opposed to also including in-dialog OPTIONS exchanges if it fit smoothly within the draft. Alternatively, we could create two drafts. Would you like to draft some initial text for in-dialog and see if it makes sense to include it in this same draft or a separate one? If in the same draft, then perhaps in-dialog and OOD would be two separate sections? Paul > -----Original Message----- > From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] > Sent: Monday, August 16, 2010 6:00 AM > To: Paul E. Jones > Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Gonzalo > Salgueiro; Hadriel Kaplan > Subject: Re: [Sip-implementors] SIP OPTIONS "ping" > > Paul E. Jones wrote: > > Folks, > > > > > > > > Gonzalo and I produced an Internet Draft aiming at trying to bring > > some consistency to the way in which SIP user agents implement an > OPTIONS "ping" > > procedure. It seems that a very large number of vendors do this, but > > unfortunately, there seems to be little consistency. > > > > > > > > Initially, we positioned the document as a standards track RFC, since > > this essentially builds on RFC 3261. However, there was some pushback > > from folks in the IETF for a variety of reasons, not the least of > > which is the fact that there is no working group chartered to do the > > work. We don't feel this one draft warrants the creation of a working > group. > > > > > > > > So, we've got three options we can consider: > > > > 1) Forge ahead outside of a working group > > > > 2) Change the status of the draft to Informational > > > > 3) Forget about the draft and let every SIP device do it the way > they > > want, throwing hope of consistency out the window > > > > > > > > (Yeah, you can tell I prefer not to go for the third option.) > > > > > > > > In any case, I'd like to get feedback from the on the SIP operators > > and SIP implementers lists. Do you think it's worth trying to address > this issue? > > If so, which option do you think we should pursue? > > > > > > > Hello, > > I have read the draft and as far I can tell it addresses OPTIONS outside a > dialog. I know that this has already been discussed on this mailing > list[1], but there still are many vendors/SIP implementors that use a in- > dialog OPTIONS to figure out if a dialog is still running(if not the UAS > "will" respond with a 481- Call does not exist). By reading the comments > and the RFC I know this is wrong(a UAS might return a 200 OK even if the > dialog does not exist), but I think this enters into the "3) Forget about > the draft and let every SIP device do it the way they want, throwing hope > of consistency out the window " category. > > My first reaction is also to address this topic in the draft. What do you > think? > > Marius > > [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- > May/019278.html > > Note that we're certainly open to feedback on the draft. I'd prefer > > it to have a few more "MUST" statements in the text, rather than > > "SHOULD". But, we need to find that right balance: > > > > http://tools.ietf.org/html/draft-jones-sip-options-ping > > > > > > > > Paul > > > > > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > From paulej@packetizer.com Mon Aug 16 09:46:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCB73A69FF; Mon, 16 Aug 2010 09:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mskALhJK5foI; Mon, 16 Aug 2010 09:46:19 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 4C51F3A6881; Mon, 16 Aug 2010 09:46:19 -0700 (PDT) Received: from sydney (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o7GGkeZv021331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Aug 2010 12:46:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1281977206; bh=dNihPNbCFDt7yt2oAriEUHRYofxgpuvfKOiXR5gK9CA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=af+MLW3kUzXW7YjHnDXc27LmEfg+fq2VZKnyy9TGHCYlB9uHQnt7+awV2P4ZQWP08 m8RysRPrRtdvSRyQCn+Gu0fop6pXUtx+e7hy22AtpOdg6DEKZ8l9yOdSA0ov1YRuZV 9bp1m9H1tcLe5DwYBHyhS7yWB8mnYdpaKqkpb1gg= From: "Paul E. Jones" To: "'marius zbihlei'" References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> <012901cb3d45$5544c880$ffce5980$@packetizer.com> <4C694532.4020109@1and1.ro> In-Reply-To: <4C694532.4020109@1and1.ro> Date: Mon, 16 Aug 2010 12:45:44 -0400 Message-ID: <017e01cb3d62$7c171d10$74455730$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ7YPXf2shkdXst8Oeg2uiqnTvIBAJGarLcAUcUVigCKte1dZFWP3xg Content-language: en-us Cc: sip-ops@ietf.org, dispatch@ietf.org, 'Hadriel Kaplan' , sip-implementors@lists.cs.columbia.edu Subject: Re: [dispatch] [Sip-implementors] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 16:46:21 -0000 Marius, There is another important consideration to give to this. The OPTIONS "ping" we described was intended to be between a device and its next hop. What you would actually want is an OPTIONS that goes end-to-end. I think both need clarification, but I'm now thinking that perhaps we ought to document these separately. Of course, I'd be happy to work with you on both. Paul > -----Original Message----- > From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] > Sent: Monday, August 16, 2010 10:04 AM > To: Paul E. Jones > Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; 'Gonzalo > Salgueiro'; 'Hadriel Kaplan'; dispatch@ietf.org > Subject: Re: [Sip-implementors] SIP OPTIONS "ping" > > Paul E. Jones wrote: > > Marius, > > > > It is certainly true that we were focused entirely on out-of-dialog > > OPTIONS messages when we wrote the draft. I'm certainly not opposed > > to also including in-dialog OPTIONS exchanges if it fit smoothly within > the draft. > > Alternatively, we could create two drafts. > > > > Would you like to draft some initial text for in-dialog and see if it > > makes sense to include it in this same draft or a separate one? If in > > the same draft, then perhaps in-dialog and OOD would be two separate > sections? > > > > Paul > > > > > Hello again, > > I would gladly draft some initial text around this idea, but I am a little > torn apart between what I expect from the draft(and current > implementations) and what previous standards say. > > Quote from RFC 3261 > 12.2.2 UAS Behavior "Requests that do not change in any way the state of a > dialog may be received within a dialog (for example, an OPTIONS request). > They are processed as if they had been received outside the dialog." > > Along with other texts[1], this means that in-dialog OPTIONS requests > should be treated as OOD(also the thread I have linked seems to suggest > that). But I know for certain that lots of implementors do return a 481, > and several services rely on that error code to check if a dialog is still > running. I know about SIP Session Timers but using OPTIONS ping like > this(to discover if a dialog has finished) has some benefits(like the > proxy being able to terminate a call , which is not possible using SST > [2]), and more and more this looks like a "de facto" behavior. > > With this in mind, I have to ask the question: Should we allow (or > inforce) the 481 response for a in-dialog OPTIONS request(if the dialog > does not exits)(this is what I personally want and many implementors > already do), or should we respond with a 200 OK regardless if the dialog > exists or not?! > > Thank you in advance for answering this. > > [1] RFC 5057 section 5.3: "OPTIONS does not belong to any usage. Only > those failures discussed in Section 5.1 and Section 5.2 that destroy > entire dialogs will have any effect on the usages sharing the dialog with > a failed OPTIONS request." > > This in fact might prove usefull, as a failed in-dialog OPTIONS request > will guaranty that the dialog will not be destroyed > > [2] http://www.rfc-editor.org/rfc/rfc4028.txt > 8.3. Session Expiration > > When the current time equals or passes the session expiration for a > session, the proxy MAY remove associated call state, and MAY free any > resources associated with the call. Unlike the UA, it MUST NOT send a BYE. > >> -----Original Message----- > >> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] > >> Sent: Monday, August 16, 2010 6:00 AM > >> To: Paul E. Jones > >> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Gonzalo > >> Salgueiro; Hadriel Kaplan > >> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" > >> > >> Paul E. Jones wrote: > >> > >>> Folks, > >>> > >>> > >>> > >>> Gonzalo and I produced an Internet Draft aiming at trying to bring > >>> some consistency to the way in which SIP user agents implement an > >>> > >> OPTIONS "ping" > >> > >>> procedure. It seems that a very large number of vendors do this, > >>> but unfortunately, there seems to be little consistency. > >>> > >>> > >>> > >>> Initially, we positioned the document as a standards track RFC, > >>> since this essentially builds on RFC 3261. However, there was some > >>> pushback from folks in the IETF for a variety of reasons, not the > >>> least of which is the fact that there is no working group chartered > >>> to do the work. We don't feel this one draft warrants the creation > >>> of a working > >>> > >> group. > >> > >>> > >>> So, we've got three options we can consider: > >>> > >>> 1) Forge ahead outside of a working group > >>> > >>> 2) Change the status of the draft to Informational > >>> > >>> 3) Forget about the draft and let every SIP device do it the way > >>> > >> they > >> > >>> want, throwing hope of consistency out the window > >>> > >>> > >>> > >>> (Yeah, you can tell I prefer not to go for the third option.) > >>> > >>> > >>> > >>> In any case, I'd like to get feedback from the on the SIP operators > >>> and SIP implementers lists. Do you think it's worth trying to > >>> address > >>> > >> this issue? > >> > >>> If so, which option do you think we should pursue? > >>> > >>> > >>> > >>> > >> Hello, > >> > >> I have read the draft and as far I can tell it addresses OPTIONS > >> outside a dialog. I know that this has already been discussed on this > >> mailing list[1], but there still are many vendors/SIP implementors > >> that use a in- dialog OPTIONS to figure out if a dialog is still > >> running(if not the UAS "will" respond with a 481- Call does not > >> exist). By reading the comments and the RFC I know this is wrong(a > >> UAS might return a 200 OK even if the dialog does not exist), but I > >> think this enters into the "3) Forget about the draft and let every > >> SIP device do it the way they want, throwing hope of consistency out > the window " category. > >> > >> My first reaction is also to address this topic in the draft. What do > >> you think? > >> > >> Marius > >> > >> [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- > >> May/019278.html > >> > >>> Note that we're certainly open to feedback on the draft. I'd prefer > >>> it to have a few more "MUST" statements in the text, rather than > >>> "SHOULD". But, we need to find that right balance: > >>> > >>> http://tools.ietf.org/html/draft-jones-sip-options-ping > >>> > >>> > >>> > >>> Paul > >>> > >>> > >>> > >>> _______________________________________________ > >>> Sip-implementors mailing list > >>> Sip-implementors@lists.cs.columbia.edu > >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >>> > >>> > >>> > > > > > > > > From mlm.michael.miller@gmail.com Mon Aug 16 14:17:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7783A6AC3; Mon, 16 Aug 2010 14:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.397 X-Spam-Level: ** X-Spam-Status: No, score=2.397 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17HH-wbfciW4; Mon, 16 Aug 2010 14:17:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 605483A6ABD; Mon, 16 Aug 2010 14:17:29 -0700 (PDT) Received: by vws10 with SMTP id 10so4217175vws.31 for ; Mon, 16 Aug 2010 14:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :x-mailer:from:subject:date:to; bh=A1WWeN+jA66ljfKs/cX2V56cvQ1cRglw2VCJjmvT5fk=; b=LMNqNvCMxbbyGKHengAlWNE2nPnydUMf4gaZuxnIcH+irvZBdGM2gHejkFSmcnm8WM LnhS7yC8dq2iF6lpXQyKd25U7h7NA8aqu3l7Zmu5sW/eRT4knbho6SeAO89yEMlxpqFn cHWh1V3BNp98zvTBrdUbCw7oBy4zTds89gqO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=rPMrs4kEOUwe1Rpmyf514rVmGnGwZjj08pL8KE48X/mzH4QMxkZnhIGwopDCbpDps5 GigylktONdgo5SGyfi9B8S73Vwg51dl7qSAVw/602wjlKLZurms/7Ldp+6KxoGn0SsZB k+J+9KrBaKt0LwF+h0XuRDCBUrwaO8WKJaiYU= Received: by 10.220.122.151 with SMTP id l23mr3365024vcr.162.1281993482887; Mon, 16 Aug 2010 14:18:02 -0700 (PDT) Received: from [10.70.112.39] (mobile-166-137-136-078.mycingular.net [166.137.136.78]) by mx.google.com with ESMTPS id a16sm432583vcm.42.2010.08.16.14.18.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Aug 2010 14:18:02 -0700 (PDT) References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> <012901cb3d45$5544c880$ffce5980$@packetizer.com> <4C694532.4020109@1and1.ro> <017e01cb3d62$7c171d10$74455730$@packetizer.com> In-Reply-To: <017e01cb3d62$7c171d10$74455730$@packetizer.com> Mime-Version: 1.0 (iPhone Mail 8A306) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8A306) From: Michael Miller Date: Mon, 16 Aug 2010 17:18:06 -0400 To: "Paul E. Jones" Cc: "dispatch@ietf.org" , "sip-ops@ietf.org" , Hadriel Kaplan , "sip-implementors@lists.cs.columbia.edu" Subject: Re: [dispatch] [Sip-implementors] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 21:17:32 -0000 The end the end OPTIONS ping sounds like a great ideal, but does this change= this doc from more of a informational/best practice to some thing that woul= d require a change to SIP (like a header or something).=20 I'm new to this Michael L. Miller Sent from my Mobile Device On Aug 16, 2010, at 12:45 PM, "Paul E. Jones" wrote:= > Marius, >=20 > There is another important consideration to give to this. The OPTIONS > "ping" we described was intended to be between a device and its next hop. > What you would actually want is an OPTIONS that goes end-to-end. >=20 > I think both need clarification, but I'm now thinking that perhaps we ough= t > to document these separately. Of course, I'd be happy to work with you on= > both. >=20 > Paul >=20 >> -----Original Message----- >> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] >> Sent: Monday, August 16, 2010 10:04 AM >> To: Paul E. Jones >> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; 'Gonzalo >> Salgueiro'; 'Hadriel Kaplan'; dispatch@ietf.org >> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" >>=20 >> Paul E. Jones wrote: >>> Marius, >>>=20 >>> It is certainly true that we were focused entirely on out-of-dialog >>> OPTIONS messages when we wrote the draft. I'm certainly not opposed >>> to also including in-dialog OPTIONS exchanges if it fit smoothly within >> the draft. >>> Alternatively, we could create two drafts. >>>=20 >>> Would you like to draft some initial text for in-dialog and see if it >>> makes sense to include it in this same draft or a separate one? If in >>> the same draft, then perhaps in-dialog and OOD would be two separate >> sections? >>>=20 >>> Paul >>>=20 >>>=20 >> Hello again, >>=20 >> I would gladly draft some initial text around this idea, but I am a littl= e >> torn apart between what I expect from the draft(and current >> implementations) and what previous standards say. >>=20 >> Quote from RFC 3261 >> 12.2.2 UAS Behavior "Requests that do not change in any way the state of a= >> dialog may be received within a dialog (for example, an OPTIONS request).= >> They are processed as if they had been received outside the dialog." >>=20 >> Along with other texts[1], this means that in-dialog OPTIONS requests >> should be treated as OOD(also the thread I have linked seems to suggest >> that). But I know for certain that lots of implementors do return a 481, >> and several services rely on that error code to check if a dialog is stil= l >> running. I know about SIP Session Timers but using OPTIONS ping like >> this(to discover if a dialog has finished) has some benefits(like the >> proxy being able to terminate a call , which is not possible using SST >> [2]), and more and more this looks like a "de facto" behavior. >>=20 >> With this in mind, I have to ask the question: Should we allow (or >> inforce) the 481 response for a in-dialog OPTIONS request(if the dialog >> does not exits)(this is what I personally want and many implementors >> already do), or should we respond with a 200 OK regardless if the dialog >> exists or not?! >>=20 >> Thank you in advance for answering this. >>=20 >> [1] RFC 5057 section 5.3: "OPTIONS does not belong to any usage. Only >> those failures discussed in Section 5.1 and Section 5.2 that destroy >> entire dialogs will have any effect on the usages sharing the dialog with= >> a failed OPTIONS request." >>=20 >> This in fact might prove usefull, as a failed in-dialog OPTIONS request >> will guaranty that the dialog will not be destroyed >>=20 >> [2] http://www.rfc-editor.org/rfc/rfc4028.txt >> 8.3. Session Expiration >>=20 >> When the current time equals or passes the session expiration for a >> session, the proxy MAY remove associated call state, and MAY free any >> resources associated with the call. Unlike the UA, it MUST NOT send a BYE= . >>>> -----Original Message----- >>>> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] >>>> Sent: Monday, August 16, 2010 6:00 AM >>>> To: Paul E. Jones >>>> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Gonzalo >>>> Salgueiro; Hadriel Kaplan >>>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" >>>>=20 >>>> Paul E. Jones wrote: >>>>=20 >>>>> Folks, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Gonzalo and I produced an Internet Draft aiming at trying to bring >>>>> some consistency to the way in which SIP user agents implement an >>>>>=20 >>>> OPTIONS "ping" >>>>=20 >>>>> procedure. It seems that a very large number of vendors do this, >>>>> but unfortunately, there seems to be little consistency. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Initially, we positioned the document as a standards track RFC, >>>>> since this essentially builds on RFC 3261. However, there was some >>>>> pushback from folks in the IETF for a variety of reasons, not the >>>>> least of which is the fact that there is no working group chartered >>>>> to do the work. We don't feel this one draft warrants the creation >>>>> of a working >>>>>=20 >>>> group. >>>>=20 >>>>>=20 >>>>> So, we've got three options we can consider: >>>>>=20 >>>>> 1) Forge ahead outside of a working group >>>>>=20 >>>>> 2) Change the status of the draft to Informational >>>>>=20 >>>>> 3) Forget about the draft and let every SIP device do it the way >>>>>=20 >>>> they >>>>=20 >>>>> want, throwing hope of consistency out the window >>>>>=20 >>>>>=20 >>>>>=20 >>>>> (Yeah, you can tell I prefer not to go for the third option.) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> In any case, I'd like to get feedback from the on the SIP operators >>>>> and SIP implementers lists. Do you think it's worth trying to >>>>> address >>>>>=20 >>>> this issue? >>>>=20 >>>>> If so, which option do you think we should pursue? >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>> Hello, >>>>=20 >>>> I have read the draft and as far I can tell it addresses OPTIONS >>>> outside a dialog. I know that this has already been discussed on this >>>> mailing list[1], but there still are many vendors/SIP implementors >>>> that use a in- dialog OPTIONS to figure out if a dialog is still >>>> running(if not the UAS "will" respond with a 481- Call does not >>>> exist). By reading the comments and the RFC I know this is wrong(a >>>> UAS might return a 200 OK even if the dialog does not exist), but I >>>> think this enters into the "3) Forget about the draft and let every >>>> SIP device do it the way they want, throwing hope of consistency out >> the window " category. >>>>=20 >>>> My first reaction is also to address this topic in the draft. What do >>>> you think? >>>>=20 >>>> Marius >>>>=20 >>>> [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- >>>> May/019278.html >>>>=20 >>>>> Note that we're certainly open to feedback on the draft. I'd prefer >>>>> it to have a few more "MUST" statements in the text, rather than >>>>> "SHOULD". But, we need to find that right balance: >>>>>=20 >>>>> http://tools.ietf.org/html/draft-jones-sip-options-ping >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Paul >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Sip-implementors mailing list >>>>> Sip-implementors@lists.cs.columbia.edu >>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Mon Aug 16 16:16:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE113A6827; Mon, 16 Aug 2010 16:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEc5N7jx-825; Mon, 16 Aug 2010 16:16:02 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id F3FF33A681D; Mon, 16 Aug 2010 16:16:01 -0700 (PDT) Received: from dyn-129.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o7GNGNnB032537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 19:16:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1282000590; bh=+S5AhyXvDDleSwLoNLEfFmVwGvtmlu2wPbDZpj8GY/0=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:CC:Message-ID; b=NDmwEFgMbVnMe74tAmRWU7Jq1RHHvuuZkAJpGBaZYEy78bzelwAAmMunPEuVg7EVx MIc35BiyhohaQoRroFw0hwoqpsJH8VDekzit+Btm60nb+2Y29Hfm7u0IH2vXQk1SFP w3Ri/7/7nc9RgxzeZNiYhuEvXfL6yRX2Pe6AmvR0= X-User-Agent: K-9 Mail for Android References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> <012901cb3d45$5544c880$ffce5980$@packetizer.com> <4C694532.4020109@1and1.ro> <017e01cb3d62$7c171d10$74455730$@packetizer.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Mon, 16 Aug 2010 18:54:09 -0400 To: Michael Miller Message-ID: Cc: "dispatch@ietf.org" , "sip-ops@ietf.org" , Hadriel Kaplan , "sip-implementors@lists.cs.columbia.edu" Subject: Re: [dispatch] [Sip-implementors] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 23:16:03 -0000 We had a side discussion and reached agreement that this end-to-end procedure really ought to be a separate document. I think the scope of each is enough to justify two documents. So, we'll collaborate to produce two separate documents. Whether those will be informational or standards track is TBD. Paul "Michael Miller" wrote: >The end the end OPTIONS ping sounds like a great ideal, but does this change this doc from more of a informational/best practice to some thing that would require a change to SIP (like a header or something). > >I'm new to this > >Michael L. Miller >Sent from my Mobile Device > >On Aug 16, 2010, at 12:45 PM, "Paul E. Jones" wrote: > >> Marius, >> >> There is another important consideration to give to this. The OPTIONS >> "ping" we described was intended to be between a device and its next hop. >> What you would actually want is an OPTIONS that goes end-to-end. >> >> I think both need clarification, but I'm now thinking that perhaps we ought >> to document these separately. Of course, I'd be happy to work with you on >> both. >> >> Paul >> >>> -----Original Message----- >>> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] >>> Sent: Monday, August 16, 2010 10:04 AM >>> To: Paul E. Jones >>> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; 'Gonzalo >>> Salgueiro'; 'Hadriel Kaplan'; dispatch@ietf.org >>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" >>> >>> Paul E. Jones wrote: >>>> Marius, >>>> >>>> It is certainly true that we were focused entirely on out-of-dialog >>>> OPTIONS messages when we wrote the draft. I'm certainly not opposed >>>> to also including in-dialog OPTIONS exchanges if it fit smoothly within >>> the draft. >>>> Alternatively, we could create two drafts. >>>> >>>> Would you like to draft some initial text for in-dialog and see if it >>>> makes sense to include it in this same draft or a separate one? If in >>>> the same draft, then perhaps in-dialog and OOD would be two separate >>> sections? >>>> >>>> Paul >>>> >>>> >>> Hello again, >>> >>> I would gladly draft some initial text around this idea, but I am a little >>> torn apart between what I expect from the draft(and current >>> implementations) and what previous standards say. >>> >>> Quote from RFC 3261 >>> 12.2.2 UAS Behavior "Requests that do not change in any way the state of a >>> dialog may be received within a dialog (for example, an OPTIONS request). >>> They are processed as if they had been received outside the dialog." >>> >>> Along with other texts[1], this means that in-dialog OPTIONS requests >>> should be treated as OOD(also the thread I have linked seems to suggest >>> that). But I know for certain that lots of implementors do return a 481, >>> and several services rely on that error code to check if a dialog is still >>> running. I know about SIP Session Timers but using OPTIONS ping like >>> this(to discover if a dialog has finished) has some benefits(like the >>> proxy being able to terminate a call , which is not possible using SST >>> [2]), and more and more this looks like a "de facto" behavior. >>> >>> With this in mind, I have to ask the question: Should we allow (or >>> inforce) the 481 response for a in-dialog OPTIONS request(if the dialog >>> does not exits)(this is what I personally want and many implementors >>> already do), or should we respond with a 200 OK regardless if the dialog >>> exists or not?! >>> >>> Thank you in advance for answering this. >>> >>> [1] RFC 5057 section 5.3: "OPTIONS does not belong to any usage. Only >>> those failures discussed in Section 5.1 and Section 5.2 that destroy >>> entire dialogs will have any effect on the usages sharing the dialog with >>> a failed OPTIONS request." >>> >>> This in fact might prove usefull, as a failed in-dialog OPTIONS request >>> will guaranty that the dialog will not be destroyed >>> >>> [2] http://www.rfc-editor.org/rfc/rfc4028.txt >>> 8.3. Session Expiration >>> >>> When the current time equals or passes the session expiration for a >>> session, the proxy MAY remove associated call state, and MAY free any >>> resources associated with the call. Unlike the UA, it MUST NOT send a BYE. >>>>> -----Original Message----- >>>>> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] >>>>> Sent: Monday, August 16, 2010 6:00 AM >>>>> To: Paul E. Jones >>>>> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Gonzalo >>>>> Salgueiro; Hadriel Kaplan >>>>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" >>>>> >>>>> Paul E. Jones wrote: >>>>> >>>>>> Folks, >>>>>> >>>>>> >>>>>> >>>>>> Gonzalo and I produced an Internet Draft aiming at trying to bring >>>>>> some consistency to the way in which SIP user agents implement an >>>>>> >>>>> OPTIONS "ping" >>>>> >>>>>> procedure. It seems that a very large number of vendors do this, >>>>>> but unfortunately, there seems to be little consistency. >>>>>> >>>>>> >>>>>> >>>>>> Initially, we positioned the document as a standards track RFC, >>>>>> since this essentially builds on RFC 3261. However, there was some >>>>>> pushback from folks in the IETF for a variety of reasons, not the >>>>>> least of which is the fact that there is no working group chartered >>>>>> to do the work. We don't feel this one draft warrants the creation >>>>>> of a working >>>>>> >>>>> group. >>>>> >>>>>> >>>>>> So, we've got three options we can consider: >>>>>> >>>>>> 1) Forge ahead outside of a working group >>>>>> >>>>>> 2) Change the status of the draft to Informational >>>>>> >>>>>> 3) Forget about the draft and let every SIP device do it the way >>>>>> >>>>> they >>>>> >>>>>> want, throwing hope of consistency out the window >>>>>> >>>>>> >>>>>> >>>>>> (Yeah, you can tell I prefer not to go for the third option.) >>>>>> >>>>>> >>>>>> >>>>>> In any case, I'd like to get feedback from the on the SIP operators >>>>>> and SIP implementers lists. Do you think it's worth trying to >>>>>> address >>>>>> >>>>> this issue? >>>>> >>>>>> If so, which option do you think we should pursue? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hello, >>>>> >>>>> I have read the draft and as far I can tell it addresses OPTIONS >>>>> outside a dialog. I know that this has already been discussed on this >>>>> mailing list[1], but there still are many vendors/SIP implementors >>>>> that use a in- dialog OPTIONS to figure out if a dialog is still >>>>> running(if not the UAS "will" respond with a 481- Call does not >>>>> exist). By reading the comments and the RFC I know this is wrong(a >>>>> UAS might return a 200 OK even if the dialog does not exist), but I >>>>> think this enters into the "3) Forget about the draft and let every >>>>> SIP device do it the way they want, throwing hope of consistency out >>> the window " category. >>>>> >>>>> My first reaction is also to address this topic in the draft. What do >>>>> you think? >>>>> >>>>> Marius >>>>> >>>>> [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- >>>>> May/019278.html >>>>> >>>>>> Note that we're certainly open to feedback on the draft. I'd prefer >>>>>> it to have a few more "MUST" statements in the text, rather than >>>>>> "SHOULD". But, we need to find that right balance: >>>>>> >>>>>> http://tools.ietf.org/html/draft-jones-sip-options-ping >>>>>> >>>>>> >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip-implementors mailing list >>>>>> Sip-implementors@lists.cs.columbia.edu >>>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From mlm.michael.miller@gmail.com Mon Aug 16 16:36:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE8A3A6827; Mon, 16 Aug 2010 16:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.397 X-Spam-Level: ** X-Spam-Status: No, score=2.397 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSwh6dVXOrcm; Mon, 16 Aug 2010 16:36:55 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id C8FB23A67F0; Mon, 16 Aug 2010 16:36:54 -0700 (PDT) Received: by gwaa18 with SMTP id a18so2562730gwa.31 for ; Mon, 16 Aug 2010 16:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :x-mailer:from:subject:date:to; bh=1ISZGdeQDIMKVkSO29svAsKiGU20+BAYTYVEYAv++4o=; b=Oits9tyQ0F6Wv13Bxs+nmPDCVCAtJcNWNgz0i0lN134bVRHs5Ugd6DFvsZ+9/DQLhN REdbdQZqG8OZyUB2xTQnmh3YHjdKx+BEF6Q3CXudmIx9MHoKLelAt97K2nDlqbSBW0bc ANOYZVGFZHqU+BX1uqWTa+IvDkqi9Eb1AFq1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=YUsaH7PW4r9hKz1HotcRzoUVBKvnN8qb+s260Ot2xMPemjAjgNtl35SetPD85dMJ01 ioziLbXYD+q0RYJxeK/8A+/3GGdb3zhP6ovW3LaAreE9IfVjPk0Ddwd3yBMNKWBSpdKf cszsZAhr3F+Oq0fhbwzkpI7m2EpI3j0HmsXH0= Received: by 10.101.138.8 with SMTP id q8mr6622814ann.164.1282001842173; Mon, 16 Aug 2010 16:37:22 -0700 (PDT) Received: from [192.168.1.162] (c-71-205-254-94.hsd1.mi.comcast.net [71.205.254.94]) by mx.google.com with ESMTPS id p12sm11128358ane.34.2010.08.16.16.37.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Aug 2010 16:37:21 -0700 (PDT) References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> <012901cb3d45$5544c880$ffce5980$@packetizer.com> <4C694532.4020109@1and1.ro> <017e01cb3d62$7c171d10$74455730$@packetizer.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A306) Content-Type: text/plain; charset=us-ascii Message-Id: <67CEA0ED-6F29-4D89-9177-6355B8EC8458@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8A306) From: Michael Miller Date: Mon, 16 Aug 2010 19:37:28 -0400 To: "Paul E. Jones" Cc: "dispatch@ietf.org" , "sip-ops@ietf.org" , Hadriel Kaplan , "sip-implementors@lists.cs.columbia.edu" Subject: Re: [dispatch] [Sip-implementors] SIP OPTIONS "ping" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 23:36:56 -0000 Ok. Sounds good. I like to help where I can.=20 Michael L. Miller Sent from my Mobile Device On Aug 16, 2010, at 6:54 PM, "Paul E. Jones" wrote: > We had a side discussion and reached agreement that this end-to-end proced= ure really ought to be a separate document. I think the scope of each is eno= ugh to justify two documents. >=20 > So, we'll collaborate to produce two separate documents. Whether those wil= l be informational or standards track is TBD. >=20 > Paul >=20 > "Michael Miller" wrote: >=20 >> The end the end OPTIONS ping sounds like a great ideal, but does this cha= nge this doc from more of a informational/best practice to some thing that w= ould require a change to SIP (like a header or something).=20 >>=20 >> I'm new to this >>=20 >> Michael L. Miller >> Sent from my Mobile Device >>=20 >> On Aug 16, 2010, at 12:45 PM, "Paul E. Jones" wro= te: >>=20 >>> Marius, >>>=20 >>> There is another important consideration to give to this. The OPTIONS >>> "ping" we described was intended to be between a device and its next hop= . >>> What you would actually want is an OPTIONS that goes end-to-end. >>>=20 >>> I think both need clarification, but I'm now thinking that perhaps we ou= ght >>> to document these separately. Of course, I'd be happy to work with you o= n >>> both. >>>=20 >>> Paul >>>=20 >>>> -----Original Message----- >>>> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] >>>> Sent: Monday, August 16, 2010 10:04 AM >>>> To: Paul E. Jones >>>> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; 'Gonzalo >>>> Salgueiro'; 'Hadriel Kaplan'; dispatch@ietf.org >>>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" >>>>=20 >>>> Paul E. Jones wrote: >>>>> Marius, >>>>>=20 >>>>> It is certainly true that we were focused entirely on out-of-dialog >>>>> OPTIONS messages when we wrote the draft. I'm certainly not opposed >>>>> to also including in-dialog OPTIONS exchanges if it fit smoothly withi= n >>>> the draft. >>>>> Alternatively, we could create two drafts. >>>>>=20 >>>>> Would you like to draft some initial text for in-dialog and see if it >>>>> makes sense to include it in this same draft or a separate one? If in= >>>>> the same draft, then perhaps in-dialog and OOD would be two separate >>>> sections? >>>>>=20 >>>>> Paul >>>>>=20 >>>>>=20 >>>> Hello again, >>>>=20 >>>> I would gladly draft some initial text around this idea, but I am a lit= tle >>>> torn apart between what I expect from the draft(and current >>>> implementations) and what previous standards say. >>>>=20 >>>> Quote from RFC 3261 >>>> 12.2.2 UAS Behavior "Requests that do not change in any way the state o= f a >>>> dialog may be received within a dialog (for example, an OPTIONS request= ). >>>> They are processed as if they had been received outside the dialog." >>>>=20 >>>> Along with other texts[1], this means that in-dialog OPTIONS requests >>>> should be treated as OOD(also the thread I have linked seems to suggest= >>>> that). But I know for certain that lots of implementors do return a 481= , >>>> and several services rely on that error code to check if a dialog is st= ill >>>> running. I know about SIP Session Timers but using OPTIONS ping like >>>> this(to discover if a dialog has finished) has some benefits(like the >>>> proxy being able to terminate a call , which is not possible using SST >>>> [2]), and more and more this looks like a "de facto" behavior. >>>>=20 >>>> With this in mind, I have to ask the question: Should we allow (or >>>> inforce) the 481 response for a in-dialog OPTIONS request(if the dialog= >>>> does not exits)(this is what I personally want and many implementors >>>> already do), or should we respond with a 200 OK regardless if the dialo= g >>>> exists or not?! >>>>=20 >>>> Thank you in advance for answering this. >>>>=20 >>>> [1] RFC 5057 section 5.3: "OPTIONS does not belong to any usage. Only >>>> those failures discussed in Section 5.1 and Section 5.2 that destroy >>>> entire dialogs will have any effect on the usages sharing the dialog wi= th >>>> a failed OPTIONS request." >>>>=20 >>>> This in fact might prove usefull, as a failed in-dialog OPTIONS request= >>>> will guaranty that the dialog will not be destroyed >>>>=20 >>>> [2] http://www.rfc-editor.org/rfc/rfc4028.txt >>>> 8.3. Session Expiration >>>>=20 >>>> When the current time equals or passes the session expiration for a >>>> session, the proxy MAY remove associated call state, and MAY free any >>>> resources associated with the call. Unlike the UA, it MUST NOT send a B= YE. >>>>>> -----Original Message----- >>>>>> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] >>>>>> Sent: Monday, August 16, 2010 6:00 AM >>>>>> To: Paul E. Jones >>>>>> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Gonzalo= >>>>>> Salgueiro; Hadriel Kaplan >>>>>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" >>>>>>=20 >>>>>> Paul E. Jones wrote: >>>>>>=20 >>>>>>> Folks, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Gonzalo and I produced an Internet Draft aiming at trying to bring >>>>>>> some consistency to the way in which SIP user agents implement an >>>>>>>=20 >>>>>> OPTIONS "ping" >>>>>>=20 >>>>>>> procedure. It seems that a very large number of vendors do this, >>>>>>> but unfortunately, there seems to be little consistency. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Initially, we positioned the document as a standards track RFC, >>>>>>> since this essentially builds on RFC 3261. However, there was some >>>>>>> pushback from folks in the IETF for a variety of reasons, not the >>>>>>> least of which is the fact that there is no working group chartered >>>>>>> to do the work. We don't feel this one draft warrants the creation >>>>>>> of a working >>>>>>>=20 >>>>>> group. >>>>>>=20 >>>>>>>=20 >>>>>>> So, we've got three options we can consider: >>>>>>>=20 >>>>>>> 1) Forge ahead outside of a working group >>>>>>>=20 >>>>>>> 2) Change the status of the draft to Informational >>>>>>>=20 >>>>>>> 3) Forget about the draft and let every SIP device do it the wa= y >>>>>>>=20 >>>>>> they >>>>>>=20 >>>>>>> want, throwing hope of consistency out the window >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> (Yeah, you can tell I prefer not to go for the third option.) >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> In any case, I'd like to get feedback from the on the SIP operators >>>>>>> and SIP implementers lists. Do you think it's worth trying to >>>>>>> address >>>>>>>=20 >>>>>> this issue? >>>>>>=20 >>>>>>> If so, which option do you think we should pursue? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> I have read the draft and as far I can tell it addresses OPTIONS >>>>>> outside a dialog. I know that this has already been discussed on this= >>>>>> mailing list[1], but there still are many vendors/SIP implementors >>>>>> that use a in- dialog OPTIONS to figure out if a dialog is still >>>>>> running(if not the UAS "will" respond with a 481- Call does not >>>>>> exist). By reading the comments and the RFC I know this is wrong(a >>>>>> UAS might return a 200 OK even if the dialog does not exist), but I >>>>>> think this enters into the "3) Forget about the draft and let every >>>>>> SIP device do it the way they want, throwing hope of consistency out >>>> the window " category. >>>>>>=20 >>>>>> My first reaction is also to address this topic in the draft. What do= >>>>>> you think? >>>>>>=20 >>>>>> Marius >>>>>>=20 >>>>>> [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- >>>>>> May/019278.html >>>>>>=20 >>>>>>> Note that we're certainly open to feedback on the draft. I'd prefer= >>>>>>> it to have a few more "MUST" statements in the text, rather than >>>>>>> "SHOULD". But, we need to find that right balance: >>>>>>>=20 >>>>>>> http://tools.ietf.org/html/draft-jones-sip-options-ping >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Paul >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Sip-implementors mailing list >>>>>>> Sip-implementors@lists.cs.columbia.edu >>>>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >=20 From ingemar.s.johansson@ericsson.com Mon Aug 16 23:38:45 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537E83A63EC for ; Mon, 16 Aug 2010 23:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=-0.957, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4yD6yk5bhrP for ; Mon, 16 Aug 2010 23:38:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 3B1563A6768 for ; Mon, 16 Aug 2010 23:38:42 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-38-4c6a2e9552c6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DF.97.06895.59E2A6C4; Tue, 17 Aug 2010 08:39:17 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.96]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 17 Aug 2010 08:39:17 +0200 From: Ingemar Johansson S To: stephen botzko Date: Tue, 17 Aug 2010 08:39:16 +0200 Thread-Topic: [dispatch] Work on Telepresence - name Thread-Index: Acs61IeUeiRKr0eqSfC0xXLvBDzV0ADAZS7w Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_DBB1DC060375D147AC43F310AD987DCC0A3B3C12B5ESESSCMS0366e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Work on Telepresence - name X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 06:38:45 -0000 --_000_DBB1DC060375D147AC43F310AD987DCC0A3B3C12B5ESESSCMS0366e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK Sounds good. Just that I got the impression that there was sme disagreement= around this subject at the Ad Hoc. Regards Ingemar ________________________________ From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: den 13 augusti 2010 12:45 To: Ingemar Johansson S Cc: Allyn Romanow (allyn); dispatch@ietf.org Subject: Re: [dispatch] Work on Telepresence - name We agree that Interoperability needs to be established in both of your exam= ples. I am not sure why this is arising in the context of the charter discussion,= since the word "asymmetry" does not appear in the charter text at all. Th= e text itself makes no statement as to how the receiving system might diffe= r from the sending system. Also, I would not have guessed that "Mobile Office" really meant "cellphon= e" if I saw it in a charter statement. I think it is already understood that telepresence systems need to interope= rate with ordinary SIP devices - if that needs to be clarified in the chart= er, that is fine. But I don't think we need work items for every particula= r SIP device out there. Regards Stephen Botzko On Fri, Aug 13, 2010 at 4:34 AM, Ingemar Johansson S > wrote: Hi I don't have any good names to suggest. However I want to raise one topic that increased the temperature at he AdHo= c meeting somewhat. My understanding of the term asymmetry is that it seems like people have di= fferent minds of what it means. One interpretation is that it involves a a different number of (almost) equ= ally lage screens in the conference rooms, the main point is that the scree= ns are big enough to make people look their natural size. Another interpretation is that this aso involves an asymmetry in the rendei= ng capabilities. As an example many hand held cellphones today are capable = of encoding 720p video (or more). The rendering capabilities are limitied t= hough. This means that often in makes sense to only send a CIF encoded vide= o stream to the cell phone. The other patries may however sit behind large = screens. The latter introduces an element that can be seen as a mix of "full grade" = teleprecense and teleconferencing and I do believe that it should be includ= ed in the workitem as it includes what one can refer to as the mobile offic= e. Already today there are (already standardized or in the pipe) signaling = mechanisms that make these cases possible, see for instance the SDPCapNeg a= nd the image attribute work in MMUSIC. Regards Ingemar > -----Original Message----- > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > Sent: den 12 augusti 2010 20:47 > To: Ingemar Johansson S; dispatch@ietf.org > Subject: RE: [dispatch] Work on Telepresence - name > > Hi, > Actually I was about to set up a mailing list a bit ago and > realized we don't have a name. > > Here are some suggestions: > > MUSCAT: MUlti-Stream Control Applied to Telepresence CLUE > ControLling mUltiple streams for TElepresence > MUSCLE: MUltiple Stream Control for teLepesencE > SCULPTS: Semantic Control for mULtiPLe Telepesence Streams > CULTS: Controlling mUltipLe Telepesence Streams > > I prefer MUSCAT among these, but maybe someone can come up > with something better. > > Thanks, > Allyn > > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On B= ehalf Of Ingemar Johansson S > Sent: Thursday, August 12, 2010 4:58 AM > To: dispatch@ietf.org > Subject: [dispatch] Work on Teleprecense > > Hi > > Things got quiet after the Ad hoc on Teleprecense. Is there > any separate mailing list created for this ? > > /Ingemar > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > INGEMAR JOHANSSON M.Sc. > Senior Research Engineer > > Ericsson AB > Multimedia Technologies > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > Visit http://labs.ericsson.com ! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_DBB1DC060375D147AC43F310AD987DCC0A3B3C12B5ESESSCMS0366e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
OK
 
Sounds good. Just that I got the impression that t= here was=20 sme disagreement around this subject at the Ad Hoc.
 
Regards
Ingemar

From: stephen botzko=20 [mailto:stephen.botzko@gmail.com]
Sent: den 13 augusti 2010=20 12:45
To: Ingemar Johansson S
Cc: Allyn Romanow (ally= n);=20 dispatch@ietf.org
Subject: Re: [dispatch] Work on Telepresence = -=20 name

We agree that Interoperability needs to be established in both= of=20 your examples. 

I am not sure why this is arising in the con= text=20 of the charter discussion, since the word "asymmetry" does not appear in = the=20 charter text at all.  The text itself makes no statement as to how t= he=20 receiving system might differ from the sending system.

Also, = ; I=20 would not have guessed that "Mobile Office" really meant "cellphone" if I= saw=20 it in a charter statement.

I think it is already understood that=20 telepresence systems need to interoperate with ordinary SIP devices - if = that=20 needs to be clarified in the charter, that is fine.  But I don't thi= nk we=20 need work items for every particular SIP device out there.=20

Regards
Stephen Botzko



On Fri, Aug 13, 2010 at 4:34 AM, Ingemar Johanss= on S=20 <ingemar.s.johansson@ericsson.com> wrote:
Hi

I=20 don't have any good names to suggest.

However I want to raise on= e=20 topic that increased the temperature at he AdHoc meeting somewhat.
M= y=20 understanding of the term asymmetry is that it seems like people have=20 different minds of what it means.

One interpretation is that it= =20 involves a a different number of (almost) equally lage screens in the=20 conference rooms, the main point is that the screens are big enough to = make=20 people look their natural size.

Another interpretation is that t= his=20 aso involves an asymmetry in the rendeing capabilities. As an example m= any=20 hand held cellphones today are capable of encoding 720p video (or more)= . The=20 rendering capabilities are limitied though. This means that often in ma= kes=20 sense to only send a CIF encoded video stream to the cell phone. The ot= her=20 patries may however sit behind large screens.
The latter introduces = an=20 element that can be seen as a mix of "full grade" teleprecense and=20 teleconferencing and I do believe that it should be included in the wor= kitem=20 as it includes what one can refer to as the mobile office. Already toda= y=20 there are (already standardized or in the pipe) signaling mechanisms th= at=20 make these cases possible, see for instance the SDPCapNeg and the image= =20 attribute work in MMUSIC.


Regards
Ingemar


> -----Original Message-----
> From: Allyn Romano= w=20 (allyn) [mailto:allyn@cisco.com]
> Sent: den 12 augusti 2010= =20 20:47
> To: Ingemar Johansson S; dispatch@ietf.org
> Subject: RE: [dispatch] W= ork on=20 Telepresence - name
>
> Hi,
> Actually I was about to= set=20 up a mailing list a bit ago and
> realized we don't have a=20 name.
>
> Here are some suggestions:
>
> MUSCAT= :=20 MUlti-Stream Control Applied to Telepresence CLUE
> ControLling=20 mUltiple streams for TElepresence
> MUSCLE: MUltiple Stream Contr= ol=20 for teLepesencE
> SCULPTS: Semantic Control for mULtiPLe Telepese= nce=20 Streams
> CULTS: Controlling mUltipLe Telepesence=20 Streams
>
> I prefer MUSCAT among these, but maybe someone = can=20 come up
> with something better.
>
> Thanks,
>= =20 Allyn
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Ingemar Joh= ansson=20 S
> Sent: Thursday, August 12, 2010 4:58 AM
> To: dispatch@ietf.org=
>=20 Subject: [dispatch] Work on Teleprecense
>
> Hi
>
= >=20 Things got quiet after the Ad hoc on Teleprecense. Is there
> any= =20 separate mailing list created for this ?
>
> /Ingemar
&g= t;=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> INGEMAR JOHANSSON=20  M.Sc.
> Senior Research Engineer
>
> Ericsson=20 AB
> Multimedia Technologies
> Labratoriegr=E4nd 11
>= 971=20 28, Lule=E5, Sweden
> Phone +46-1071 43042
> SMS/MMS +46-73= 078=20 3289
> ingemar.s.johansson@ericsson.com
> www.ericsson.com>=20 Visit http://labs.ericsson.com !
>=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20 _______________________________________________
> dispatch mailin= g=20 list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
&= gt;
_______________________________________________
dispatch=20 mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
<= /DIV>

--_000_DBB1DC060375D147AC43F310AD987DCC0A3B3C12B5ESESSCMS0366e_-- From ingemar.s.johansson@ericsson.com Mon Aug 16 23:44:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3733A63EC for ; Mon, 16 Aug 2010 23:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=-0.888, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAnHrCq6fAx8 for ; Mon, 16 Aug 2010 23:44:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id BFB933A6768 for ; Mon, 16 Aug 2010 23:44:00 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-ba-4c6a2fccc0bb Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9B.38.06895.CCF2A6C4; Tue, 17 Aug 2010 08:44:28 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.96]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 17 Aug 2010 08:44:27 +0200 From: Ingemar Johansson S To: Marshall Eubanks Date: Tue, 17 Aug 2010 08:44:25 +0200 Thread-Topic: [dispatch] Work on Telepresence - name Thread-Index: Acs6xXxI5lsGDOPhTLa0OFkCZnFMDgDEYjmQ Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC021E18E1@xmb-sjc-221.amer.cisco.com> <49F4DB44-AA83-4409-969C-D965D1632654@americafree.tv> In-Reply-To: <49F4DB44-AA83-4409-969C-D965D1632654@americafree.tv> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Work on Telepresence - name X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 06:44:02 -0000 Hi There is a possibility that the text is interpreted in a way that faces on = the screens must have a natural size. With a mix of "full grade" telepresen= ce and teleconferencing this definition may not always hold, it may hold fo= r some participants but not all. Regards Ingemar=20 > -----Original Message----- > From: Marshall Eubanks [mailto:tme@americafree.tv]=20 > Sent: den 13 augusti 2010 10:57 > To: Ingemar Johansson S > Cc: Allyn Romanow (allyn); dispatch@ietf.org > Subject: Re: [dispatch] Work on Telepresence - name >=20 >=20 > On Aug 13, 2010, at 4:34 AM, Ingemar Johansson S wrote: >=20 > > Hi > >=20 > > I don't have any good names to suggest.=20 > >=20 > > However I want to raise one topic that increased the=20 > temperature at he AdHoc meeting somewhat.=20 > > My understanding of the term asymmetry is that it seems=20 > like people have different minds of what it means. >=20 > This is from my text for the charter : >=20 > While there is some debate about the exact meaning of=20 > telepresence, a reasonable definition of immersive=20 > telepresence is a system engineered to make local and remote=20 > participants feel that they are in the same room at the same time. >=20 > ----- >=20 > Does that seem OK ? >=20 > Regards > Marshall >=20 >=20 > > =20 > >=20 > > One interpretation is that it involves a a different number=20 > of (almost) equally lage screens in the conference rooms, the=20 > main point is that the screens are big enough to make people=20 > look their natural size.=20 > >=20 > > Another interpretation is that this aso involves an=20 > asymmetry in the rendeing capabilities. As an example many=20 > hand held cellphones today are capable of encoding 720p video=20 > (or more). The rendering capabilities are limitied though.=20 > This means that often in makes sense to only send a CIF=20 > encoded video stream to the cell phone. The other patries may=20 > however sit behind large screens. > > The latter introduces an element that can be seen as a mix=20 > of "full grade" teleprecense and teleconferencing and I do=20 > believe that it should be included in the workitem as it=20 > includes what one can refer to as the mobile office. Already=20 > today there are (already standardized or in the pipe)=20 > signaling mechanisms that make these cases possible, see for=20 > instance the SDPCapNeg and the image attribute work in MMUSIC. > >=20 > >=20 > > Regards > > Ingemar > >=20 > >=20 > >> -----Original Message----- > >> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > >> Sent: den 12 augusti 2010 20:47 > >> To: Ingemar Johansson S; dispatch@ietf.org > >> Subject: RE: [dispatch] Work on Telepresence - name > >>=20 > >> Hi, > >> Actually I was about to set up a mailing list a bit ago=20 > and realized=20 > >> we don't have a name. > >>=20 > >> Here are some suggestions: > >>=20 > >> MUSCAT: MUlti-Stream Control Applied to Telepresence CLUE=20 > ControLling=20 > >> mUltiple streams for TElepresence > >> MUSCLE: MUltiple Stream Control for teLepesencE > >> SCULPTS: Semantic Control for mULtiPLe Telepesence Streams > >> CULTS: Controlling mUltipLe Telepesence Streams > >>=20 > >> I prefer MUSCAT among these, but maybe someone can come up with=20 > >> something better. > >>=20 > >> Thanks, > >> Allyn > >>=20 > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Ingemar Johansson S > >> Sent: Thursday, August 12, 2010 4:58 AM > >> To: dispatch@ietf.org > >> Subject: [dispatch] Work on Teleprecense > >>=20 > >> Hi > >>=20 > >> Things got quiet after the Ad hoc on Teleprecense. Is there any=20 > >> separate mailing list created for this ? > >>=20 > >> /Ingemar > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> INGEMAR JOHANSSON M.Sc.=20 > >> Senior Research Engineer > >>=20 > >> Ericsson AB > >> Multimedia Technologies > >> Labratoriegr=E4nd 11 > >> 971 28, Lule=E5, Sweden > >> Phone +46-1071 43042 > >> SMS/MMS +46-73 078 3289 > >> ingemar.s.johansson@ericsson.com > >> www.ericsson.com > >> Visit http://labs.ericsson.com ! > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >>=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 > = From HKaplan@acmepacket.com Wed Aug 18 13:36:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FFE73A6A6A for ; Wed, 18 Aug 2010 13:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9ncb2GtVTh3 for ; Wed, 18 Aug 2010 13:36:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 466663A6A33 for ; Wed, 18 Aug 2010 13:36:56 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 18 Aug 2010 16:37:24 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 18 Aug 2010 16:37:24 -0400 From: Hadriel Kaplan To: "Parthasarathi R (partr)" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" , Peter Musgrave Date: Wed, 18 Aug 2010 16:37:23 -0400 Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvzxBsafq1F/F2TyimIJKjLTIAkgADQTWQAABlmWACRNMNFAANh4QwAAOR2WABdSOo8A== Message-ID: <430FC6BDED356B4C8498F634416644A9269438170D@mail> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> 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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:36:59 -0000 Hi Partha, Right, so this is the re-invite transfer use-case we talked about in Maastr= icht I believe. I think B2BUA-2 is not necessary in the call flow drawing = to show the issue you want to solve, right? It's just B2BUA-1 that's impor= tant. Like this: Alice B2BUA1 Bob Carol | | | | |--INV(D1/S1)---->|--INV(D2/S1)-->| | | | | | |<-200(D1/S1)-----|<-200(D2/S1)---| | | | | | |---ACK(D1/S1)--->|--ACK(D2/S1)-->| | | | | | |<=3D=3DAlice Put Bob on Hold (RE-INV/200/ACK S1)=3D=3D=3D=3D> | | | | | |--INV(D4/s2)---->|--INV(D5/S2)------------------->| | | | | |<-200(D4/S2)-----|<-200(D5/s2)--------------------| | | | | |--ACK(D4/S2)---->|--ACK(D5/S2)------------------->| | | | | |<=3D=3D=3DAlice put Carol on Hold (RE-INV/200/ACK S2)=3D=3D>| | | | | | | | | |--REFER/200(D1)->| | | |<-NOTIFY/200(D1)-| | | | |--Re-INV(D2/S?)>| | | | | | | |--Re-INV(D5/S?)---------------->| | | | | | |<--200(D2/S?)---| | | | | | | |<--200(D5/S?)-------------------| | | | | | |---ACK(D2/S?)-->| | | | | | | |---ACK(D5/S?)------------------>| |<-NOTIFY/200(D1)-| | | | | | | |<-BYE/200(D4/S2)-| | | | | | | |-BYE/200(D1/S1)->| | | | | | | In terms of the currently proposed SIPSCOTCH charter, this use-case has no = impact, since the charter arguably includes it in scope... of course whethe= r we solve it, or how we solve it, is not answered by the charter and would= be a decision for the new WG I think. -hadriel > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Wednesday, August 11, 2010 5:19 AM > To: Elwell, John; Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave >=20 > Thanks for accepting the use case and also for pointing out the flaw in > it. As you already guess, D2 & D5 is between B2BUA1 and B2BUA2, D3 is > between B2BUA2 and Bob, D6 is between B2BUA2 and Carol. I updated the > use case and attached with this mail for avoiding the confusion. >=20 > The focus of the use case is to show that session-id may change during > the mid-dialog. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, August 11, 2010 1:04 PM > To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat); > Peter Musgrave > Cc: dispatch@ietf.org > Subject: RE: [dispatch] Proposal for Session ID charter >=20 > Partha, >=20 > I see the point you are making, which sounds reasonable, although I > think the diagram is confusing because separate dialog D2 starts off > between B2BUA1 and B2BUA2, but suddenly changes to being between B2BUA1 > and Bob. Likewise D5 changes its scope. >=20 > John >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R > > (partr) > > Sent: 11 August 2010 02:35 > > To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat); > > Peter Musgrave > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] Proposal for Session ID charter > > > > Hadriel, > > > > > > > > I attached the use case which illustrates the session-id change during >=20 > > mid-dialog. As a individual use case, the use case is used for > > transfer based on "Re-INVITE" mechanism. The use case is useful for > > creating the complex supplementary services when use case is used as > > service primitive. This use case is deployed by B2BUA in Service > > Provider softswitches and Enterprise PBXs. The use case does not > > propose any solution but it just indicates the problem in creating the >=20 > > session-id. Even in case session-id is used for troubleshooting only, > > the session-id has to be generic enough to handle this use case. > > Please let me know your thought on this. > > > > > > > > I'll add more usecases based on the response for this mail. > > > > > > > > Thanks > > > > Partha > > > > ________________________________ > > > > From: dispatch-bounces@ietf.org on behalf of Parthasarathi R (partr) > > Sent: Fri 7/30/2010 5:47 PM > > To: Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] Proposal for Session ID charter > > > > > > > > Hadriel, > > > > Instead working with solution in mind, Shall we start with the > > usecases document. The usecase document will help us to decide whether >=20 > > the single header or multiple header required. It will help to > > identify the generic session-id if one exists. The usecase requirement >=20 > > will be very useful as we are talking about the complex dialog > > scenarios which involves set of B2BUA. > > > > As I mentioned in the earlier mail thread, I'll come up with the > > usecase document as a starting point, add more relevant usecases and > > we will brainstorm whether the usecases are relevant for the session > > id or not. > > Please let me know your opinion on the same. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Hadriel Kaplan > > Sent: Friday, July 30, 2010 5:14 PM > > To: Paul Kyzivat (pkyzivat); Peter Musgrave > > Cc: dispatch@ietf.org list > > Subject: Re: [dispatch] Proposal for Session ID charter > > > > > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On > > > Behalf Of Paul Kyzivat > > > Sent: Friday, July 30, 2010 6:08 AM > > > > > > 2) Other applications that require correlation of some class of > > > related dialogs for some purpose other than troubleshooting > > > are driven away, and so must define yet another header and id > > > for their own purposes. > > > > I know adding more headers sucks. But that may be the safest thing. > > > > -hadriel > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > From HKaplan@acmepacket.com Wed Aug 18 13:42:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8AC3A6A08 for ; Wed, 18 Aug 2010 13:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCKnLGE6NZX4 for ; Wed, 18 Aug 2010 13:42:14 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 816CE3A6A33 for ; Wed, 18 Aug 2010 13:42:13 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 18 Aug 2010 16:42:48 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 18 Aug 2010 16:42:26 -0400 From: Hadriel Kaplan To: "Parthasarathi R (partr)" , Peter Musgrave Date: Wed, 18 Aug 2010 16:42:25 -0400 Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: Acs5je8Y/qt7tJTgRLau5RNcym+AaAANpRYgAVQvgnA= Message-ID: <430FC6BDED356B4C8498F634416644A92694381714@mail> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> 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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:42:17 -0000 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Thursday, August 12, 2010 1:56 AM > To: Peter Musgrave >=20 > Thanks for accepting that usecases are useful for this discussion. The > mentioned usecase is not about REFER in B2BUA1, but it is about Re-INVITE > changing the session-id between two B2BUAs. From B2BUA2 perspective, it > does not have any intelligence that REFER received in B2BUA1. The same RE= - > INVITE session-id scenario may occurs in B2BUA2 due to some other trigger= . > The current Hadriel's session-id solution does not cover this. I wish tha= t > usecase document has to be considered as one of the work item for this > charter to identify which are all the usecases will be covered by the > proposed session-id charter. > > The main issue is whether the charter is applicable only for > troubleshooting or it is the new SIP infrastructure which shall be used > for different purpose depends upon the application.=20 Just to be clear - all we're talking about right now is a SIPSCOTCH charter= , not a solution to it. The session-id draft is just one possible solution= . The re-Invite due to transfer call flow is still about troubleshooting, pre= sumably, and the currently proposed charter would cover it. That doesn't m= ean we'd have to solve it or support it, I think... just that it's in scope= to be considered. The currently proposed charter is: Troubleshooting SIP networks can be improved by correlating messaging acros= s several devices. This working group will define a correlation identifier = to be used for the troubleshooting and the for correlation of logging infor= mation from different SIP devices in the network.=20 Sip transactions are often triggered by another SIP transaction. Two transa= ctions are in the same "session" if one was triggered by the other due to r= edirection, REFER processing, retargeting, or forwarding on a B2BUA. This w= orking group will define a correlation identifier that identifies all the = transactions in the same session. The scope of the identifier pertains to = the SIP signaling layer only, and not media. For example, several UA part= icipating in a conference call may be receiving the same media but would no= t be in the same session.=20 The design of the correlation identifier needs to take into account the iss= ue of not revealing the topology of network. The mechanism should be applic= able for Proxies, UAs, PBXs, SBCs, Application Servers, Softswitches, Phone= s, and Gateways.=20 This working group will coordinate with other relevant working groups and a= rea including Ops, and sipcore.=20 From pkyzivat@cisco.com Wed Aug 18 18:10:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710813A6823 for ; Wed, 18 Aug 2010 18:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.477 X-Spam-Level: X-Spam-Status: No, score=-110.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGSB1FssGxzL for ; Wed, 18 Aug 2010 18:10:27 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 89C473A6817 for ; Wed, 18 Aug 2010 18:10:27 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,230,1280707200"; d="scan'208";a="149302515" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Aug 2010 01:11:02 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7J1B2MS013068; Thu, 19 Aug 2010 01:11:02 GMT Message-ID: <4C6C849F.1000708@cisco.com> Date: Wed, 18 Aug 2010 21:10:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> <430FC6BDED356B4C8498F634416644A92694381714@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A92694381714@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 01:10:29 -0000 Hadriel, The problem I have with using "troubleshooting" as the criterion for what things are in scope for this id is: it can include anything you might have trouble with: if I'm trying to debug problems with conferencing, then it might be helpful to have the same session-id for all the participant connections to the focus; if I was called by a conference focus, and then transfer that call to my other phone, then I want all that to have the same session-id; yada yada I would understand if the criterion was "troubleshooting the problems an SBC has correlating the logs of customers on both sides of the calls it handles". Thanks, Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >> Sent: Thursday, August 12, 2010 1:56 AM >> To: Peter Musgrave >> >> Thanks for accepting that usecases are useful for this discussion. The >> mentioned usecase is not about REFER in B2BUA1, but it is about Re-INVITE >> changing the session-id between two B2BUAs. From B2BUA2 perspective, it >> does not have any intelligence that REFER received in B2BUA1. The same RE- >> INVITE session-id scenario may occurs in B2BUA2 due to some other trigger. >> The current Hadriel's session-id solution does not cover this. I wish that >> usecase document has to be considered as one of the work item for this >> charter to identify which are all the usecases will be covered by the >> proposed session-id charter. >> >> The main issue is whether the charter is applicable only for >> troubleshooting or it is the new SIP infrastructure which shall be used >> for different purpose depends upon the application. > > Just to be clear - all we're talking about right now is a SIPSCOTCH charter, not a solution to it. The session-id draft is just one possible solution. > The re-Invite due to transfer call flow is still about troubleshooting, presumably, and the currently proposed charter would cover it. That doesn't mean we'd have to solve it or support it, I think... just that it's in scope to be considered. > > > The currently proposed charter is: > > Troubleshooting SIP networks can be improved by correlating messaging across several devices. This working group will define a correlation identifier to be used for the troubleshooting and the for correlation of logging information from different SIP devices in the network. > > Sip transactions are often triggered by another SIP transaction. Two transactions are in the same "session" if one was triggered by the other due to redirection, REFER processing, retargeting, or forwarding on a B2BUA. This working group will define a correlation identifier that identifies all the transactions in the same session. The scope of the identifier pertains to the SIP signaling layer only, and not media. For example, several UA participating in a conference call may be receiving the same media but would not be in the same session. > > The design of the correlation identifier needs to take into account the issue of not revealing the topology of network. The mechanism should be applicable for Proxies, UAs, PBXs, SBCs, Application Servers, Softswitches, Phones, and Gateways. > > This working group will coordinate with other relevant working groups and area including Ops, and sipcore. > > From peter.musgrave@magorcorp.com Thu Aug 19 03:17:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567173A69F6 for ; Thu, 19 Aug 2010 03:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.017 X-Spam-Level: X-Spam-Status: No, score=-102.017 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcLghLYv+jne for ; Thu, 19 Aug 2010 03:16:59 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 5607F3A69C5 for ; Thu, 19 Aug 2010 03:16:59 -0700 (PDT) Received: by qwc9 with SMTP id 9so1661296qwc.31 for ; Thu, 19 Aug 2010 03:17:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.224.85 with SMTP id in21mr7057258qcb.102.1282213053935; Thu, 19 Aug 2010 03:17:33 -0700 (PDT) Received: by 10.229.219.8 with HTTP; Thu, 19 Aug 2010 03:17:33 -0700 (PDT) In-Reply-To: <4C6C849F.1000708@cisco.com> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> <4C528B89.5090906@cisco.com> <4C52A46E.1070305@cisco.com> <430FC6BDED356B4C8498F634416644A92694002E6A@mail> <430FC6BDED356B4C8498F634416644A92694381714@mail> <4C6C849F.1000708@cisco.com> Date: Thu, 19 Aug 2010 06:17:33 -0400 Message-ID: From: Peter Musgrave To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 10:17:00 -0000 Hi Paul, I don't have any issues with limiting the charter in that form - although I would use the term B2BUA to be consistent with paragraph 2 of the charter. Peter Musgrave On Wed, Aug 18, 2010 at 9:10 PM, Paul Kyzivat wrote: > Hadriel, > > The problem I have with using "troubleshooting" as the criterion for what > things are in scope for this id is: it can include anything you might hav= e > trouble with: > > if I'm trying to debug problems with conferencing, then it might be helpf= ul > to have the same session-id for all the participant connections to the > focus; > > if I was called by a conference focus, and then transfer that call to my > other phone, then I want all that to have the same session-id; > > yada yada > > I would understand if the criterion was "troubleshooting the problems an = SBC > has correlating the logs of customers on both sides of the calls it > handles". > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > > Hadriel Kaplan wrote: >> >>> -----Original Message----- >>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>> Sent: Thursday, August 12, 2010 1:56 AM >>> To: Peter Musgrave >>> >>> Thanks for accepting that usecases are useful for this discussion. The >>> mentioned usecase is not about REFER in B2BUA1, but it is about Re-INVI= TE >>> changing the session-id between two B2BUAs. From B2BUA2 perspective, it >>> does not have any intelligence that REFER received in B2BUA1. The same >>> RE- >>> INVITE session-id scenario may occurs in B2BUA2 due to some other >>> trigger. >>> The current Hadriel's session-id solution does not cover this. I wish >>> that >>> usecase document has to be considered as one of the work item for this >>> charter to identify which are all the usecases will be covered by the >>> proposed session-id charter. >>> >>> The main issue is whether the charter is applicable only for >>> troubleshooting or it is the new SIP infrastructure which shall be used >>> for different purpose depends upon the application. >> >> Just to be clear - all we're talking about right now is a SIPSCOTCH >> charter, not a solution to it. =A0The session-id draft is just one possi= ble >> solution. >> The re-Invite due to transfer call flow is still about troubleshooting, >> presumably, and the currently proposed charter would cover it. =A0That d= oesn't >> mean we'd have to solve it or support it, I think... just that it's in s= cope >> to be considered. >> >> >> The currently proposed charter is: >> >> Troubleshooting SIP networks can be improved by correlating messaging >> across several devices. This working group will define a correlation >> identifier to be used for the troubleshooting and the for correlation of >> logging information from different SIP devices in the network. >> Sip transactions are often triggered by another SIP transaction. Two >> transactions are in the same "session" if one was triggered by the other= due >> to redirection, REFER processing, retargeting, or forwarding on a B2BUA. >> This working group will define a correlation identifier that identifies = =A0all >> the transactions in the same session. =A0The scope of the identifier per= tains >> to the SIP signaling layer only, and not media. =A0 For example, several= UA >> participating in a conference call may be receiving the same media but w= ould >> not be in the same session. >> The design of the correlation identifier needs to take into account the >> issue of not revealing the topology of network. The mechanism should be >> applicable for Proxies, UAs, PBXs, SBCs, Application Servers, Softswitch= es, >> Phones, and Gateways. >> This working group will coordinate with other relevant working groups an= d >> area including Ops, and sipcore. >> > From pkyzivat@cisco.com Thu Aug 19 05:06:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F33C3A6922 for ; Thu, 19 Aug 2010 05:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.475 X-Spam-Level: X-Spam-Status: No, score=-110.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmb+Rins89hp for ; Thu, 19 Aug 2010 05:06:21 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C4F9A3A67CF for ; Thu, 19 Aug 2010 05:06:20 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,233,1280707200"; d="scan'208";a="149630886" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Aug 2010 12:06:55 +0000 Received: from [10.86.251.101] (bxb-vpn3-869.cisco.com [10.86.251.101]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7JC6tcC022550; Thu, 19 Aug 2010 12:06:55 GMT Message-ID: <4C6D1E5B.8060500@cisco.com> Date: Thu, 19 Aug 2010 08:06:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Musgrave References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> <4C528B89.5090906@cisco.com> <4C52A46E.1070305@cisco.com> <430FC6BDED356B4C8498F634416644A92694002E6A@mail> <430FC6BDED356B4C8498F634416644A92694381714@mail> <4C6C849F.1000708@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 12:06:22 -0000 Peter Musgrave wrote: > Hi Paul, > > I don't have any issues with limiting the charter in that form - > although I would use the term B2BUA to be consistent with paragraph 2 > of the charter. That isn't what I meant to suggest. If the charter were drawn that narrowly then IMO it wouldn't be worth doing at all. My point was that the scope needs to be specific enough that what is in and what is out can be determined. I'm pretty sure that most people interested in this work are interested in it for some reason other than "troubleshooting". But "troubleshooting" has been used in the charter in order to avoid the conflict and/or political incorrectness of mentioning the actual reasons. Thanks, Paul > Peter Musgrave > > On Wed, Aug 18, 2010 at 9:10 PM, Paul Kyzivat wrote: >> Hadriel, >> >> The problem I have with using "troubleshooting" as the criterion for what >> things are in scope for this id is: it can include anything you might have >> trouble with: >> >> if I'm trying to debug problems with conferencing, then it might be helpful >> to have the same session-id for all the participant connections to the >> focus; >> >> if I was called by a conference focus, and then transfer that call to my >> other phone, then I want all that to have the same session-id; >> >> yada yada >> >> I would understand if the criterion was "troubleshooting the problems an SBC >> has correlating the logs of customers on both sides of the calls it >> handles". >> >> Thanks, >> Paul >> >> Hadriel Kaplan wrote: >>>> -----Original Message----- >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>> Sent: Thursday, August 12, 2010 1:56 AM >>>> To: Peter Musgrave >>>> >>>> Thanks for accepting that usecases are useful for this discussion. The >>>> mentioned usecase is not about REFER in B2BUA1, but it is about Re-INVITE >>>> changing the session-id between two B2BUAs. From B2BUA2 perspective, it >>>> does not have any intelligence that REFER received in B2BUA1. The same >>>> RE- >>>> INVITE session-id scenario may occurs in B2BUA2 due to some other >>>> trigger. >>>> The current Hadriel's session-id solution does not cover this. I wish >>>> that >>>> usecase document has to be considered as one of the work item for this >>>> charter to identify which are all the usecases will be covered by the >>>> proposed session-id charter. >>>> >>>> The main issue is whether the charter is applicable only for >>>> troubleshooting or it is the new SIP infrastructure which shall be used >>>> for different purpose depends upon the application. >>> Just to be clear - all we're talking about right now is a SIPSCOTCH >>> charter, not a solution to it. The session-id draft is just one possible >>> solution. >>> The re-Invite due to transfer call flow is still about troubleshooting, >>> presumably, and the currently proposed charter would cover it. That doesn't >>> mean we'd have to solve it or support it, I think... just that it's in scope >>> to be considered. >>> >>> >>> The currently proposed charter is: >>> >>> Troubleshooting SIP networks can be improved by correlating messaging >>> across several devices. This working group will define a correlation >>> identifier to be used for the troubleshooting and the for correlation of >>> logging information from different SIP devices in the network. >>> Sip transactions are often triggered by another SIP transaction. Two >>> transactions are in the same "session" if one was triggered by the other due >>> to redirection, REFER processing, retargeting, or forwarding on a B2BUA. >>> This working group will define a correlation identifier that identifies all >>> the transactions in the same session. The scope of the identifier pertains >>> to the SIP signaling layer only, and not media. For example, several UA >>> participating in a conference call may be receiving the same media but would >>> not be in the same session. >>> The design of the correlation identifier needs to take into account the >>> issue of not revealing the topology of network. The mechanism should be >>> applicable for Proxies, UAs, PBXs, SBCs, Application Servers, Softswitches, >>> Phones, and Gateways. >>> This working group will coordinate with other relevant working groups and >>> area including Ops, and sipcore. >>> > From mary.ietf.barnes@gmail.com Thu Aug 19 09:41:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AA353A6889 for ; Thu, 19 Aug 2010 09:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.655 X-Spam-Level: X-Spam-Status: No, score=-101.655 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKukAyWD7qn1 for ; Thu, 19 Aug 2010 09:41:18 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 36ADA3A6840 for ; Thu, 19 Aug 2010 09:41:13 -0700 (PDT) Received: by yxk8 with SMTP id 8so925404yxk.31 for ; Thu, 19 Aug 2010 09:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=zKLUKb5DuYMX8pwaTgs9Y51kUHfxmtdRky/9yPpHHO4=; b=WdbYIiPA+q0CjuU7GCD2lYuAMIPcjr8g2KKnFAxKcTe8wtL9ov3p+QucQi2WbuG9w9 usqvtwD+dzd/wOTWZARHT3v10XUem13XAEqGOxhkJqZoUzrg1YhvCmY7D9P/yaCwYbTS wkfAqNrSuh/ivqNAO01EDIM/tnBV3TUlECdYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hHFH5eD7O+F8YZkQSSS/lRsLd6l5iRgHXN+Rbyry5YBvFEyKY7JSZmVe2dUp5t38Dc amopWbuSIuSUOni4e/L5TfonwkhOOA1Ei6FVLlhz1M3vQ4RRXhSeHoGdvP6CgZ2tqcUF 1BoQTgUQLFis7v7Hk0HnathNUjS1BU+HM+WSQ= MIME-Version: 1.0 Received: by 10.151.60.4 with SMTP id n4mr227922ybk.294.1282236107786; Thu, 19 Aug 2010 09:41:47 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Thu, 19 Aug 2010 09:41:47 -0700 (PDT) Date: Thu, 19 Aug 2010 11:41:47 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=000325552e3eb90fb2048e2fdb84 Subject: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:41:23 -0000 --000325552e3eb90fb2048e2fdb84 Content-Type: text/plain; charset=ISO-8859-1 Per the discussion at IETF-78, an action was taken to update the telepresence charter to be more specific and more tightly scoped. To that end, the updated charter is below. Please review and provide any additional feedback and comments to the list. In addition, if you think the charter is ready to move forward in terms of creating a new WG, please respond to the mailing list. In the latter case, if you could also please let us know (offlist if you'd prefer) if you are willing to technically contribute to this work, we can guage whether there will be sufficient contributors to support a WG. Best Regards, Mary. DISPATCH WG co-chair ================================================================ CLUE ControLling mUltiple streams for TElepresence or MUSCAT: MUlti-Stream Control Applied to Telepresence In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders and microphones. Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor in the inability of telepresence systems to interwork is that there is no standard description of the multiple streams of audio and video that comprise the media flows. In addition, there is no standardized way to exchange semantic information about what each media stream represents. The WG will create specification to enable communication of enough information about each media stream so that each receiving system or bridge system can make reasonable decisions about selecting and displaying media streams. This enables systems to make display choices that optimize the "just like being there" experience. This working group is chartered to specify the information about media streams from one endpoint to another endpoint or conference bridge including: * Spatial relationships of cameras, displays, microphones, and speakers in relation to each other and to likely positions of participants * Specific characteristics such as viewpoint, field of view/capture for camera/microphone/display/speaker so that senders and middleboxes can understand how best to compose streams for receivers and the receivers will know the characteristics of its received streams * Aspect ratio of cameras and displays Information between sources and sinks about media stream capabilities will be exchanged. The working group will define the semantics, language and transport mechanism necessary for communicating the necessary information. It will consider whether the existing signaling mechanisms (SDP, BFCP) can be extended, or another messaging method should be used. The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and video streams for the current speaker. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. The focus of this work is on multiple audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster. Also not in scope is signaling to tell the originator to which receivers the media streams should be sent. Reuse of existing protocols and backwards compatibility with existing systems is an important factor for the working group to consider. The work will closely coordinate with the appropriate areas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Milestones Nov 2010 Submit information draft to IESG on use cases and requirements Nov 2011 Submit standards track specification to IESG on indicating spatial relationships of screens, cameras (including variable field of view and orientation), speakers and microphones. This includes, semantics, language and transport. Apr 2011 Submit standards track specification to IESG on indicating the "usage" of a stream as define in charter. --000325552e3eb90fb2048e2fdb84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Per the discussion at IETF-78, an action was taken to update the telepresen= ce charter to be more specific and more tightly scoped. =A0To that end, the= updated charter is below. =A0

Please review and provide= any additional feedback and comments to the list. In addition, if you thin= k the charter is ready to move forward in terms of creating a new WG, pleas= e respond to the mailing list. =A0In the latter case, if you could also ple= ase let us know (offlist if you'd prefer) if you are willing to technic= ally contribute to this work, =A0we can guage whether there will be suffici= ent contributors to support a WG.=A0

Best Regards,
Mary.
DISPATCH WG co-= chair

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CLUE ControLling mUltiple streams for TEl= epresence
or
MUSCAT: MUlti-Stream Control Applied to Telepresence


In the context of this WG, the term tel= epresence is used in a general manner to describe systems that provide high= definition, high quality audio enabling a "being-there" experien= ce. =A0One example is an immersive telepresence system using specially desi= gned and special purpose rooms with multiple displays permitting life size = image reproduction using multiple cameras, encoders, decoders and microphon= es.=A0

Current telepresence systems are based on open standard= s such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily int= eroperate with each other without operator assistance and expensive additio= nal equipment which translates from one vendor to another. A major factor i= n the inability of telepresence systems to interwork is that there is no st= andard description of the multiple streams of audio and video that comprise= the media flows. =A0In addition, =A0there is =A0no standardized way =A0to = exchange semantic information about what each media stream represents. =A0<= /div>

The WG will create specification to enable communicatio= n of enough information about each media stream so that each receiving syst= em or bridge system can make reasonable decisions about selecting and displ= aying media streams. This enables systems to make display choices that opti= mize the "just like being there" experience.=A0

This working group is chartered to specify the informat= ion about media streams from one endpoint to another endpoint or conference= bridge including:

* Spatial relationships of came= ras, displays, microphones, and
=A0=A0speakers in relation to each other and to likely positions of
=A0=A0participants

* Specific characterist= ics such as viewpoint, field of view/capture
=A0=A0for camera/mic= rophone/display/speaker so that senders and =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0<= /div>
=A0=A0middleboxes can understand how best to compose streams for
=
=A0=A0receivers and the receivers will know the characteristics of its= =A0
=A0=A0received streams

* Aspect rati= o of cameras and displays

Information between sources and sinks about media strea= m capabilities will be exchanged.=A0

The working g= roup will define the semantics, language and transport mechanism necessary = for communicating the necessary information. It will consider whether the e= xisting signaling mechanisms (SDP, BFCP) can be extended, or another messag= ing method should be used. =A0

The scope of the work includes describing relatively st= atic relations between entities (participants and devices). It also include= s handling more dynamic relationships, such as identifying the audio and vi= deo streams for the current speaker. The scope includes both systems that p= rovide a fully immersive experience, and systems that interwork with them a= nd therefore need to understand the same multiple stream semantics. =A0

The focus of this work is on multiple audio and video s= treams. =A0Other media types may be considered, however development of meth= odologies for them is not within the scope of this work.

Interoperation with standards compliant systems is required, such as S= IP-based video conferencing systems. =A0However, backwards compatibility wi= th existing non-standards compliant telepresence systems is not required.

This working group is not currently chartered to work o= n issues of continuous conference control including: far end camera control= , indication of fast frame update for video codecs or other rapid switches,= floor control, conference roster. Also not in scope is signaling to tell t= he originator to which receivers the media streams should be sent.

Reuse of existing protocols and backwards compatibility= with existing systems is an important factor for the working group to cons= ider. The work will closely coordinate with the appropriate areas and worki= ng groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE.

=A0Milestones =A0

=A0Nov 2010 = Submit information draft to IESG on use cases and requirements
=A0Nov 2011 Submit standards track specification to IESG on in= dicating
=A0=A0 =A0 =A0 =A0 =A0spatial relationships of screens, cameras (inclu= ding variable
=A0=A0 =A0 =A0 =A0 =A0field of view and orientation= ), speakers and microphones. This
=A0=A0 =A0 =A0 =A0 =A0includes,= semantics, language and transport.

=A0Apr 2011 Submit standards track specification to IES= G on indicating the
=A0=A0 =A0 =A0 =A0 =A0"usage" of a = stream as define in charter.

=A0

--000325552e3eb90fb2048e2fdb84-- From peter.musgrave@magorcorp.com Thu Aug 19 10:12:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B770D3A6972 for ; Thu, 19 Aug 2010 10:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.016 X-Spam-Level: X-Spam-Status: No, score=-102.016 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hvam9FKCrWJ for ; Thu, 19 Aug 2010 10:12:33 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id D829B3A67F1 for ; Thu, 19 Aug 2010 10:12:32 -0700 (PDT) Received: by qwc9 with SMTP id 9so2105457qwc.31 for ; Thu, 19 Aug 2010 10:13:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.97.97 with SMTP id k33mr113892qan.49.1282237987411; Thu, 19 Aug 2010 10:13:07 -0700 (PDT) Received: by 10.229.219.8 with HTTP; Thu, 19 Aug 2010 10:13:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Aug 2010 13:13:07 -0400 Message-ID: From: Peter Musgrave To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:12:35 -0000 Hi, I have no issues with the charter as posed. I am willing to make technical contributions to this work. Cheers, Peter Musgrave On Thu, Aug 19, 2010 at 12:41 PM, Mary Barnes wrote: > Per the discussion at IETF-78, an action was taken to update the > telepresence charter to be more specific and more tightly scoped. =A0To t= hat > end, the updated charter is below. > Please review and provide any additional feedback and comments to the lis= t. > In addition, if you think the charter is ready to move forward in terms o= f > creating a new WG, please respond to the mailing list. =A0In the latter c= ase, > if you could also please let us know (offlist if you'd prefer) if you are > willing to technically contribute to this work, =A0we can guage whether t= here > will be sufficient contributors to support a WG. > Best Regards, > Mary. > DISPATCH WG co-chair > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CLUE ControLling mUltiple streams for TElepresence > or > MUSCAT: MUlti-Stream Control Applied to Telepresence > > In the context of this WG, the term telepresence is used in a general man= ner > to describe systems that provide high definition, high quality audio > enabling a "being-there" experience. =A0One example is an immersive > telepresence system using specially designed and special purpose rooms wi= th > multiple displays permitting life size image reproduction using multiple > cameras, encoders, decoders and microphones. > Current telepresence systems are based on open standards such as RTP, SIP= , > H.264, the H.323 suite, however, they cannot easily interoperate with eac= h > other without operator assistance and expensive additional equipment whic= h > translates from one vendor to another. A major factor in the inability of > telepresence systems to interwork is that there is no standard descriptio= n > of the multiple streams of audio and video that comprise the media flows. > =A0In addition, =A0there is =A0no standardized way =A0to exchange semanti= c > information about what each media stream represents. > The WG will create specification to enable communication of enough > information about each media stream so that each receiving system or brid= ge > system can make reasonable decisions about selecting and displaying media > streams. This enables systems to make display choices that optimize the > "just like being there" experience. > This working group is chartered to specify the information about media > streams from one endpoint to another endpoint or conference bridge > including: > * Spatial relationships of cameras, displays, microphones, and > =A0=A0speakers in relation to each other and to likely positions of > =A0=A0participants > * Specific characteristics such as viewpoint, field of view/capture > =A0=A0for camera/microphone/display/speaker so that senders and > =A0=A0middleboxes can understand how best to compose streams for > =A0=A0receivers and the receivers will know the characteristics of its > =A0=A0received streams > * Aspect ratio of cameras and displays > Information between sources and sinks about media stream capabilities wil= l > be exchanged. > The working group will define the semantics, language and transport > mechanism necessary for communicating the necessary information. It will > consider whether the existing signaling mechanisms (SDP, BFCP) can be > extended, or another messaging method should be used. > The scope of the work includes describing relatively static relations > between entities (participants and devices). It also includes handling mo= re > dynamic relationships, such as identifying the audio and video streams fo= r > the current speaker. The scope includes both systems that provide a fully > immersive experience, and systems that interwork with them and therefore > need to understand the same multiple stream semantics. > The focus of this work is on multiple audio and video streams. =A0Other m= edia > types may be considered, however development of methodologies for them is > not within the scope of this work. > Interoperation with standards compliant systems is required, such as > SIP-based video conferencing systems. =A0However, backwards compatibility= with > existing non-standards compliant telepresence systems is not required. > This working group is not currently chartered to work on issues of > continuous conference control including: far end camera control, indicati= on > of fast frame update for video codecs or other rapid switches, floor > control, conference roster. Also not in scope is signaling to tell the > originator to which receivers the media streams should be sent. > Reuse of existing protocols and backwards compatibility with existing > systems is an important factor for the working group to consider. The wor= k > will closely coordinate with the appropriate areas and working groups > including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. > =A0Milestones > =A0Nov 2010 Submit information draft to IESG on use cases and requirement= s > =A0Nov 2011 Submit standards track specification to IESG on indicating > =A0=A0 =A0 =A0 =A0 =A0spatial relationships of screens, cameras (includin= g variable > =A0=A0 =A0 =A0 =A0 =A0field of view and orientation), speakers and microp= hones. This > =A0=A0 =A0 =A0 =A0 =A0includes, semantics, language and transport. > =A0Apr 2011 Submit standards track specification to IESG on indicating th= e > =A0=A0 =A0 =A0 =A0 =A0"usage" of a stream as define in charter. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From pkyzivat@cisco.com Thu Aug 19 10:23:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4353A69E6 for ; Thu, 19 Aug 2010 10:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.48 X-Spam-Level: X-Spam-Status: No, score=-110.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zrR2H0evG1W for ; Thu, 19 Aug 2010 10:23:09 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 239283A6982 for ; Thu, 19 Aug 2010 10:23:09 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGEFbUxAZnwM/2dsb2JhbACgUnGjFpt4hTcEiXE X-IronPort-AV: E=Sophos;i="4.56,234,1280707200"; d="scan'208";a="149568068" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Aug 2010 17:23:43 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7JHNh5S018951; Thu, 19 Aug 2010 17:23:43 GMT Message-ID: <4C6D689A.3080901@cisco.com> Date: Thu, 19 Aug 2010 13:23:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:23:11 -0000 This seems good, but I've indicated a few nits inline. Thanks, Paul Mary Barnes wrote: > Per the discussion at IETF-78, an action was taken to update the > telepresence charter to be more specific and more tightly scoped. To > that end, the updated charter is below. > > Please review and provide any additional feedback and comments to the > list. In addition, if you think the charter is ready to move forward in > terms of creating a new WG, please respond to the mailing list. In the > latter case, if you could also please let us know (offlist if you'd > prefer) if you are willing to technically contribute to this work, we > can guage whether there will be sufficient contributors to support a WG. > > Best Regards, > Mary. > DISPATCH WG co-chair > > ================================================================ > > CLUE ControLling mUltiple streams for TElepresence > or > MUSCAT: MUlti-Stream Control Applied to Telepresence > > > In the context of this WG, the term telepresence is used in a general > manner to describe systems that provide high definition, high quality > audio enabling a "being-there" experience. One example is an immersive *audio*??? s:audio:video: or s:audio:audio/video: > telepresence system using specially designed and special purpose rooms > with multiple displays permitting life size image reproduction using > multiple cameras, encoders, decoders and microphones. > > Current telepresence systems are based on open standards such as RTP, > SIP, H.264, the H.323 suite, however, they cannot easily interoperate > with each other without operator assistance and expensive additional s/with each other// (implied by "interoperate") > equipment which translates from one vendor to another. A major factor in > the inability of telepresence systems to interwork is that there is no > standard description of the multiple streams of audio and video that > comprise the media flows. In addition, there is no standardized way > to exchange semantic information about what each media stream represents. > > The WG will create specification to enable communication of enough > information about each media stream so that each receiving system or > bridge system can make reasonable decisions about selecting and > displaying media streams. This enables systems to make display choices s/displaying/rendering/ (both audio and video being discussed, but you don't *display* audio.) > that optimize the "just like being there" experience. > > This working group is chartered to specify the information about media > streams from one endpoint to another endpoint or conference bridge > including: > > * Spatial relationships of cameras, displays, microphones, and > speakers in relation to each other and to likely positions of > participants > > * Specific characteristics such as viewpoint, field of view/capture > for camera/microphone/display/speaker so that senders and > middleboxes can understand how best to compose streams for > receivers and the receivers will know the characteristics of its > received streams > > * Aspect ratio of cameras and displays > > Information between sources and sinks about media stream capabilities > will be exchanged. > > The working group will define the semantics, language and transport > mechanism necessary for communicating the necessary information. It will > consider whether the existing signaling mechanisms (SDP, BFCP) can be I don't think SDP and BFCP are the only existing mechanisms. So s/(/(e.g. / > extended, or another messaging method should be used. > > The scope of the work includes describing relatively static relations > between entities (participants and devices). It also includes handling > more dynamic relationships, such as identifying the audio and video > streams for the current speaker. The scope includes both systems that > provide a fully immersive experience, and systems that interwork with > them and therefore need to understand the same multiple stream semantics. > > The focus of this work is on multiple audio and video streams. Other > media types may be considered, however development of methodologies for > them is not within the scope of this work. > > Interoperation with standards compliant systems is required, such as > SIP-based video conferencing systems. However, backwards compatibility > with existing non-standards compliant telepresence systems is not required. > > This working group is not currently chartered to work on issues of > continuous conference control including: far end camera control, > indication of fast frame update for video codecs or other rapid > switches, floor control, conference roster. Also not in scope is > signaling to tell the originator to which receivers the media streams > should be sent. > > Reuse of existing protocols and backwards compatibility with existing > systems is an important factor for the working group to consider. The > work will closely coordinate with the appropriate areas and working > groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. > > Milestones > > Nov 2010 Submit information draft to IESG on use cases and requirements > > Nov 2011 Submit standards track specification to IESG on indicating > spatial relationships of screens, cameras (including variable > field of view and orientation), speakers and microphones. This > includes, semantics, language and transport. > > Apr 2011 Submit standards track specification to IESG on indicating the > "usage" of a stream as define in charter. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Thu Aug 19 10:36:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8693A695D for ; Thu, 19 Aug 2010 10:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU+ImDeT8sBP for ; Thu, 19 Aug 2010 10:36:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A5E883A68CB for ; Thu, 19 Aug 2010 10:36:49 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 19 Aug 2010 13:37:23 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 19 Aug 2010 13:37:14 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Thu, 19 Aug 2010 13:37:12 -0400 Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: Acs/O2TIxwL70wLaQoSLOHHdbbnUeQAiPmUA Message-ID: <430FC6BDED356B4C8498F634416644A9269438193C@mail> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> <430FC6BDED356B4C8498F634416644A92694381714@mail> <4C6C849F.1000708@cisco.com> In-Reply-To: <4C6C849F.1000708@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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:36:50 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, August 18, 2010 9:11 PM > To: Hadriel Kaplan >=20 > The problem I have with using "troubleshooting" as the criterion for > what things are in scope for this id is: it can include anything you > might have trouble with: > if I'm trying to debug problems with conferencing, then it might be > helpful to have the same session-id for all the participant connections > to the focus; > if I was called by a conference focus, and then transfer that call to my > other phone, then I want all that to have the same session-id; Sure, but the proposed charter doesn't say it will solve all troubleshootin= g needs imaginable, nor does it say it will cover such conference scenarios= . And it does NOT say "troubleshooting is the criterion for what things ar= e in scope". It just says: Sip transactions are often triggered by another SIP transaction. Two transactions are in the same "session" if one was triggered by the other due to redirection, REFER processing, retargeting, or forwarding on a B2BUA. This working group will define a correlation identifier that identifies all the transactions in the same session. -hadriel From HKaplan@acmepacket.com Thu Aug 19 10:41:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB8113A695D for ; Thu, 19 Aug 2010 10:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ThR4qD-UCGW for ; Thu, 19 Aug 2010 10:41:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 861783A69E3 for ; Thu, 19 Aug 2010 10:41:31 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 19 Aug 2010 13:42:05 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 19 Aug 2010 13:42:06 -0400 From: Hadriel Kaplan To: "Parthasarathi R (partr)" , Peter Musgrave Date: Thu, 19 Aug 2010 13:42:04 -0400 Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: Acs5je8Y/qt7tJTgRLau5RNcym+AaAANpRYgAYAywnA= Message-ID: <430FC6BDED356B4C8498F634416644A92694381942@mail> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> 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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:41:33 -0000 Hi Partha, In one of our emails you attached the description of why SIPREC might need = an identifier like session-id. I'll respond to that in the siprec list, to= see if they really mean a SIP session identifier, or if they mean a media = identifier. -hadriel > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Thursday, August 12, 2010 1:56 AM > To: Peter Musgrave >=20 > [snip] > > I attached the mail thread by John Elwell which indicates the session-id > usage in SIPREC. I also attached one of the possible callflow for the sam= e. > SIPREC is yet to define the callflows, so the callflow may change. From tme@americafree.tv Thu Aug 19 11:03:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9AC3A686C for ; Thu, 19 Aug 2010 11:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eDBVqGMCSI2 for ; Thu, 19 Aug 2010 11:03:46 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 78DB33A6844 for ; Thu, 19 Aug 2010 11:03:44 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id E7A4C87CA785; Thu, 19 Aug 2010 14:04:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <4C6D689A.3080901@cisco.com> Date: Thu, 19 Aug 2010 14:04:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <41F3405E-1FD9-45AD-BFDE-3850624DB435@americafree.tv> References: <4C6D689A.3080901@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1081) Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:03:50 -0000 These changes all WFM. Marshall On Aug 19, 2010, at 1:23 PM, Paul Kyzivat wrote: > This seems good, but I've indicated a few nits inline. >=20 > Thanks, > Paul >=20 > Mary Barnes wrote: >> Per the discussion at IETF-78, an action was taken to update the = telepresence charter to be more specific and more tightly scoped. To = that end, the updated charter is below. Please review and provide any = additional feedback and comments to the list. In addition, if you think = the charter is ready to move forward in terms of creating a new WG, = please respond to the mailing list. In the latter case, if you could = also please let us know (offlist if you'd prefer) if you are willing to = technically contribute to this work, we can guage whether there will be = sufficient contributors to support a WG. Best Regards, >> Mary. >> DISPATCH WG co-chair >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> CLUE ControLling mUltiple streams for TElepresence >> or >> MUSCAT: MUlti-Stream Control Applied to Telepresence >> In the context of this WG, the term telepresence is used in a general = manner to describe systems that provide high definition, high quality = audio enabling a "being-there" experience. One example is an immersive=20= >=20 > *audio*??? >=20 > s:audio:video: or s:audio:audio/video: >=20 >> telepresence system using specially designed and special purpose = rooms with multiple displays permitting life size image reproduction = using multiple cameras, encoders, decoders and microphones. Current = telepresence systems are based on open standards such as RTP, SIP, = H.264, the H.323 suite, however, they cannot easily interoperate with = each other without operator assistance and expensive additional=20 >=20 > s/with each other// > (implied by "interoperate") >=20 >> equipment which translates from one vendor to another. A major factor = in the inability of telepresence systems to interwork is that there is = no standard description of the multiple streams of audio and video that = comprise the media flows. In addition, there is no standardized way = to exchange semantic information about what each media stream = represents. The WG will create specification to enable communication of = enough information about each media stream so that each receiving system = or bridge system can make reasonable decisions about selecting and = displaying media streams. This enables systems to make display choices=20= >=20 > s/displaying/rendering/ > (both audio and video being discussed, but you don't *display* audio.) >=20 >> that optimize the "just like being there" experience. This working = group is chartered to specify the information about media streams from = one endpoint to another endpoint or conference bridge including: >> * Spatial relationships of cameras, displays, microphones, and >> speakers in relation to each other and to likely positions of >> participants >> * Specific characteristics such as viewpoint, field of view/capture >> for camera/microphone/display/speaker so that senders and = middleboxes can understand how best to compose streams for >> receivers and the receivers will know the characteristics of its = received streams >> * Aspect ratio of cameras and displays >> Information between sources and sinks about media stream capabilities = will be exchanged. The working group will define the semantics, language = and transport mechanism necessary for communicating the necessary = information. It will consider whether the existing signaling mechanisms = (SDP, BFCP) can be=20 >=20 > I don't think SDP and BFCP are the only existing mechanisms. So >=20 > s/(/(e.g. / >=20 >> extended, or another messaging method should be used. The scope of = the work includes describing relatively static relations between = entities (participants and devices). It also includes handling more = dynamic relationships, such as identifying the audio and video streams = for the current speaker. The scope includes both systems that provide a = fully immersive experience, and systems that interwork with them and = therefore need to understand the same multiple stream semantics. The = focus of this work is on multiple audio and video streams. Other media = types may be considered, however development of methodologies for them = is not within the scope of this work. >> Interoperation with standards compliant systems is required, such as = SIP-based video conferencing systems. However, backwards compatibility = with existing non-standards compliant telepresence systems is not = required. >> This working group is not currently chartered to work on issues of = continuous conference control including: far end camera control, = indication of fast frame update for video codecs or other rapid = switches, floor control, conference roster. Also not in scope is = signaling to tell the originator to which receivers the media streams = should be sent. >> Reuse of existing protocols and backwards compatibility with existing = systems is an important factor for the working group to consider. The = work will closely coordinate with the appropriate areas and working = groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. >> Milestones Nov 2010 Submit information draft to IESG on use cases = and requirements >> Nov 2011 Submit standards track specification to IESG on indicating >> spatial relationships of screens, cameras (including = variable >> field of view and orientation), speakers and microphones. = This >> includes, semantics, language and transport. >> Apr 2011 Submit standards track specification to IESG on indicating = the >> "usage" of a stream as define in charter. >> = ------------------------------------------------------------------------ >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From allyn@cisco.com Thu Aug 19 12:03:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DCC3A69CB for ; Thu, 19 Aug 2010 12:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jlyia75gczyC for ; Thu, 19 Aug 2010 12:02:52 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BFE863A68AB for ; Thu, 19 Aug 2010 12:02:52 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAEocbUyrR7Hu/2dsb2JhbACBRJ8OcaQXm3CFNwSEM4gr X-IronPort-AV: E=Sophos;i="4.56,235,1280707200"; d="scan'208,217";a="353708258" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 19 Aug 2010 19:03:27 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7JJ3RKO001669; Thu, 19 Aug 2010 19:03:27 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Aug 2010 12:03:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3FD1.3483E26C" Date: Thu, 19 Aug 2010 12:03:25 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02283D41@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated Telepresence charter Thread-Index: Acs/vXjOitvmGsNeQ0K0JjB+8yGkpgAE6DZQ References: From: "Allyn Romanow (allyn)" To: "Mary Barnes" , "DISPATCH" X-OriginalArrivalTime: 19 Aug 2010 19:03:27.0457 (UTC) FILETIME=[34ABA510:01CB3FD1] Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:03:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3FD1.3483E26C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks good to me, with Paul's improvements. =20 Allyn=20 =20 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, August 19, 2010 9:42 AM To: DISPATCH Subject: [dispatch] Updated Telepresence charter =20 Per the discussion at IETF-78, an action was taken to update the telepresence charter to be more specific and more tightly scoped. To that end, the updated charter is below. =20 =20 Please review and provide any additional feedback and comments to the list. In addition, if you think the charter is ready to move forward in terms of creating a new WG, please respond to the mailing list. In the latter case, if you could also please let us know (offlist if you'd prefer) if you are willing to technically contribute to this work, we can guage whether there will be sufficient contributors to support a WG. =20 Best Regards, Mary. DISPATCH WG co-chair =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 CLUE ControLling mUltiple streams for TElepresence or MUSCAT: MUlti-Stream Control Applied to Telepresence =20 =20 In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders and microphones.=20 =20 Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor in the inability of telepresence systems to interwork is that there is no standard description of the multiple streams of audio and video that comprise the media flows. In addition, there is no standardized way to exchange semantic information about what each media stream represents. =20 =20 The WG will create specification to enable communication of enough information about each media stream so that each receiving system or bridge system can make reasonable decisions about selecting and displaying media streams. This enables systems to make display choices that optimize the "just like being there" experience.=20 =20 This working group is chartered to specify the information about media streams from one endpoint to another endpoint or conference bridge including: =20 * Spatial relationships of cameras, displays, microphones, and speakers in relation to each other and to likely positions of participants =20 * Specific characteristics such as viewpoint, field of view/capture for camera/microphone/display/speaker so that senders and middleboxes can understand how best to compose streams for receivers and the receivers will know the characteristics of its=20 received streams =20 * Aspect ratio of cameras and displays =20 Information between sources and sinks about media stream capabilities will be exchanged.=20 =20 The working group will define the semantics, language and transport mechanism necessary for communicating the necessary information. It will consider whether the existing signaling mechanisms (SDP, BFCP) can be extended, or another messaging method should be used. =20 =20 The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and video streams for the current speaker. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. =20 =20 The focus of this work is on multiple audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. =20 Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. =20 This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster. Also not in scope is signaling to tell the originator to which receivers the media streams should be sent. =20 Reuse of existing protocols and backwards compatibility with existing systems is an important factor for the working group to consider. The work will closely coordinate with the appropriate areas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. =20 Milestones =20 =20 Nov 2010 Submit information draft to IESG on use cases and requirements =20 Nov 2011 Submit standards track specification to IESG on indicating spatial relationships of screens, cameras (including variable field of view and orientation), speakers and microphones. This includes, semantics, language and transport. =20 Apr 2011 Submit standards track specification to IESG on indicating the "usage" of a stream as define in charter. =20 =20 =20 ------_=_NextPart_001_01CB3FD1.3483E26C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Looks good to me, with Paul’s = improvements.

 

Allyn

 

From:= = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Thursday, August 19, 2010 9:42 AM
To: DISPATCH
Subject: [dispatch] Updated Telepresence = charter

 

Per the discussion at IETF-78, an action was taken = to update the telepresence charter to be more specific and more tightly scoped. =  To that end, the updated charter is below.  

 

Please review and provide any additional feedback = and comments to the list. In addition, if you think the charter is ready to = move forward in terms of creating a new WG, please respond to the mailing = list.  In the latter case, if you could also please let us know (offlist = if you'd prefer) if you are willing to technically contribute to this work,  we can guage whether there will be sufficient contributors to = support a WG. 

 

Best Regards,

Mary.

DISPATCH WG co-chair

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

CLUE ControLling mUltiple streams for = TElepresence

or

MUSCAT: MUlti-Stream Control Applied to = Telepresence

 

 

In the context of this WG, the term telepresence is = used in a general manner to describe systems that provide high definition, high = quality audio enabling a "being-there" experience.  One example = is an immersive telepresence system using specially designed and special = purpose rooms with multiple displays permitting life size image reproduction = using multiple cameras, encoders, decoders and = microphones. 

 

Current telepresence systems are based on open = standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A = major factor in the inability of telepresence systems to interwork is that = there is no standard description of the multiple streams of audio and video that comprise the media flows.  In addition,  there is  no standardized way  to exchange semantic information about what each = media stream represents.  

 

The WG will create specification to enable = communication of enough information about each media stream so that each receiving system = or bridge system can make reasonable decisions about selecting and = displaying media streams. This enables systems to make display choices that = optimize the "just like being there" experience. 

 

This working group is chartered to specify the = information about media streams from one endpoint to another endpoint or conference = bridge including:

 

* Spatial relationships of cameras, displays, = microphones, and

  speakers in relation to each other and = to likely positions of

  participants

 

* Specific characteristics such as viewpoint, field = of view/capture

  for camera/microphone/display/speaker = so that senders and             =   

  middleboxes can understand how best to = compose streams for

  receivers and the receivers will know = the characteristics of its 

  received streams

 

* Aspect ratio of cameras and = displays

 

Information between sources and sinks about media = stream capabilities will be exchanged. 

 

The working group will define the semantics, = language and transport mechanism necessary for communicating the necessary = information. It will consider whether the existing signaling mechanisms (SDP, BFCP) can = be extended, or another messaging method should be used. =  

 

The scope of the work includes describing = relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and = video streams for the current speaker. The scope includes both systems that = provide a fully immersive experience, and systems that interwork with them and = therefore need to understand the same multiple stream semantics. =  

 

The focus of this work is on multiple audio and = video streams.  Other media types may be considered, however development = of methodologies for them is not within the scope of this = work.

 

Interoperation with standards compliant systems is = required, such as SIP-based video conferencing systems.  However, backwards compatibility with existing non-standards compliant telepresence systems = is not required.

 

This working group is not currently chartered to = work on issues of continuous conference control including: far end camera = control, indication of fast frame update for video codecs or other rapid = switches, floor control, conference roster. Also not in scope is signaling to tell the = originator to which receivers the media streams should be sent.

 

Reuse of existing protocols and backwards = compatibility with existing systems is an important factor for the working group to = consider. The work will closely coordinate with the appropriate areas and working = groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and = SIPCORE.

 

 Milestones  

 

 Nov 2010 Submit information draft to IESG on = use cases and requirements

 

 Nov 2011 Submit standards track specification = to IESG on indicating

          spatial relationships of screens, cameras (including variable

          field of = view and orientation), speakers and microphones. This

          includes, = semantics, language and transport.

 

 Apr 2011 Submit standards track specification = to IESG on indicating the

         =  "usage" of a stream as define in charter.

 

 

 

------_=_NextPart_001_01CB3FD1.3483E26C-- From alex@vidyo.com Fri Aug 20 02:26:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E6B3A6A67 for ; Fri, 20 Aug 2010 02:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uXBSXwPwm1K for ; Fri, 20 Aug 2010 02:26:57 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 916733A6A3F for ; Fri, 20 Aug 2010 02:26:56 -0700 (PDT) Received: from st020.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id AAB8C8BD043; Fri, 20 Aug 2010 05:27:30 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from mx1.myoutlookonline.com (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id B67FC8BD066; Fri, 20 Aug 2010 05:27:29 -0400 (EDT) Received: from BH012.mail.lan ([10.110.21.112]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Aug 2010 05:26:21 -0400 Received: from HUB012.mail.lan ([10.110.17.12]) by BH012.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Aug 2010 05:26:32 -0400 Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Fri, 20 Aug 2010 05:26:21 -0400 From: Alex Eleftheriadis To: "Allyn Romanow (allyn)" Date: Fri, 20 Aug 2010 05:27:27 -0400 Thread-Topic: [dispatch] Updated Telepresence charter Thread-Index: ActAScaAvE767q6nSw2q1BSbsday0w== Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02283D41@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02283D41@xmb-sjc-221.amer.cisco.com> 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_F76652B108EA4B4A8BC7AB7D814FBBF4vidyocom_" MIME-Version: 1.0 X-OriginalArrivalTime: 20 Aug 2010 09:26:32.0764 (UTC) FILETIME=[C71E67C0:01CB4049] Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 09:26:59 -0000 --_000_F76652B108EA4B4A8BC7AB7D814FBBF4vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It looks good, and I will be happy to contribute. I only have a clarificati= on question. Can you elaborate on the sentence: "Also not in scope is signaling to tell = the originator to which receivers the media streams should be sent." Specif= ically, is it within scope for a single receiver to tell the originator whi= ch of the multiple streams should be sent to itself? --Alex On Aug 19, 2010, at 10:03 PM, Allyn Romanow (allyn) wrote: Looks good to me, with Paul=92s improvements. Allyn From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, August 19, 2010 9:42 AM To: DISPATCH Subject: [dispatch] Updated Telepresence charter Per the discussion at IETF-78, an action was taken to update the telepresen= ce charter to be more specific and more tightly scoped. To that end, the u= pdated charter is below. Please review and provide any additional feedback and comments to the list.= In addition, if you think the charter is ready to move forward in terms of= creating a new WG, please respond to the mailing list. In the latter case= , if you could also please let us know (offlist if you'd prefer) if you are= willing to technically contribute to this work, we can guage whether ther= e will be sufficient contributors to support a WG. Best Regards, Mary. DISPATCH WG co-chair =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CLUE ControLling mUltiple streams for TElepresence or MUSCAT: MUlti-Stream Control Applied to Telepresence In the context of this WG, the term telepresence is used in a general manne= r to describe systems that provide high definition, high quality audio enab= ling a "being-there" experience. One example is an immersive telepresence = system using specially designed and special purpose rooms with multiple dis= plays permitting life size image reproduction using multiple cameras, encod= ers, decoders and microphones. Current telepresence systems are based on open standards such as RTP, SIP, = H.264, the H.323 suite, however, they cannot easily interoperate with each = other without operator assistance and expensive additional equipment which = translates from one vendor to another. A major factor in the inability of t= elepresence systems to interwork is that there is no standard description o= f the multiple streams of audio and video that comprise the media flows. I= n addition, there is no standardized way to exchange semantic informatio= n about what each media stream represents. The WG will create specification to enable communication of enough informat= ion about each media stream so that each receiving system or bridge system = can make reasonable decisions about selecting and displaying media streams.= This enables systems to make display choices that optimize the "just like = being there" experience. This working group is chartered to specify the information about media stre= ams from one endpoint to another endpoint or conference bridge including: * Spatial relationships of cameras, displays, microphones, and speakers in relation to each other and to likely positions of participants * Specific characteristics such as viewpoint, field of view/capture for camera/microphone/display/speaker so that senders and middleboxes can understand how best to compose streams for receivers and the receivers will know the characteristics of its received streams * Aspect ratio of cameras and displays Information between sources and sinks about media stream capabilities will = be exchanged. The working group will define the semantics, language and transport mechani= sm necessary for communicating the necessary information. It will consider = whether the existing signaling mechanisms (SDP, BFCP) can be extended, or a= nother messaging method should be used. The scope of the work includes describing relatively static relations betwe= en entities (participants and devices). It also includes handling more dyna= mic relationships, such as identifying the audio and video streams for the = current speaker. The scope includes both systems that provide a fully immer= sive experience, and systems that interwork with them and therefore need to= understand the same multiple stream semantics. The focus of this work is on multiple audio and video streams. Other media= types may be considered, however development of methodologies for them is = not within the scope of this work. Interoperation with standards compliant systems is required, such as SIP-ba= sed video conferencing systems. However, backwards compatibility with exis= ting non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuo= us conference control including: far end camera control, indication of fast= frame update for video codecs or other rapid switches, floor control, conf= erence roster. Also not in scope is signaling to tell the originator to whi= ch receivers the media streams should be sent. Reuse of existing protocols and backwards compatibility with existing syste= ms is an important factor for the working group to consider. The work will = closely coordinate with the appropriate areas and working groups including = OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Milestones Nov 2010 Submit information draft to IESG on use cases and requirements Nov 2011 Submit standards track specification to IESG on indicating spatial relationships of screens, cameras (including variable field of view and orientation), speakers and microphones. This includes, semantics, language and transport. Apr 2011 Submit standards track specification to IESG on indicating the "usage" of a stream as define in charter. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_F76652B108EA4B4A8BC7AB7D814FBBF4vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Also not in scope is signaling to tell = the originator to which receivers the media streams should be sent." Specif= ically, is it within scope for a single receiver to tell the originator whi= ch of the multiple streams should be sent to itself? 

=
Looks good to me, with Paul=92s improvements.
 
Ally= n
 
<= div style=3D"border-right-style: none; border-bottom-style: none; border-le= ft-style: none; border-width: initial; border-color: initial; border-top-st= yle: solid; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; pa= dding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in;= ">
F= rom: dispatch-bounces@ietf.org&nb= sp;[mailto:dispatch-bounces@ietf.org] On Behalf Of&n= bsp;Mary Barnes
Sent: Thursday, August 19, 2010 9:42 AM
To: DISPATCH
Subject: [dispatch] Updated Telepresence= charter
 
Per the disc= ussion at IETF-78, an action was taken to update the telepresence charter t= o be more specific and more tightly scoped.  To that end, the updated = charter is below.  
 
Please review and provide any additional feedback and comments to th= e list. In addition, if you think the charter is ready to move forward in t= erms of creating a new WG, please respond to the mailing list.  In the= latter case, if you could also please let us know (offlist if you'd prefer= ) if you are willing to technically contribute to this work,  we can g= uage whether there will be sufficient contributors to support a WG. 
 
Best Regards,=
Mary.
DISPATCH WG = co-chair
 
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
&n= bsp;
CLUE ControLling mUltiple streams for TEle= presence
or
MUSCAT:= MUlti-Stream Control Applied to Telepresence
<= o:p> 
 
In the= context of this WG, the term telepresence is used in a general manner to d= escribe systems that provide high definition, high quality audio enabling a= "being-there" experience.  One example is an immersive telepresence s= ystem using specially designed and special purpose rooms with multiple disp= lays permitting life size image reproduction using multiple cameras, encode= rs, decoders and microphones. 
&nbs= p;
Current telepresence systems are based on open st= andards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easi= ly interoperate with each other without operator assistance and expensive a= dditional equipment which translates from one vendor to another. A major fa= ctor in the inability of telepresence systems to interwork is that there is= no standard description of the multiple streams of audio and video that co= mprise the media flows.  In addition,  there is  no standard= ized way  to exchange semantic information about what each media strea= m represents.  
 
The WG will create specification to enable communication of enough= information about each media stream so that each receiving system or bridg= e system can make reasonable decisions about selecting and displaying media= streams. This enables systems to make display choices that optimize the "j= ust like being there" experience. 
&n= bsp;
This working group is chartered to specify the = information about media streams from one endpoint to another endpoint or co= nference bridge including:
 
* Spatial relationships of cameras, displays, microphones, a= nd
  speakers in relation to each oth= er and to likely positions of
  parti= cipants
 
* Sp= ecific characteristics such as viewpoint, field of view/capture<= /div>
  for camera/microphone/display/speaker so that = senders and               
  middleboxes can understand how best to comp= ose streams for
  receivers and the r= eceivers will know the characteristics of its 
<= div>
  received streams
 
* Aspect ratio of cameras and displays
 
Information between source= s and sinks about media stream capabilities will be exchanged. 
 
The working group = will define the semantics, language and transport mechanism necessary for c= ommunicating the necessary information. It will consider whether the existi= ng signaling mechanisms (SDP, BFCP) can be extended, or another messaging m= ethod should be used.  
 <= /div>
The scope of the work includes describing relatively stati= c relations between entities (participants and devices). It also includes h= andling more dynamic relationships, such as identifying the audio and video= streams for the current speaker. The scope includes both systems that prov= ide a fully immersive experience, and systems that interwork with them and = therefore need to understand the same multiple stream semantics.  
 
The focus of th= is work is on multiple audio and video streams.  Other media types may= be considered, however development of methodologies for them is not within= the scope of this work.
 
Interoperation with standards compliant systems is required, s= uch as SIP-based video conferencing systems.  However, backwards compa= tibility with existing non-standards compliant telepresence systems is not = required.
 
Th= is working group is not currently chartered to work on issues of continuous= conference control including: far end camera control, indication of fast f= rame update for video codecs or other rapid switches, floor control, confer= ence roster. Also not in scope is signaling to tell the originator to which= receivers the media streams should be sent.
 
Reuse of existing protocols and backwards = compatibility with existing systems is an important factor for the working = group to consider. The work will closely coordinate with the appropriate ar= eas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, an= d SIPCORE.
 
&= nbsp;Milestones  
 
<= /div>
 Nov 2010 Submit information draft to IESG on use cases and= requirements
 
          spatia= l relationships of screens, cameras (including variable
          field of view and orientat= ion), speakers and microphones. This
 &nb= sp;        includes, semantics, language and transport.=
 
 Apr= 2011 Submit standards track specification to IESG on indicating the
          "usage" of a = stream as define in charter.
 <= /div>
 
 
=
_______________________________________________
dispat= ch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --_000_F76652B108EA4B4A8BC7AB7D814FBBF4vidyocom_-- From tme@americafree.tv Fri Aug 20 03:24:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7803A68BD for ; Fri, 20 Aug 2010 03:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwfO1uFa4wWM for ; Fri, 20 Aug 2010 03:24:05 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 00B8D3A67F2 for ; Fri, 20 Aug 2010 03:24:05 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 2E44D880060B; Fri, 20 Aug 2010 06:24:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Marshall Eubanks In-Reply-To: Date: Fri, 20 Aug 2010 06:24:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <90083321-FBB0-44D8-A960-120C814D5D69@americafree.tv> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02283D41@xmb-sjc-221.amer.cisco.com> To: Alex Eleftheriadis X-Mailer: Apple Mail (2.1081) Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 10:24:06 -0000 On Aug 20, 2010, at 5:27 AM, Alex Eleftheriadis wrote: > It looks good, and I will be happy to contribute. I only have a = clarification question.=20 >=20 > Can you elaborate on the sentence: "Also not in scope is signaling to = tell the originator to which receivers the media streams should be = sent." Specifically, is it within scope for a single receiver to tell = the originator which of the multiple streams should be sent to itself?=20= I interpret this as meaning=20 - there are existing, adequate, means to signal the existence and = location of receivers to senders, so such signaling is out of scope. There are _not_ existing, adequate, means to tell which streams of a set = of multiple streams should be sent where, so IMO the answer to your = question is yes, such signaling is within scope.=20 If we want to tweak that text, here is a suggestion : As there are existing, adequate, means to signal the existence and = location of receivers to senders, such signaling is also not in scope. Regards Marshall=20 >=20 > --Alex >=20 >=20 > On Aug 19, 2010, at 10:03 PM, Allyn Romanow (allyn) wrote: >=20 >> Looks good to me, with Paul=92s improvements. >> =20 >> Allyn >> =20 >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Mary Barnes >> Sent: Thursday, August 19, 2010 9:42 AM >> To: DISPATCH >> Subject: [dispatch] Updated Telepresence charter >> =20 >> Per the discussion at IETF-78, an action was taken to update the = telepresence charter to be more specific and more tightly scoped. To = that end, the updated charter is below. =20 >> =20 >> Please review and provide any additional feedback and comments to the = list. In addition, if you think the charter is ready to move forward in = terms of creating a new WG, please respond to the mailing list. In the = latter case, if you could also please let us know (offlist if you'd = prefer) if you are willing to technically contribute to this work, we = can guage whether there will be sufficient contributors to support a WG.=20= >> =20 >> Best Regards, >> Mary. >> DISPATCH WG co-chair >> =20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> CLUE ControLling mUltiple streams for TElepresence >> or >> MUSCAT: MUlti-Stream Control Applied to Telepresence >> =20 >> =20 >> In the context of this WG, the term telepresence is used in a general = manner to describe systems that provide high definition, high quality = audio enabling a "being-there" experience. One example is an immersive = telepresence system using specially designed and special purpose rooms = with multiple displays permitting life size image reproduction using = multiple cameras, encoders, decoders and microphones.=20 >> =20 >> Current telepresence systems are based on open standards such as RTP, = SIP, H.264, the H.323 suite, however, they cannot easily interoperate = with each other without operator assistance and expensive additional = equipment which translates from one vendor to another. A major factor in = the inability of telepresence systems to interwork is that there is no = standard description of the multiple streams of audio and video that = comprise the media flows. In addition, there is no standardized way = to exchange semantic information about what each media stream = represents. =20 >> =20 >> The WG will create specification to enable communication of enough = information about each media stream so that each receiving system or = bridge system can make reasonable decisions about selecting and = displaying media streams. This enables systems to make display choices = that optimize the "just like being there" experience.=20 >> =20 >> This working group is chartered to specify the information about = media streams from one endpoint to another endpoint or conference bridge = including: >> =20 >> * Spatial relationships of cameras, displays, microphones, and >> speakers in relation to each other and to likely positions of >> participants >> =20 >> * Specific characteristics such as viewpoint, field of view/capture >> for camera/microphone/display/speaker so that senders and = =20 >> middleboxes can understand how best to compose streams for >> receivers and the receivers will know the characteristics of its=20 >> received streams >> =20 >> * Aspect ratio of cameras and displays >> =20 >> Information between sources and sinks about media stream capabilities = will be exchanged.=20 >> =20 >> The working group will define the semantics, language and transport = mechanism necessary for communicating the necessary information. It will = consider whether the existing signaling mechanisms (SDP, BFCP) can be = extended, or another messaging method should be used. =20 >> =20 >> The scope of the work includes describing relatively static relations = between entities (participants and devices). It also includes handling = more dynamic relationships, such as identifying the audio and video = streams for the current speaker. The scope includes both systems that = provide a fully immersive experience, and systems that interwork with = them and therefore need to understand the same multiple stream = semantics. =20 >> =20 >> The focus of this work is on multiple audio and video streams. Other = media types may be considered, however development of methodologies for = them is not within the scope of this work. >> =20 >> Interoperation with standards compliant systems is required, such as = SIP-based video conferencing systems. However, backwards compatibility = with existing non-standards compliant telepresence systems is not = required. >> =20 >> This working group is not currently chartered to work on issues of = continuous conference control including: far end camera control, = indication of fast frame update for video codecs or other rapid = switches, floor control, conference roster. Also not in scope is = signaling to tell the originator to which receivers the media streams = should be sent. >> =20 >> Reuse of existing protocols and backwards compatibility with existing = systems is an important factor for the working group to consider. The = work will closely coordinate with the appropriate areas and working = groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. >> =20 >> Milestones =20 >> =20 >> Nov 2010 Submit information draft to IESG on use cases and = requirements >> =20 >> Nov 2011 Submit standards track specification to IESG on indicating >> spatial relationships of screens, cameras (including = variable >> field of view and orientation), speakers and microphones. = This >> includes, semantics, language and transport. >> =20 >> Apr 2011 Submit standards track specification to IESG on indicating = the >> "usage" of a stream as define in charter. >> =20 >> =20 >> =20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From stephen.botzko@gmail.com Fri Aug 20 03:38:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F48C3A67F2 for ; Fri, 20 Aug 2010 03:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BtgVYTHvG0n for ; Fri, 20 Aug 2010 03:37:53 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 2DA5C3A6A75 for ; Fri, 20 Aug 2010 03:35:53 -0700 (PDT) Received: by qyk9 with SMTP id 9so2937067qyk.10 for ; Fri, 20 Aug 2010 03:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=M3AQz09SKtK/o1in8Df8QzAlET/j/H9tX3DPuJa2kxg=; b=eh1vBBpNNgbiTJ0h04qyaZsetYDGAucx31SBEPAGYILzscYKTSarm9dQyb6o+feTdy CnayXtdxvrL1F4/EuZFiHn+qW7Fc5VTmAAhGAwUCTjJESsjnb4StctlBjRkMFB6RN9kX eUEJju3VRylUl6HwcPQR7hfn6ySSHD0WcO5vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wmztv993azFoHDr53gZZyO7GPSedT9NDOzT8DJFBDWbroh3xQlIxvRtHeO1RoIXNoy 4qsoJyILIS/m3lK101fTiUwn/sA9DdbBwK+FVVtT9caJbIPU70yMLUUwB/IWyPwIJAcP CmUaxyFco8f1icQ6nPej4KAOp+c9xN2Q//K4o= MIME-Version: 1.0 Received: by 10.229.51.214 with SMTP id e22mr113466qcg.233.1282300508659; Fri, 20 Aug 2010 03:35:08 -0700 (PDT) Received: by 10.229.31.138 with HTTP; Fri, 20 Aug 2010 03:35:08 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02283D41@xmb-sjc-221.amer.cisco.com> Date: Fri, 20 Aug 2010 06:35:08 -0400 Message-ID: From: stephen botzko To: Alex Eleftheriadis Content-Type: multipart/alternative; boundary=0016367d5c10506310048e3eda5e Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 10:38:00 -0000 --0016367d5c10506310048e3eda5e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>> Specifically, is it within scope for a single receiver to tell the originator which of the multiple streams should be sent to itself? >>> I think this needs to be in scope. It looks to me like the intent of the sentence is to exclude signaling identifying which receivers are in the conference. IMHO it should not exclude signaling on which media streams should be sent to a given receiver= . --Stephen Botzko On Fri, Aug 20, 2010 at 5:27 AM, Alex Eleftheriadis wrote: > It looks good, and I will be happy to contribute. I only have a > clarification question. > > Can you elaborate on the sentence: "Also not in scope is signaling to tel= l > the originator to which receivers the media streams should be sent." > Specifically, is it within scope for a single receiver to tell the > originator which of the multiple streams should be sent to itself? > > --Alex > > > On Aug 19, 2010, at 10:03 PM, Allyn Romanow (allyn) wrote: > > Looks good to me, with Paul=92s improvements. > > Allyn > > *From:* dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] *On > Behalf Of *Mary Barnes > *Sent:* Thursday, August 19, 2010 9:42 AM > *To:* DISPATCH > *Subject:* [dispatch] Updated Telepresence charter > > Per the discussion at IETF-78, an action was taken to update the > telepresence charter to be more specific and more tightly scoped. To tha= t > end, the updated charter is below. > > Please review and provide any additional feedback and comments to the lis= t. > In addition, if you think the charter is ready to move forward in terms o= f > creating a new WG, please respond to the mailing list. In the latter cas= e, > if you could also please let us know (offlist if you'd prefer) if you are > willing to technically contribute to this work, we can guage whether the= re > will be sufficient contributors to support a WG. > > Best Regards, > Mary. > DISPATCH WG co-chair > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > CLUE ControLling mUltiple streams for TElepresence > or > MUSCAT: MUlti-Stream Control Applied to Telepresence > > > In the context of this WG, the term telepresence is used in a general > manner to describe systems that provide high definition, high quality aud= io > enabling a "being-there" experience. One example is an immersive > telepresence system using specially designed and special purpose rooms wi= th > multiple displays permitting life size image reproduction using multiple > cameras, encoders, decoders and microphones. > > Current telepresence systems are based on open standards such as RTP, SIP= , > H.264, the H.323 suite, however, they cannot easily interoperate with eac= h > other without operator assistance and expensive additional equipment whic= h > translates from one vendor to another. A major factor in the inability of > telepresence systems to interwork is that there is no standard descriptio= n > of the multiple streams of audio and video that comprise the media flows. > In addition, there is no standardized way to exchange semantic > information about what each media stream represents. > > The WG will create specification to enable communication of enough > information about each media stream so that each receiving system or brid= ge > system can make reasonable decisions about selecting and displaying media > streams. This enables systems to make display choices that optimize the > "just like being there" experience. > > This working group is chartered to specify the information about media > streams from one endpoint to another endpoint or conference bridge > including: > > * Spatial relationships of cameras, displays, microphones, and > speakers in relation to each other and to likely positions of > participants > > * Specific characteristics such as viewpoint, field of view/capture > for camera/microphone/display/speaker so that senders and > middleboxes can understand how best to compose streams for > receivers and the receivers will know the characteristics of its > received streams > > * Aspect ratio of cameras and displays > > Information between sources and sinks about media stream capabilities wil= l > be exchanged. > > The working group will define the semantics, language and transport > mechanism necessary for communicating the necessary information. It will > consider whether the existing signaling mechanisms (SDP, BFCP) can be > extended, or another messaging method should be used. > > The scope of the work includes describing relatively static relations > between entities (participants and devices). It also includes handling mo= re > dynamic relationships, such as identifying the audio and video streams fo= r > the current speaker. The scope includes both systems that provide a fully > immersive experience, and systems that interwork with them and therefore > need to understand the same multiple stream semantics. > > The focus of this work is on multiple audio and video streams. Other med= ia > types may be considered, however development of methodologies for them is > not within the scope of this work. > > Interoperation with standards compliant systems is required, such as > SIP-based video conferencing systems. However, backwards compatibility w= ith > existing non-standards compliant telepresence systems is not required. > > This working group is not currently chartered to work on issues of > continuous conference control including: far end camera control, indicati= on > of fast frame update for video codecs or other rapid switches, floor > control, conference roster. Also not in scope is signaling to tell the > originator to which receivers the media streams should be sent. > > Reuse of existing protocols and backwards compatibility with existing > systems is an important factor for the working group to consider. The wor= k > will closely coordinate with the appropriate areas and working groups > including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. > > Milestones > > Nov 2010 Submit information draft to IESG on use cases and requirements > > Nov 2011 Submit standards track specification to IESG on indicating > spatial relationships of screens, cameras (including variable > field of view and orientation), speakers and microphones. This > includes, semantics, language and transport. > > Apr 2011 Submit standards track specification to IESG on indicating the > "usage" of a stream as define in charter. > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --0016367d5c10506310048e3eda5e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>>
=20 Specifically, is it within scope for a single receiver to tell the=20 originator which of the multiple streams should be sent to itself?
>= >>
I think this needs to be in scope.

It looks to me like t= he intent of the sentence is to exclude signaling identifying which receive= rs are in the conference.=A0 IMHO it should not exclude signaling on which = media streams should be sent to a given receiver.

--Stephen Botzko


On Fri, A= ug 20, 2010 at 5:27 AM, Alex Eleftheriadis <alex@vidyo.com> wrote:
It looks good, and I will be happy to= contribute.=A0I only have a clarification question.=A0

=
Can you elaborate on the sentence: "Also not in scope is sign= aling to tell the originator to which receivers the media streams should be= sent." Specifically, is it within scope for a single receiver to tell= the originator which of the multiple streams should be sent to itself?=A0<= /span>

--Alex<= br>


On Aug 19, 2= 010, at 10:03 PM, Allyn Romanow (allyn) wrote:

Looks good to me, with Paul=92s improvements.
=A0
Allyn
=A0
From:=A0dispatch-bounces@ietf.org=A0[mailto:dispatch-bounces@ietf.org]=A0On Behalf Of=A0Mary Barnes
Sent:=A0Thursday, August 19, 2010 9:42 AM
To:= =A0DISPATCH
Subject:=A0[dispatch] Updat= ed Telepresence charter
=A0
Per the discussion at IETF-78, an act= ion was taken to update the telepresence charter to be more specific and mo= re tightly scoped. =A0To that end, the updated charter is below. =A0
=A0
Please review and provide any additional feedback and comments to the list.= In addition, if you think the charter is ready to move forward in terms of= creating a new WG, please respond to the mailing list. =A0In the latter ca= se, if you could also please let us know (offlist if you'd prefer) if y= ou are willing to technically contribute to this work, =A0we can guage whet= her there will be sufficient contributors to support a WG.=A0
=A0
Best Regards,
Mary.
DISPATCH WG co-chair
=A0
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0
CLUE ControLling mUltiple streams for TElepresence
or
MUSCAT: MUlti-Stream Control Applied to Telepresence
=A0
=A0
In the context of this WG,= the term telepresence is used in a general manner to describe systems that= provide high definition, high quality audio enabling a "being-there&q= uot; experience. =A0One example is an immersive telepresence system using s= pecially designed and special purpose rooms with multiple displays permitti= ng life size image reproduction using multiple cameras, encoders, decoders = and microphones.=A0
=A0
Current telepresence systems are based on open standards such as RTP, SIP, = H.264, the H.323 suite, however, they cannot easily interoperate with each = other without operator assistance and expensive additional equipment which = translates from one vendor to another. A major factor in the inability of t= elepresence systems to interwork is that there is no standard description o= f the multiple streams of audio and video that comprise the media flows. = =A0In addition, =A0there is =A0no standardized way =A0to exchange semantic = information about what each media stream represents. =A0
=A0
The WG will create specification to enable communication of enough informat= ion about each media stream so that each receiving system or bridge system = can make reasonable decisions about selecting and displaying media streams.= This enables systems to make display choices that optimize the "just = like being there" experience.=A0
=A0
This working group is chartered to specify the information about media stre= ams from one endpoint to another endpoint or conference bridge including:
=A0
* Spatial relationships of= cameras, displays, microphones, and
=A0=A0speakers in relation to each other and to likely positions of
=A0=A0participants
=A0
* Specific characteristics= such as viewpoint, field of view/capture
=A0=A0for camera/microphone/display/speaker so that senders and =A0 =A0 =A0= =A0 =A0 =A0 =A0=A0
=A0=A0midd= leboxes can understand how best to compose streams for
=A0=A0receivers and the receivers w= ill know the characteristics of its=A0
=A0=A0received streams
=A0
* Aspect ratio of cameras and displays
=A0
Information between sources and sinks about media stream capabilities will = be exchanged.=A0
=A0
The working group will define the semanti= cs, language and transport mechanism necessary for communicating the necess= ary information. It will consider whether the existing signaling mechanisms= (SDP, BFCP) can be extended, or another messaging method should be used. = =A0
=A0
The scope of the work includes describing relatively static relations betwe= en entities (participants and devices). It also includes handling more dyna= mic relationships, such as identifying the audio and video streams for the = current speaker. The scope includes both systems that provide a fully immer= sive experience, and systems that interwork with them and therefore need to= understand the same multiple stream semantics. =A0
=A0
The focus of this work is on multiple audio and video streams. =A0Other med= ia types may be considered, however development of methodologies for them i= s not within the scope of this work.
=A0
Interoperation with standa= rds compliant systems is required, such as SIP-based video conferencing sys= tems. =A0However, backwards compatibility with existing non-standards compl= iant telepresence systems is not required.
=A0
This working group is not currently chartered to work on issues of continuo= us conference control including: far end camera control, indication of fast= frame update for video codecs or other rapid switches, floor control, conf= erence roster. Also not in scope is signaling to tell the originator to whi= ch receivers the media streams should be sent.
=A0
Reuse of existing protocols and backwards compatibility with existing syste= ms is an important factor for the working group to consider. The work will = closely coordinate with the appropriate areas and working groups including = OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE.
=A0
=A0Milestones =A0
=A0
=A0Nov 2010 Submit information draft to IESG on use cases and requirements<= /div>
=A0
=A0Nov 2011 Submit standards track specification to IESG on indicating
=A0=A0 =A0 =A0 =A0 =A0spatial rela= tionships of screens, cameras (including variable
=A0=A0 =A0 =A0 =A0 =A0field of view= and orientation), speakers and microphones. This
=A0=A0 =A0 =A0 =A0 =A0includes, semantics, language and transport.
=A0
=A0Apr 2011 Submit standards track specification to IESG on indicating the<= /div>
=A0=A0 =A0 =A0 =A0 =A0"us= age" of a stream as define in charter.
=A0
=A0
=A0
____________________________________________= ___
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch


_____= __________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--0016367d5c10506310048e3eda5e-- From peter.musgrave@magorcorp.com Fri Aug 20 03:41:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE79A3A690A for ; Fri, 20 Aug 2010 03:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.713 X-Spam-Level: X-Spam-Status: No, score=-101.713 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOAIuzJhoFuR for ; Fri, 20 Aug 2010 03:41:31 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 542403A68EC for ; Fri, 20 Aug 2010 03:41:31 -0700 (PDT) Received: by qwc9 with SMTP id 9so3031639qwc.31 for ; Fri, 20 Aug 2010 03:42:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.235.65 with SMTP id kf1mr924666qcb.42.1282300925695; Fri, 20 Aug 2010 03:42:05 -0700 (PDT) Received: by 10.229.219.8 with HTTP; Fri, 20 Aug 2010 03:42:05 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02283D41@xmb-sjc-221.amer.cisco.com> Date: Fri, 20 Aug 2010 06:42:05 -0400 Message-ID: From: Peter Musgrave To: stephen botzko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 10:41:32 -0000 Not to go too far down the rat-hole here - but I would assume this could be done simply with a reINVITE with new SDP which indicated what IP:port the stream should go to (and sending inactive to the streams it does not want to receive). I do not see this as requiring specific work from the new WG - existing SIP signalling will meet this need. Peter Musgrave On Fri, Aug 20, 2010 at 6:35 AM, stephen botzko wrote: >>>> > Specifically, is it within scope for a single receiver to tell the > originator which of the multiple streams should be sent to itself? >>>> > I think this needs to be in scope. > > It looks to me like the intent of the sentence is to exclude signaling > identifying which receivers are in the conference.=A0 IMHO it should not > exclude signaling on which media streams should be sent to a given receiv= er. > > --Stephen Botzko > > > On Fri, Aug 20, 2010 at 5:27 AM, Alex Eleftheriadis wrot= e: >> >> It looks good, and I will be happy to contribute.=A0I only have a >> clarification question. >> Can you elaborate on the sentence: "Also not in scope is signaling to te= ll >> the originator to which receivers the media streams should be sent." >> Specifically, is it within scope for a single receiver to tell the >> originator which of the multiple streams should be sent to itself? >> --Alex >> >> >> On Aug 19, 2010, at 10:03 PM, Allyn Romanow (allyn) wrote: >> >> Looks good to me, with Paul=92s improvements. >> >> Allyn >> >> From:=A0dispatch-bounces@ietf.org=A0[mailto:dispatch-bounces@ietf.org]= =A0On >> Behalf Of=A0Mary Barnes >> Sent:=A0Thursday, August 19, 2010 9:42 AM >> To:=A0DISPATCH >> Subject:=A0[dispatch] Updated Telepresence charter >> >> Per the discussion at IETF-78, an action was taken to update the >> telepresence charter to be more specific and more tightly scoped. =A0To = that >> end, the updated charter is below. >> >> Please review and provide any additional feedback and comments to the >> list. In addition, if you think the charter is ready to move forward in >> terms of creating a new WG, please respond to the mailing list. =A0In th= e >> latter case, if you could also please let us know (offlist if you'd pref= er) >> if you are willing to technically contribute to this work, =A0we can gua= ge >> whether there will be sufficient contributors to support a WG. >> >> Best Regards, >> Mary. >> DISPATCH WG co-chair >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> CLUE ControLling mUltiple streams for TElepresence >> or >> MUSCAT: MUlti-Stream Control Applied to Telepresence >> >> >> In the context of this WG, the term telepresence is used in a general >> manner to describe systems that provide high definition, high quality au= dio >> enabling a "being-there" experience. =A0One example is an immersive >> telepresence system using specially designed and special purpose rooms w= ith >> multiple displays permitting life size image reproduction using multiple >> cameras, encoders, decoders and microphones. >> >> Current telepresence systems are based on open standards such as RTP, SI= P, >> H.264, the H.323 suite, however, they cannot easily interoperate with ea= ch >> other without operator assistance and expensive additional equipment whi= ch >> translates from one vendor to another. A major factor in the inability o= f >> telepresence systems to interwork is that there is no standard descripti= on >> of the multiple streams of audio and video that comprise the media flows= . >> =A0In addition, =A0there is =A0no standardized way =A0to exchange semant= ic >> information about what each media stream represents. >> >> The WG will create specification to enable communication of enough >> information about each media stream so that each receiving system or bri= dge >> system can make reasonable decisions about selecting and displaying medi= a >> streams. This enables systems to make display choices that optimize the >> "just like being there" experience. >> >> This working group is chartered to specify the information about media >> streams from one endpoint to another endpoint or conference bridge >> including: >> >> * Spatial relationships of cameras, displays, microphones, and >> =A0=A0speakers in relation to each other and to likely positions of >> =A0=A0participants >> >> * Specific characteristics such as viewpoint, field of view/capture >> =A0=A0for camera/microphone/display/speaker so that senders and >> =A0=A0middleboxes can understand how best to compose streams for >> =A0=A0receivers and the receivers will know the characteristics of its >> =A0=A0received streams >> >> * Aspect ratio of cameras and displays >> >> Information between sources and sinks about media stream capabilities wi= ll >> be exchanged. >> >> The working group will define the semantics, language and transport >> mechanism necessary for communicating the necessary information. It will >> consider whether the existing signaling mechanisms (SDP, BFCP) can be >> extended, or another messaging method should be used. >> >> The scope of the work includes describing relatively static relations >> between entities (participants and devices). It also includes handling m= ore >> dynamic relationships, such as identifying the audio and video streams f= or >> the current speaker. The scope includes both systems that provide a full= y >> immersive experience, and systems that interwork with them and therefore >> need to understand the same multiple stream semantics. >> >> The focus of this work is on multiple audio and video streams. =A0Other >> media types may be considered, however development of methodologies for = them >> is not within the scope of this work. >> >> Interoperation with standards compliant systems is required, such as >> SIP-based video conferencing systems. =A0However, backwards compatibilit= y with >> existing non-standards compliant telepresence systems is not required. >> >> This working group is not currently chartered to work on issues of >> continuous conference control including: far end camera control, indicat= ion >> of fast frame update for video codecs or other rapid switches, floor >> control, conference roster. Also not in scope is signaling to tell the >> originator to which receivers the media streams should be sent. >> >> Reuse of existing protocols and backwards compatibility with existing >> systems is an important factor for the working group to consider. The wo= rk >> will closely coordinate with the appropriate areas and working groups >> including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. >> >> =A0Milestones >> >> =A0Nov 2010 Submit information draft to IESG on use cases and requiremen= ts >> >> =A0Nov 2011 Submit standards track specification to IESG on indicating >> =A0=A0 =A0 =A0 =A0 =A0spatial relationships of screens, cameras (includi= ng variable >> =A0=A0 =A0 =A0 =A0 =A0field of view and orientation), speakers and micro= phones. This >> =A0=A0 =A0 =A0 =A0 =A0includes, semantics, language and transport. >> >> =A0Apr 2011 Submit standards track specification to IESG on indicating t= he >> =A0=A0 =A0 =A0 =A0 =A0"usage" of a stream as define in charter. >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From stephen.botzko@gmail.com Fri Aug 20 04:02:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8421B3A6A77 for ; Fri, 20 Aug 2010 04:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMIB1b48S23H for ; Fri, 20 Aug 2010 04:02:46 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 2AA363A6A75 for ; Fri, 20 Aug 2010 04:02:46 -0700 (PDT) Received: by qyk9 with SMTP id 9so2964226qyk.10 for ; Fri, 20 Aug 2010 04:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=N9vst0ibUL5sW177yVQ4mA+hN95MFzo23zcUhyvT1GE=; b=otDsChS/dlE+lIxrrYZMch5BqMtKmjwk8vcoL+jjW+j3zzSKLBbYA9A3S1B9Ccrnoq a53bsgyqvxnJcjayc1kXeaBWasgNB3RIFHaU0LvLx5SqWPUCCBzH6huVC6To9D9xr5RE OlEiGmt61vNpSfMkSsnazk4nHbqtIMYC0dPvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SQ7auj+YzHs9+DcHuVq/RgrqAPGjlKeA8EIXcGveFpX439PX5BtRPyRE0y9PvNbvqo 2tKB9qsuvWRFodkLHCNnMTRvPbSN2GKLW70vaGVRGgHa6RmGc6MuX5DTO+gT+95P1BHL ultgMTh/oqrBMc9faoQ5EDxdw5uffSeCroMVE= MIME-Version: 1.0 Received: by 10.224.103.204 with SMTP id l12mr779287qao.351.1282302200571; Fri, 20 Aug 2010 04:03:20 -0700 (PDT) Received: by 10.229.31.138 with HTTP; Fri, 20 Aug 2010 04:03:20 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02283D41@xmb-sjc-221.amer.cisco.com> Date: Fri, 20 Aug 2010 07:03:20 -0400 Message-ID: From: stephen botzko To: Peter Musgrave Content-Type: multipart/alternative; boundary=00163630f7b728e80b048e3f3f7b Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 11:02:48 -0000 --00163630f7b728e80b048e3f3f7b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What if the receiver wants to tell the sender that it should receive the video stream of whomever is speaking? The desired behavior is that if a 3-screen system is sending video stream X= , and someone at that site speaks (but is sent on Video Stream Y), then video stream Y would automatically be forwarded to the receiver instead of X. That cannot be done easily with a reINVITE (at least not w/o incurring at least a RTT delay). Another complication with this scenario - even if you are willing to accept the RTT delay, in the multipoint case the various receivers will be doing the reINVITE at different times. Each reINVITE forces an intra video refresh, which will result in visible artifacts for all receivers for several seconds. -- Stephen Botzko On Fri, Aug 20, 2010 at 6:42 AM, Peter Musgrave < peter.musgrave@magorcorp.com> wrote: > Not to go too far down the rat-hole here - but I would assume this > could be done simply with a reINVITE with new SDP which indicated what > IP:port the stream should go to (and sending inactive to the streams > it does not want to receive). > > I do not see this as requiring specific work from the new WG - > existing SIP signalling will meet this need. > > Peter Musgrave > > On Fri, Aug 20, 2010 at 6:35 AM, stephen botzko > wrote: > >>>> > > Specifically, is it within scope for a single receiver to tell the > > originator which of the multiple streams should be sent to itself? > >>>> > > I think this needs to be in scope. > > > > It looks to me like the intent of the sentence is to exclude signaling > > identifying which receivers are in the conference. IMHO it should not > > exclude signaling on which media streams should be sent to a given > receiver. > > > > --Stephen Botzko > > > > > > On Fri, Aug 20, 2010 at 5:27 AM, Alex Eleftheriadis > wrote: > >> > >> It looks good, and I will be happy to contribute. I only have a > >> clarification question. > >> Can you elaborate on the sentence: "Also not in scope is signaling to > tell > >> the originator to which receivers the media streams should be sent." > >> Specifically, is it within scope for a single receiver to tell the > >> originator which of the multiple streams should be sent to itself? > >> --Alex > >> > >> > >> On Aug 19, 2010, at 10:03 PM, Allyn Romanow (allyn) wrote: > >> > >> Looks good to me, with Paul=92s improvements. > >> > >> Allyn > >> > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Mary Barnes > >> Sent: Thursday, August 19, 2010 9:42 AM > >> To: DISPATCH > >> Subject: [dispatch] Updated Telepresence charter > >> > >> Per the discussion at IETF-78, an action was taken to update the > >> telepresence charter to be more specific and more tightly scoped. To > that > >> end, the updated charter is below. > >> > >> Please review and provide any additional feedback and comments to the > >> list. In addition, if you think the charter is ready to move forward i= n > >> terms of creating a new WG, please respond to the mailing list. In th= e > >> latter case, if you could also please let us know (offlist if you'd > prefer) > >> if you are willing to technically contribute to this work, we can gua= ge > >> whether there will be sufficient contributors to support a WG. > >> > >> Best Regards, > >> Mary. > >> DISPATCH WG co-chair > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> CLUE ControLling mUltiple streams for TElepresence > >> or > >> MUSCAT: MUlti-Stream Control Applied to Telepresence > >> > >> > >> In the context of this WG, the term telepresence is used in a general > >> manner to describe systems that provide high definition, high quality > audio > >> enabling a "being-there" experience. One example is an immersive > >> telepresence system using specially designed and special purpose rooms > with > >> multiple displays permitting life size image reproduction using multip= le > >> cameras, encoders, decoders and microphones. > >> > >> Current telepresence systems are based on open standards such as RTP, > SIP, > >> H.264, the H.323 suite, however, they cannot easily interoperate with > each > >> other without operator assistance and expensive additional equipment > which > >> translates from one vendor to another. A major factor in the inability > of > >> telepresence systems to interwork is that there is no standard > description > >> of the multiple streams of audio and video that comprise the media > flows. > >> In addition, there is no standardized way to exchange semantic > >> information about what each media stream represents. > >> > >> The WG will create specification to enable communication of enough > >> information about each media stream so that each receiving system or > bridge > >> system can make reasonable decisions about selecting and displaying > media > >> streams. This enables systems to make display choices that optimize th= e > >> "just like being there" experience. > >> > >> This working group is chartered to specify the information about media > >> streams from one endpoint to another endpoint or conference bridge > >> including: > >> > >> * Spatial relationships of cameras, displays, microphones, and > >> speakers in relation to each other and to likely positions of > >> participants > >> > >> * Specific characteristics such as viewpoint, field of view/capture > >> for camera/microphone/display/speaker so that senders and > >> middleboxes can understand how best to compose streams for > >> receivers and the receivers will know the characteristics of its > >> received streams > >> > >> * Aspect ratio of cameras and displays > >> > >> Information between sources and sinks about media stream capabilities > will > >> be exchanged. > >> > >> The working group will define the semantics, language and transport > >> mechanism necessary for communicating the necessary information. It wi= ll > >> consider whether the existing signaling mechanisms (SDP, BFCP) can be > >> extended, or another messaging method should be used. > >> > >> The scope of the work includes describing relatively static relations > >> between entities (participants and devices). It also includes handling > more > >> dynamic relationships, such as identifying the audio and video streams > for > >> the current speaker. The scope includes both systems that provide a > fully > >> immersive experience, and systems that interwork with them and therefo= re > >> need to understand the same multiple stream semantics. > >> > >> The focus of this work is on multiple audio and video streams. Other > >> media types may be considered, however development of methodologies fo= r > them > >> is not within the scope of this work. > >> > >> Interoperation with standards compliant systems is required, such as > >> SIP-based video conferencing systems. However, backwards compatibilit= y > with > >> existing non-standards compliant telepresence systems is not required. > >> > >> This working group is not currently chartered to work on issues of > >> continuous conference control including: far end camera control, > indication > >> of fast frame update for video codecs or other rapid switches, floor > >> control, conference roster. Also not in scope is signaling to tell the > >> originator to which receivers the media streams should be sent. > >> > >> Reuse of existing protocols and backwards compatibility with existing > >> systems is an important factor for the working group to consider. The > work > >> will closely coordinate with the appropriate areas and working groups > >> including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. > >> > >> Milestones > >> > >> Nov 2010 Submit information draft to IESG on use cases and requiremen= ts > >> > >> Nov 2011 Submit standards track specification to IESG on indicating > >> spatial relationships of screens, cameras (including variabl= e > >> field of view and orientation), speakers and microphones. Th= is > >> includes, semantics, language and transport. > >> > >> Apr 2011 Submit standards track specification to IESG on indicating t= he > >> "usage" of a stream as define in charter. > >> > >> > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > --00163630f7b728e80b048e3f3f7b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What if the receiver wants to tell the sender that it should receive the vi= deo stream of whomever is speaking?=A0

The desired behavior is that= if a 3-screen system is sending video stream X, and someone at that site s= peaks (but is sent on Video Stream Y), then video stream Y would automatica= lly be forwarded to the receiver instead of X.

That cannot be done easily with a reINVITE (at least not w/o incurring = at least a RTT delay).=A0

Another complication with this scenario -= even if you are willing to accept the RTT delay, in the multipoint case th= e various receivers will be doing the reINVITE at different times.=A0 Each = reINVITE forces an intra video refresh, which will result in visible artifa= cts for all receivers for several seconds.

-- Stephen Botzko

On Fri, Aug 20, 201= 0 at 6:42 AM, Peter Musgrave <peter.musgrave@magorcorp.com> wrote:<= br>
Not to go too far= down the rat-hole here - but I would assume this
could be done simply with a reINVITE with new SDP which indicated what
IP:port the stream should go to (and sending inactive to the streams
it does not want to receive).

I do not see this as requiring specific work from the new WG -
existing SIP signalling will meet this need.

Peter Musgrave

On Fri, Aug 20, 2010 at 6:35 AM, stephen botzko
<stephen.botzko@gmail.com> wrote:
>>>>
> Specifically, is it within scope for a single receiver to tell the
> originator which of the multiple streams should be sent to itself?
>>>>
> I think this needs to be in scope.
>
> It looks to me like the intent of the sentence is to exclude signaling=
> identifying which receivers are in the conference.=A0 IMHO it should n= ot
> exclude signaling on which media streams should be sent to a given rec= eiver.
>
> --Stephen Botzko
>
>
> On Fri, Aug 20, 2010 at 5:27 AM, Alex Eleftheriadis <alex@vidyo.com> wrote:
>>
>> It looks good, and I will be happy to contribute.=A0I only have a<= br> >> clarification question.
>> Can you elaborate on the sentence: "Also not in scope is sign= aling to tell
>> the originator to which receivers the media streams should be sent= ."
>> Specifically, is it within scope for a single receiver to tell the=
>> originator which of the multiple streams should be sent to itself?=
>> --Alex
>>
>>
>> On Aug 19, 2010, at 10:03 PM, Allyn Romanow (allyn) wrote:
>>
>> Looks good to me, with Paul=92s improvements.
>>
>> Allyn
>>
>> From:=A0dispatch-boun= ces@ietf.org=A0[mailto:dis= patch-bounces@ietf.org]=A0On
>> Behalf Of=A0Mary Barnes
>> Sent:=A0Thursday, August 19, 2010 9:42 AM
>> To:=A0DISPATCH
>> Subject:=A0[dispatch] Updated Telepresence charter
>>
>> Per the discussion at IETF-78, an action was taken to update the >> telepresence charter to be more specific and more tightly scoped. = =A0To that
>> end, the updated charter is below.
>>
>> Please review and provide any additional feedback and comments to = the
>> list. In addition, if you think the charter is ready to move forwa= rd in
>> terms of creating a new WG, please respond to the mailing list. = =A0In the
>> latter case, if you could also please let us know (offlist if you&= #39;d prefer)
>> if you are willing to technically contribute to this work, =A0we c= an guage
>> whether there will be sufficient contributors to support a WG.
>>
>> Best Regards,
>> Mary.
>> DISPATCH WG co-chair
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> CLUE ControLling mUltiple streams for TElepresence
>> or
>> MUSCAT: MUlti-Stream Control Applied to Telepresence
>>
>>
>> In the context of this WG, the term telepresence is used in a gene= ral
>> manner to describe systems that provide high definition, high qual= ity audio
>> enabling a "being-there" experience. =A0One example is a= n immersive
>> telepresence system using specially designed and special purpose r= ooms with
>> multiple displays permitting life size image reproduction using mu= ltiple
>> cameras, encoders, decoders and microphones.
>>
>> Current telepresence systems are based on open standards such as R= TP, SIP,
>> H.264, the H.323 suite, however, they cannot easily interoperate w= ith each
>> other without operator assistance and expensive additional equipme= nt which
>> translates from one vendor to another. A major factor in the inabi= lity of
>> telepresence systems to interwork is that there is no standard des= cription
>> of the multiple streams of audio and video that comprise the media= flows.
>> =A0In addition, =A0there is =A0no standardized way =A0to exchange = semantic
>> information about what each media stream represents.
>>
>> The WG will create specification to enable communication of enough=
>> information about each media stream so that each receiving system = or bridge
>> system can make reasonable decisions about selecting and displayin= g media
>> streams. This enables systems to make display choices that optimiz= e the
>> "just like being there" experience.
>>
>> This working group is chartered to specify the information about m= edia
>> streams from one endpoint to another endpoint or conference bridge=
>> including:
>>
>> * Spatial relationships of cameras, displays, microphones, and
>> =A0=A0speakers in relation to each other and to likely positions o= f
>> =A0=A0participants
>>
>> * Specific characteristics such as viewpoint, field of view/captur= e
>> =A0=A0for camera/microphone/display/speaker so that senders and >> =A0=A0middleboxes can understand how best to compose streams for >> =A0=A0receivers and the receivers will know the characteristics of= its
>> =A0=A0received streams
>>
>> * Aspect ratio of cameras and displays
>>
>> Information between sources and sinks about media stream capabilit= ies will
>> be exchanged.
>>
>> The working group will define the semantics, language and transpor= t
>> mechanism necessary for communicating the necessary information. I= t will
>> consider whether the existing signaling mechanisms (SDP, BFCP) can= be
>> extended, or another messaging method should be used.
>>
>> The scope of the work includes describing relatively static relati= ons
>> between entities (participants and devices). It also includes hand= ling more
>> dynamic relationships, such as identifying the audio and video str= eams for
>> the current speaker. The scope includes both systems that provide = a fully
>> immersive experience, and systems that interwork with them and the= refore
>> need to understand the same multiple stream semantics.
>>
>> The focus of this work is on multiple audio and video streams. =A0= Other
>> media types may be considered, however development of methodologie= s for them
>> is not within the scope of this work.
>>
>> Interoperation with standards compliant systems is required, such = as
>> SIP-based video conferencing systems. =A0However, backwards compat= ibility with
>> existing non-standards compliant telepresence systems is not requi= red.
>>
>> This working group is not currently chartered to work on issues of=
>> continuous conference control including: far end camera control, i= ndication
>> of fast frame update for video codecs or other rapid switches, flo= or
>> control, conference roster. Also not in scope is signaling to tell= the
>> originator to which receivers the media streams should be sent. >>
>> Reuse of existing protocols and backwards compatibility with exist= ing
>> systems is an important factor for the working group to consider. = The work
>> will closely coordinate with the appropriate areas and working gro= ups
>> including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE.
>>
>> =A0Milestones
>>
>> =A0Nov 2010 Submit information draft to IESG on use cases and requ= irements
>>
>> =A0Nov 2011 Submit standards track specification to IESG on indica= ting
>> =A0=A0 =A0 =A0 =A0 =A0spatial relationships of screens, cameras (i= ncluding variable
>> =A0=A0 =A0 =A0 =A0 =A0field of view and orientation), speakers and= microphones. This
>> =A0=A0 =A0 =A0 =A0 =A0includes, semantics, language and transport.=
>>
>> =A0Apr 2011 Submit standards track specification to IESG on indica= ting the
>> =A0=A0 =A0 =A0 =A0 =A0"usage" of a stream as define in c= harter.
>>
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>

--00163630f7b728e80b048e3f3f7b-- From peter.musgrave@magorcorp.com Fri Aug 20 04:16:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A06B3A69D6 for ; Fri, 20 Aug 2010 04:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.706 X-Spam-Level: X-Spam-Status: No, score=-101.706 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2VQnYqMsJpx for ; Fri, 20 Aug 2010 04:16:48 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id D1F683A68EC for ; Fri, 20 Aug 2010 04:16:47 -0700 (PDT) Received: by qwc9 with SMTP id 9so3067753qwc.31 for ; Fri, 20 Aug 2010 04:17:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.94.75 with SMTP id y11mr840856qam.190.1282303041776; Fri, 20 Aug 2010 04:17:21 -0700 (PDT) Received: by 10.229.219.8 with HTTP; Fri, 20 Aug 2010 04:17:21 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02283D41@xmb-sjc-221.amer.cisco.com> Date: Fri, 20 Aug 2010 07:17:21 -0400 Message-ID: From: Peter Musgrave To: stephen botzko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 11:16:49 -0000 Hi Stephen, Sorry, I misunderstood your use case. If this is a call configuration issue (i.e. at negotiation RX intends "please send video of loudest speaker to me at IP:port" then I think this becomes an out-of-band meta-info issue (and not the SDP mechanism I had suggested). In this case I think the part of the charter that refers to other RAI groups covers the work e.g. a SIP TP event package might be defined. I'm ok if the charter is changed to state this case explicitly - but I'd be surprised if there was not a way to do within the existing protocols. I'd suggest defining the need and assuming it can be done within the protocols. Peter Musgrave On Fri, Aug 20, 2010 at 7:03 AM, stephen botzko wrote: > What if the receiver wants to tell the sender that it should receive the > video stream of whomever is speaking? > > The desired behavior is that if a 3-screen system is sending video stream= X, > and someone at that site speaks (but is sent on Video Stream Y), then vid= eo > stream Y would automatically be forwarded to the receiver instead of X. > > That cannot be done easily with a reINVITE (at least not w/o incurring at > least a RTT delay). > > Another complication with this scenario - even if you are willing to acce= pt > the RTT delay, in the multipoint case the various receivers will be doing > the reINVITE at different times.=A0 Each reINVITE forces an intra video > refresh, which will result in visible artifacts for all receivers for > several seconds. > > -- Stephen Botzko > > On Fri, Aug 20, 2010 at 6:42 AM, Peter Musgrave > wrote: >> >> Not to go too far down the rat-hole here - but I would assume this >> could be done simply with a reINVITE with new SDP which indicated what >> IP:port the stream should go to (and sending inactive to the streams >> it does not want to receive). >> >> I do not see this as requiring specific work from the new WG - >> existing SIP signalling will meet this need. >> >> Peter Musgrave >> >> On Fri, Aug 20, 2010 at 6:35 AM, stephen botzko >> wrote: >> >>>> >> > Specifically, is it within scope for a single receiver to tell the >> > originator which of the multiple streams should be sent to itself? >> >>>> >> > I think this needs to be in scope. >> > >> > It looks to me like the intent of the sentence is to exclude signaling >> > identifying which receivers are in the conference.=A0 IMHO it should n= ot >> > exclude signaling on which media streams should be sent to a given >> > receiver. >> > >> > --Stephen Botzko >> > >> > >> > On Fri, Aug 20, 2010 at 5:27 AM, Alex Eleftheriadis >> > wrote: >> >> >> >> It looks good, and I will be happy to contribute.=A0I only have a >> >> clarification question. >> >> Can you elaborate on the sentence: "Also not in scope is signaling to >> >> tell >> >> the originator to which receivers the media streams should be sent." >> >> Specifically, is it within scope for a single receiver to tell the >> >> originator which of the multiple streams should be sent to itself? >> >> --Alex >> >> >> >> >> >> On Aug 19, 2010, at 10:03 PM, Allyn Romanow (allyn) wrote: >> >> >> >> Looks good to me, with Paul=92s improvements. >> >> >> >> Allyn >> >> >> >> From:=A0dispatch-bounces@ietf.org=A0[mailto:dispatch-bounces@ietf.org= ]=A0On >> >> Behalf Of=A0Mary Barnes >> >> Sent:=A0Thursday, August 19, 2010 9:42 AM >> >> To:=A0DISPATCH >> >> Subject:=A0[dispatch] Updated Telepresence charter >> >> >> >> Per the discussion at IETF-78, an action was taken to update the >> >> telepresence charter to be more specific and more tightly scoped. =A0= To >> >> that >> >> end, the updated charter is below. >> >> >> >> Please review and provide any additional feedback and comments to the >> >> list. In addition, if you think the charter is ready to move forward = in >> >> terms of creating a new WG, please respond to the mailing list. =A0In= the >> >> latter case, if you could also please let us know (offlist if you'd >> >> prefer) >> >> if you are willing to technically contribute to this work, =A0we can >> >> guage >> >> whether there will be sufficient contributors to support a WG. >> >> >> >> Best Regards, >> >> Mary. >> >> DISPATCH WG co-chair >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> CLUE ControLling mUltiple streams for TElepresence >> >> or >> >> MUSCAT: MUlti-Stream Control Applied to Telepresence >> >> >> >> >> >> In the context of this WG, the term telepresence is used in a general >> >> manner to describe systems that provide high definition, high quality >> >> audio >> >> enabling a "being-there" experience. =A0One example is an immersive >> >> telepresence system using specially designed and special purpose room= s >> >> with >> >> multiple displays permitting life size image reproduction using >> >> multiple >> >> cameras, encoders, decoders and microphones. >> >> >> >> Current telepresence systems are based on open standards such as RTP, >> >> SIP, >> >> H.264, the H.323 suite, however, they cannot easily interoperate with >> >> each >> >> other without operator assistance and expensive additional equipment >> >> which >> >> translates from one vendor to another. A major factor in the inabilit= y >> >> of >> >> telepresence systems to interwork is that there is no standard >> >> description >> >> of the multiple streams of audio and video that comprise the media >> >> flows. >> >> =A0In addition, =A0there is =A0no standardized way =A0to exchange sem= antic >> >> information about what each media stream represents. >> >> >> >> The WG will create specification to enable communication of enough >> >> information about each media stream so that each receiving system or >> >> bridge >> >> system can make reasonable decisions about selecting and displaying >> >> media >> >> streams. This enables systems to make display choices that optimize t= he >> >> "just like being there" experience. >> >> >> >> This working group is chartered to specify the information about medi= a >> >> streams from one endpoint to another endpoint or conference bridge >> >> including: >> >> >> >> * Spatial relationships of cameras, displays, microphones, and >> >> =A0=A0speakers in relation to each other and to likely positions of >> >> =A0=A0participants >> >> >> >> * Specific characteristics such as viewpoint, field of view/capture >> >> =A0=A0for camera/microphone/display/speaker so that senders and >> >> =A0=A0middleboxes can understand how best to compose streams for >> >> =A0=A0receivers and the receivers will know the characteristics of it= s >> >> =A0=A0received streams >> >> >> >> * Aspect ratio of cameras and displays >> >> >> >> Information between sources and sinks about media stream capabilities >> >> will >> >> be exchanged. >> >> >> >> The working group will define the semantics, language and transport >> >> mechanism necessary for communicating the necessary information. It >> >> will >> >> consider whether the existing signaling mechanisms (SDP, BFCP) can be >> >> extended, or another messaging method should be used. >> >> >> >> The scope of the work includes describing relatively static relations >> >> between entities (participants and devices). It also includes handlin= g >> >> more >> >> dynamic relationships, such as identifying the audio and video stream= s >> >> for >> >> the current speaker. The scope includes both systems that provide a >> >> fully >> >> immersive experience, and systems that interwork with them and >> >> therefore >> >> need to understand the same multiple stream semantics. >> >> >> >> The focus of this work is on multiple audio and video streams. =A0Oth= er >> >> media types may be considered, however development of methodologies f= or >> >> them >> >> is not within the scope of this work. >> >> >> >> Interoperation with standards compliant systems is required, such as >> >> SIP-based video conferencing systems. =A0However, backwards compatibi= lity >> >> with >> >> existing non-standards compliant telepresence systems is not required= . >> >> >> >> This working group is not currently chartered to work on issues of >> >> continuous conference control including: far end camera control, >> >> indication >> >> of fast frame update for video codecs or other rapid switches, floor >> >> control, conference roster. Also not in scope is signaling to tell th= e >> >> originator to which receivers the media streams should be sent. >> >> >> >> Reuse of existing protocols and backwards compatibility with existing >> >> systems is an important factor for the working group to consider. The >> >> work >> >> will closely coordinate with the appropriate areas and working groups >> >> including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. >> >> >> >> =A0Milestones >> >> >> >> =A0Nov 2010 Submit information draft to IESG on use cases and >> >> requirements >> >> >> >> =A0Nov 2011 Submit standards track specification to IESG on indicatin= g >> >> =A0=A0 =A0 =A0 =A0 =A0spatial relationships of screens, cameras (incl= uding variable >> >> =A0=A0 =A0 =A0 =A0 =A0field of view and orientation), speakers and mi= crophones. >> >> This >> >> =A0=A0 =A0 =A0 =A0 =A0includes, semantics, language and transport. >> >> >> >> =A0Apr 2011 Submit standards track specification to IESG on indicatin= g >> >> the >> >> =A0=A0 =A0 =A0 =A0 =A0"usage" of a stream as define in charter. >> >> >> >> >> >> >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> >> >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> > >> > >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> > >> > > > From peter.musgrave@magorcorp.com Fri Aug 20 04:17:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6EE23A6A90 for ; Fri, 20 Aug 2010 04:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFsvO0j3bLEm for ; Fri, 20 Aug 2010 04:17:03 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 1DAEA3A68EC for ; Fri, 20 Aug 2010 04:17:03 -0700 (PDT) Received: by mail-qw0-f44.google.com with SMTP id 9so3067753qwc.31 for ; Fri, 20 Aug 2010 04:17:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.11.8 with SMTP id r8mr779706qcr.236.1282303057722; Fri, 20 Aug 2010 04:17:37 -0700 (PDT) Received: by 10.229.219.8 with HTTP; Fri, 20 Aug 2010 04:17:37 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02283D41@xmb-sjc-221.amer.cisco.com> Date: Fri, 20 Aug 2010 07:17:37 -0400 Message-ID: From: Peter Musgrave To: stephen botzko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 11:17:05 -0000 Hi Stephen, Sorry, I misunderstood your use case. If this is a call configuration issue (i.e. at negotiation RX intends "please send video of loudest speaker to me at IP:port" then I think this becomes an out-of-band meta-info issue (and not the SDP mechanism I had suggested). In this case I think the part of the charter that refers to other RAI groups covers the work e.g. a SIP TP event package might be defined. I'm ok if the charter is changed to state this case explicitly - but I'd be surprised if there was not a way to do within the existing protocols. I'd suggest defining the need and assuming it can be done within the protocols [and if we're wrong we'll need to a Peter Musgrave On Fri, Aug 20, 2010 at 7:03 AM, stephen botzko wrote: > What if the receiver wants to tell the sender that it should receive the > video stream of whomever is speaking? > > The desired behavior is that if a 3-screen system is sending video stream= X, > and someone at that site speaks (but is sent on Video Stream Y), then vid= eo > stream Y would automatically be forwarded to the receiver instead of X. > > That cannot be done easily with a reINVITE (at least not w/o incurring at > least a RTT delay). > > Another complication with this scenario - even if you are willing to acce= pt > the RTT delay, in the multipoint case the various receivers will be doing > the reINVITE at different times.=A0 Each reINVITE forces an intra video > refresh, which will result in visible artifacts for all receivers for > several seconds. > > -- Stephen Botzko > > On Fri, Aug 20, 2010 at 6:42 AM, Peter Musgrave > wrote: >> >> Not to go too far down the rat-hole here - but I would assume this >> could be done simply with a reINVITE with new SDP which indicated what >> IP:port the stream should go to (and sending inactive to the streams >> it does not want to receive). >> >> I do not see this as requiring specific work from the new WG - >> existing SIP signalling will meet this need. >> >> Peter Musgrave >> >> On Fri, Aug 20, 2010 at 6:35 AM, stephen botzko >> wrote: >> >>>> >> > Specifically, is it within scope for a single receiver to tell the >> > originator which of the multiple streams should be sent to itself? >> >>>> >> > I think this needs to be in scope. >> > >> > It looks to me like the intent of the sentence is to exclude signaling >> > identifying which receivers are in the conference.=A0 IMHO it should n= ot >> > exclude signaling on which media streams should be sent to a given >> > receiver. >> > >> > --Stephen Botzko >> > >> > >> > On Fri, Aug 20, 2010 at 5:27 AM, Alex Eleftheriadis >> > wrote: >> >> >> >> It looks good, and I will be happy to contribute.=A0I only have a >> >> clarification question. >> >> Can you elaborate on the sentence: "Also not in scope is signaling to >> >> tell >> >> the originator to which receivers the media streams should be sent." >> >> Specifically, is it within scope for a single receiver to tell the >> >> originator which of the multiple streams should be sent to itself? >> >> --Alex >> >> >> >> >> >> On Aug 19, 2010, at 10:03 PM, Allyn Romanow (allyn) wrote: >> >> >> >> Looks good to me, with Paul=92s improvements. >> >> >> >> Allyn >> >> >> >> From:=A0dispatch-bounces@ietf.org=A0[mailto:dispatch-bounces@ietf.org= ]=A0On >> >> Behalf Of=A0Mary Barnes >> >> Sent:=A0Thursday, August 19, 2010 9:42 AM >> >> To:=A0DISPATCH >> >> Subject:=A0[dispatch] Updated Telepresence charter >> >> >> >> Per the discussion at IETF-78, an action was taken to update the >> >> telepresence charter to be more specific and more tightly scoped. =A0= To >> >> that >> >> end, the updated charter is below. >> >> >> >> Please review and provide any additional feedback and comments to the >> >> list. In addition, if you think the charter is ready to move forward = in >> >> terms of creating a new WG, please respond to the mailing list. =A0In= the >> >> latter case, if you could also please let us know (offlist if you'd >> >> prefer) >> >> if you are willing to technically contribute to this work, =A0we can >> >> guage >> >> whether there will be sufficient contributors to support a WG. >> >> >> >> Best Regards, >> >> Mary. >> >> DISPATCH WG co-chair >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> CLUE ControLling mUltiple streams for TElepresence >> >> or >> >> MUSCAT: MUlti-Stream Control Applied to Telepresence >> >> >> >> >> >> In the context of this WG, the term telepresence is used in a general >> >> manner to describe systems that provide high definition, high quality >> >> audio >> >> enabling a "being-there" experience. =A0One example is an immersive >> >> telepresence system using specially designed and special purpose room= s >> >> with >> >> multiple displays permitting life size image reproduction using >> >> multiple >> >> cameras, encoders, decoders and microphones. >> >> >> >> Current telepresence systems are based on open standards such as RTP, >> >> SIP, >> >> H.264, the H.323 suite, however, they cannot easily interoperate with >> >> each >> >> other without operator assistance and expensive additional equipment >> >> which >> >> translates from one vendor to another. A major factor in the inabilit= y >> >> of >> >> telepresence systems to interwork is that there is no standard >> >> description >> >> of the multiple streams of audio and video that comprise the media >> >> flows. >> >> =A0In addition, =A0there is =A0no standardized way =A0to exchange sem= antic >> >> information about what each media stream represents. >> >> >> >> The WG will create specification to enable communication of enough >> >> information about each media stream so that each receiving system or >> >> bridge >> >> system can make reasonable decisions about selecting and displaying >> >> media >> >> streams. This enables systems to make display choices that optimize t= he >> >> "just like being there" experience. >> >> >> >> This working group is chartered to specify the information about medi= a >> >> streams from one endpoint to another endpoint or conference bridge >> >> including: >> >> >> >> * Spatial relationships of cameras, displays, microphones, and >> >> =A0=A0speakers in relation to each other and to likely positions of >> >> =A0=A0participants >> >> >> >> * Specific characteristics such as viewpoint, field of view/capture >> >> =A0=A0for camera/microphone/display/speaker so that senders and >> >> =A0=A0middleboxes can understand how best to compose streams for >> >> =A0=A0receivers and the receivers will know the characteristics of it= s >> >> =A0=A0received streams >> >> >> >> * Aspect ratio of cameras and displays >> >> >> >> Information between sources and sinks about media stream capabilities >> >> will >> >> be exchanged. >> >> >> >> The working group will define the semantics, language and transport >> >> mechanism necessary for communicating the necessary information. It >> >> will >> >> consider whether the existing signaling mechanisms (SDP, BFCP) can be >> >> extended, or another messaging method should be used. >> >> >> >> The scope of the work includes describing relatively static relations >> >> between entities (participants and devices). It also includes handlin= g >> >> more >> >> dynamic relationships, such as identifying the audio and video stream= s >> >> for >> >> the current speaker. The scope includes both systems that provide a >> >> fully >> >> immersive experience, and systems that interwork with them and >> >> therefore >> >> need to understand the same multiple stream semantics. >> >> >> >> The focus of this work is on multiple audio and video streams. =A0Oth= er >> >> media types may be considered, however development of methodologies f= or >> >> them >> >> is not within the scope of this work. >> >> >> >> Interoperation with standards compliant systems is required, such as >> >> SIP-based video conferencing systems. =A0However, backwards compatibi= lity >> >> with >> >> existing non-standards compliant telepresence systems is not required= . >> >> >> >> This working group is not currently chartered to work on issues of >> >> continuous conference control including: far end camera control, >> >> indication >> >> of fast frame update for video codecs or other rapid switches, floor >> >> control, conference roster. Also not in scope is signaling to tell th= e >> >> originator to which receivers the media streams should be sent. >> >> >> >> Reuse of existing protocols and backwards compatibility with existing >> >> systems is an important factor for the working group to consider. The >> >> work >> >> will closely coordinate with the appropriate areas and working groups >> >> including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. >> >> >> >> =A0Milestones >> >> >> >> =A0Nov 2010 Submit information draft to IESG on use cases and >> >> requirements >> >> >> >> =A0Nov 2011 Submit standards track specification to IESG on indicatin= g >> >> =A0=A0 =A0 =A0 =A0 =A0spatial relationships of screens, cameras (incl= uding variable >> >> =A0=A0 =A0 =A0 =A0 =A0field of view and orientation), speakers and mi= crophones. >> >> This >> >> =A0=A0 =A0 =A0 =A0 =A0includes, semantics, language and transport. >> >> >> >> =A0Apr 2011 Submit standards track specification to IESG on indicatin= g >> >> the >> >> =A0=A0 =A0 =A0 =A0 =A0"usage" of a stream as define in charter. >> >> >> >> >> >> >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> >> >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> > >> > >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> > >> > > > From pkyzivat@cisco.com Fri Aug 20 06:26:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2733A687A for ; Fri, 20 Aug 2010 06:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT9Yzm-fTQh2 for ; Fri, 20 Aug 2010 06:26:35 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 66C313A68F0 for ; Fri, 20 Aug 2010 06:26:35 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,239,1280707200"; d="scan'208";a="149881938" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 20 Aug 2010 13:27:09 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7KDR9eC029391; Fri, 20 Aug 2010 13:27:09 GMT Message-ID: <4C6E82AD.4030302@cisco.com> Date: Fri, 20 Aug 2010 09:27:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> <430FC6BDED356B4C8498F634416644A92694381714@mail> <4C6C849F.1000708@cisco.com> <430FC6BDED356B4C8498F634416644A9269438193C@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A9269438193C@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 13:26:36 -0000 Hadriel, OK, my bad. :-( (I've been following the thread for too long without going back to reread what the charter proposal actually said.) Its true that "troubleshooting" is largely gratuitous in the proposal - it has little to do with what the group is chartered to work on. The "session" is the focus, and the things that belong in the same session is, more or less, defined in the charter itself. So the bottom line here is that anybody who wants the definition of "session" tweaked needs to accomplish that by proposing changes to the charter text. Right? Thanks, Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, August 18, 2010 9:11 PM >> To: Hadriel Kaplan >> >> The problem I have with using "troubleshooting" as the criterion for >> what things are in scope for this id is: it can include anything you >> might have trouble with: >> if I'm trying to debug problems with conferencing, then it might be >> helpful to have the same session-id for all the participant connections >> to the focus; >> if I was called by a conference focus, and then transfer that call to my >> other phone, then I want all that to have the same session-id; > > Sure, but the proposed charter doesn't say it will solve all troubleshooting needs imaginable, nor does it say it will cover such conference scenarios. And it does NOT say "troubleshooting is the criterion for what things are in scope". > > It just says: > Sip transactions are often triggered by another SIP transaction. Two > transactions are in the same "session" if one was triggered by the other > due to redirection, REFER processing, retargeting, or forwarding on a > B2BUA. This working group will define a correlation identifier that > identifies all the transactions in the same session. > > -hadriel > From hmmr@cisco.com Fri Aug 20 07:01:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C433A6A09 for ; Fri, 20 Aug 2010 07:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdSFubMMW+vX for ; Fri, 20 Aug 2010 07:01:34 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 514BB3A68B3 for ; Fri, 20 Aug 2010 07:01:33 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPUnbkytJV2Z/2dsb2JhbACgTHGfSptshTcEhDSILA X-IronPort-AV: E=Sophos;i="4.56,239,1280707200"; d="scan'208";a="149897415" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 20 Aug 2010 14:02:07 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o7KE274E007708; Fri, 20 Aug 2010 14:02:07 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Aug 2010 09:02:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Aug 2010 09:02:05 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated Telepresence charter Thread-Index: ActAWUhiCE50P22mSNGalhtX58WG1QAFt8XQ References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02283D41@xmb-sjc-221.amer.cisco.com> From: "Mike Hammer (hmmr)" To: "Peter Musgrave" , "stephen botzko" X-OriginalArrivalTime: 20 Aug 2010 14:02:06.0778 (UTC) FILETIME=[4628B9A0:01CB4070] Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 14:01:36 -0000 Perhaps it should just say to not duplicate the work of SDP. Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Peter Musgrave Sent: Friday, August 20, 2010 7:17 AM To: stephen botzko Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter Hi Stephen, Sorry, I misunderstood your use case. If this is a call configuration issue (i.e. at negotiation RX intends "please send video of loudest speaker to me at IP:port" then I think this becomes an out-of-band meta-info issue (and not the SDP mechanism I had suggested). In this case I think the part of the charter that refers to other RAI groups covers the work e.g. a SIP TP event package might be defined. I'm ok if the charter is changed to state this case explicitly - but I'd be surprised if there was not a way to do within the existing protocols. I'd suggest defining the need and assuming it can be done within the protocols. Peter Musgrave On Fri, Aug 20, 2010 at 7:03 AM, stephen botzko wrote: > What if the receiver wants to tell the sender that it should receive = the > video stream of whomever is speaking? > > The desired behavior is that if a 3-screen system is sending video = stream X, > and someone at that site speaks (but is sent on Video Stream Y), then = video > stream Y would automatically be forwarded to the receiver instead of = X. > > That cannot be done easily with a reINVITE (at least not w/o incurring = at > least a RTT delay). > > Another complication with this scenario - even if you are willing to = accept > the RTT delay, in the multipoint case the various receivers will be = doing > the reINVITE at different times.=A0 Each reINVITE forces an intra = video > refresh, which will result in visible artifacts for all receivers for > several seconds. > > -- Stephen Botzko > > On Fri, Aug 20, 2010 at 6:42 AM, Peter Musgrave > wrote: >> >> Not to go too far down the rat-hole here - but I would assume this >> could be done simply with a reINVITE with new SDP which indicated = what >> IP:port the stream should go to (and sending inactive to the streams >> it does not want to receive). >> >> I do not see this as requiring specific work from the new WG - >> existing SIP signalling will meet this need. >> >> Peter Musgrave >> >> On Fri, Aug 20, 2010 at 6:35 AM, stephen botzko >> wrote: >> >>>> >> > Specifically, is it within scope for a single receiver to tell the >> > originator which of the multiple streams should be sent to itself? >> >>>> >> > I think this needs to be in scope. >> > >> > It looks to me like the intent of the sentence is to exclude = signaling >> > identifying which receivers are in the conference.=A0 IMHO it = should not >> > exclude signaling on which media streams should be sent to a given >> > receiver. >> > >> > --Stephen Botzko >> > >> > >> > On Fri, Aug 20, 2010 at 5:27 AM, Alex Eleftheriadis = >> > wrote: >> >> >> >> It looks good, and I will be happy to contribute.=A0I only have a >> >> clarification question. >> >> Can you elaborate on the sentence: "Also not in scope is signaling = to >> >> tell >> >> the originator to which receivers the media streams should be = sent." >> >> Specifically, is it within scope for a single receiver to tell the >> >> originator which of the multiple streams should be sent to itself? >> >> --Alex >> >> >> >> >> >> On Aug 19, 2010, at 10:03 PM, Allyn Romanow (allyn) wrote: >> >> >> >> Looks good to me, with Paul's improvements. >> >> >> >> Allyn >> >> >> >> = From:=A0dispatch-bounces@ietf.org=A0[mailto:dispatch-bounces@ietf.org]=A0= On >> >> Behalf Of=A0Mary Barnes >> >> Sent:=A0Thursday, August 19, 2010 9:42 AM >> >> To:=A0DISPATCH >> >> Subject:=A0[dispatch] Updated Telepresence charter >> >> >> >> Per the discussion at IETF-78, an action was taken to update the >> >> telepresence charter to be more specific and more tightly scoped. = =A0To >> >> that >> >> end, the updated charter is below. >> >> >> >> Please review and provide any additional feedback and comments to = the >> >> list. In addition, if you think the charter is ready to move = forward in >> >> terms of creating a new WG, please respond to the mailing list. = =A0In the >> >> latter case, if you could also please let us know (offlist if = you'd >> >> prefer) >> >> if you are willing to technically contribute to this work, =A0we = can >> >> guage >> >> whether there will be sufficient contributors to support a WG. >> >> >> >> Best Regards, >> >> Mary. >> >> DISPATCH WG co-chair >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> CLUE ControLling mUltiple streams for TElepresence >> >> or >> >> MUSCAT: MUlti-Stream Control Applied to Telepresence >> >> >> >> >> >> In the context of this WG, the term telepresence is used in a = general >> >> manner to describe systems that provide high definition, high = quality >> >> audio >> >> enabling a "being-there" experience. =A0One example is an = immersive >> >> telepresence system using specially designed and special purpose = rooms >> >> with >> >> multiple displays permitting life size image reproduction using >> >> multiple >> >> cameras, encoders, decoders and microphones. >> >> >> >> Current telepresence systems are based on open standards such as = RTP, >> >> SIP, >> >> H.264, the H.323 suite, however, they cannot easily interoperate = with >> >> each >> >> other without operator assistance and expensive additional = equipment >> >> which >> >> translates from one vendor to another. A major factor in the = inability >> >> of >> >> telepresence systems to interwork is that there is no standard >> >> description >> >> of the multiple streams of audio and video that comprise the media >> >> flows. >> >> =A0In addition, =A0there is =A0no standardized way =A0to exchange = semantic >> >> information about what each media stream represents. >> >> >> >> The WG will create specification to enable communication of enough >> >> information about each media stream so that each receiving system = or >> >> bridge >> >> system can make reasonable decisions about selecting and = displaying >> >> media >> >> streams. This enables systems to make display choices that = optimize the >> >> "just like being there" experience. >> >> >> >> This working group is chartered to specify the information about = media >> >> streams from one endpoint to another endpoint or conference bridge >> >> including: >> >> >> >> * Spatial relationships of cameras, displays, microphones, and >> >> =A0=A0speakers in relation to each other and to likely positions = of >> >> =A0=A0participants >> >> >> >> * Specific characteristics such as viewpoint, field of = view/capture >> >> =A0=A0for camera/microphone/display/speaker so that senders and >> >> =A0=A0middleboxes can understand how best to compose streams for >> >> =A0=A0receivers and the receivers will know the characteristics of = its >> >> =A0=A0received streams >> >> >> >> * Aspect ratio of cameras and displays >> >> >> >> Information between sources and sinks about media stream = capabilities >> >> will >> >> be exchanged. >> >> >> >> The working group will define the semantics, language and = transport >> >> mechanism necessary for communicating the necessary information. = It >> >> will >> >> consider whether the existing signaling mechanisms (SDP, BFCP) can = be >> >> extended, or another messaging method should be used. >> >> >> >> The scope of the work includes describing relatively static = relations >> >> between entities (participants and devices). It also includes = handling >> >> more >> >> dynamic relationships, such as identifying the audio and video = streams >> >> for >> >> the current speaker. The scope includes both systems that provide = a >> >> fully >> >> immersive experience, and systems that interwork with them and >> >> therefore >> >> need to understand the same multiple stream semantics. >> >> >> >> The focus of this work is on multiple audio and video streams. = =A0Other >> >> media types may be considered, however development of = methodologies for >> >> them >> >> is not within the scope of this work. >> >> >> >> Interoperation with standards compliant systems is required, such = as >> >> SIP-based video conferencing systems. =A0However, backwards = compatibility >> >> with >> >> existing non-standards compliant telepresence systems is not = required. >> >> >> >> This working group is not currently chartered to work on issues of >> >> continuous conference control including: far end camera control, >> >> indication >> >> of fast frame update for video codecs or other rapid switches, = floor >> >> control, conference roster. Also not in scope is signaling to tell = the >> >> originator to which receivers the media streams should be sent. >> >> >> >> Reuse of existing protocols and backwards compatibility with = existing >> >> systems is an important factor for the working group to consider. = The >> >> work >> >> will closely coordinate with the appropriate areas and working = groups >> >> including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. >> >> >> >> =A0Milestones >> >> >> >> =A0Nov 2010 Submit information draft to IESG on use cases and >> >> requirements >> >> >> >> =A0Nov 2011 Submit standards track specification to IESG on = indicating >> >> =A0=A0 =A0 =A0 =A0 =A0spatial relationships of screens, cameras = (including variable >> >> =A0=A0 =A0 =A0 =A0 =A0field of view and orientation), speakers and = microphones. >> >> This >> >> =A0=A0 =A0 =A0 =A0 =A0includes, semantics, language and transport. >> >> >> >> =A0Apr 2011 Submit standards track specification to IESG on = indicating >> >> the >> >> =A0=A0 =A0 =A0 =A0 =A0"usage" of a stream as define in charter. >> >> >> >> >> >> >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> >> >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> > >> > >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> > >> > > > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From eckelcu@cisco.com Fri Aug 20 08:43:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160D43A6AB1 for ; Fri, 20 Aug 2010 08:43:32 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt806Pnripnh for ; Fri, 20 Aug 2010 08:43:30 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CF68F3A68C5 for ; Fri, 20 Aug 2010 08:43:30 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABdAbkyrR7H+/2dsb2JhbACgUHGgRptnhTcEhDSILA X-IronPort-AV: E=Sophos;i="4.56,239,1280707200"; d="scan'208";a="234965151" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 20 Aug 2010 15:44:05 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7KFi5UY022580; Fri, 20 Aug 2010 15:44:05 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Aug 2010 08:44:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Aug 2010 08:44:04 -0700 Message-ID: In-Reply-To: <4C6D689A.3080901@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated Telepresence charter Thread-Index: Acs/w01FKrLB5tZSRHCzNnhX86hIAAAuOG7Q References: <4C6D689A.3080901@cisco.com> From: "Charles Eckel (eckelcu)" To: "Mary Barnes" X-OriginalArrivalTime: 20 Aug 2010 15:44:05.0456 (UTC) FILETIME=[852CE500:01CB407E] Cc: DISPATCH Subject: Re: [dispatch] Updated Telepresence charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 15:43:32 -0000 Hi Mary, I agree with Paul's comments, and added a few minor suggestions as well (inline). I think the charter is ready to move forward in terms of creating a new WG, and I am looking forward to contributing to this work. Cheers, Charles > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > (pkyzivat) > Sent: Thursday, August 19, 2010 10:24 AM > To: Mary Barnes > Cc: DISPATCH > Subject: Re: [dispatch] Updated Telepresence charter >=20 > This seems good, but I've indicated a few nits inline. >=20 > Thanks, > Paul >=20 > Mary Barnes wrote: > > Per the discussion at IETF-78, an action was taken to update the > > telepresence charter to be more specific and more tightly scoped. To > > that end, the updated charter is below. > > > > Please review and provide any additional feedback and comments to the > > list. In addition, if you think the charter is ready to move forward in > > terms of creating a new WG, please respond to the mailing list. In the > > latter case, if you could also please let us know (offlist if you'd > > prefer) if you are willing to technically contribute to this work, we > > can guage whether there will be sufficient contributors to support a WG. > > > > Best Regards, > > Mary. > > DISPATCH WG co-chair > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > CLUE ControLling mUltiple streams for TElepresence > > or > > MUSCAT: MUlti-Stream Control Applied to Telepresence > > > > > > In the context of this WG, the term telepresence is used in a general > > manner to describe systems that provide high definition, high quality > > audio enabling a "being-there" experience. One example is an immersive >=20 > *audio*??? >=20 > s:audio:video: or s:audio:audio/video: >=20 > > telepresence system using specially designed and special purpose rooms > > with multiple displays permitting life size image reproduction using > > multiple cameras, encoders, decoders and microphones. Add speakers. > > > > Current telepresence systems are based on open standards such as RTP, > > SIP, H.264, the H.323 suite, however, they cannot easily interoperate > > with each other without operator assistance and expensive additional >=20 > s/with each other// > (implied by "interoperate") >=20 > > equipment which translates from one vendor to another. A major factor in > > the inability of telepresence systems to interwork is that there is no > > standard description of the multiple streams of audio and video that s/standard description/standardized way to describe and negotiate the use/ > > comprise the media flows. In addition, there is no standardized way > > to exchange semantic information about what each media stream represents. > > > > The WG will create specification to enable communication of enough > > information about each media stream so that each receiving system or > > bridge system can make reasonable decisions about selecting and > > displaying media streams. This enables systems to make display choices >=20 > s/displaying/rendering/ > (both audio and video being discussed, but you don't *display* audio.) >=20 > > that optimize the "just like being there" experience. > > > > This working group is chartered to specify the information about media > > streams from one endpoint to another endpoint or conference bridge > > including: > > > > * Spatial relationships of cameras, displays, microphones, and > > speakers in relation to each other and to likely positions of > > participants > > > > * Specific characteristics such as viewpoint, field of view/capture > > for camera/microphone/display/speaker so that senders and > > middleboxes can understand how best to compose streams for > > receivers and the receivers will know the characteristics of its > > received streams > > > > * Aspect ratio of cameras and displays > > > > Information between sources and sinks about media stream capabilities > > will be exchanged. > > > > The working group will define the semantics, language and transport s/language/syntax > > mechanism necessary for communicating the necessary information. It will > > consider whether the existing signaling mechanisms (SDP, BFCP) can be >=20 > I don't think SDP and BFCP are the only existing mechanisms. So >=20 > s/(/(e.g. / >=20 > > extended, or another messaging method should be used. > > > > The scope of the work includes describing relatively static relations > > between entities (participants and devices). It also includes handling > > more dynamic relationships, such as identifying the audio and video > > streams for the current speaker. The scope includes both systems that > > provide a fully immersive experience, and systems that interwork with > > them and therefore need to understand the same multiple stream semantics. > > > > The focus of this work is on multiple audio and video streams. Other > > media types may be considered, however development of methodologies for > > them is not within the scope of this work. > > > > Interoperation with standards compliant systems is required, such as > > SIP-based video conferencing systems. However, backwards compatibility > > with existing non-standards compliant telepresence systems is not required. > > > > This working group is not currently chartered to work on issues of > > continuous conference control including: far end camera control, > > indication of fast frame update for video codecs or other rapid > > switches, floor control, conference roster. Also not in scope is > > signaling to tell the originator to which receivers the media streams > > should be sent. > > > > Reuse of existing protocols and backwards compatibility with existing > > systems is an important factor for the working group to consider. The > > work will closely coordinate with the appropriate areas and working > > groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. > > > > Milestones > > > > Nov 2010 Submit information draft to IESG on use cases and requirements > > > > Nov 2011 Submit standards track specification to IESG on indicating > > spatial relationships of screens, cameras (including variable > > field of view and orientation), speakers and microphones. This > > includes, semantics, language and transport. > > > > Apr 2011 Submit standards track specification to IESG on indicating the > > "usage" of a stream as define in charter. > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Fri Aug 20 08:47:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690FF3A6ADA for ; Fri, 20 Aug 2010 08:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG2-zrSjWhzl for ; Fri, 20 Aug 2010 08:47:56 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 583A43A6ADB for ; Fri, 20 Aug 2010 08:47:56 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 20 Aug 2010 11:48:30 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 20 Aug 2010 11:48:09 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Fri, 20 Aug 2010 11:48:08 -0400 Thread-Topic: I-D Action: draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActAfxYqhZm2eYqvQqSbEji8cpHjOQ== Message-ID: <430FC6BDED356B4C8498F634416644A92694381B86@mail> 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 Subject: [dispatch] I-D Action: draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 15:47:57 -0000 Howdy, I've submitted an I-D for a DTMF Info-Package, registering it following the= rules of draft-ietf-sipcore-info-events-08. The info-events draft is not = in the publication queue yet - it's held up by a single DISCUSS, but I expe= ct that to be resolved. With regards to my I-D, I'd like to go through A-D sponsored instead of a n= ew WG, for obvious reasons. Any comments/flames are appreciated. -hadriel From HKaplan@acmepacket.com Fri Aug 20 10:31:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14373A6B0A for ; Fri, 20 Aug 2010 10:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KekvUqP3cmB for ; Fri, 20 Aug 2010 10:31:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8EAF03A6B02 for ; Fri, 20 Aug 2010 10:31:09 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 20 Aug 2010 13:31:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 20 Aug 2010 13:31:43 -0400 From: Hadriel Kaplan To: Hadriel Kaplan , "dispatch@ietf.org" Date: Fri, 20 Aug 2010 13:31:34 -0400 Thread-Topic: [dispatch] I-D Action: draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActAfxYqhZm2eYqvQqSbEji8cpHjOQADlyow Message-ID: <430FC6BDED356B4C8498F634416644A92694381BFB@mail> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A92694381B86@mail> 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 Subject: Re: [dispatch] I-D Action: draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 17:31:12 -0000 Ooops, forgot the link: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Session Initiation Protocol (SIP) INFO Package for Dua= l-Tone Multi-Frequency (DTMF) Events Author(s) : H. Kaplan Filename : draft-kaplan-dispatch-info-dtmf-package-00.txt Pages : 7 Date : 2010-08-20 The SIP INFO request method now supports explicit indication and exchange o= f specified application information. Such usages are documented as an "INF= O Package", following the requirements outlined in [info-packages]. This d= ocument specifies one such SIP INFO Package, for the purpose of indicating = DTMF signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-info-dtmf-package= -00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Friday, August 20, 2010 11:48 AM > To: dispatch@ietf.org > Subject: [dispatch] I-D Action: draft-kaplan-dispatch-info-dtmf-package- > 00.txt >=20 > Howdy, > I've submitted an I-D for a DTMF Info-Package, registering it following > the rules of draft-ietf-sipcore-info-events-08. The info-events draft is > not in the publication queue yet - it's held up by a single DISCUSS, but = I > expect that to be resolved. >=20 > With regards to my I-D, I'd like to go through A-D sponsored instead of a > new WG, for obvious reasons. >=20 > Any comments/flames are appreciated. >=20 > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mperumal@cisco.com Fri Aug 20 10:58:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0123A6B0A for ; Fri, 20 Aug 2010 10:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.654 X-Spam-Level: X-Spam-Status: No, score=-9.654 tagged_above=-999 required=5 tests=[AWL=0.945, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5q7qqlhPxpU6 for ; Fri, 20 Aug 2010 10:58:32 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A56EF3A6AFC for ; Fri, 20 Aug 2010 10:58:32 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALtfbkxAaMHG/2dsb2JhbACgPXGgW5tyhTcEhDKILg X-IronPort-AV: E=Sophos;i="4.56,240,1280707200"; d="scan'208";a="234989849" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-3.cisco.com with ESMTP; 20 Aug 2010 17:59:06 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7KHx389009257; Fri, 20 Aug 2010 17:59:05 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Aug 2010 23:29:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Aug 2010 23:28:58 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> In-Reply-To: <430FC6BDED356B4C8498F634416644A92694381B86@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActAfxYqhZm2eYqvQqSbEji8cpHjOQADdeLw References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 20 Aug 2010 17:59:02.0360 (UTC) FILETIME=[5F4E6580:01CB4091] Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 17:58:33 -0000 Hi Hadriel, There draft doesn't provide a method to indicate the start of a DTMF event and requires the INFO to be generated only when the user releases the button. So, in the following scenario where the B2BUAs support only the INFO method of sending DTMF events, if the user presses the long '#', which typically lasts for 2 - 4 sec, the app server at the far end would detect the long '#' only after 6 - 12 sec.=20 user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN GW]--app Would it be better to provide a way to indicate the start of a DTMF event so that the far end can start playing it as soon as the user presses the button? It could be indicated using an empty value for duration, like this:=20 Signal=3D # Duration=3D=20 Muthu |-----Original Message----- |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf |Of Hadriel Kaplan |Sent: Friday, August 20, 2010 9:18 PM |To: dispatch@ietf.org |Subject: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package- |00.txt | |Howdy, |I've submitted an I-D for a DTMF Info-Package, registering it following the |rules of draft-ietf-sipcore-info-events-08. The info-events draft is not in |the publication queue yet - it's held up by a single DISCUSS, but I expect |that to be resolved. | |With regards to my I-D, I'd like to go through A-D sponsored instead of a |new WG, for obvious reasons. | |Any comments/flames are appreciated. | |-hadriel |_______________________________________________ |dispatch mailing list |dispatch@ietf.org |https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Fri Aug 20 11:25:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28883A6B12 for ; Fri, 20 Aug 2010 11:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS6s93mGD2Lz for ; Fri, 20 Aug 2010 11:25:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3C57D3A69E8 for ; Fri, 20 Aug 2010 11:25:07 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 20 Aug 2010 14:25:41 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 20 Aug 2010 14:25:40 -0400 From: Hadriel Kaplan To: "Muthu ArulMozhi Perumal (mperumal)" , "dispatch@ietf.org" Date: Fri, 20 Aug 2010 14:25:39 -0400 Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActAfxYqhZm2eYqvQqSbEji8cpHjOQADdeLwAAH9gFA= Message-ID: <430FC6BDED356B4C8498F634416644A92694381C2C@mail> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.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 Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 18:25:08 -0000 You tell me - afaik it's Cisco's dtmf-relay that everyone's copied (and tha= t I'm proposing be an info-package, so it can be "legal").=20 :) -hadriel > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Friday, August 20, 2010 1:59 PM > To: Hadriel Kaplan; dispatch@ietf.org > Subject: RE: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf- > package-00.txt >=20 > Hi Hadriel, >=20 > There draft doesn't provide a method to indicate the start of a DTMF > event and requires the INFO to be generated only when the user releases > the button. So, in the following scenario where the B2BUAs support only > the INFO method of sending DTMF events, if the user presses the long > '#', which typically lasts for 2 - 4 sec, the app server at the far end > would detect the long '#' only after 6 - 12 sec. >=20 > user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN > GW]--app >=20 > Would it be better to provide a way to indicate the start of a DTMF > event so that the far end can start playing it as soon as the user > presses the button? It could be indicated using an empty value for > duration, like this: >=20 > Signal=3D # > Duration=3D >=20 > Muthu >=20 > |-----Original Message----- > |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf > |Of Hadriel Kaplan > |Sent: Friday, August 20, 2010 9:18 PM > |To: dispatch@ietf.org > |Subject: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package- > |00.txt > | > |Howdy, > |I've submitted an I-D for a DTMF Info-Package, registering it following > the > |rules of draft-ietf-sipcore-info-events-08. The info-events draft is > not in > |the publication queue yet - it's held up by a single DISCUSS, but I > expect > |that to be resolved. > | > |With regards to my I-D, I'd like to go through A-D sponsored instead of > a > |new WG, for obvious reasons. > | > |Any comments/flames are appreciated. > | > |-hadriel > |_______________________________________________ > |dispatch mailing list > |dispatch@ietf.org > |https://www.ietf.org/mailman/listinfo/dispatch From mperumal@cisco.com Sun Aug 22 22:58:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9823A6886 for ; Sun, 22 Aug 2010 22:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.709 X-Spam-Level: X-Spam-Status: No, score=-9.709 tagged_above=-999 required=5 tests=[AWL=0.890, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EbnxfrpKuaE for ; Sun, 22 Aug 2010 22:58:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A82623A67A1 for ; Sun, 22 Aug 2010 22:58:06 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMiqcUxAaMHG/2dsb2JhbACgL3GbM5plhTcEhDOIMA X-IronPort-AV: E=Sophos;i="4.56,255,1280707200"; d="scan'208";a="577315965" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 23 Aug 2010 05:58:39 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7N5vFC0015556; Mon, 23 Aug 2010 05:58:38 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Aug 2010 11:28:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Aug 2010 11:28:24 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> In-Reply-To: <430FC6BDED356B4C8498F634416644A92694381C2C@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActAfxYqhZm2eYqvQqSbEji8cpHjOQADdeLwAAH9gFAAe8v98A== References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 23 Aug 2010 05:58:26.0711 (UTC) FILETIME=[34172A70:01CB4288] Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 05:58:08 -0000 Yes, this is exactly what Cisco implemented 9 years back and hasn't undergone any change since then. But I am not sure what purpose it would solve by just calling it an IETF standard, without addressing some of its limitations for the Internet community. It would be desirable for this DTMF method to address 2 kinds of deployments: 1. PSTN interworking, where it provides the ability for the receiver to generate the DTMF tone in-sync with the user pressing and releasing the button. However, I don't think we need to achieve such precise timing as H.245 signal/signalUpdate messages, by carrying RTP timestamp etc, since the purpose would be to only avoid the detection delay at the receiver. 2. No PSTN interworking, where it provides the ability for a SIP soft-phone to send a DTMF digit to an app server, without having to bother about the duration to the tone.=20 Muthu |-----Original Message----- |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |Sent: Friday, August 20, 2010 11:56 PM |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org |Subject: RE: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package- |00.txt | | |You tell me - afaik it's Cisco's dtmf-relay that everyone's copied (and that |I'm proposing be an info-package, so it can be "legal"). |:) | |-hadriel | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: Friday, August 20, 2010 1:59 PM |> To: Hadriel Kaplan; dispatch@ietf.org |> Subject: RE: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf- |> package-00.txt |> |> Hi Hadriel, |> |> There draft doesn't provide a method to indicate the start of a DTMF |> event and requires the INFO to be generated only when the user releases |> the button. So, in the following scenario where the B2BUAs support only |> the INFO method of sending DTMF events, if the user presses the long |> '#', which typically lasts for 2 - 4 sec, the app server at the far end |> would detect the long '#' only after 6 - 12 sec. |> |> user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN |> GW]--app |> |> Would it be better to provide a way to indicate the start of a DTMF |> event so that the far end can start playing it as soon as the user |> presses the button? It could be indicated using an empty value for |> duration, like this: |> |> Signal=3D # |> Duration=3D |> |> Muthu |> |> |-----Original Message----- |> |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On |> Behalf |> |Of Hadriel Kaplan |> |Sent: Friday, August 20, 2010 9:18 PM |> |To: dispatch@ietf.org |> |Subject: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package- |> |00.txt |> | |> |Howdy, |> |I've submitted an I-D for a DTMF Info-Package, registering it following |> the |> |rules of draft-ietf-sipcore-info-events-08. The info-events draft is |> not in |> |the publication queue yet - it's held up by a single DISCUSS, but I |> expect |> |that to be resolved. |> | |> |With regards to my I-D, I'd like to go through A-D sponsored instead of |> a |> |new WG, for obvious reasons. |> | |> |Any comments/flames are appreciated. |> | |> |-hadriel |> |_______________________________________________ |> |dispatch mailing list |> |dispatch@ietf.org |> |https://www.ietf.org/mailman/listinfo/dispatch From Simo.Veikkolainen@nokia.com Sun Aug 22 23:16:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95313A6971 for ; Sun, 22 Aug 2010 23:16:23 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su3DNdGToNxV for ; Sun, 22 Aug 2010 23:16:22 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 5B28C3A6886 for ; Sun, 22 Aug 2010 23:16:21 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o7N6FsOH013636 for ; Mon, 23 Aug 2010 09:16:54 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Aug 2010 09:16:26 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Aug 2010 09:16:22 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 23 Aug 2010 08:16:07 +0200 From: To: Date: Mon, 23 Aug 2010 08:16:06 +0200 Thread-Topic: I-D Action:draft-veikkolainen-sip-xmpp-coex-reqs-01.txt Thread-Index: ActCgD8WNJER8axeSLuqEyHUehkSoQAChzbQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_B23B311878A0B4438F5F09F47E01AAE050FF07AC33NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 23 Aug 2010 06:16:22.0190 (UTC) FILETIME=[B5203CE0:01CB428A] X-Nokia-AV: Clean Cc: Markus.Isomaki@nokia.com Subject: [dispatch] FW: I-D Action:draft-veikkolainen-sip-xmpp-coex-reqs-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 06:16:24 -0000 --_003_B23B311878A0B4438F5F09F47E01AAE050FF07AC33NOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have just submitted a new version of the SIP-XMPp co-existance requireme= nts draft.=20 This version is just a date update while we are still working on the charte= r text. Regards, Simo >-----Original Message----- >From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- >bounces@ietf.org] On Behalf Of ext Internet-Drafts@ietf.org >Sent: 23 August, 2010 08:00 >To: i-d-announce@ietf.org >Subject: I-D Action:draft-veikkolainen-sip-xmpp-coex-reqs-01.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Requirements and Use Cases for Combining SIP >Based Real-time Media Sessions With XMPP Based Instant Messaging and >Presence Service. > Author(s) : S. Veikkolainen, M. Isomaki > Filename : draft-veikkolainen-sip-xmpp-coex-reqs-01.txt > Pages : 8 > Date : 2010-08-22 > >This memo defines use cases and requirements for combining Session >Initiation Protocol (SIP) based real-time media sessions with Extensible >Messaging and Presence Protocol (XMPP) based instant messaging and >presence services in a seamless manner. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-veikkolainen-sip-xmpp-coex- >reqs-01.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. --_003_B23B311878A0B4438F5F09F47E01AAE050FF07AC33NOKEUMSG01mgd_ Content-Type: message/external-body; name="draft-veikkolainen-sip-xmpp-coex-reqs-01.url" Content-Description: draft-veikkolainen-sip-xmpp-coex-reqs-01.url Content-Disposition: attachment; filename="draft-veikkolainen-sip-xmpp-coex-reqs-01.url"; size=105; creation-date="Mon, 23 Aug 2010 07:01:29 GMT"; modification-date="Mon, 23 Aug 2010 07:01:29 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC12ZWlra29sYWluZW4tc2lwLXhtcHAtY29leC1yZXFzLTAxLnR4dA0K --_003_B23B311878A0B4438F5F09F47E01AAE050FF07AC33NOKEUMSG01mgd_ Content-Type: text/plain; name="ATT00001..txt" Content-Description: ATT00001..txt Content-Disposition: attachment; filename="ATT00001..txt"; size=258; creation-date="Mon, 23 Aug 2010 07:01:29 GMT"; modification-date="Mon, 23 Aug 2010 07:01:29 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K --_003_B23B311878A0B4438F5F09F47E01AAE050FF07AC33NOKEUMSG01mgd_-- From partr@cisco.com Mon Aug 23 06:24:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6BB3A6A4F for ; Mon, 23 Aug 2010 06:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.679 X-Spam-Level: X-Spam-Status: No, score=-8.679 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myCcd4TMqA92 for ; Mon, 23 Aug 2010 06:24:24 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 936DE3A6A49 for ; Mon, 23 Aug 2010 06:24:24 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: Siprec-usecases.txt : 2431 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMYTckxAaMHG/2dsb2JhbACgLXGeKZs4gm2CSgSEM4gw X-IronPort-AV: E=Sophos;i="4.56,257,1280707200"; d="txt'?scan'208";a="243870341" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 23 Aug 2010 13:24:56 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7NDOo5E008718; Mon, 23 Aug 2010 13:24:55 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Aug 2010 18:54:50 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB42C6.905ADCC7" Date: Mon, 23 Aug 2010 18:54:49 +0530 Message-ID: In-Reply-To: <430FC6BDED356B4C8498F634416644A9269438170D@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvzxBsafq1F/F2TyimIJKjLTIAkgADQTWQAABlmWACRNMNFAANh4QwAAOR2WABdSOo8ADurBEg References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> <430FC6BDED356B4C8498F634416644A9269438170D@mail> From: "Parthasarathi R (partr)" To: "Hadriel Kaplan" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" , "Peter Musgrave" X-OriginalArrivalTime: 23 Aug 2010 13:24:50.0691 (UTC) FILETIME=[90962D30:01CB42C6] Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:24:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB42C6.905ADCC7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Hadriel, I put B2BUA-2 in usecase with different application in mind.=20 The main issue is whether the charter is applicable only for troubleshooting or it is the new SIP infrastructure which shall be used for different purpose depends upon the application. In case session-id is possible for the mentioned usecase, session-id shall be used for session loopback identification in B2BUA2 with the combination of other SIP parameters. Without session-id in SIP message, it is not possible to identify the session loopback for all the usecases today.=20 The other way to look at SIP loopback detection in B2BUA/SBC using session-id is as follows: The session loopback detection mechanism in B2BUA/SBC avoids the complicated troubleshooting of loop callflows in B2BUA SIP networks. I'm interested in hearing your and others opinion here. In case B2BUA2 has the intelligence of session-id, it will be possible for B2BUA2 to build the signaling loopback application which is beyond the current scope of SIP SCOTCH. The current charter restricts itself to troubleshooting. IMO, the charter should not restrict the application/usage (troubleshooting) of the generic session-id header rather the charter shall define the "session" like mentioned in Para 2 of current SIP SCOTCH charter. I wish to add the usecase document as a workitem in the charter as it will help in coming up with the proper solution for session-id. Thanks Partha -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Thursday, August 19, 2010 2:07 AM To: Parthasarathi R (partr); Elwell, John; Paul Kyzivat (pkyzivat); Peter Musgrave Cc: dispatch@ietf.org Subject: RE: [dispatch] Proposal for Session ID charter Hi Partha, Right, so this is the re-invite transfer use-case we talked about in Maastricht I believe. I think B2BUA-2 is not necessary in the call flow drawing to show the issue you want to solve, right? It's just B2BUA-1 that's important. Like this: Alice B2BUA1 Bob Carol | | | | |--INV(D1/S1)---->|--INV(D2/S1)-->| | | | | | |<-200(D1/S1)-----|<-200(D2/S1)---| | | | | | |---ACK(D1/S1)--->|--ACK(D2/S1)-->| | | | | | |<=3D=3DAlice Put Bob on Hold (RE-INV/200/ACK S1)=3D=3D=3D=3D> | | | | | |--INV(D4/s2)---->|--INV(D5/S2)------------------->| | | | | |<-200(D4/S2)-----|<-200(D5/s2)--------------------| | | | | |--ACK(D4/S2)---->|--ACK(D5/S2)------------------->| | | | | |<=3D=3D=3DAlice put Carol on Hold (RE-INV/200/ACK S2)=3D=3D>| | | | | | | | | |--REFER/200(D1)->| | | |<-NOTIFY/200(D1)-| | | | |--Re-INV(D2/S?)>| | | | | | | |--Re-INV(D5/S?)---------------->| | | | | | |<--200(D2/S?)---| | | | | | | |<--200(D5/S?)-------------------| | | | | | |---ACK(D2/S?)-->| | | | | | | |---ACK(D5/S?)------------------>| |<-NOTIFY/200(D1)-| | | | | | | |<-BYE/200(D4/S2)-| | | | | | | |-BYE/200(D1/S1)->| | | | | | | In terms of the currently proposed SIPSCOTCH charter, this use-case has no impact, since the charter arguably includes it in scope... of course whether we solve it, or how we solve it, is not answered by the charter and would be a decision for the new WG I think. -hadriel > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Wednesday, August 11, 2010 5:19 AM > To: Elwell, John; Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter=20 > Musgrave >=20 > Thanks for accepting the use case and also for pointing out the flaw=20 > in it. As you already guess, D2 & D5 is between B2BUA1 and B2BUA2, D3=20 > is between B2BUA2 and Bob, D6 is between B2BUA2 and Carol. I updated=20 > the use case and attached with this mail for avoiding the confusion. >=20 > The focus of the use case is to show that session-id may change during > the mid-dialog. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, August 11, 2010 1:04 PM > To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat);=20 > Peter Musgrave > Cc: dispatch@ietf.org > Subject: RE: [dispatch] Proposal for Session ID charter >=20 > Partha, >=20 > I see the point you are making, which sounds reasonable, although I=20 > think the diagram is confusing because separate dialog D2 starts off=20 > between B2BUA1 and B2BUA2, but suddenly changes to being between=20 > B2BUA1 and Bob. Likewise D5 changes its scope. >=20 > John >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R > > (partr) > > Sent: 11 August 2010 02:35 > > To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat=20 > > (pkyzivat); Peter Musgrave > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] Proposal for Session ID charter > > > > Hadriel, > > > > > > > > I attached the use case which illustrates the session-id change=20 > > during >=20 > > mid-dialog. As a individual use case, the use case is used for=20 > > transfer based on "Re-INVITE" mechanism. The use case is useful for=20 > > creating the complex supplementary services when use case is used as > > service primitive. This use case is deployed by B2BUA in Service=20 > > Provider softswitches and Enterprise PBXs. The use case does not=20 > > propose any solution but it just indicates the problem in creating=20 > > the >=20 > > session-id. Even in case session-id is used for troubleshooting=20 > > only, the session-id has to be generic enough to handle this use case. > > Please let me know your thought on this. > > > > > > > > I'll add more usecases based on the response for this mail. > > > > > > > > Thanks > > > > Partha > > > > ________________________________ > > > > From: dispatch-bounces@ietf.org on behalf of Parthasarathi R (partr) > > Sent: Fri 7/30/2010 5:47 PM > > To: Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] Proposal for Session ID charter > > > > > > > > Hadriel, > > > > Instead working with solution in mind, Shall we start with the=20 > > usecases document. The usecase document will help us to decide=20 > > whether >=20 > > the single header or multiple header required. It will help to=20 > > identify the generic session-id if one exists. The usecase=20 > > requirement >=20 > > will be very useful as we are talking about the complex dialog=20 > > scenarios which involves set of B2BUA. > > > > As I mentioned in the earlier mail thread, I'll come up with the=20 > > usecase document as a starting point, add more relevant usecases and > > we will brainstorm whether the usecases are relevant for the session > > id or not. > > Please let me know your opinion on the same. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org]=20 > > On Behalf Of Hadriel Kaplan > > Sent: Friday, July 30, 2010 5:14 PM > > To: Paul Kyzivat (pkyzivat); Peter Musgrave > > Cc: dispatch@ietf.org list > > Subject: Re: [dispatch] Proposal for Session ID charter > > > > > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On > > > Behalf Of Paul Kyzivat > > > Sent: Friday, July 30, 2010 6:08 AM > > > > > > 2) Other applications that require correlation of some class of > > > related dialogs for some purpose other than troubleshooting > > > are driven away, and so must define yet another header and id > > > for their own purposes. > > > > I know adding more headers sucks. But that may be the safest thing. > > > > -hadriel > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > ------_=_NextPart_001_01CB42C6.905ADCC7 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01CB39E3.0A199800" Subject: RE: [dispatch] Proposal for Session ID charter Date: Thu, 12 Aug 2010 11:26:04 +0530 In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: Acs5je8Y/qt7tJTgRLau5RNcym+AaAANpRYg References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> From: "Parthasarathi R (partr)" To: "Peter Musgrave" Cc: "Elwell, John" , "Hadriel Kaplan" , "Paul Kyzivat (pkyzivat)" , This is a multi-part message in MIME format. ------_=_NextPart_002_01CB39E3.0A199800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Peter/all, Thanks for accepting that usecases are useful for this discussion. The = mentioned usecase is not about REFER in B2BUA1, but it is about = Re-INVITE changing the session-id between two B2BUAs. From B2BUA2 = perspective, it does not have any intelligence that REFER received in = B2BUA1. The same RE-INVITE session-id scenario may occurs in B2BUA2 due = to some other trigger. The current Hadriel's session-id solution does = not cover this. I wish that usecase document has to be considered as one = of the work item for this charter to identify which are all the usecases = will be covered by the proposed session-id charter. The main issue is whether the charter is applicable only for = troubleshooting or it is the new SIP infrastructure which shall be used = for different purpose depends upon the application. In case session-id = is possible for the mentioned usecase, session-id shall be used for = session loopback identification in B2BUA2 with the combination of other = SIP parameters. Without session-id in SIP message, it is not possible to = identify the session loopback for all the usecases today.=20 The other way to look at SIP loopback detection in B2BUA/SBC using = session-id is as follows: The session loopback detection mechanism in = B2BUA/SBC avoids the complicated troubleshooting of loop callflows in = B2BUA SIP networks. I'm interested in hearing your and others opinion = here. =20 I attached the mail thread by John Elwell which indicates the session-id = usage in SIPREC. I also attached one of the possible callflow for the = same. SIPREC is yet to define the callflows, so the callflow may change. = Thanks Partha =20 -----Original Message----- From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 Sent: Thursday, August 12, 2010 1:17 AM To: Parthasarathi R (partr) Cc: Elwell, John; Hadriel Kaplan; Paul Kyzivat (pkyzivat); = dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter Hi, I agree use cases like this are useful. I think they are covered by the = part of the charter which indicates that the specific behaviour under = REFER will be defined. It may not be what is ideal for every scenario - = but the behaviour will be predictable. I think the main issue w.r.t the charter is whether siprec needs = something like session-id (and if that something requires dialog = correlation - which the current session-id does not claim to provide). The path forward to me seems to be 1) go down the dialog correlation rabbit hole - or - 2) re-label this into something more representative of it's purpose = (i.e. Debug-Tag:) and keep the scope narrow. Peter On Wed, Aug 11, 2010 at 5:18 AM, Parthasarathi R (partr) = wrote: > John, > > Thanks for accepting the use case and also for pointing out the flaw=20 > in it. As you already guess, D2 & D5 is between B2BUA1 and B2BUA2, D3=20 > is between B2BUA2 and Bob, D6 is between B2BUA2 and Carol. I updated=20 > the use case and attached with this mail for avoiding the confusion. > > The focus of the use case is to show that session-id may change during = > the mid-dialog. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, August 11, 2010 1:04 PM > To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat);=20 > Peter Musgrave > Cc: dispatch@ietf.org > Subject: RE: [dispatch] Proposal for Session ID charter > > Partha, > > I see the point you are making, which sounds reasonable, although I=20 > think the diagram is confusing because separate dialog D2 starts off=20 > between B2BUA1 and B2BUA2, but suddenly changes to being between=20 > B2BUA1 and Bob. Likewise D5 changes its scope. > > John > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R >> (partr) >> Sent: 11 August 2010 02:35 >> To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat); = >> Peter Musgrave >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Proposal for Session ID charter >> >> Hadriel, >> >> >> >> I attached the use case which illustrates the session-id change=20 >> during > >> mid-dialog. As a individual use case, the use case is used for=20 >> transfer based on "Re-INVITE" mechanism. The use case is useful for=20 >> creating the complex supplementary services when use case is used as=20 >> service primitive. This use case is deployed by B2BUA in Service=20 >> Provider softswitches and Enterprise PBXs. The use case does not=20 >> propose any solution but it just indicates the problem in creating=20 >> the > >> session-id. Even in case session-id is used for troubleshooting only, = >> the session-id has to be generic enough to handle this use case. >> Please let me know your thought on this. >> >> >> >> I'll add more usecases based on the response for this mail. >> >> >> >> Thanks >> >> Partha >> >> ________________________________ >> >> From: dispatch-bounces@ietf.org on behalf of Parthasarathi R (partr) >> Sent: Fri 7/30/2010 5:47 PM >> To: Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Proposal for Session ID charter >> >> >> >> Hadriel, >> >> Instead working with solution in mind, Shall we start with the=20 >> usecases document. The usecase document will help us to decide=20 >> whether > >> the single header or multiple header required. It will help to=20 >> identify the generic session-id if one exists. The usecase=20 >> requirement > >> will be very useful as we are talking about the complex dialog=20 >> scenarios which involves set of B2BUA. >> >> As I mentioned in the earlier mail thread, I'll come up with the=20 >> usecase document as a starting point, add more relevant usecases and=20 >> we will brainstorm whether the usecases are relevant for the session=20 >> id or not. >> Please let me know your opinion on the same. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = >> Behalf Of Hadriel Kaplan >> Sent: Friday, July 30, 2010 5:14 PM >> To: Paul Kyzivat (pkyzivat); Peter Musgrave >> Cc: dispatch@ietf.org list >> Subject: Re: [dispatch] Proposal for Session ID charter >> >> >> >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On >> > Behalf Of Paul Kyzivat >> > Sent: Friday, July 30, 2010 6:08 AM >> > >> > 2) Other applications that require correlation of some class of >> > =A0 =A0 related dialogs for some purpose other than troubleshooting >> > =A0 =A0 are driven away, and so must define yet another header and = id >> > =A0 =A0 for their own purposes. >> >> I know adding more headers sucks. =A0But that may be the safest = thing. >> >> -hadriel >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> > ------_=_NextPart_002_01CB39E3.0A199800 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from xbh-bgl-411.cisco.com ([72.163.129.201]) by xmb-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 14:18:57 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from xbh-rcd-202.cisco.com ([72.163.62.201]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 14:18:57 +0530 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 03:48:54 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 05 Aug 2010 08:48:53 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o758mqNq001637; Thu, 5 Aug 2010 08:48:53 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-f.cisco.com with ESMTP; 05 Aug 2010 08:48:52 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273EA3A68D8; Thu, 5 Aug 2010 01:48:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B203A69B9 for ; Thu, 5 Aug 2010 01:48:20 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsNCV+0KYWsD for ; Thu, 5 Aug 2010 01:48:19 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D43CE3A6829 for ; Thu, 5 Aug 2010 01:48:18 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1076574; Thu, 5 Aug 2010 10:48:47 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C54C21EB82AB; Thu, 5 Aug 2010 10:48:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 5 Aug 2010 10:48:47 +0200 Content-class: urn:content-classes:message Subject: Re: [siprec] Session-id proposal in DISPATCH Date: Thu, 5 Aug 2010 14:18:46 +0530 Message-ID: In-Reply-To: <4C598B67.80906@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Session-id proposal in DISPATCH Thread-Index: Acsz7EBMS5K0KeTQSuWeeSRzqcX0dQAit/IA References: <4C598B67.80906@cisco.com> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Elwell, John" Sender: To: "Paul Kyzivat (pkyzivat)" Cc: In fact there are at least two cases where there are multiple RSs for a = single CS (in its broader sense). 1. Where there is a single SRC, which has time-separated RSs to the SRS = (because recording is stopped and started again). This should not be a = problem, because presumably the single SRC could provide appropriate = metadata to correlate the two RSs as belonging to the same CS. 2. Where there are different SRCs, each with an RS to the SRS - these = can be simultaneous, overlapping or time-separated). This is the case = where some form of session-id might help. However, it is quite difficult to write requirements for case 2, because = of getting agreement on the precise circumstances in which two SIP = dialogs at different entities can be considered to be the same CS. = Features such as attended transfer, unattended transfer, local = conferencing, centralized conferencing, shared appearance bridging, = etc., can all be involved, and these can be implemented in different = ways (end-to-end, 3PCC). Getting agreement on exactly how a mediating = SIP entity (UA/B2BUA) should behave in ensuring that appropriate SIP = dialogs are given the same session-id and that others are given a = different session-id sounds like it could be a nightmare. Furthermore, = the mediating SIP entity might not be SIPREC-compliant, and therefore = would not be obliged to support whatever session-id mechanism SIPREC = might mandate. For example, consider the case where there is an SRC at an agent's UA = (or at a B2BUA serving the agent), and an SRC at a supervisor's UA (or = at a B2BUA serving the supervisor). The agent's UA transfers a call = (unattended) to the supervisor by sending a REFER request to the remote = UA (say a PSTN gateway). If that remote UA does not support whatever = session-id mechanism SIPREC requires, it might not be possible to = achieve correlation. So I have doubts whether we are in a position to specify precise = requirements in a form that would solve case 2 in the vast majority of = situations. In the absence of a session-id usable for this purpose, we = are back to the SRS using heuristics (e.g., recording start/stop times, = caller ID, CCUS content, etc..) to correlate two CSs from different = SRCs. John (as individual) > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 04 August 2010 16:47 > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] Session-id proposal in DISPATCH >=20 > To follow up on this we need to get some homework done here=20 > in siprec,=20 > to know what correlations we need help with. >=20 > I think session-id is not needed for siprec in those cases where a=20 > single SRC is managing an RC. It can then provide all the needed=20 > correlation data itself. >=20 > ISTM the case where session-id is useful is when there are=20 > multiple RS=20 > that involve a single CS (in the loose sense, since we don't=20 > yet have a=20 > clear def of CS.) Then it may be up to the SRS to recognize the=20 > correlation, so session-id could be useful. >=20 > I don't think we (yet) have enough facts to turn that need into=20 > requirements on session-id. >=20 > Thanks, > Paul >=20 > Elwell, John wrote: > > DISPATCH is considering a proposed charter for a WG to=20 > specify a session-id header field for correlating dialogs=20 > belonging to the same session across B2BUAs. At present, it=20 > is being specified only for troubleshooting purposes. > >=20 > > During some of the discussions in SIPREC, I have sensed=20 > that there may be a need for correlating recordings that=20 > derive from the same communication session. If so, I don't=20 > know whether reuse of the proposed session-id would be a=20 > candidate solution. The present scoping of the session-id=20 > charter, whilst not necessarily preventing its reuse for=20 > SIPREC purposes, may not be adequate, depending on exact=20 > requirements from SIPREC. Thus we may end up defining yet=20 > another mechanism for correlation, where a single mechanism,=20 > adequately scoped, would have sufficed. > >=20 > > I would urge anyone who expects the session-id charter to=20 > deliver a solution suitable for SIPREC use to engage in=20 > discussions on the DISPATCH list, e.g., in the following thread: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg02426.html > >=20 > > The SIPREC list can, of course, be used to discuss SIPREC=20 > requirements in this area, but please do not cross-post. Use: > > - the SIPREC list to discuss requirements for correlation; > > - the DISPATCH list to influence the Session-ID charter,=20 > based on requirements from SIPREC. > >=20 > > John > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_002_01CB39E3.0A199800 Content-Type: text/plain; name="Siprec-usecases.txt" Content-Transfer-Encoding: base64 Content-Description: Siprec-usecases.txt Content-Disposition: attachment; filename="Siprec-usecases.txt" VXNlY2FzZSAyOiBTZXNzaW9uLWlkIHVzYWdlIGluIERpc3RyaWJ1dGVkIFNSQyB3aXRoIFNpbmds ZSBTUlMgKEpvaG4gRWx3ZWxsIFNJUFJFQyBjYWxsZmxvdykNCg0KTXVsdGlwbGUgU2Vzc2lvbiBS ZWNvcmRpbmcgY2xpZW50IChTUkMpIG1heSBiZSB1c2VkIGZvciByZWNvcmRpbmcgdGhlIHNpbmds ZSBjb21tdW5pY2F0aW9uIHNlc3Npb24gdG8gdGhlIHNhbWUgU2Vzc2lvbiBSZWNvcmRpbmcgU2Vy dmVyIChTUlMpLiBNdWx0aXBsZSBTUkMgYXJlIGNvbm5lY3RlZCB0aHJvdWdoIEIyQlVBLiBUaGlz IGRlcGxveW1lbnQgbm9ybWFsbHkgY29tZXMgd2hlbiB0aGUgZW5kcG9pbnQgcGVyZm9ybXMgdGhl IHVuaWRpcmVjdGlvbmFsIG1lZGlhIHJlY29yZGluZyAoVHggcmVjb3JkaW5nIG9ubHkpIGluc3Rl YWQgb2YgYmlkaXJlY3Rpb25hbCByZWNvcmRpbmcgKFR4L1J4IHJlY29yZGluZykuIFNSUyBoYXMg dG8gbWVyZ2UgYm90aCB0aGUgZGlhbG9ncyBiYXNlZCBvbiB0aGUgcmVjZWl2ZWQgbWV0YWRhdGEu IA0KDQpUb3BvbG9neToNCg0KICAgICAgICAgICAgIFNSQzEtLS0tLUIyQlVBLS0tLVNSQzItLS0t LS1TUlMNCiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIA0KICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkIyQlVBIG9wZXJhdGVzIGluIDNQQ0MgbW9k ZS4gRWFjaCBkaWFsb2cgaXMgY3JlYXRlZCB3aXRoIElOVklURS8yMDAvQUNLIHNlcXVlbmNlLiBJ biB0aGUgYmVsb3cgZGlhZ3JhbSwgZGlhbG9nLWlkIGlzIHJlcHJlc2VudGVkIGJ5ICJEIiwgc2Vz c2lvbi1pZCBpcyByZXByZXNlbnRlZCBieSAiUyIgYW5kIG1ldGFkYXRhIHVuaXF1ZSAoc2Vzc2lv bikgaWQgYnkgIk1TIi4NCg0KVGhlIENhbGxmbG93IGlzIGFzIGZvbGxvd3M6DQoNCjEpIFNSQzEg ZXN0YWJsaXNoZXMgc2Vzc2lvbiB0byBTUkMyIHRocm91Z2ggQjJCVUENCjIpIFNSQzEgJiBTUkMy IGluaXRpYXRlcyByZWNvcmRpbmcgdG93YXJkcyBTUlMNCg0KICANCiBTUkMxICAgICAgICAgICAg QjJCVUEgICAgICAgICAgICAgU1JDMiAgICAgICAgICAgICAgIFNSUyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgDQog fC0tSU5WKEQxL1MxKS0tLS0+fC0tSU5WKEQyL1MxKS0tLS0+fCAgICAgICAgICAgICAgICAgfCAg ICANCiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICB8DQogfC1JTlYoRDMvUzIvTVMxKS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0+fA0KIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgIHwNCiB8PC0yMDAoRDEvUzEpLS0tLS18PC0yMDAoRDIvUzEpLS0tLS18ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgDQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg fC1JTlYoRDQvUzMvTVMxKS0+fA0KIHwtLUFDSyhEMS9TMSktLS0tPnwtLUFDSyhEMi9TMSktLS0t PnwgICAgICAgICAgICAgICAgIHwNCiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICB8DQogfDwtMjAwKEQzL1MyL01TMSktLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tfCANCiB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICB8DQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgfDwtMjAwKEQ0L1MzL01TMSktfA0KIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgIHwNCiB8LS1BQ0soRDMvUzIvTVMxKS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQogfCAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgfA0KIHwgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgIHwtQUNLKEQ0L1MzL01TMSktPnwNCg0KSW4gdGhlIGFib3ZlIGRpYWdyYW0sIFNS QzEgYW5kIFNSQzIgaGF2ZSBubyB1bmlxdWUtaWQgZm9yIHRoZSBzZXNzaW9uIGFzIHRoZSBjYWxs LWlkIHdpbGwgYmUgb3ZlcnJpZGRlbiBieSBCMkJVQS4gSW4gY2FzZSBzZXNzaW9uIGlkIGV4aXN0 IGJldHdlZW4gU1JDMSBhbmQgU1JDMiBkdXJpbmcgdGhlIGNhbGwgZXN0YWJsaXNobWVudCwgU1JD MSBhbmQgU1JDMiB3aWxsIHBhc3MgdGhlIHNlc3Npb24taWQgKFMxKSBpbiB0aGUgbWV0YWRhdGEg dG93YXJkcyBTUlMgZm9yIHRoZSBsYXRlciByZXRyaWV2YWwuIA== ------_=_NextPart_002_01CB39E3.0A199800-- ------_=_NextPart_001_01CB42C6.905ADCC7-- From pkyzivat@cisco.com Mon Aug 23 06:28:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2123A6A35 for ; Mon, 23 Aug 2010 06:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.375 X-Spam-Level: X-Spam-Status: No, score=-110.375 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F1JvCZaCet8 for ; Mon, 23 Aug 2010 06:28:42 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DB4393A6A1A for ; Mon, 23 Aug 2010 06:28:41 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYFAD8UckxAZnwM/2dsb2JhbACTJY0IcZ44mziFNwSJdg X-IronPort-AV: E=Sophos;i="4.56,257,1280707200"; d="scan'208";a="150672642" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2010 13:29:15 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7NDTFnQ009410; Mon, 23 Aug 2010 13:29:15 GMT Message-ID: <4C7277AA.7070608@cisco.com> Date: Mon, 23 Aug 2010 09:29:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, Markus.Isomaki@nokia.com Subject: Re: [dispatch] FW: I-D Action:draft-veikkolainen-sip-xmpp-coex-reqs-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:28:43 -0000 This seems clear and straightforward. As much as I wish we weren't in a position where we need to do this, we are, so I'm in favor. One nit (I think). The third use case ends in the middle of a sentence: A user who has obtained another user's SIP URI is able to discover the other user's XMPP URI so that she can send the other user XMPP IM or subscribe to the other user's presence, or just populate her address book for futher use. The user is able to do this without bothering the other user, provided the other user has pre- authorized the operation. but I gather there was more to say that was omitted. Thanks, Paul Simo.Veikkolainen@nokia.com wrote: > We have just submitted a new version of the SIP-XMPp co-existance requirements draft. > > This version is just a date update while we are still working on the charter text. > > Regards, > Simo > >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- >> bounces@ietf.org] On Behalf Of ext Internet-Drafts@ietf.org >> Sent: 23 August, 2010 08:00 >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-veikkolainen-sip-xmpp-coex-reqs-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Requirements and Use Cases for Combining SIP >> Based Real-time Media Sessions With XMPP Based Instant Messaging and >> Presence Service. >> Author(s) : S. Veikkolainen, M. Isomaki >> Filename : draft-veikkolainen-sip-xmpp-coex-reqs-01.txt >> Pages : 8 >> Date : 2010-08-22 >> >> This memo defines use cases and requirements for combining Session >> Initiation Protocol (SIP) based real-time media sessions with Extensible >> Messaging and Presence Protocol (XMPP) based instant messaging and >> presence services in a seamless manner. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-veikkolainen-sip-xmpp-coex- >> reqs-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Mon Aug 23 07:06:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B8B3A6A3F; Mon, 23 Aug 2010 07:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4arfVqHT1LHS; Mon, 23 Aug 2010 07:06:10 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A6AED3A6A11; Mon, 23 Aug 2010 07:06:10 -0700 (PDT) Received: by iwn3 with SMTP id 3so6366330iwn.31 for ; Mon, 23 Aug 2010 07:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=gVqwmaDx2xzlFvvSXY59YmXhfMdxQ+PeTcRo405hkQQ=; b=JT9Q3+eOTaFca86Ut3Y1tDrDmdnYV+nsBRQH6I46dAJPAdXu3mEURBPDHYzstndDOL XpR0o+z+zzRG1U4/7CjXhOqVsRJQwDOVLJnwuNEYaD0lf+ej6m0nZxypkY1oQe8DvxNJ 3OHiX1LtUsalEHJFa4yqjOeK0XqLbNMll9XuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=eB75emboPs6Tj8/X+yVePPDoh/WWA0/taD4SsEqFoap8637xpaFKghC3eTQ3qYdGq+ Bj57hsjtBZVn5xAOO2OHLmoxDkEnNvgGyBGOvTzenEUdaqeYlZif2HpEebtpZlU9AuVa aM8dItzSWkM8PM66xo8EJ5CFa24bA+1UuSdp8= MIME-Version: 1.0 Received: by 10.231.39.201 with SMTP id h9mr6437115ibe.118.1282572403246; Mon, 23 Aug 2010 07:06:43 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Mon, 23 Aug 2010 07:06:42 -0700 (PDT) Date: Mon, 23 Aug 2010 09:06:42 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=00032555cf9a7eb50e048e7e2872 Cc: rai@ietf.org, rai-ads@tools.ietf.org Subject: [dispatch] Reminder: DISPATCH deadlines for IETF-79 - One week left to notify us of plans to submit proposals X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 14:06:12 -0000 --00032555cf9a7eb50e048e7e2872 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Another reminder - the deadline for IETF-79 topics for DISPATCH is next Monday, August 30th (5 pm PST). Thanks, Mary. On Fri, Aug 13, 2010 at 11:37 AM, Mary Barnes wrote: > Hi all, > > Just a reminder that the first deadline for IETF-79 for the DISPATCH WG > topics is two weeks from Monday. > > Regards, > Mary. > > On Thu, Jul 29, 2010 at 10:20 AM, Mary Barnes wrote: > >> Hi folks, >> >> The following summarizes the deadlines for topics for DISPATCH for >> IETF-79: >> >> * August 30, 2010. Cutoff date to notify the chairs/DISPATCH WG of >> plans to submit a proposal. [Two weeks prior to BoF proposal deadline] >> >> * Sept. 6, 2010. Cutoff for charter proposals for topics. [One week prior >> to BoF proposal deadline] >> >> >> * Sept. 20, 2010. Topics that are to be the focus of IETF-79 >> are announced. >> [One week before deadline to request WG slots] >> >> * Oct. 18th, 2010. -00 draft deadline. >> >> * Oct. 25th, 2010. Draft deadline. >> >> These deadlines have been published on the DISPATCH WG wiki page: >> http://trac.tools.ietf.org/wg/dispatch/trac/wiki >> >> Note that these dates are closer to the end of the meeting than those >> for IETF-78 because there is just over 3 months between the end of IETF-78 >> and beginning of IETF-79 (versus the 4 months we had between this meeting >> and Anaheim). >> >> Note that registration and WG/Bof scheduling for IETF-79 starts on August >> 9th: >> http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF79 >> >> DISPATCH sets the first deadline such that it's still possible to request >> a BoF for topics that may be wider in scope and require broader community >> review. The deadlines for BoFs are set by the leadership so that there is >> time to consider BoFs in the scheduling. Also, as Gonzalo noted in a >> separate email, WGs need to have a draft charter at the time they request a >> WG slot. Further information on the motivation for the DISPATCH planning >> model is provided in the wiki. >> >> Regards, >> Mary >> DISPATCH WG co-chair >> >> > --00032555cf9a7eb50e048e7e2872 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0
Another reminder - the deadline for IETF-79=A0 topics for DISPATCH is = next Monday, August 30th (5 pm PST).
=A0
Thanks,
Mary.

On Fri, Aug 13, 2010 at 11:37 AM, Mary Barnes <mary.ietf= .barnes@gmail.com> wrote:
Hi all,=A0=20

Just a reminder that the first deadline for IETF-79 for the DISPATCH W= G topics is two weeks from Monday. =A0

Regards,
Mary.=A0

On Thu, Jul 29, 2010 at 10:20 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Hi folks,

The following summarizes the deadlines for topics for= DISPATCH for IETF-79:=20

* August 30, 2010. Cutoff date to notify the chairs/DISPATCH WG of
= =A0=A0plans to submit a proposal. [Two weeks prior to BoF proposal deadline= ]

* Sept. 6, 2010. Cutoff for charter proposals for topics. [O= ne week prior to BoF proposal deadline]=20


* Sept. 20, 2010. Topics that are to be the focus of IETF-79 a= re=A0announced.
=A0=A0[One week before deadline to request WG=A0slots]

* Oct. 18= th, 2010. -00 draft deadline.

* Oct. 25th, 2010. Draft deadline.
=
These deadlines have been published on the DISPATCH WG wiki page:
http://trac.tools.ietf.org/wg/dispatch/trac/w= iki=A0

Note that these dates are closer to the end of the meeting than those f= or IETF-78 =A0because there is just over 3 months between the end of IETF-7= 8 and beginning of IETF-79 (versus the 4 months we had between this meeting= and Anaheim).=A0
=A0
Note that registration and WG/Bof scheduling for IETF-79 starts on Augu= st 9th:

DISPATCH sets the first deadline such that it's still possible to r= equest a BoF for topics that may be wider in scope and require broader comm= unity review. =A0The deadlines for BoFs are set by the leadership so that t= here is time to consider BoFs in the scheduling. Also, as Gonzalo noted in = a separate email, WGs need to have a draft charter at the time they request= a WG slot. =A0Further information on the motivation for the DISPATCH plann= ing model =A0is provided in the wiki.

Regards,
Mary
DISPATCH WG co-chair


--00032555cf9a7eb50e048e7e2872-- From HKaplan@acmepacket.com Mon Aug 23 09:02:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7AFC3A6991 for ; Mon, 23 Aug 2010 09:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTf43hXRy97O for ; Mon, 23 Aug 2010 09:02:42 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3217E3A6A59 for ; Mon, 23 Aug 2010 09:02:42 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 23 Aug 2010 12:03:15 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 23 Aug 2010 12:03:15 -0400 From: Hadriel Kaplan To: "Muthu ArulMozhi Perumal (mperumal)" , "dispatch@ietf.org" Date: Mon, 23 Aug 2010 12:03:13 -0400 Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActAfxYqhZm2eYqvQqSbEji8cpHjOQADdeLwAAH9gFAAe8v98AAV1Chw Message-ID: <430FC6BDED356B4C8498F634416644A92694381E9F@mail> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.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 Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 16:02:43 -0000 The reason I'm proposing to generate an RFC for it, without substantively c= hanging it, is: 1) Stop it from being a proprietary (albeit industry defacto) mechanism. 2) Register the MIME type name. 3) Provide a static, numbered, public document for implementers and users t= o reference, as opposed to a specific company's changing config-documentati= on URLs. -hadriel > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Monday, August 23, 2010 1:58 AM >=20 > Yes, this is exactly what Cisco implemented 9 years back and hasn't > undergone any change since then. But I am not sure what purpose it would > solve by just calling it an IETF standard, without addressing some of > its limitations for the Internet community. >=20 > It would be desirable for this DTMF method to address 2 kinds of > deployments: > 1. PSTN interworking, where it provides the ability for the receiver to > generate the DTMF tone in-sync with the user pressing and releasing the > button. However, I don't think we need to achieve such precise timing as > H.245 signal/signalUpdate messages, by carrying RTP timestamp etc, since > the purpose would be to only avoid the detection delay at the receiver. >=20 > 2. No PSTN interworking, where it provides the ability for a SIP > soft-phone to send a DTMF digit to an app server, without having to > bother about the duration to the tone. >=20 > Muthu >=20 > |-----Original Message----- > |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > |Sent: Friday, August 20, 2010 11:56 PM > |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org > |Subject: RE: [dispatch] I-D > Action:draft-kaplan-dispatch-info-dtmf-package- > |00.txt > | > | > |You tell me - afaik it's Cisco's dtmf-relay that everyone's copied (and > that > |I'm proposing be an info-package, so it can be "legal"). > |:) > | > |-hadriel > | > |> -----Original Message----- > |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > |> Sent: Friday, August 20, 2010 1:59 PM > |> To: Hadriel Kaplan; dispatch@ietf.org > |> Subject: RE: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf- > |> package-00.txt > |> > |> Hi Hadriel, > |> > |> There draft doesn't provide a method to indicate the start of a DTMF > |> event and requires the INFO to be generated only when the user > releases > |> the button. So, in the following scenario where the B2BUAs support > only > |> the INFO method of sending DTMF events, if the user presses the long > |> '#', which typically lasts for 2 - 4 sec, the app server at the far > end > |> would detect the long '#' only after 6 - 12 sec. > |> > |> > user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN > |> GW]--app > |> > |> Would it be better to provide a way to indicate the start of a DTMF > |> event so that the far end can start playing it as soon as the user > |> presses the button? It could be indicated using an empty value for > |> duration, like this: > |> > |> Signal=3D # > |> Duration=3D > |> > |> Muthu > |> > |> |-----Original Message----- > |> |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > |> Behalf > |> |Of Hadriel Kaplan > |> |Sent: Friday, August 20, 2010 9:18 PM > |> |To: dispatch@ietf.org > |> |Subject: [dispatch] I-D > Action:draft-kaplan-dispatch-info-dtmf-package- > |> |00.txt > |> | > |> |Howdy, > |> |I've submitted an I-D for a DTMF Info-Package, registering it > following > |> the > |> |rules of draft-ietf-sipcore-info-events-08. The info-events draft > is > |> not in > |> |the publication queue yet - it's held up by a single DISCUSS, but I > |> expect > |> |that to be resolved. > |> | > |> |With regards to my I-D, I'd like to go through A-D sponsored instead > of > |> a > |> |new WG, for obvious reasons. > |> | > |> |Any comments/flames are appreciated. > |> | > |> |-hadriel > |> |_______________________________________________ > |> |dispatch mailing list > |> |dispatch@ietf.org > |> |https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Mon Aug 23 09:20:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB5B3A68BF for ; Mon, 23 Aug 2010 09:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.491 X-Spam-Level: X-Spam-Status: No, score=-110.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLkc7n1jC+Pb for ; Mon, 23 Aug 2010 09:20:34 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8A2843A689C for ; Mon, 23 Aug 2010 09:20:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,258,1280707200"; d="scan'208";a="150924675" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2010 16:21:03 +0000 Received: from [161.44.182.214] (dhcp-161-44-182-214.cisco.com [161.44.182.214]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7NGL3hQ022309; Mon, 23 Aug 2010 16:21:03 GMT Message-ID: <4C729FEF.6020509@cisco.com> Date: Mon, 23 Aug 2010 12:21:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A92694381E9F@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 16:20:36 -0000 Hadriel, I think this is not as benign as it seems. The problem is that even though it is *essentially* the same, it is not *exactly* the same as what is currently implemented in the field. Hence moving to this also requires *some* (small) effort. And there will be things that still do it the old way. So there are interop considerations to take into account. For a data point, in Cisco we have *five* mechanisms (that I know of) for DTMF transport in sip that we support and use one way or another. There are complex negotiation and configuration mechanisms for deciding what to use, and we often have to convert between them. This proposal would just increase that number from 5 to 6. So lets not do it without careful consideration. Thanks, Paul Hadriel Kaplan wrote: > The reason I'm proposing to generate an RFC for it, without substantively changing it, is: > > 1) Stop it from being a proprietary (albeit industry defacto) mechanism. > 2) Register the MIME type name. > 3) Provide a static, numbered, public document for implementers and users to reference, as opposed to a specific company's changing config-documentation URLs. > > -hadriel > >> -----Original Message----- >> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >> Sent: Monday, August 23, 2010 1:58 AM >> >> Yes, this is exactly what Cisco implemented 9 years back and hasn't >> undergone any change since then. But I am not sure what purpose it would >> solve by just calling it an IETF standard, without addressing some of >> its limitations for the Internet community. >> >> It would be desirable for this DTMF method to address 2 kinds of >> deployments: >> 1. PSTN interworking, where it provides the ability for the receiver to >> generate the DTMF tone in-sync with the user pressing and releasing the >> button. However, I don't think we need to achieve such precise timing as >> H.245 signal/signalUpdate messages, by carrying RTP timestamp etc, since >> the purpose would be to only avoid the detection delay at the receiver. >> >> 2. No PSTN interworking, where it provides the ability for a SIP >> soft-phone to send a DTMF digit to an app server, without having to >> bother about the duration to the tone. >> >> Muthu >> >> |-----Original Message----- >> |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> |Sent: Friday, August 20, 2010 11:56 PM >> |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org >> |Subject: RE: [dispatch] I-D >> Action:draft-kaplan-dispatch-info-dtmf-package- >> |00.txt >> | >> | >> |You tell me - afaik it's Cisco's dtmf-relay that everyone's copied (and >> that >> |I'm proposing be an info-package, so it can be "legal"). >> |:) >> | >> |-hadriel >> | >> |> -----Original Message----- >> |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >> |> Sent: Friday, August 20, 2010 1:59 PM >> |> To: Hadriel Kaplan; dispatch@ietf.org >> |> Subject: RE: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf- >> |> package-00.txt >> |> >> |> Hi Hadriel, >> |> >> |> There draft doesn't provide a method to indicate the start of a DTMF >> |> event and requires the INFO to be generated only when the user >> releases >> |> the button. So, in the following scenario where the B2BUAs support >> only >> |> the INFO method of sending DTMF events, if the user presses the long >> |> '#', which typically lasts for 2 - 4 sec, the app server at the far >> end >> |> would detect the long '#' only after 6 - 12 sec. >> |> >> |> >> user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN >> |> GW]--app >> |> >> |> Would it be better to provide a way to indicate the start of a DTMF >> |> event so that the far end can start playing it as soon as the user >> |> presses the button? It could be indicated using an empty value for >> |> duration, like this: >> |> >> |> Signal= # >> |> Duration= >> |> >> |> Muthu >> |> >> |> |-----Original Message----- >> |> |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On >> |> Behalf >> |> |Of Hadriel Kaplan >> |> |Sent: Friday, August 20, 2010 9:18 PM >> |> |To: dispatch@ietf.org >> |> |Subject: [dispatch] I-D >> Action:draft-kaplan-dispatch-info-dtmf-package- >> |> |00.txt >> |> | >> |> |Howdy, >> |> |I've submitted an I-D for a DTMF Info-Package, registering it >> following >> |> the >> |> |rules of draft-ietf-sipcore-info-events-08. The info-events draft >> is >> |> not in >> |> |the publication queue yet - it's held up by a single DISCUSS, but I >> |> expect >> |> |that to be resolved. >> |> | >> |> |With regards to my I-D, I'd like to go through A-D sponsored instead >> of >> |> a >> |> |new WG, for obvious reasons. >> |> | >> |> |Any comments/flames are appreciated. >> |> | >> |> |-hadriel >> |> |_______________________________________________ >> |> |dispatch mailing list >> |> |dispatch@ietf.org >> |> |https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From peter.musgrave@magorcorp.com Mon Aug 23 09:22:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5283A67B4 for ; Mon, 23 Aug 2010 09:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.139 X-Spam-Level: X-Spam-Status: No, score=-101.139 tagged_above=-999 required=5 tests=[AWL=0.838, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWeKGfNGWey1 for ; Mon, 23 Aug 2010 09:22:53 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 2F2043A6358 for ; Mon, 23 Aug 2010 09:22:53 -0700 (PDT) Received: by gwb20 with SMTP id 20so2578943gwb.31 for ; Mon, 23 Aug 2010 09:23:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.188.1 with SMTP id z1mr4711788wem.57.1282580605487; Mon, 23 Aug 2010 09:23:25 -0700 (PDT) Received: by 10.216.156.83 with HTTP; Mon, 23 Aug 2010 09:23:25 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A92694381E9F@mail> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> Date: Mon, 23 Aug 2010 12:23:25 -0400 Message-ID: From: Peter Musgrave To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 16:22:54 -0000 HI Hadriel, I concur. I would like to have it written down somewhere more or less "as-i= s". Peter Musgrave On Mon, Aug 23, 2010 at 12:03 PM, Hadriel Kaplan w= rote: > > The reason I'm proposing to generate an RFC for it, without substantively= changing it, is: > > 1) Stop it from being a proprietary (albeit industry defacto) mechanism. > 2) Register the MIME type name. > 3) Provide a static, numbered, public document for implementers and users= to reference, as opposed to a specific company's changing config-documenta= tion URLs. > > -hadriel > >> -----Original Message----- >> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >> Sent: Monday, August 23, 2010 1:58 AM >> >> Yes, this is exactly what Cisco implemented 9 years back and hasn't >> undergone any change since then. But I am not sure what purpose it would >> solve by just calling it an IETF standard, without addressing some of >> its limitations for the Internet community. >> >> It would be desirable for this DTMF method to address 2 kinds of >> deployments: >> 1. PSTN interworking, where it provides the ability for the receiver to >> generate the DTMF tone in-sync with the user pressing and releasing the >> button. However, I don't think we need to achieve such precise timing as >> H.245 signal/signalUpdate messages, by carrying RTP timestamp etc, since >> the purpose would be to only avoid the detection delay at the receiver. >> >> 2. No PSTN interworking, where it provides the ability for a SIP >> soft-phone to send a DTMF digit to an app server, without having to >> bother about the duration to the tone. >> >> Muthu >> >> |-----Original Message----- >> |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> |Sent: Friday, August 20, 2010 11:56 PM >> |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org >> |Subject: RE: [dispatch] I-D >> Action:draft-kaplan-dispatch-info-dtmf-package- >> |00.txt >> | >> | >> |You tell me - afaik it's Cisco's dtmf-relay that everyone's copied (and >> that >> |I'm proposing be an info-package, so it can be "legal"). >> |:) >> | >> |-hadriel >> | >> |> -----Original Message----- >> |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >> |> Sent: Friday, August 20, 2010 1:59 PM >> |> To: Hadriel Kaplan; dispatch@ietf.org >> |> Subject: RE: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf- >> |> package-00.txt >> |> >> |> Hi Hadriel, >> |> >> |> There draft doesn't provide a method to indicate the start of a DTMF >> |> event and requires the INFO to be generated only when the user >> releases >> |> the button. So, in the following scenario where the B2BUAs support >> only >> |> the INFO method of sending DTMF events, if the user presses the long >> |> '#', which typically lasts for 2 - 4 sec, the app server at the far >> end >> |> would detect the long '#' only after 6 - 12 sec. >> |> >> |> >> user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN >> |> GW]--app >> |> >> |> Would it be better to provide a way to indicate the start of a DTMF >> |> event so that the far end can start playing it as soon as the user >> |> presses the button? It could be indicated using an empty value for >> |> duration, like this: >> |> >> |> Signal=3D # >> |> Duration=3D >> |> >> |> Muthu >> |> >> |> |-----Original Message----- >> |> |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On >> |> Behalf >> |> |Of Hadriel Kaplan >> |> |Sent: Friday, August 20, 2010 9:18 PM >> |> |To: dispatch@ietf.org >> |> |Subject: [dispatch] I-D >> Action:draft-kaplan-dispatch-info-dtmf-package- >> |> |00.txt >> |> | >> |> |Howdy, >> |> |I've submitted an I-D for a DTMF Info-Package, registering it >> following >> |> the >> |> |rules of draft-ietf-sipcore-info-events-08. =A0The info-events draft >> is >> |> not in >> |> |the publication queue yet - it's held up by a single DISCUSS, but I >> |> expect >> |> |that to be resolved. >> |> | >> |> |With regards to my I-D, I'd like to go through A-D sponsored instead >> of >> |> a >> |> |new WG, for obvious reasons. >> |> | >> |> |Any comments/flames are appreciated. >> |> | >> |> |-hadriel >> |> |_______________________________________________ >> |> |dispatch mailing list >> |> |dispatch@ietf.org >> |> |https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From HKaplan@acmepacket.com Mon Aug 23 11:17:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520603A6A7A for ; Mon, 23 Aug 2010 11:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5KYOLxLJrmR for ; Mon, 23 Aug 2010 11:17:14 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 760B83A67E6 for ; Mon, 23 Aug 2010 11:17:14 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 23 Aug 2010 14:17:45 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 23 Aug 2010 14:17:45 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Mon, 23 Aug 2010 14:17:44 -0400 Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActC3zIKsvn9XYPwSZGQgCFPgsMmDQADqjCQ Message-ID: <430FC6BDED356B4C8498F634416644A92694381F16@mail> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> In-Reply-To: <4C729FEF.6020509@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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 18:17:16 -0000 The goal is to make it exactly the same. Obviously having it be an info-pa= ckage to begin with changes it, simply due to the "negotiation" and the inf= o-package header. However, my assumption is that info-packages can be used= by static configuration without negotiation (as anything can by local conf= iguration), and thus if provisioned it can work like today... yes there wou= ld be an info-package header in the INFO (unless static configuration overr= ides that too), but in theory it would be ignored by the legacy receiver an= d just processed as a dtmf-relay. I meant to actually include a descriptio= n of that in the draft, but just realized I forgot to add it. Option-2 is to change the draft to define a "legacy INFO usage" as describe= d in draft-ietf-sipcore-info-events-08, and just register the MIME type and= describe the syntax and semantics. Since "application/dtmf-relay" is unam= biguous for the INFO request's purpose, and it appearing in the Accept head= er for the INVITE is also unambiguous, it avoids the issues people have wit= h using INFO. -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, August 23, 2010 12:21 PM > To: Hadriel Kaplan >=20 > I think this is not as benign as it seems. The problem is that even > though it is *essentially* the same, it is not *exactly* the same as > what is currently implemented in the field. Hence moving to this also > requires *some* (small) effort. And there will be things that still do > it the old way. So there are interop considerations to take into account. >=20 > For a data point, in Cisco we have *five* mechanisms (that I know of) > for DTMF transport in sip that we support and use one way or another. > There are complex negotiation and configuration mechanisms for deciding > what to use, and we often have to convert between them. This proposal > would just increase that number from 5 to 6. >=20 > So lets not do it without careful consideration. >=20 From mperumal@cisco.com Mon Aug 23 12:08:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2487E3A6A7D for ; Mon, 23 Aug 2010 12:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.759 X-Spam-Level: X-Spam-Status: No, score=-9.759 tagged_above=-999 required=5 tests=[AWL=0.840, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zitXSzpCiWCr for ; Mon, 23 Aug 2010 12:08:19 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D39E83A6942 for ; Mon, 23 Aug 2010 12:08:19 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHdjckxAaMHG/2dsb2JhbACgMHGhapt7hTcEhDM1h3s X-IronPort-AV: E=Sophos;i="4.56,259,1280707200"; d="scan'208";a="175724719" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 23 Aug 2010 19:08:52 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7NJ8nYp027753; Mon, 23 Aug 2010 19:08:51 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 00:38:50 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Aug 2010 00:38:45 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202036C3DFB@XMB-BGL-414.cisco.com> In-Reply-To: <430FC6BDED356B4C8498F634416644A92694381E9F@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActAfxYqhZm2eYqvQqSbEji8cpHjOQADdeLwAAH9gFAAe8v98AAV1ChwAAaNM+A= References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 23 Aug 2010 19:08:50.0250 (UTC) FILETIME=[9EB8F2A0:01CB42F6] Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:08:21 -0000 The motivation looks good. However, I am not sure why it should be standardized 'as is' with known limitations/issues, when we can make slight modifications to make it more valuable. Muthu |-----Original Message----- |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |Sent: Monday, August 23, 2010 9:33 PM |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org |Subject: RE: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package- |00.txt | |The reason I'm proposing to generate an RFC for it, without substantively |changing it, is: | |1) Stop it from being a proprietary (albeit industry defacto) mechanism. |2) Register the MIME type name. |3) Provide a static, numbered, public document for implementers and users to |reference, as opposed to a specific company's changing config-documentation |URLs. | |-hadriel | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: Monday, August 23, 2010 1:58 AM |> |> Yes, this is exactly what Cisco implemented 9 years back and hasn't |> undergone any change since then. But I am not sure what purpose it would |> solve by just calling it an IETF standard, without addressing some of |> its limitations for the Internet community. |> |> It would be desirable for this DTMF method to address 2 kinds of |> deployments: |> 1. PSTN interworking, where it provides the ability for the receiver to |> generate the DTMF tone in-sync with the user pressing and releasing the |> button. However, I don't think we need to achieve such precise timing as |> H.245 signal/signalUpdate messages, by carrying RTP timestamp etc, since |> the purpose would be to only avoid the detection delay at the receiver. |> |> 2. No PSTN interworking, where it provides the ability for a SIP |> soft-phone to send a DTMF digit to an app server, without having to |> bother about the duration to the tone. |> |> Muthu |> |> |-----Original Message----- |> |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |> |Sent: Friday, August 20, 2010 11:56 PM |> |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org |> |Subject: RE: [dispatch] I-D |> Action:draft-kaplan-dispatch-info-dtmf-package- |> |00.txt |> | |> | |> |You tell me - afaik it's Cisco's dtmf-relay that everyone's copied (and |> that |> |I'm proposing be an info-package, so it can be "legal"). |> |:) |> | |> |-hadriel |> | |> |> -----Original Message----- |> |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> |> Sent: Friday, August 20, 2010 1:59 PM |> |> To: Hadriel Kaplan; dispatch@ietf.org |> |> Subject: RE: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf- |> |> package-00.txt |> |> |> |> Hi Hadriel, |> |> |> |> There draft doesn't provide a method to indicate the start of a DTMF |> |> event and requires the INFO to be generated only when the user |> releases |> |> the button. So, in the following scenario where the B2BUAs support |> only |> |> the INFO method of sending DTMF events, if the user presses the long |> |> '#', which typically lasts for 2 - 4 sec, the app server at the far |> end |> |> would detect the long '#' only after 6 - 12 sec. |> |> |> |> |> user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN |> |> GW]--app |> |> |> |> Would it be better to provide a way to indicate the start of a DTMF |> |> event so that the far end can start playing it as soon as the user |> |> presses the button? It could be indicated using an empty value for |> |> duration, like this: |> |> |> |> Signal=3D # |> |> Duration=3D |> |> |> |> Muthu |> |> |> |> |-----Original Message----- |> |> |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] |> On |> |> Behalf |> |> |Of Hadriel Kaplan |> |> |Sent: Friday, August 20, 2010 9:18 PM |> |> |To: dispatch@ietf.org |> |> |Subject: [dispatch] I-D |> Action:draft-kaplan-dispatch-info-dtmf-package- |> |> |00.txt |> |> | |> |> |Howdy, |> |> |I've submitted an I-D for a DTMF Info-Package, registering it |> following |> |> the |> |> |rules of draft-ietf-sipcore-info-events-08. The info-events draft |> is |> |> not in |> |> |the publication queue yet - it's held up by a single DISCUSS, but I |> |> expect |> |> |that to be resolved. |> |> | |> |> |With regards to my I-D, I'd like to go through A-D sponsored instead |> of |> |> a |> |> |new WG, for obvious reasons. |> |> | |> |> |Any comments/flames are appreciated. |> |> | |> |> |-hadriel |> |> |_______________________________________________ |> |> |dispatch mailing list |> |> |dispatch@ietf.org |> |> |https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Mon Aug 23 12:19:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4203A6A81 for ; Mon, 23 Aug 2010 12:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bcOXHq6FCmY for ; Mon, 23 Aug 2010 12:19:10 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 56E6E3A6A8D for ; Mon, 23 Aug 2010 12:19:10 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,259,1280707200"; d="scan'208";a="150996509" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2010 19:19:39 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7NJJcPJ026018; Mon, 23 Aug 2010 19:19:39 GMT Message-ID: <4C72C9CA.3070304@cisco.com> Date: Mon, 23 Aug 2010 15:19:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A92694381F16@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:19:12 -0000 Hadriel Kaplan wrote: > The goal is to make it exactly the same. Obviously having it be an info-package to begin with changes it, simply due to the "negotiation" and the info-package header. However, my assumption is that info-packages can be used by static configuration without negotiation (as anything can by local configuration), and thus if provisioned it can work like today... yes there would be an info-package header in the INFO (unless static configuration overrides that too), but in theory it would be ignored by the legacy receiver and just processed as a dtmf-relay. I meant to actually include a description of that in the draft, but just realized I forgot to add it. Yes, having it be an info-package changes it. If this is introduced, we will have those that support it (P) and those that don't. (NP) We will also have those that support the legacy INFO way of doing DTMF (L) and those that don't. (NL) That immediately gives four different kinds of UAs that we then need to consider interop among: NP-NL NP-L P-NL P-L That gives 16 cases to consider interop for: UAC UAS NP-NL * (Not an interesting case - no DTMF will be used.) NP-L NP-NL (Legacy DTMF will be sent and ignored.) NP-L NP-L (Legacy DTMF will be sent and honored.) NP-L P-NL (Legacy DTMF will be sent and ignored by a device that does DTMF.) NP-L P-L (Legacy DTMF will be sent and honored.) P-NL NP-NL (The info package will be offered and ignored. DTMF will not be used.) P-NL NP-L (The info package will be offered and ignored. DTMF will not be used, by a device that does DTMF.) P-NL P-NL (The info package will be offered and accepted. The DTMF package will be used.) P-NL P-L (The info package will be offered and accepted. The DTMF package will be used.) P-L NP-NL (The info package will be offered and ignored. Legacy DTMF will be sent and ignored.) P-L NP-L (The info package will be offered and ignored. The UAC will fall back to sending legacy DTMF which will be accepted.) P-L P-NL (The info package will be offered and accepted. The DTMF package will be used.) P-L P-L (The info package will be offered and accepted. The DTMF package will be used.) The bottom line is that as long as there are things that support the legacy way and not the new info-package way there will be interop issues. And those that do support the new info-package way should still *also* support the legacy way to maximize interop when possible. Its less trouble to get people to support the old legacy way, if they really want it. But once we start talking about that, there will be demand to "improve" it, because it has a lot of limitations. That will make more of a mess. > Option-2 is to change the draft to define a "legacy INFO usage" as described in draft-ietf-sipcore-info-events-08, and just register the MIME type and describe the syntax and semantics. Since "application/dtmf-relay" is unambiguous for the INFO request's purpose, and it appearing in the Accept header for the INVITE is also unambiguous, it avoids the issues people have with using INFO. Perhaps we can find an old draft definition of this legacy usage. (I don't know if it was ever published, but it seems likely.) If so, maybe we can republish it as HISTORIC, as was recently done with the Diversion header draft. Thanks, Paul > -hadriel > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, August 23, 2010 12:21 PM >> To: Hadriel Kaplan >> >> I think this is not as benign as it seems. The problem is that even >> though it is *essentially* the same, it is not *exactly* the same as >> what is currently implemented in the field. Hence moving to this also >> requires *some* (small) effort. And there will be things that still do >> it the old way. So there are interop considerations to take into account. >> >> For a data point, in Cisco we have *five* mechanisms (that I know of) >> for DTMF transport in sip that we support and use one way or another. >> There are complex negotiation and configuration mechanisms for deciding >> what to use, and we often have to convert between them. This proposal >> would just increase that number from 5 to 6. >> >> So lets not do it without careful consideration. >> > From pkyzivat@cisco.com Mon Aug 23 12:41:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915443A6AD0 for ; Mon, 23 Aug 2010 12:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZv+-aZ6Lkwd for ; Mon, 23 Aug 2010 12:41:25 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1EDF63A6ACF for ; Mon, 23 Aug 2010 12:41:25 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,259,1280707200"; d="scan'208";a="150819369" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2010 19:41:58 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7NJfwbd003074; Mon, 23 Aug 2010 19:41:58 GMT Message-ID: <4C72CF06.1030609@cisco.com> Date: Mon, 23 Aug 2010 15:41:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Muthu ArulMozhi Perumal (mperumal)" References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <1D062974A4845E4D8A343C6538049202036C3DFB@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202036C3DFB@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:41:28 -0000 Muthu ArulMozhi Perumal (mperumal) wrote: > The motivation looks good. However, I am not sure why it should be > standardized 'as is' with known limitations/issues, when we can make > slight modifications to make it more valuable. If we start to make mods to "improve" it then we will probably arrive at something similar to KPML. I would offer the following questions: - do people have a problem with DTMF now, *other* than deciding which of the many techniques to use, or wishing that you peer supported the existing technique that you want to use??? - would yet another DTMF technique make things better than they are, or worse? My suspicion is that the answers are mostly NO/NO. Thanks, Paul > Muthu > > |-----Original Message----- > |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > |Sent: Monday, August 23, 2010 9:33 PM > |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org > |Subject: RE: [dispatch] I-D > Action:draft-kaplan-dispatch-info-dtmf-package- > |00.txt > | > |The reason I'm proposing to generate an RFC for it, without > substantively > |changing it, is: > | > |1) Stop it from being a proprietary (albeit industry defacto) > mechanism. > |2) Register the MIME type name. > |3) Provide a static, numbered, public document for implementers and > users to > |reference, as opposed to a specific company's changing > config-documentation > |URLs. > | > |-hadriel > | > |> -----Original Message----- > |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > |> Sent: Monday, August 23, 2010 1:58 AM > |> > |> Yes, this is exactly what Cisco implemented 9 years back and hasn't > |> undergone any change since then. But I am not sure what purpose it > would > |> solve by just calling it an IETF standard, without addressing some of > |> its limitations for the Internet community. > |> > |> It would be desirable for this DTMF method to address 2 kinds of > |> deployments: > |> 1. PSTN interworking, where it provides the ability for the receiver > to > |> generate the DTMF tone in-sync with the user pressing and releasing > the > |> button. However, I don't think we need to achieve such precise timing > as > |> H.245 signal/signalUpdate messages, by carrying RTP timestamp etc, > since > |> the purpose would be to only avoid the detection delay at the > receiver. > |> > |> 2. No PSTN interworking, where it provides the ability for a SIP > |> soft-phone to send a DTMF digit to an app server, without having to > |> bother about the duration to the tone. > |> > |> Muthu > |> > |> |-----Original Message----- > |> |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > |> |Sent: Friday, August 20, 2010 11:56 PM > |> |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org > |> |Subject: RE: [dispatch] I-D > |> Action:draft-kaplan-dispatch-info-dtmf-package- > |> |00.txt > |> | > |> | > |> |You tell me - afaik it's Cisco's dtmf-relay that everyone's copied > (and > |> that > |> |I'm proposing be an info-package, so it can be "legal"). > |> |:) > |> | > |> |-hadriel > |> | > |> |> -----Original Message----- > |> |> From: Muthu ArulMozhi Perumal (mperumal) > [mailto:mperumal@cisco.com] > |> |> Sent: Friday, August 20, 2010 1:59 PM > |> |> To: Hadriel Kaplan; dispatch@ietf.org > |> |> Subject: RE: [dispatch] I-D > Action:draft-kaplan-dispatch-info-dtmf- > |> |> package-00.txt > |> |> > |> |> Hi Hadriel, > |> |> > |> |> There draft doesn't provide a method to indicate the start of a > DTMF > |> |> event and requires the INFO to be generated only when the user > |> releases > |> |> the button. So, in the following scenario where the B2BUAs support > |> only > |> |> the INFO method of sending DTMF events, if the user presses the > long > |> |> '#', which typically lasts for 2 - 4 sec, the app server at the > far > |> end > |> |> would detect the long '#' only after 6 - 12 sec. > |> |> > |> |> > |> > user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN > |> |> GW]--app > |> |> > |> |> Would it be better to provide a way to indicate the start of a > DTMF > |> |> event so that the far end can start playing it as soon as the user > |> |> presses the button? It could be indicated using an empty value for > |> |> duration, like this: > |> |> > |> |> Signal= # > |> |> Duration= > |> |> > |> |> Muthu > |> |> > |> |> |-----Original Message----- > |> |> |From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] > |> On > |> |> Behalf > |> |> |Of Hadriel Kaplan > |> |> |Sent: Friday, August 20, 2010 9:18 PM > |> |> |To: dispatch@ietf.org > |> |> |Subject: [dispatch] I-D > |> Action:draft-kaplan-dispatch-info-dtmf-package- > |> |> |00.txt > |> |> | > |> |> |Howdy, > |> |> |I've submitted an I-D for a DTMF Info-Package, registering it > |> following > |> |> the > |> |> |rules of draft-ietf-sipcore-info-events-08. The info-events > draft > |> is > |> |> not in > |> |> |the publication queue yet - it's held up by a single DISCUSS, but > I > |> |> expect > |> |> |that to be resolved. > |> |> | > |> |> |With regards to my I-D, I'd like to go through A-D sponsored > instead > |> of > |> |> a > |> |> |new WG, for obvious reasons. > |> |> | > |> |> |Any comments/flames are appreciated. > |> |> | > |> |> |-hadriel > |> |> |_______________________________________________ > |> |> |dispatch mailing list > |> |> |dispatch@ietf.org > |> |> |https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From mperumal@cisco.com Mon Aug 23 13:51:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B903A6AE5 for ; Mon, 23 Aug 2010 13:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.803 X-Spam-Level: X-Spam-Status: No, score=-9.803 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ObWDm78c2FB for ; Mon, 23 Aug 2010 13:51:26 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 70CE73A6844 for ; Mon, 23 Aug 2010 13:51:26 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABJ8ckxAaMHG/2dsb2JhbACgOnGhZZwBhTcEhDM1h3s X-IronPort-AV: E=Sophos;i="4.56,259,1280707200"; d="scan'208";a="175774348" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 23 Aug 2010 20:51:59 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7NKpuSl013031; Mon, 23 Aug 2010 20:51:58 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 02:20:38 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Aug 2010 02:20:36 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202036C3E11@XMB-BGL-414.cisco.com> In-Reply-To: <4C72CF06.1030609@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActC+0doZcJwD4mUSEOftDLM+ZUF7wAAi69A References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <1D062974A4845E4D8A343C6538049202036C3DFB@XMB-BGL-414.cisco.com> <4C72CF06.1030609@cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 23 Aug 2010 20:50:38.0829 (UTC) FILETIME=[D7B821D0:01CB4304] Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 20:51:28 -0000 I've heard of people arguing that KPML is slightly heavy weight and doesn't work as expected across B2BUAs/SBC, so they would use INFO instead. thanks, Muthu=20 |-----Original Message----- |From: Paul Kyzivat (pkyzivat) |Sent: Tuesday, August 24, 2010 1:12 AM |To: Muthu ArulMozhi Perumal (mperumal) |Cc: Hadriel Kaplan; dispatch@ietf.org |Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package- |00.txt | |Muthu ArulMozhi Perumal (mperumal) wrote: |> The motivation looks good. However, I am not sure why it should be |> standardized 'as is' with known limitations/issues, when we can make |> slight modifications to make it more valuable. | |If we start to make mods to "improve" it then we will probably arrive at |something similar to KPML. | |I would offer the following questions: | |- do people have a problem with DTMF now, | *other* than deciding which of the many techniques to use, | or wishing that you peer supported the existing technique | that you want to use??? | |- would yet another DTMF technique make things better than | they are, or worse? | |My suspicion is that the answers are mostly NO/NO. | | Thanks, | Paul | |> Muthu |> |> |-----Original Message----- |> |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |> |Sent: Monday, August 23, 2010 9:33 PM |> |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org |> |Subject: RE: [dispatch] I-D |> Action:draft-kaplan-dispatch-info-dtmf-package- |> |00.txt |> | |> |The reason I'm proposing to generate an RFC for it, without |> substantively |> |changing it, is: |> | |> |1) Stop it from being a proprietary (albeit industry defacto) |> mechanism. |> |2) Register the MIME type name. |> |3) Provide a static, numbered, public document for implementers and |> users to |> |reference, as opposed to a specific company's changing |> config-documentation |> |URLs. |> | |> |-hadriel |> | |> |> -----Original Message----- |> |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> |> Sent: Monday, August 23, 2010 1:58 AM |> |> |> |> Yes, this is exactly what Cisco implemented 9 years back and hasn't |> |> undergone any change since then. But I am not sure what purpose it |> would |> |> solve by just calling it an IETF standard, without addressing some of |> |> its limitations for the Internet community. |> |> |> |> It would be desirable for this DTMF method to address 2 kinds of |> |> deployments: |> |> 1. PSTN interworking, where it provides the ability for the receiver |> to |> |> generate the DTMF tone in-sync with the user pressing and releasing |> the |> |> button. However, I don't think we need to achieve such precise timing |> as |> |> H.245 signal/signalUpdate messages, by carrying RTP timestamp etc, |> since |> |> the purpose would be to only avoid the detection delay at the |> receiver. |> |> |> |> 2. No PSTN interworking, where it provides the ability for a SIP |> |> soft-phone to send a DTMF digit to an app server, without having to |> |> bother about the duration to the tone. |> |> |> |> Muthu |> |> |> |> |-----Original Message----- |> |> |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |> |> |Sent: Friday, August 20, 2010 11:56 PM |> |> |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org |> |> |Subject: RE: [dispatch] I-D |> |> Action:draft-kaplan-dispatch-info-dtmf-package- |> |> |00.txt |> |> | |> |> | |> |> |You tell me - afaik it's Cisco's dtmf-relay that everyone's copied |> (and |> |> that |> |> |I'm proposing be an info-package, so it can be "legal"). |> |> |:) |> |> | |> |> |-hadriel |> |> | |> |> |> -----Original Message----- |> |> |> From: Muthu ArulMozhi Perumal (mperumal) |> [mailto:mperumal@cisco.com] |> |> |> Sent: Friday, August 20, 2010 1:59 PM |> |> |> To: Hadriel Kaplan; dispatch@ietf.org |> |> |> Subject: RE: [dispatch] I-D |> Action:draft-kaplan-dispatch-info-dtmf- |> |> |> package-00.txt |> |> |> |> |> |> Hi Hadriel, |> |> |> |> |> |> There draft doesn't provide a method to indicate the start of a |> DTMF |> |> |> event and requires the INFO to be generated only when the user |> |> releases |> |> |> the button. So, in the following scenario where the B2BUAs support |> |> only |> |> |> the INFO method of sending DTMF events, if the user presses the |> long |> |> |> '#', which typically lasts for 2 - 4 sec, the app server at the |> far |> |> end |> |> |> would detect the long '#' only after 6 - 12 sec. |> |> |> |> |> |> |> |> |> user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN |> |> |> GW]--app |> |> |> |> |> |> Would it be better to provide a way to indicate the start of a |> DTMF |> |> |> event so that the far end can start playing it as soon as the user |> |> |> presses the button? It could be indicated using an empty value for |> |> |> duration, like this: |> |> |> |> |> |> Signal=3D # |> |> |> Duration=3D |> |> |> |> |> |> Muthu |> |> |> |> |> |> |-----Original Message----- |> |> |> |From: dispatch-bounces@ietf.org |> [mailto:dispatch-bounces@ietf.org] |> |> On |> |> |> Behalf |> |> |> |Of Hadriel Kaplan |> |> |> |Sent: Friday, August 20, 2010 9:18 PM |> |> |> |To: dispatch@ietf.org |> |> |> |Subject: [dispatch] I-D |> |> Action:draft-kaplan-dispatch-info-dtmf-package- |> |> |> |00.txt |> |> |> | |> |> |> |Howdy, |> |> |> |I've submitted an I-D for a DTMF Info-Package, registering it |> |> following |> |> |> the |> |> |> |rules of draft-ietf-sipcore-info-events-08. The info-events |> draft |> |> is |> |> |> not in |> |> |> |the publication queue yet - it's held up by a single DISCUSS, but |> I |> |> |> expect |> |> |> |that to be resolved. |> |> |> | |> |> |> |With regards to my I-D, I'd like to go through A-D sponsored |> instead |> |> of |> |> |> a |> |> |> |new WG, for obvious reasons. |> |> |> | |> |> |> |Any comments/flames are appreciated. |> |> |> | |> |> |> |-hadriel |> |> |> |_______________________________________________ |> |> |> |dispatch mailing list |> |> |> |dispatch@ietf.org |> |> |> |https://www.ietf.org/mailman/listinfo/dispatch |> _______________________________________________ |> dispatch mailing list |> dispatch@ietf.org |> https://www.ietf.org/mailman/listinfo/dispatch |> From pkyzivat@cisco.com Mon Aug 23 14:16:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DEE3A68B1 for ; Mon, 23 Aug 2010 14:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.489 X-Spam-Level: X-Spam-Status: No, score=-110.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY+8o+yKzTct for ; Mon, 23 Aug 2010 14:16:18 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EB9473A6AFF for ; Mon, 23 Aug 2010 14:16:17 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,259,1280707200"; d="scan'208";a="150851519" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2010 21:16:51 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7NLGpUm001993; Mon, 23 Aug 2010 21:16:51 GMT Message-ID: <4C72E542.4050908@cisco.com> Date: Mon, 23 Aug 2010 17:16:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Muthu ArulMozhi Perumal (mperumal)" References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <1D062974A4845E4D8A343C6538049202036C3DFB@XMB-BGL-414.cisco.com> <4C72CF06.1030609@cisco.com> <1D062974A4845E4D8A343C6538049202036C3E11@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202036C3E11@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 21:16:20 -0000 Muthu ArulMozhi Perumal (mperumal) wrote: > I've heard of people arguing that KPML is slightly heavy weight and > doesn't work as expected across B2BUAs/SBC, so they would use INFO > instead. I'm somewhat sympathetic to the problems of having it be a separate dialog. (Not too sympathetic - people need to get it through their heads that this is required functionality through SBCs or whatever.) But IMO the rest of the heavy weightedness is really not such a big deal, and is there for good reasons. So I can see something similar to kpml using an info-package. (If it really is too heavy, we might have to revisit that.) But this is all moot unless somebody can make a case for yet another DTMF mechanism. Thanks, Paul > thanks, > Muthu > > |-----Original Message----- > |From: Paul Kyzivat (pkyzivat) > |Sent: Tuesday, August 24, 2010 1:12 AM > |To: Muthu ArulMozhi Perumal (mperumal) > |Cc: Hadriel Kaplan; dispatch@ietf.org > |Subject: Re: [dispatch] I-D > Action:draft-kaplan-dispatch-info-dtmf-package- > |00.txt > | > |Muthu ArulMozhi Perumal (mperumal) wrote: > |> The motivation looks good. However, I am not sure why it should be > |> standardized 'as is' with known limitations/issues, when we can make > |> slight modifications to make it more valuable. > | > |If we start to make mods to "improve" it then we will probably arrive > at > |something similar to KPML. > | > |I would offer the following questions: > | > |- do people have a problem with DTMF now, > | *other* than deciding which of the many techniques to use, > | or wishing that you peer supported the existing technique > | that you want to use??? > | > |- would yet another DTMF technique make things better than > | they are, or worse? > | > |My suspicion is that the answers are mostly NO/NO. > | > | Thanks, > | Paul > | > |> Muthu > |> > |> |-----Original Message----- > |> |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > |> |Sent: Monday, August 23, 2010 9:33 PM > |> |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org > |> |Subject: RE: [dispatch] I-D > |> Action:draft-kaplan-dispatch-info-dtmf-package- > |> |00.txt > |> | > |> |The reason I'm proposing to generate an RFC for it, without > |> substantively > |> |changing it, is: > |> | > |> |1) Stop it from being a proprietary (albeit industry defacto) > |> mechanism. > |> |2) Register the MIME type name. > |> |3) Provide a static, numbered, public document for implementers and > |> users to > |> |reference, as opposed to a specific company's changing > |> config-documentation > |> |URLs. > |> | > |> |-hadriel > |> | > |> |> -----Original Message----- > |> |> From: Muthu ArulMozhi Perumal (mperumal) > [mailto:mperumal@cisco.com] > |> |> Sent: Monday, August 23, 2010 1:58 AM > |> |> > |> |> Yes, this is exactly what Cisco implemented 9 years back and > hasn't > |> |> undergone any change since then. But I am not sure what purpose it > |> would > |> |> solve by just calling it an IETF standard, without addressing some > of > |> |> its limitations for the Internet community. > |> |> > |> |> It would be desirable for this DTMF method to address 2 kinds of > |> |> deployments: > |> |> 1. PSTN interworking, where it provides the ability for the > receiver > |> to > |> |> generate the DTMF tone in-sync with the user pressing and > releasing > |> the > |> |> button. However, I don't think we need to achieve such precise > timing > |> as > |> |> H.245 signal/signalUpdate messages, by carrying RTP timestamp etc, > |> since > |> |> the purpose would be to only avoid the detection delay at the > |> receiver. > |> |> > |> |> 2. No PSTN interworking, where it provides the ability for a SIP > |> |> soft-phone to send a DTMF digit to an app server, without having > to > |> |> bother about the duration to the tone. > |> |> > |> |> Muthu > |> |> > |> |> |-----Original Message----- > |> |> |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > |> |> |Sent: Friday, August 20, 2010 11:56 PM > |> |> |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org > |> |> |Subject: RE: [dispatch] I-D > |> |> Action:draft-kaplan-dispatch-info-dtmf-package- > |> |> |00.txt > |> |> | > |> |> | > |> |> |You tell me - afaik it's Cisco's dtmf-relay that everyone's > copied > |> (and > |> |> that > |> |> |I'm proposing be an info-package, so it can be "legal"). > |> |> |:) > |> |> | > |> |> |-hadriel > |> |> | > |> |> |> -----Original Message----- > |> |> |> From: Muthu ArulMozhi Perumal (mperumal) > |> [mailto:mperumal@cisco.com] > |> |> |> Sent: Friday, August 20, 2010 1:59 PM > |> |> |> To: Hadriel Kaplan; dispatch@ietf.org > |> |> |> Subject: RE: [dispatch] I-D > |> Action:draft-kaplan-dispatch-info-dtmf- > |> |> |> package-00.txt > |> |> |> > |> |> |> Hi Hadriel, > |> |> |> > |> |> |> There draft doesn't provide a method to indicate the start of a > |> DTMF > |> |> |> event and requires the INFO to be generated only when the user > |> |> releases > |> |> |> the button. So, in the following scenario where the B2BUAs > support > |> |> only > |> |> |> the INFO method of sending DTMF events, if the user presses the > |> long > |> |> |> '#', which typically lasts for 2 - 4 sec, the app server at the > |> far > |> |> end > |> |> |> would detect the long '#' only after 6 - 12 sec. > |> |> |> > |> |> |> > |> |> > |> > user--[PSTN-GW]--SIP--[B2BUA]--SIP--[B2BUA]--[PSTN-GW]--[B2BUA]--[PSTN > |> |> |> GW]--app > |> |> |> > |> |> |> Would it be better to provide a way to indicate the start of a > |> DTMF > |> |> |> event so that the far end can start playing it as soon as the > user > |> |> |> presses the button? It could be indicated using an empty value > for > |> |> |> duration, like this: > |> |> |> > |> |> |> Signal= # > |> |> |> Duration= > |> |> |> > |> |> |> Muthu > |> |> |> > |> |> |> |-----Original Message----- > |> |> |> |From: dispatch-bounces@ietf.org > |> [mailto:dispatch-bounces@ietf.org] > |> |> On > |> |> |> Behalf > |> |> |> |Of Hadriel Kaplan > |> |> |> |Sent: Friday, August 20, 2010 9:18 PM > |> |> |> |To: dispatch@ietf.org > |> |> |> |Subject: [dispatch] I-D > |> |> Action:draft-kaplan-dispatch-info-dtmf-package- > |> |> |> |00.txt > |> |> |> | > |> |> |> |Howdy, > |> |> |> |I've submitted an I-D for a DTMF Info-Package, registering it > |> |> following > |> |> |> the > |> |> |> |rules of draft-ietf-sipcore-info-events-08. The info-events > |> draft > |> |> is > |> |> |> not in > |> |> |> |the publication queue yet - it's held up by a single DISCUSS, > but > |> I > |> |> |> expect > |> |> |> |that to be resolved. > |> |> |> | > |> |> |> |With regards to my I-D, I'd like to go through A-D sponsored > |> instead > |> |> of > |> |> |> a > |> |> |> |new WG, for obvious reasons. > |> |> |> | > |> |> |> |Any comments/flames are appreciated. > |> |> |> | > |> |> |> |-hadriel > |> |> |> |_______________________________________________ > |> |> |> |dispatch mailing list > |> |> |> |dispatch@ietf.org > |> |> |> |https://www.ietf.org/mailman/listinfo/dispatch > |> _______________________________________________ > |> dispatch mailing list > |> dispatch@ietf.org > |> https://www.ietf.org/mailman/listinfo/dispatch > |> > From HKaplan@acmepacket.com Mon Aug 23 14:24:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31AA53A68C3 for ; Mon, 23 Aug 2010 14:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n11u1SYxMDl5 for ; Mon, 23 Aug 2010 14:24:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D5C663A6B09 for ; Mon, 23 Aug 2010 14:24:17 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 23 Aug 2010 17:24:50 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 23 Aug 2010 17:24:29 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Mon, 23 Aug 2010 17:24:28 -0400 Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActC+CTweGaxcMcKToay1vK+C7Ue6wAENF+A Message-ID: <430FC6BDED356B4C8498F634416644A92694381FDF@mail> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> In-Reply-To: <4C72C9CA.3070304@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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 21:24:19 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, August 23, 2010 3:20 PM > To: Hadriel Kaplan >=20 > Yes, having it be an info-package changes it. > If this is introduced, we will have those that support it (P) and those > that don't. (NP) We will also have those that support the legacy INFO > way of doing DTMF (L) and those that don't. (NL) That immediately gives > four different kinds of UAs that we then need to consider interop among: >=20 > NP-NL > NP-L > P-NL > P-L No, I think you misunderstand what I meant: I meant a device supporting thi= s draft would also support legacy, by definition. So there are only NP-NL,= NP-L, and P-L. And any combination with NP-NL does not matter (since by d= efinition an NP-NL doesn't do DTMF with INFO to begin with). So the only combinations that exist and matter are: NP-L NP-L (Legacy DTMF will be sent and honored.) NP-L P-L (Legacy DTMF will be sent and honored.) P-L NP-L (The info package will be offered and ignored. The UAC will fall back to sending legacy DTMF which will be accepted.) P-L P-L (The info package will be offered and accepted. The DTMF package will be used.) -hadriel > That gives 16 cases to consider interop for: >=20 > UAC UAS >=20 > NP-NL * (Not an interesting case - no DTMF will be used.) >=20 > NP-L NP-NL (Legacy DTMF will be sent and ignored.) >=20 > NP-L NP-L (Legacy DTMF will be sent and honored.) >=20 > NP-L P-NL (Legacy DTMF will be sent and ignored by a device > that does DTMF.) >=20 > NP-L P-L (Legacy DTMF will be sent and honored.) >=20 > P-NL NP-NL (The info package will be offered and ignored. > DTMF will not be used.) >=20 > P-NL NP-L (The info package will be offered and ignored. > DTMF will not be used, by a device that does DTMF.) >=20 > P-NL P-NL (The info package will be offered and accepted. > The DTMF package will be used.) >=20 > P-NL P-L (The info package will be offered and accepted. > The DTMF package will be used.) >=20 > P-L NP-NL (The info package will be offered and ignored. > Legacy DTMF will be sent and ignored.) >=20 > P-L NP-L (The info package will be offered and ignored. > The UAC will fall back to sending legacy DTMF > which will be accepted.) >=20 > P-L P-NL (The info package will be offered and accepted. > The DTMF package will be used.) >=20 > P-L P-L (The info package will be offered and accepted. > The DTMF package will be used.) >=20 > The bottom line is that as long as there are things that support the > legacy way and not the new info-package way there will be interop > issues. And those that do support the new info-package way should still > *also* support the legacy way to maximize interop when possible. >=20 > Its less trouble to get people to support the old legacy way, if they > really want it. But once we start talking about that, there will be > demand to "improve" it, because it has a lot of limitations. That will > make more of a mess. >=20 > > Option-2 is to change the draft to define a "legacy INFO usage" as > described in draft-ietf-sipcore-info-events-08, and just register the MIM= E > type and describe the syntax and semantics. Since "application/dtmf- > relay" is unambiguous for the INFO request's purpose, and it appearing in > the Accept header for the INVITE is also unambiguous, it avoids the issue= s > people have with using INFO. >=20 > Perhaps we can find an old draft definition of this legacy usage. > (I don't know if it was ever published, but it seems likely.) > If so, maybe we can republish it as HISTORIC, as was recently done with > the Diversion header draft. >=20 > Thanks, > Paul >=20 > > -hadriel > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Monday, August 23, 2010 12:21 PM > >> To: Hadriel Kaplan > >> > >> I think this is not as benign as it seems. The problem is that even > >> though it is *essentially* the same, it is not *exactly* the same as > >> what is currently implemented in the field. Hence moving to this also > >> requires *some* (small) effort. And there will be things that still do > >> it the old way. So there are interop considerations to take into > account. > >> > >> For a data point, in Cisco we have *five* mechanisms (that I know of) > >> for DTMF transport in sip that we support and use one way or another. > >> There are complex negotiation and configuration mechanisms for decidin= g > >> what to use, and we often have to convert between them. This proposal > >> would just increase that number from 5 to 6. > >> > >> So lets not do it without careful consideration. > >> > > From pkyzivat@cisco.com Mon Aug 23 15:01:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5663A6967 for ; Mon, 23 Aug 2010 15:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAdYlFVk4gGs for ; Mon, 23 Aug 2010 15:01:16 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 994533A6964 for ; Mon, 23 Aug 2010 15:01:15 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,259,1280707200"; d="scan'208";a="151048620" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2010 22:01:48 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7NM1mDO015290; Mon, 23 Aug 2010 22:01:48 GMT Message-ID: <4C72EFCC.2000107@cisco.com> Date: Mon, 23 Aug 2010 18:01:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A92694381FDF@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 22:01:17 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, August 23, 2010 3:20 PM >> To: Hadriel Kaplan >> >> Yes, having it be an info-package changes it. >> If this is introduced, we will have those that support it (P) and those >> that don't. (NP) We will also have those that support the legacy INFO >> way of doing DTMF (L) and those that don't. (NL) That immediately gives >> four different kinds of UAs that we then need to consider interop among: >> >> NP-NL >> NP-L >> P-NL >> P-L > > No, I think you misunderstand what I meant: I meant a device supporting this draft would also support legacy, by definition. So there are only NP-NL, NP-L, and P-L. And any combination with NP-NL does not matter (since by definition an NP-NL doesn't do DTMF with INFO to begin with). > > So the only combinations that exist and matter are: > > NP-L NP-L (Legacy DTMF will be sent and honored.) > > NP-L P-L (Legacy DTMF will be sent and honored.) > > P-L NP-L (The info package will be offered and ignored. > The UAC will fall back to sending legacy DTMF > which will be accepted.) > > P-L P-L (The info package will be offered and accepted. > The DTMF package will be used.) That reduces things somewhat. But if everybody that supports the package also supports the legacy approach, what is the win? I guess if both UAC and UAS support both, and the UAS doesn't want DTMF, then you avoid sending it. Other than that there is no win over supporting only legacy. Its slightly more trouble to support both than to support only the legacy, though not a lot more. The real *advantage* of info packages is that their use is negotiated. And that is lost if you support the legacy approach too. As I mentioned, Cisco currently supports five different dtmf approaches, and this would make six. Its really difficult to figure out which one to use with such a mess, so making it worse is not very attractive. I'm usually the theorist. But here I think we need to focus very much on the pragmatic - what will make implementor's jobs easier and/or the end results tangibly better. Thanks, Paul > -hadriel > > >> That gives 16 cases to consider interop for: >> >> UAC UAS >> >> NP-NL * (Not an interesting case - no DTMF will be used.) >> >> NP-L NP-NL (Legacy DTMF will be sent and ignored.) >> >> NP-L NP-L (Legacy DTMF will be sent and honored.) >> >> NP-L P-NL (Legacy DTMF will be sent and ignored by a device >> that does DTMF.) >> >> NP-L P-L (Legacy DTMF will be sent and honored.) >> >> P-NL NP-NL (The info package will be offered and ignored. >> DTMF will not be used.) >> >> P-NL NP-L (The info package will be offered and ignored. >> DTMF will not be used, by a device that does DTMF.) >> >> P-NL P-NL (The info package will be offered and accepted. >> The DTMF package will be used.) >> >> P-NL P-L (The info package will be offered and accepted. >> The DTMF package will be used.) >> >> P-L NP-NL (The info package will be offered and ignored. >> Legacy DTMF will be sent and ignored.) >> >> P-L NP-L (The info package will be offered and ignored. >> The UAC will fall back to sending legacy DTMF >> which will be accepted.) >> >> P-L P-NL (The info package will be offered and accepted. >> The DTMF package will be used.) >> >> P-L P-L (The info package will be offered and accepted. >> The DTMF package will be used.) >> >> The bottom line is that as long as there are things that support the >> legacy way and not the new info-package way there will be interop >> issues. And those that do support the new info-package way should still >> *also* support the legacy way to maximize interop when possible. >> >> Its less trouble to get people to support the old legacy way, if they >> really want it. But once we start talking about that, there will be >> demand to "improve" it, because it has a lot of limitations. That will >> make more of a mess. >> >>> Option-2 is to change the draft to define a "legacy INFO usage" as >> described in draft-ietf-sipcore-info-events-08, and just register the MIME >> type and describe the syntax and semantics. Since "application/dtmf- >> relay" is unambiguous for the INFO request's purpose, and it appearing in >> the Accept header for the INVITE is also unambiguous, it avoids the issues >> people have with using INFO. >> >> Perhaps we can find an old draft definition of this legacy usage. >> (I don't know if it was ever published, but it seems likely.) >> If so, maybe we can republish it as HISTORIC, as was recently done with >> the Diversion header draft. >> >> Thanks, >> Paul >> >>> -hadriel >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, August 23, 2010 12:21 PM >>>> To: Hadriel Kaplan >>>> >>>> I think this is not as benign as it seems. The problem is that even >>>> though it is *essentially* the same, it is not *exactly* the same as >>>> what is currently implemented in the field. Hence moving to this also >>>> requires *some* (small) effort. And there will be things that still do >>>> it the old way. So there are interop considerations to take into >> account. >>>> For a data point, in Cisco we have *five* mechanisms (that I know of) >>>> for DTMF transport in sip that we support and use one way or another. >>>> There are complex negotiation and configuration mechanisms for deciding >>>> what to use, and we often have to convert between them. This proposal >>>> would just increase that number from 5 to 6. >>>> >>>> So lets not do it without careful consideration. >>>> > From christer.holmberg@ericsson.com Mon Aug 23 17:53:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277573A6900 for ; Mon, 23 Aug 2010 17:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7-7AdJM6pvv for ; Mon, 23 Aug 2010 17:53:12 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 595593A6899 for ; Mon, 23 Aug 2010 17:53:12 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-5a-4c731818c808 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1D.2B.06895.818137C4; Tue, 24 Aug 2010 02:53:44 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 24 Aug 2010 02:53:44 +0200 From: Christer Holmberg To: Paul Kyzivat , Hadriel Kaplan Date: Tue, 24 Aug 2010 02:53:41 +0200 Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDDs0TbfwEfQmVQaGg5PPmqipLgwAF8feA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851B8056@ESESSCMS0356.eemea.ericsson.se> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> In-Reply-To: <4C72EFCC.2000107@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: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 00:53:14 -0000 Hi, A while ago, 3GPP also defined a DTMF package. For some reason it hasn't be= en registered with IANA yet, but I have requested to ensure that it happens= . Regards, Christer =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 24. elokuuta 2010 1:02 > To: Hadriel Kaplan > Cc: dispatch@ietf.org > Subject: Re: [dispatch] I-D=20 > Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >=20 >=20 >=20 > Hadriel Kaplan wrote: > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Monday, August 23, 2010 3:20 PM > >> To: Hadriel Kaplan > >> > >> Yes, having it be an info-package changes it. > >> If this is introduced, we will have those that support it (P) and=20 > >> those that don't. (NP) We will also have those that support the=20 > >> legacy INFO way of doing DTMF (L) and those that don't. (NL) That=20 > >> immediately gives four different kinds of UAs that we then=20 > need to consider interop among: > >> > >> NP-NL > >> NP-L > >> P-NL > >> P-L > >=20 > > No, I think you misunderstand what I meant: I meant a=20 > device supporting this draft would also support legacy, by=20 > definition. So there are only NP-NL, NP-L, and P-L. And any=20 > combination with NP-NL does not matter (since by definition=20 > an NP-NL doesn't do DTMF with INFO to begin with). > >=20 > > So the only combinations that exist and matter are: > >=20 > > NP-L NP-L (Legacy DTMF will be sent and honored.) > >=20 > > NP-L P-L (Legacy DTMF will be sent and honored.) > >=20 > > P-L NP-L (The info package will be offered and ignored. > > The UAC will fall back to sending legacy DTMF > > which will be accepted.) > >=20 > > P-L P-L (The info package will be offered and accepted. > > The DTMF package will be used.) >=20 > That reduces things somewhat. But if everybody that supports=20 > the package also supports the legacy approach, what is the win? >=20 > I guess if both UAC and UAS support both, and the UAS doesn't=20 > want DTMF, then you avoid sending it. Other than that there=20 > is no win over supporting only legacy. >=20 > Its slightly more trouble to support both than to support=20 > only the legacy, though not a lot more. >=20 > The real *advantage* of info packages is that their use is=20 > negotiated.=20 > And that is lost if you support the legacy approach too. >=20 > As I mentioned, Cisco currently supports five different dtmf=20 > approaches, and this would make six. Its really difficult to=20 > figure out which one to use with such a mess, so making it=20 > worse is not very attractive. >=20 > I'm usually the theorist. But here I think we need to focus=20 > very much on the pragmatic - what will make implementor's=20 > jobs easier and/or the end results tangibly better. >=20 > Thanks, > Paul >=20 >=20 > > -hadriel > >=20 > >=20 > >> That gives 16 cases to consider interop for: > >> > >> UAC UAS > >> > >> NP-NL * (Not an interesting case - no DTMF will=20 > be used.) > >> > >> NP-L NP-NL (Legacy DTMF will be sent and ignored.) > >> > >> NP-L NP-L (Legacy DTMF will be sent and honored.) > >> > >> NP-L P-NL (Legacy DTMF will be sent and ignored=20 > by a device > >> that does DTMF.) > >> > >> NP-L P-L (Legacy DTMF will be sent and honored.) > >> > >> P-NL NP-NL (The info package will be offered and ignored. > >> DTMF will not be used.) > >> > >> P-NL NP-L (The info package will be offered and ignored. > >> DTMF will not be used, by a device that does DTMF.) > >> > >> P-NL P-NL (The info package will be offered and accepted. > >> The DTMF package will be used.) > >> > >> P-NL P-L (The info package will be offered and accepted. > >> The DTMF package will be used.) > >> > >> P-L NP-NL (The info package will be offered and ignored. > >> Legacy DTMF will be sent and ignored.) > >> > >> P-L NP-L (The info package will be offered and ignored. > >> The UAC will fall back to sending legacy DTMF > >> which will be accepted.) > >> > >> P-L P-NL (The info package will be offered and accepted. > >> The DTMF package will be used.) > >> > >> P-L P-L (The info package will be offered and accepted. > >> The DTMF package will be used.) > >> > >> The bottom line is that as long as there are things that=20 > support the=20 > >> legacy way and not the new info-package way there will be interop=20 > >> issues. And those that do support the new info-package way should=20 > >> still > >> *also* support the legacy way to maximize interop when possible. > >> > >> Its less trouble to get people to support the old legacy=20 > way, if they=20 > >> really want it. But once we start talking about that,=20 > there will be=20 > >> demand to "improve" it, because it has a lot of limitations. That=20 > >> will make more of a mess. > >> > >>> Option-2 is to change the draft to define a "legacy INFO usage" as > >> described in draft-ietf-sipcore-info-events-08, and just=20 > register the=20 > >> MIME type and describe the syntax and semantics. Since=20 > >> "application/dtmf- relay" is unambiguous for the INFO request's=20 > >> purpose, and it appearing in the Accept header for the=20 > INVITE is also=20 > >> unambiguous, it avoids the issues people have with using INFO. > >> > >> Perhaps we can find an old draft definition of this legacy usage. > >> (I don't know if it was ever published, but it seems=20 > likely.) If so,=20 > >> maybe we can republish it as HISTORIC, as was recently=20 > done with the=20 > >> Diversion header draft. > >> > >> Thanks, > >> Paul > >> > >>> -hadriel > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Monday, August 23, 2010 12:21 PM > >>>> To: Hadriel Kaplan > >>>> > >>>> I think this is not as benign as it seems. The problem=20 > is that even=20 > >>>> though it is *essentially* the same, it is not *exactly*=20 > the same=20 > >>>> as what is currently implemented in the field. Hence=20 > moving to this=20 > >>>> also requires *some* (small) effort. And there will be=20 > things that=20 > >>>> still do it the old way. So there are interop considerations to=20 > >>>> take into > >> account. > >>>> For a data point, in Cisco we have *five* mechanisms=20 > (that I know=20 > >>>> of) for DTMF transport in sip that we support and use=20 > one way or another. > >>>> There are complex negotiation and configuration mechanisms for=20 > >>>> deciding what to use, and we often have to convert between them.=20 > >>>> This proposal would just increase that number from 5 to 6. > >>>> > >>>> So lets not do it without careful consideration. > >>>> > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From Simo.Veikkolainen@nokia.com Mon Aug 23 22:57:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 947503A68DC for ; Mon, 23 Aug 2010 22:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exF6VqJ4lKxn for ; Mon, 23 Aug 2010 22:57:53 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id DDAF83A67F3 for ; Mon, 23 Aug 2010 22:57:52 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o7O5wDYZ006883; Tue, 24 Aug 2010 08:58:21 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 08:58:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 08:58:19 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 24 Aug 2010 07:58:18 +0200 From: To: Date: Tue, 24 Aug 2010 07:58:17 +0200 Thread-Topic: [dispatch] FW: I-D Action:draft-veikkolainen-sip-xmpp-coex-reqs-01.txt Thread-Index: ActCx0fNdUkclrePTFKwng9+lx6uBwAia8Rw Message-ID: References: <4C7277AA.7070608@cisco.com> In-Reply-To: <4C7277AA.7070608@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-OriginalArrivalTime: 24 Aug 2010 05:58:19.0246 (UTC) FILETIME=[5A0DD8E0:01CB4351] X-Nokia-AV: Clean Cc: dispatch@ietf.org, Markus.Isomaki@nokia.com Subject: Re: [dispatch] FW: I-D Action:draft-veikkolainen-sip-xmpp-coex-reqs-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 05:57:56 -0000 >-----Original Message----- >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >Behalf Of ext Paul Kyzivat >Sent: 23 August, 2010 16:29 >To: Veikkolainen Simo (Nokia-MS/Helsinki) >Cc: dispatch@ietf.org; Isomaki Markus (Nokia-CIC/Espoo) >Subject: Re: [dispatch] FW: I-D Action:draft-veikkolainen-sip-xmpp-coex- >reqs-01.txt > >This seems clear and straightforward. >As much as I wish we weren't in a position where we need to do this, we >are, so I'm in favor. > >One nit (I think). The third use case ends in the middle of a sentence: > > A user who has obtained another user's SIP URI is able to >discover > the other user's XMPP URI so that she can send the other user >XMPP > IM or subscribe to the other user's presence, or just populate >her > address book for futher use. The user is able to do this without > bothering the other user, provided the other user has pre- > authorized the operation. but > >I gather there was more to say that was omitted. Good catch. It seems the "but" is superfluous, we'll fix that in the next v= ersion. Simo=20 > Thanks, > Paul > >Simo.Veikkolainen@nokia.com wrote: >> We have just submitted a new version of the SIP-XMPp co-existance >requirements draft. >> >> This version is just a date update while we are still working on the >charter text. >> >> Regards, >> Simo >> >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- >>> bounces@ietf.org] On Behalf Of ext Internet-Drafts@ietf.org >>> Sent: 23 August, 2010 08:00 >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-veikkolainen-sip-xmpp-coex-reqs-01.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Requirements and Use Cases for Combining SIP >>> Based Real-time Media Sessions With XMPP Based Instant Messaging and >>> Presence Service. >>> Author(s) : S. Veikkolainen, M. Isomaki >>> Filename : draft-veikkolainen-sip-xmpp-coex-reqs-01.txt >>> Pages : 8 >>> Date : 2010-08-22 >>> >>> This memo defines use cases and requirements for combining Session >>> Initiation Protocol (SIP) based real-time media sessions with >Extensible >>> Messaging and Presence Protocol (XMPP) based instant messaging and >>> presence services in a seamless manner. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-veikkolainen-sip-xmpp-coex- >>> reqs-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> --------------------------------------------------------------------- >--- >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Tue Aug 24 07:55:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239793A6B69 for ; Tue, 24 Aug 2010 07:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUTJ1m75GNkw for ; Tue, 24 Aug 2010 07:55:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 249A53A6B11 for ; Tue, 24 Aug 2010 07:55:02 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 24 Aug 2010 10:55:35 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 24 Aug 2010 10:55:14 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Tue, 24 Aug 2010 10:55:13 -0400 Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDDsmtl061FEcFSXWCR2LK3Z8nZAAjMSwg Message-ID: <430FC6BDED356B4C8498F634416644A92694382179@mail> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> In-Reply-To: <4C72EFCC.2000107@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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 14:55:07 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, August 23, 2010 6:02 PM > To: Hadriel Kaplan >=20 > That reduces things somewhat. But if everybody that supports the package > also supports the legacy approach, what is the win? The legacy mode has no published standards document defining it. I thought= when the info-packages work was started, DTMF-in-info was one of the main = drivers. But I take your point - if people would prefer to just document i= t as it is today (sans info-packages), I can change the draft to just be th= at. I'm cool with either way (defining the current dtmf-relay as a legacy = mode was Option-2). -hadriel=20 From pkyzivat@cisco.com Tue Aug 24 08:50:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C03F3A6898 for ; Tue, 24 Aug 2010 08:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.491 X-Spam-Level: X-Spam-Status: No, score=-110.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axBvaXUdeEv8 for ; Tue, 24 Aug 2010 08:50:30 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4896A3A6892 for ; Tue, 24 Aug 2010 08:50:30 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,263,1280707200"; d="scan'208";a="151150917" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2010 15:51:03 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7OFp2ge018572; Tue, 24 Aug 2010 15:51:02 GMT Message-ID: <4C73EA66.4000305@cisco.com> Date: Tue, 24 Aug 2010 11:51:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <430FC6BDED356B4C8498F634416644A92694382179@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A92694382179@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 15:50:31 -0000 Maybe we should ask our ADs if they have an opinion about this. Thanks, Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, August 23, 2010 6:02 PM >> To: Hadriel Kaplan >> >> That reduces things somewhat. But if everybody that supports the package >> also supports the legacy approach, what is the win? > > The legacy mode has no published standards document defining it. I thought when the info-packages work was started, DTMF-in-info was one of the main drivers. But I take your point - if people would prefer to just document it as it is today (sans info-packages), I can change the draft to just be that. I'm cool with either way (defining the current dtmf-relay as a legacy mode was Option-2). > > -hadriel > From christer.holmberg@ericsson.com Tue Aug 24 10:57:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72013A69DD for ; Tue, 24 Aug 2010 10:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.262 X-Spam-Level: X-Spam-Status: No, score=-5.262 tagged_above=-999 required=5 tests=[AWL=1.337, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwNVsJbR-XHR for ; Tue, 24 Aug 2010 10:57:56 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 7CB0F3A6A35 for ; Tue, 24 Aug 2010 10:57:56 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-dd-4c740844c3a4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 97.75.10125.448047C4; Tue, 24 Aug 2010 19:58:28 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 24 Aug 2010 19:58:28 +0200 From: Christer Holmberg To: Paul Kyzivat , Hadriel Kaplan Date: Tue, 24 Aug 2010 19:58:20 +0200 Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDpCzRI7O0R7mSRfm3WbBAhc3UNwAESoUA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> In-Reply-To: <4C73EA66.4000305@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: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 17:57:57 -0000 Hi, I think it is strange to reject something based on a claim there already ex= ists a number of legacy ways of there. Not everyone has implemented the sam= e (if any) of them, and the whole purpose of the Info Package framework is = to come up with a mechanism for which the usage can be negotiated. And, as I said earlier, at least in IMS an Info Package is being used for D= TMF transport. It is currently defined in 3GPP specifications, but there sh= ouldn't be anything IMS specific about the package itself. Regards, Christer =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 24. elokuuta 2010 18:51 > To: Hadriel Kaplan > Cc: dispatch@ietf.org > Subject: Re: [dispatch] I-D=20 > Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >=20 > Maybe we should ask our ADs if they have an opinion about this. >=20 > Thanks, > Paul >=20 > Hadriel Kaplan wrote: > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Monday, August 23, 2010 6:02 PM > >> To: Hadriel Kaplan > >> > >> That reduces things somewhat. But if everybody that supports the=20 > >> package also supports the legacy approach, what is the win? > >=20 > > The legacy mode has no published standards document=20 > defining it. I thought when the info-packages work was=20 > started, DTMF-in-info was one of the main drivers. But I=20 > take your point - if people would prefer to just document it=20 > as it is today (sans info-packages), I can change the draft=20 > to just be that. I'm cool with either way (defining the=20 > current dtmf-relay as a legacy mode was Option-2). > >=20 > > -hadriel > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From pkyzivat@cisco.com Tue Aug 24 11:47:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6113A3A6901 for ; Tue, 24 Aug 2010 11:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyx5TwLROPPP for ; Tue, 24 Aug 2010 11:47:24 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2B37F3A6889 for ; Tue, 24 Aug 2010 11:47:24 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEawc0xAZnwN/2dsb2JhbACgQnGhYJt2hTcEiXg X-IronPort-AV: E=Sophos;i="4.56,264,1280707200"; d="scan'208";a="151405410" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2010 18:47:53 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7OIlrWV022825; Tue, 24 Aug 2010 18:47:53 GMT Message-ID: <4C7413D9.80804@cisco.com> Date: Tue, 24 Aug 2010 14:47:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 18:47:25 -0000 Christer Holmberg wrote: > Hi, > > I think it is strange to reject something based on a claim there already exists a number of legacy ways of there. Not everyone has implemented the same (if any) of them, and the whole purpose of the Info Package framework is to come up with a mechanism for which the usage can be negotiated. > > And, as I said earlier, at least in IMS an Info Package is being used for DTMF transport. It is currently defined in 3GPP specifications, but there shouldn't be anything IMS specific about the package itself. I wasn't asserting a general principle. I was talking about this particular mechanism. If there is yet another dtmf package, then I guess we can consider the pros/cons of it. Those are probably best assessed by those who use the existing one and/or might use whatever info package you might propose to replace it. We clearly suffer from a surplus of ways to convey dtmf. While its not impossible to argue than another one would improve the situation, it is going to be a hard sell. OTOH, the more there are the more case it makes for having an SBC in the path to "fix" the interoperability. We sell them, so maybe I should be cheering on every new one as a way to boost sales. Thanks, Paul > Regards, > > Christer > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 24. elokuuta 2010 18:51 >> To: Hadriel Kaplan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] I-D >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >> >> Maybe we should ask our ADs if they have an opinion about this. >> >> Thanks, >> Paul >> >> Hadriel Kaplan wrote: >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, August 23, 2010 6:02 PM >>>> To: Hadriel Kaplan >>>> >>>> That reduces things somewhat. But if everybody that supports the >>>> package also supports the legacy approach, what is the win? >>> The legacy mode has no published standards document >> defining it. I thought when the info-packages work was >> started, DTMF-in-info was one of the main drivers. But I >> take your point - if people would prefer to just document it >> as it is today (sans info-packages), I can change the draft >> to just be that. I'm cool with either way (defining the >> current dtmf-relay as a legacy mode was Option-2). >>> -hadriel >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From kpfleming@digium.com Tue Aug 24 12:36:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331453A6A35 for ; Tue, 24 Aug 2010 12:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OK2oCOfAoiJz for ; Tue, 24 Aug 2010 12:36:02 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 53C8C3A6A6D for ; Tue, 24 Aug 2010 12:34:58 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1OnzHJ-0003XZ-8M for dispatch@ietf.org; Tue, 24 Aug 2010 14:35:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 3857AD8026 for ; Tue, 24 Aug 2010 14:35:25 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GJDMeymx1Iu for ; Tue, 24 Aug 2010 14:35:24 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id AB91CD8025 for ; Tue, 24 Aug 2010 14:35:24 -0500 (CDT) Message-ID: <4C741EFC.1080902@digium.com> Date: Tue, 24 Aug 2010 14:35:24 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: dispatch@ietf.org References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> In-Reply-To: <4C7413D9.80804@cisco.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 19:36:08 -0000 On 08/24/2010 01:47 PM, Paul Kyzivat wrote: > > > Christer Holmberg wrote: >> Hi, >> >> I think it is strange to reject something based on a claim there >> already exists a number of legacy ways of there. Not everyone has >> implemented the same (if any) of them, and the whole purpose of the >> Info Package framework is to come up with a mechanism for which the >> usage can be negotiated. >> >> And, as I said earlier, at least in IMS an Info Package is being used >> for DTMF transport. It is currently defined in 3GPP specifications, >> but there shouldn't be anything IMS specific about the package itself. > > I wasn't asserting a general principle. > I was talking about this particular mechanism. > > If there is yet another dtmf package, then I guess we can consider the > pros/cons of it. Those are probably best assessed by those who use the > existing one and/or might use whatever info package you might propose to > replace it. > > We clearly suffer from a surplus of ways to convey dtmf. > While its not impossible to argue than another one would improve the > situation, it is going to be a hard sell. > > OTOH, the more there are the more case it makes for having an SBC in the > path to "fix" the interoperability. We sell them, so maybe I should be > cheering on every new one as a way to boost sales. We see almost zero usage of SIP INFO now, although I know it's out there and there are probably cases where people have had to configure our systems to support it. To date it's been considered a bit of an 'oddball' for DTMF transport, since there was no standards document defining it. I'm a bit concerned that producing such a standards document will in fact encourage implementors to start implementing it, even though it is not as capable as RFC4733/4734 are (but of course it has some benefits over media stream based signaling). We've not even bothered to implement KPML, for many of the same reasons; there's just little or no demand for it. Instead of 'blessing' this INFO package for DTMF transport, I think the group's time would be better spent determining the use cases that cause implementors to want to use it, and then figuring out if those use cases can be addressed via existing mechanisms, or with modifications to existing mechanisms. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From HKaplan@acmepacket.com Tue Aug 24 13:37:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80BBC3A6A75 for ; Tue, 24 Aug 2010 13:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOcFldrmwkeA for ; Tue, 24 Aug 2010 13:36:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E471D3A69ED for ; Tue, 24 Aug 2010 13:34:43 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 24 Aug 2010 16:34:51 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 24 Aug 2010 16:34:51 -0400 From: Hadriel Kaplan To: "Kevin P. Fleming" , "dispatch@ietf.org" Date: Tue, 24 Aug 2010 16:34:49 -0400 Thread-Topic: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDxAbdrFYxIN6ETWG5XtKmlI4xYAABregg Message-ID: <430FC6BDED356B4C8498F634416644A926943822EF@mail> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <4C741EFC.1080902@digium.com> In-Reply-To: <4C741EFC.1080902@digium.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 Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 20:37:12 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Kevin P. Fleming > Sent: Tuesday, August 24, 2010 3:35 PM >=20 > We see almost zero usage of SIP INFO now, although I know it's out there > and there are probably cases where people have had to configure our > systems to support it. To date it's been considered a bit of an > 'oddball' for DTMF transport, since there was no standards document > defining it. I'm a bit concerned that producing such a standards > document will in fact encourage implementors to start implementing it, > even though it is not as capable as RFC4733/4734 are (but of course it > has some benefits over media stream based signaling). That's odd. We've seen tons of dtmf in INFO used. It hasn't been as popul= ar as 2833/4733 RTP-based dtmf overall, but for the guys who need signaling= -based DTMF it's been the king (way more than KPML or proprietary Notify-ba= sed ones). =20 > We've not even bothered to implement KPML, for many of the same reasons; > there's just little or no demand for it. Likewise. -hadriel From partr@cisco.com Tue Aug 24 20:01:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4435B3A681E for ; Tue, 24 Aug 2010 20:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.243 X-Spam-Level: X-Spam-Status: No, score=-9.243 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbtUTJTrkeZM for ; Tue, 24 Aug 2010 20:01:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C86D63A680B for ; Tue, 24 Aug 2010 20:01:40 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAFAEokdExAaMHG/2dsb2JhbACBQ54iVHGiApwIhTcEhDOIMw X-IronPort-AV: E=Sophos;i="4.56,266,1280707200"; d="scan'208,217";a="235390011" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-3.cisco.com with ESMTP; 25 Aug 2010 03:02:12 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7P32BBj020298; Wed, 25 Aug 2010 03:02:11 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 08:32:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB4401.E8C13180" Date: Wed, 25 Aug 2010 08:32:10 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch]I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDvOLBe1YZhBFsTWqLWKL3I3mobgAQIrjJ References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , "Christer Holmberg" X-OriginalArrivalTime: 25 Aug 2010 03:02:10.0726 (UTC) FILETIME=[E9236C60:01CB4401] Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 03:01:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB4401.E8C13180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer/Hadriel, =20 In case IMS needs new INFO based DTMF relay mechanism, I agree that it = is the valid requirement and we need to evaluate it. Before concluding = about new INFO based mechanism in IMS, Please throw the light for not = selecting KPML in IMS. I'm comparing KPML vs INFO based mechanism as = both are based on SIP signaling based mechanism. KPML has limited = deployment as mentioned in Hadriel Info draft but new INFO package is = yet to be defined. It is better to have the single active IETF SIP = signaling based dtmf-relay mechanism rather than producing more = standards wherein implementers will completely confused which one to = select.=20 =20 As Muthu mentioned, I also heard about KPML deployment issues but the = legacy INFO based dtmf-relay has lot more caveats. I guess that Info = package is designed as generic as KPML, and then both KPML and INFO may = look heavyweight.=20 =20 I agree with Paul that new INFO based DTMF will not solve interop issue = but call for SBC functionality addition due to this new behavior. But in = case it is the industry or IMS needs, let us explore it. =20 Thanks Partha ________________________________ From: dispatch-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) Sent: Wed 8/25/2010 12:17 AM To: Christer Holmberg Cc: dispatch@ietf.org; Hadriel Kaplan Subject: Re: [dispatch]I-D = Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Christer Holmberg wrote: > Hi, > > I think it is strange to reject something based on a claim there = already exists a number of legacy ways of there. Not everyone has = implemented the same (if any) of them, and the whole purpose of the Info = Package framework is to come up with a mechanism for which the usage can = be negotiated. > > And, as I said earlier, at least in IMS an Info Package is being used = for DTMF transport. It is currently defined in 3GPP specifications, but = there shouldn't be anything IMS specific about the package itself. I wasn't asserting a general principle. I was talking about this particular mechanism. If there is yet another dtmf package, then I guess we can consider the pros/cons of it. Those are probably best assessed by those who use the existing one and/or might use whatever info package you might propose to replace it. We clearly suffer from a surplus of ways to convey dtmf. While its not impossible to argue than another one would improve the situation, it is going to be a hard sell. OTOH, the more there are the more case it makes for having an SBC in the path to "fix" the interoperability. We sell them, so maybe I should be cheering on every new one as a way to boost sales. Thanks, Paul > Regards, > > Christer > >=20 > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 24. elokuuta 2010 18:51 >> To: Hadriel Kaplan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] I-D >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >> >> Maybe we should ask our ADs if they have an opinion about this. >> >> Thanks, >> Paul >> >> Hadriel Kaplan wrote: >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, August 23, 2010 6:02 PM >>>> To: Hadriel Kaplan >>>> >>>> That reduces things somewhat. But if everybody that supports the >>>> package also supports the legacy approach, what is the win? >>> The legacy mode has no published standards document >> defining it. I thought when the info-packages work was >> started, DTMF-in-info was one of the main drivers. But I >> take your point - if people would prefer to just document it >> as it is today (sans info-packages), I can change the draft >> to just be that. I'm cool with either way (defining the >> current dtmf-relay as a legacy mode was Option-2). >>> -hadriel >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------_=_NextPart_001_01CB4401.E8C13180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch]I-D = Action:draft-kaplan-dispatch-info-dtmf-package-00.txt=0A= =0A= =0A= =0A=
=0A=
=0A=

Christer/Hadriel,

=0A=

 

=0A=

In case IMS needs new INFO = based DTMF relay mechanism, I agree that it is the valid requirement and = we need to evaluate it. Before concluding about new INFO based mechanism = in IMS, Please throw the light for not selecting KPML in IMS. I'm = comparing KPML vs INFO based mechanism as both are based on SIP = signaling based mechanism. KPML has limited deployment as mentioned = in Hadriel Info draft but new INFO package is yet to be = defined. It is better to have the single active IETF SIP signaling = based dtmf-relay mechanism rather than producing more = standards wherein implementers will completely confused which one = to select.

=0A=

 

=0A=

As Muthu mentioned, I also = heard about KPML deployment issues but the legacy INFO based = dtmf-relay has lot more caveats. I guess that Info package is = designed as generic as KPML, and then both KPML and INFO may look = heavyweight.

=0A=

 

=0A=

I agree with Paul that new = INFO based DTMF will not solve interop issue but call for SBC = functionality addition due to this new behavior. But in case it is the = industry or IMS needs, let us explore it.

=0A=

 

=0A=

Thanks

=0A=

Partha

=0A=

=0A=
=0A= From: dispatch-bounces@ietf.org on = behalf of Paul Kyzivat (pkyzivat)
Sent: Wed 8/25/2010 12:17 = AM
To: Christer Holmberg
Cc: dispatch@ietf.org; = Hadriel Kaplan
Subject: Re: [dispatch]I-D = Action:draft-kaplan-dispatch-info-dtmf-package-00.txt

=0A=


=0A=

Christer Holmberg wrote:
> Hi,
>
> I = think it is strange to reject something based on a claim there already = exists a number of legacy ways of there. Not everyone has implemented = the same (if any) of them, and the whole purpose of the Info Package = framework is to come up with a mechanism for which the usage can be = negotiated.
>
> And, as I said earlier, at least in IMS an = Info Package is being used for DTMF transport. It is currently defined = in 3GPP specifications, but there shouldn't be anything IMS specific = about the package itself.

I wasn't asserting a general = principle.
I was talking about this particular mechanism.

If = there is yet another dtmf package, then I guess we can consider = the
pros/cons of it. Those are probably best assessed by those who = use the
existing one and/or might use whatever info package you might = propose to
replace it.

We clearly suffer from a surplus of = ways to convey dtmf.
While its not impossible to argue than another = one would improve the
situation, it is going to be a hard = sell.

OTOH, the more there are the more case it makes for having = an SBC in the
path to "fix" the interoperability. We sell them, so = maybe I should be
cheering on every new one as a way to boost = sales.

        = Thanks,
        Paul

> = Regards,
>
> = Christer
>
> 
>
>> -----Original = Message-----
>> From: dispatch-bounces@ietf.org
>> [mailto:dispatch-bounces@ietf.or= g] On Behalf Of Paul Kyzivat
>> Sent: 24. elokuuta 2010 = 18:51
>> To: Hadriel Kaplan
>> Cc: = dispatch@ietf.org
>> Subject: Re: [dispatch] I-D
>> = Action:draft-kaplan-dispatch-info-dtmf-package-00.txt
>>
>= > Maybe we should ask our ADs if they have an opinion about = this.
>>
>>      = Thanks,
>>      = Paul
>>
>> Hadriel Kaplan wrote:
>>>> = -----Original Message-----
>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>= >>> Sent: Monday, August 23, 2010 6:02 PM
>>>> = To: Hadriel Kaplan
>>>>
>>>> That reduces = things somewhat. But if everybody that supports the
>>>> = package also supports the legacy approach, what is the = win?
>>> The legacy mode has no published standards = document
>> defining it.  I thought when the info-packages = work was
>> started, DTMF-in-info was one of the main = drivers.  But I
>> take your point - if people would = prefer to just document it
>> as it is today (sans = info-packages), I can change the draft
>> to just be = that.  I'm cool with either way (defining the
>> current = dtmf-relay as a legacy mode was Option-2).
>>> = -hadriel
>>>
>> = _______________________________________________
>> dispatch = mailing list
>> dispatch@ietf.org
>> https://www.ietf.= org/mailman/listinfo/dispatch
>>
________________________= _______________________
dispatch mailing = list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch

------_=_NextPart_001_01CB4401.E8C13180-- From christer.holmberg@ericsson.com Tue Aug 24 20:14:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50113A6832 for ; Tue, 24 Aug 2010 20:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.302 X-Spam-Level: X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxW-y6fcDMeW for ; Tue, 24 Aug 2010 20:14:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 8D45C3A681E for ; Tue, 24 Aug 2010 20:14:34 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-6c-4c748aba4be4 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 18.D8.06895.ABA847C4; Wed, 25 Aug 2010 05:15:06 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 25 Aug 2010 05:15:06 +0200 From: Christer Holmberg To: "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" Date: Wed, 25 Aug 2010 05:15:03 +0200 Thread-Topic: [dispatch]I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDvOLBe1YZhBFsTWqLWKL3I3mobgAQIrjJAAEnJwA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.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-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 03:14:37 -0000 Hi,=20 =20 >In case IMS needs new INFO based DTMF relay mechanism, I agree that it is = the valid requirement and we need to evaluate it. Before concluding about n= ew >INFO based mechanism in IMS, Please throw the light for not selecting KPML= in IMS. I'm comparing KPML vs INFO based mechanism as both are based on SI= P=20 >signaling based mechanism. KPML has limited deployment as mentioned in Had= riel Info draft but new INFO package is yet to be defined. It is better to = have=20 >the single active IETF SIP signaling based dtmf-relay mechanism rather tha= n producing more standards wherein implementers will completely confused wh= ich=20 >one to select.=20 > >As Muthu mentioned, I also heard about KPML deployment issues but the lega= cy INFO based dtmf-relay has lot more caveats. I guess that Info package is= =20 >designed as generic as KPML, and then both KPML and INFO may look heavywei= ght.=20 The 3GPP DTMF Info Package is very simple. Regards, Christer =09 ________________________________ From: dispatch-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) Sent: Wed 8/25/2010 12:17 AM To: Christer Holmberg Cc: dispatch@ietf.org; Hadriel Kaplan Subject: Re: [dispatch]I-D Action:draft-kaplan-dispatch-info-dtmf-package-= 00.txt =09 =09 Christer Holmberg wrote: > Hi, > > I think it is strange to reject something based on a claim there already= exists a number of legacy ways of there. Not everyone has implemented the = same (if any) of them, and the whole purpose of the Info Package framework = is to come up with a mechanism for which the usage can be negotiated. > > And, as I said earlier, at least in IMS an Info Package is being used fo= r DTMF transport. It is currently defined in 3GPP specifications, but there= shouldn't be anything IMS specific about the package itself. =09 I wasn't asserting a general principle. I was talking about this particular mechanism. =09 If there is yet another dtmf package, then I guess we can consider the pros/cons of it. Those are probably best assessed by those who use the existing one and/or might use whatever info package you might propose to replace it. =09 We clearly suffer from a surplus of ways to convey dtmf. While its not impossible to argue than another one would improve the situation, it is going to be a hard sell. =09 OTOH, the more there are the more case it makes for having an SBC in the path to "fix" the interoperability. We sell them, so maybe I should be cheering on every new one as a way to boost sales. =09 Thanks, Paul =09 > Regards, > > Christer > >=20 > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 24. elokuuta 2010 18:51 >> To: Hadriel Kaplan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] I-D >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >> >> Maybe we should ask our ADs if they have an opinion about this. >> >> Thanks, >> Paul >> >> Hadriel Kaplan wrote: >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, August 23, 2010 6:02 PM >>>> To: Hadriel Kaplan >>>> >>>> That reduces things somewhat. But if everybody that supports the >>>> package also supports the legacy approach, what is the win? >>> The legacy mode has no published standards document >> defining it. I thought when the info-packages work was >> started, DTMF-in-info was one of the main drivers. But I >> take your point - if people would prefer to just document it >> as it is today (sans info-packages), I can change the draft >> to just be that. I'm cool with either way (defining the >> current dtmf-relay as a legacy mode was Option-2). >>> -hadriel >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =09 From partr@cisco.com Tue Aug 24 20:25:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE733A67F7 for ; Tue, 24 Aug 2010 20:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.241 X-Spam-Level: X-Spam-Status: No, score=-9.241 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmGWYLFVOw2B for ; Tue, 24 Aug 2010 20:25:12 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B8FCD3A681E for ; Tue, 24 Aug 2010 20:25:12 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADAqdExAaMHG/2dsb2JhbACfZVRxogGcCYU3BIQziDM X-IronPort-AV: E=Sophos;i="4.56,266,1280707200"; d="scan'208,217";a="235394498" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-3.cisco.com with ESMTP; 25 Aug 2010 03:25:44 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7P3PhQY025156; Wed, 25 Aug 2010 03:25:43 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 08:55:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB4405.329C57FD" Date: Wed, 25 Aug 2010 08:55:42 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDvOLBe1YZhBFsTWqLWKL3I3mobgAQIrjJAAEnJwAAAJN2aQ== References: <430FC6BDED356B4C8498F634416644A92694381B86@mail><1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381C2C@mail><1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381E9F@mail><4C729FEF.6020509@cisco.com><430FC6BDED356B4C8498F634416644A92694381F16@mail><4C72C9CA.3070304@cisco.com><430FC6BDED356B4C8498F634416644A92694381FDF@mail><4C72EFCC.2000107@cisco.com><430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> From: "Parthasarathi R (partr)" To: "Christer Holmberg" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 25 Aug 2010 03:25:42.0621 (UTC) FILETIME=[32B180D0:01CB4405] Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 03:25:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB4405.329C57FD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer, =20 My questions are =20 1) whether 3GPP DTMF Info package is in the state to be accepted as IETF = standards. 2) Whether current IETF standard (KPML) has to be deprecated for the = proposed DTMF Info packages. Both KPML, DTMF Info package are SIP = signaling based mechanism for DTMF relay. =20 In case both questions are answered in favor of DTMF Info package, I'm = fine with DTMF Info package proposal. =20 Thanks Partha ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wed 8/25/2010 8:45 AM To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal = (mperumal) Subject: RE: = [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Hi, =20 >In case IMS needs new INFO based DTMF relay mechanism, I agree that it = is the valid requirement and we need to evaluate it. Before concluding = about new >INFO based mechanism in IMS, Please throw the light for not selecting = KPML in IMS. I'm comparing KPML vs INFO based mechanism as both are = based on SIP >signaling based mechanism. KPML has limited deployment as mentioned in = Hadriel Info draft but new INFO package is yet to be defined. It is = better to have >the single active IETF SIP signaling based dtmf-relay mechanism rather = than producing more standards wherein implementers will completely = confused which >one to select. > >As Muthu mentioned, I also heard about KPML deployment issues but the = legacy INFO based dtmf-relay has lot more caveats. I guess that Info = package is >designed as generic as KPML, and then both KPML and INFO may look = heavyweight. The 3GPP DTMF Info Package is very simple. Regards, Christer =20 ________________________________ From: dispatch-bounces@ietf.org on behalf of Paul Kyzivat = (pkyzivat) Sent: Wed 8/25/2010 12:17 AM To: Christer Holmberg Cc: dispatch@ietf.org; Hadriel Kaplan Subject: Re: [dispatch]I-D = Action:draft-kaplan-dispatch-info-dtmf-package-00.txt =20 =20 Christer Holmberg wrote: > Hi, > > I think it is strange to reject something based on a claim = there already exists a number of legacy ways of there. Not everyone has = implemented the same (if any) of them, and the whole purpose of the Info = Package framework is to come up with a mechanism for which the usage can = be negotiated. > > And, as I said earlier, at least in IMS an Info Package is = being used for DTMF transport. It is currently defined in 3GPP = specifications, but there shouldn't be anything IMS specific about the = package itself. =20 I wasn't asserting a general principle. I was talking about this particular mechanism. =20 If there is yet another dtmf package, then I guess we can = consider the pros/cons of it. Those are probably best assessed by those who = use the existing one and/or might use whatever info package you might = propose to replace it. =20 We clearly suffer from a surplus of ways to convey dtmf. While its not impossible to argue than another one would improve = the situation, it is going to be a hard sell. =20 OTOH, the more there are the more case it makes for having an = SBC in the path to "fix" the interoperability. We sell them, so maybe I = should be cheering on every new one as a way to boost sales. =20 Thanks, Paul =20 > Regards, > > Christer > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 24. elokuuta 2010 18:51 >> To: Hadriel Kaplan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] I-D >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >> >> Maybe we should ask our ADs if they have an opinion about = this. >> >> Thanks, >> Paul >> >> Hadriel Kaplan wrote: >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, August 23, 2010 6:02 PM >>>> To: Hadriel Kaplan >>>> >>>> That reduces things somewhat. But if everybody that = supports the >>>> package also supports the legacy approach, what is the win? >>> The legacy mode has no published standards document >> defining it. I thought when the info-packages work was >> started, DTMF-in-info was one of the main drivers. But I >> take your point - if people would prefer to just document it >> as it is today (sans info-packages), I can change the draft >> to just be that. I'm cool with either way (defining the >> current dtmf-relay as a legacy mode was Option-2). >>> -hadriel >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 ------_=_NextPart_001_01CB4405.329C57FD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: = [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt</TITLE= >=0A= <META content=3D"text/html; charset=3Dunicode" http-equiv=3DContent-Type>=0A= <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18928"></HEAD>=0A= <BODY>=0A= <DIV dir=3Dltr id=3DidOWAReplyText44151>=0A= <DIV dir=3Dltr><FONT color=3D#000000 size=3D2 = face=3DArial>Christer,</FONT></DIV>=0A= <DIV dir=3Dltr><FONT size=3D2 face=3DArial></FONT> </DIV>=0A= <DIV dir=3Dltr>My questions are</DIV>=0A= <DIV dir=3Dltr> </DIV>=0A= <DIV dir=3Dltr>1) whether 3GPP DTMF Info package is in the state to be = accepted as IETF standards.</DIV>=0A= <DIV dir=3Dltr>2) Whether current IETF standard (KPML) has to be = deprecated for the proposed DTMF Info packages. Both KPML, DTMF = Info package are SIP signaling based mechanism for DTMF relay.</DIV>=0A= <DIV dir=3Dltr> </DIV>=0A= <DIV dir=3Dltr>In case both questions are answered in favor of DTMF Info = package, I'm fine with DTMF Info package proposal.</DIV>=0A= <DIV dir=3Dltr> </DIV>=0A= <DIV dir=3Dltr>Thanks</DIV>=0A= <DIV dir=3Dltr>Partha</DIV></DIV>=0A= <DIV dir=3Dltr><BR>=0A= <HR tabIndex=3D-1>=0A= <FONT size=3D2 face=3DTahoma><B>From:</B> Christer Holmberg = [mailto:christer.holmberg@ericsson.com]<BR><B>Sent:</B> Wed 8/25/2010 = 8:45 AM<BR><B>To:</B> Parthasarathi R (partr); Paul Kyzivat = (pkyzivat)<BR><B>Cc:</B> dispatch@ietf.org; Hadriel Kaplan; Muthu = ArulMozhi Perumal (mperumal)<BR><B>Subject:</B> RE: = [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt<BR></F= ONT><BR></DIV>=0A= <DIV><BR>=0A= <P><FONT = size=3D2>Hi,<BR>        <BR>>I= n case IMS needs new INFO based DTMF relay mechanism, I agree that it is = the valid requirement and we need to evaluate it. Before concluding = about new<BR>>INFO based mechanism in IMS, Please throw the light for = not selecting KPML in IMS. I'm comparing KPML vs INFO based mechanism as = both are based on SIP<BR>>signaling based mechanism. KPML has limited = deployment as mentioned in Hadriel Info draft but new INFO package is = yet to be defined. It is better to have<BR>>the single active IETF = SIP signaling based dtmf-relay mechanism rather than producing more = standards wherein implementers will completely confused which<BR>>one = to select.<BR>><BR>>As Muthu mentioned, I also heard about KPML = deployment issues but the legacy INFO based dtmf-relay has lot more = caveats. I guess that Info package is<BR>>designed as generic as = KPML, and then both KPML and INFO may look heavyweight.<BR><BR>The 3GPP = DTMF Info Package is very = simple.<BR><BR>Regards,<BR><BR>Christer<BR><BR><BR><BR>   =     <BR>________________________________<BR><BR> = ;       From: dispatch-bounces@ietf.org on = behalf of Paul Kyzivat = (pkyzivat)<BR>        Sent: Wed = 8/25/2010 12:17 AM<BR>        To: = Christer Holmberg<BR>        Cc: = dispatch@ietf.org; Hadriel = Kaplan<BR>        Subject: Re: = [dispatch]I-D = Action:draft-kaplan-dispatch-info-dtmf-package-00.txt<BR>  &nbs= p;    <BR>       <= BR><BR><BR><BR>        Christer = Holmberg wrote:<BR>        > = Hi,<BR>        = ><BR>        > I think it is = strange to reject something based on a claim there already exists a = number of legacy ways of there. Not everyone has implemented the same = (if any) of them, and the whole purpose of the Info Package framework is = to come up with a mechanism for which the usage can be = negotiated.<BR>        = ><BR>        > And, as I said = earlier, at least in IMS an Info Package is being used for DTMF = transport. It is currently defined in 3GPP specifications, but there = shouldn't be anything IMS specific about the package = itself.<BR>       <BR>  &nbs= p;     I wasn't asserting a general = principle.<BR>        I was talking = about this particular = mechanism.<BR>       <BR>  &= nbsp;     If there is yet another dtmf package, then = I guess we can consider = the<BR>        pros/cons of it. Those = are probably best assessed by those who use = the<BR>        existing one and/or = might use whatever info package you might propose = to<BR>        replace = it.<BR>       <BR>   &n= bsp;    We clearly suffer from a surplus of ways to = convey dtmf.<BR>        While its not = impossible to argue than another one would improve = the<BR>        situation, it is going = to be a hard = sell.<BR>       <BR>   =      OTOH, the more there are the more case it makes = for having an SBC in the<BR>        = path to "fix" the interoperability. We sell them, so maybe I should = be<BR>        cheering on every new = one as a way to boost = sales.<BR>       <BR>   = ;             = Thanks,<BR>        =         = Paul<BR>       <BR>   &= nbsp;    > = Regards,<BR>        = ><BR>        > = Christer<BR>        = ><BR>        = ><BR>        = ><BR>        >> = -----Original Message-----<BR>        = >> From: = dispatch-bounces@ietf.org<BR>        = >> [<A = href=3D"mailto:dispatch-bounces@ietf.org">mailto:dispatch-bounces@ietf.or= g</A>] On Behalf Of Paul = Kyzivat<BR>        >> Sent: 24. = elokuuta 2010 18:51<BR>        = >> To: Hadriel = Kaplan<BR>        >> Cc: = dispatch@ietf.org<BR>        >> = Subject: Re: [dispatch] = I-D<BR>        >> = Action:draft-kaplan-dispatch-info-dtmf-package-00.txt<BR>  &nbs= p;     = >><BR>        >> Maybe we = should ask our ADs if they have an opinion about = this.<BR>        = >><BR>        = >>      = Thanks,<BR>        = >>      = Paul<BR>        = >><BR>        >> Hadriel = Kaplan wrote:<BR>        = >>>> -----Original = Message-----<BR>        = >>>> From: Paul Kyzivat [<A = href=3D"mailto:pkyzivat@cisco.com">mailto:pkyzivat@cisco.com</A>]<BR>&nbs= p;       >>>> Sent: Monday, = August 23, 2010 6:02 PM<BR>        = >>>> To: Hadriel = Kaplan<BR>        = >>>><BR>        = >>>> That reduces things somewhat. But if everybody that = supports the<BR>        = >>>> package also supports the legacy approach, what is the = win?<BR>        >>> The = legacy mode has no published standards = document<BR>        >> defining = it.  I thought when the info-packages work = was<BR>        >> started, = DTMF-in-info was one of the main drivers.  But = I<BR>        >> take your point = - if people would prefer to just document = it<BR>        >> as it is today = (sans info-packages), I can change the = draft<BR>        >> to just be = that.  I'm cool with either way (defining = the<BR>        >> current = dtmf-relay as a legacy mode was = Option-2).<BR>        >>> = -hadriel<BR>        = >>><BR>        >> = _______________________________________________<BR>   &nbs= p;    >> dispatch mailing = list<BR>        >> = dispatch@ietf.org<BR>        >> = <A = href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.= org/mailman/listinfo/dispatch</A><BR>      =   >><BR>        = _______________________________________________<BR>   &nbs= p;    dispatch mailing = list<BR>        = dispatch@ietf.org<BR>        <A = href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.= org/mailman/listinfo/dispatch</A><BR>      =  <BR><BR></FONT></P></DIV></BODY></HTML> ------_=_NextPart_001_01CB4405.329C57FD-- From christer.holmberg@ericsson.com Tue Aug 24 20:34:27 2010 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F883A6832 for <dispatch@core3.amsl.com>; Tue, 24 Aug 2010 20:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.282 X-Spam-Level: X-Spam-Status: No, score=-5.282 tagged_above=-999 required=5 tests=[AWL=1.317, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml+zYtkW-NZV for <dispatch@core3.amsl.com>; Tue, 24 Aug 2010 20:34:25 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8A97C3A693A for <dispatch@ietf.org>; Tue, 24 Aug 2010 20:34:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-e8-4c748f5f8ac4 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 54.8A.10125.F5F847C4; Wed, 25 Aug 2010 05:34:56 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 25 Aug 2010 05:34:55 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 25 Aug 2010 05:34:55 +0200 From: Christer Holmberg <christer.holmberg@ericsson.com> To: "Parthasarathi R (partr)" <partr@cisco.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com> Date: Wed, 25 Aug 2010 05:34:35 +0200 Thread-Topic: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDvOLBe1YZhBFsTWqLWKL3I3mobgAQIrjJAAEnJwAAAJN2aQAAQDNA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851B8652@ESESSCMS0356.eemea.ericsson.se> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail><1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381C2C@mail><1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381E9F@mail><4C729FEF.6020509@cisco.com><430FC6BDED356B4C8498F634416644A92694381F16@mail><4C72C9CA.3070304@cisco.com><430FC6BDED356B4C8498F634416644A92694381FDF@mail><4C72EFCC.2000107@cisco.com><430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <A11921905DA1564D9BCF64A6430A62390293A4A8@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> <A11921905DA1564D9BCF64A6430A62390293A4A9@XMB-BGL-411.cisco.com> In-Reply-To: <A11921905DA1564D9BCF64A6430A62390293A4A9@XMB-BGL-411.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: AAAAAA== Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Hadriel Kaplan <HKaplan@acmepacket.com> Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Aug 2010 03:34:27 -0000 Hi,=20 >1) whether 3GPP DTMF Info package is in the state to be accepted as IETF s= tandards. The Info Package registration procedure requires an expert review, which pu= rpose is to ensure that the Info Package does not break the SIP protocol et= c. I assume such review will take place when the package is registered with= IANA. Regards, Christer ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wed 8/25/2010 8:45 AM To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal (mperumal) Subject: RE: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-0= 0.txt =09 =09 Hi, =20 >In case IMS needs new INFO based DTMF relay mechanism, I agree that it is= the valid requirement and we need to evaluate it. Before concluding about = new >INFO based mechanism in IMS, Please throw the light for not selecting KPM= L in IMS. I'm comparing KPML vs INFO based mechanism as both are based on S= IP >signaling based mechanism. KPML has limited deployment as mentioned in Ha= driel Info draft but new INFO package is yet to be defined. It is better to= have >the single active IETF SIP signaling based dtmf-relay mechanism rather th= an producing more standards wherein implementers will completely confused w= hich >one to select. > >As Muthu mentioned, I also heard about KPML deployment issues but the leg= acy INFO based dtmf-relay has lot more caveats. I guess that Info package i= s >designed as generic as KPML, and then both KPML and INFO may look heavywe= ight. =09 The 3GPP DTMF Info Package is very simple. =09 Regards, =09 Christer =09 =09 =09 =20 ________________________________ =09 From: dispatch-bounces@ietf.org on behalf of Paul Kyzivat (pkyziva= t) Sent: Wed 8/25/2010 12:17 AM To: Christer Holmberg Cc: dispatch@ietf.org; Hadriel Kaplan Subject: Re: [dispatch]I-D Action:draft-kaplan-dispatch-info-dtmf-= package-00.txt =20 =20 =09 =09 =09 Christer Holmberg wrote: > Hi, > > I think it is strange to reject something based on a claim there= already exists a number of legacy ways of there. Not everyone has implemen= ted the same (if any) of them, and the whole purpose of the Info Package fr= amework is to come up with a mechanism for which the usage can be negotiate= d. > > And, as I said earlier, at least in IMS an Info Package is being= used for DTMF transport. It is currently defined in 3GPP specifications, b= ut there shouldn't be anything IMS specific about the package itself. =20 I wasn't asserting a general principle. I was talking about this particular mechanism. =20 If there is yet another dtmf package, then I guess we can consider= the pros/cons of it. Those are probably best assessed by those who use= the existing one and/or might use whatever info package you might prop= ose to replace it. =20 We clearly suffer from a surplus of ways to convey dtmf. While its not impossible to argue than another one would improve t= he situation, it is going to be a hard sell. =20 OTOH, the more there are the more case it makes for having an SBC = in the path to "fix" the interoperability. We sell them, so maybe I shoul= d be cheering on every new one as a way to boost sales. =20 Thanks, Paul =20 > Regards, > > Christer > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 24. elokuuta 2010 18:51 >> To: Hadriel Kaplan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] I-D >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >> >> Maybe we should ask our ADs if they have an opinion about this. >> >> Thanks, >> Paul >> >> Hadriel Kaplan wrote: >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, August 23, 2010 6:02 PM >>>> To: Hadriel Kaplan >>>> >>>> That reduces things somewhat. But if everybody that supports = the >>>> package also supports the legacy approach, what is the win? >>> The legacy mode has no published standards document >> defining it. I thought when the info-packages work was >> started, DTMF-in-info was one of the main drivers. But I >> take your point - if people would prefer to just document it >> as it is today (sans info-packages), I can change the draft >> to just be that. I'm cool with either way (defining the >> current dtmf-relay as a legacy mode was Option-2). >>> -hadriel >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 =09 =09 From mperumal@cisco.com Tue Aug 24 20:47:26 2010 Return-Path: <mperumal@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487403A695B for <dispatch@core3.amsl.com>; Tue, 24 Aug 2010 20:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.843 X-Spam-Level: X-Spam-Status: No, score=-9.843 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Dms+JoZI587 for <dispatch@core3.amsl.com>; Tue, 24 Aug 2010 20:47:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 437E03A693A for <dispatch@ietf.org>; Tue, 24 Aug 2010 20:47:24 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE8vdExAaMHG/2dsb2JhbACgOXGiAJwMhTcEhDOIMw X-IronPort-AV: E=Sophos;i="4.56,266,1280707200"; d="scan'208";a="578403631" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2010 03:47:56 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7P3lf6X000007; Wed, 25 Aug 2010 03:47:55 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 09:16:59 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Aug 2010 09:16:54 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202036C3F6D@XMB-BGL-414.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851B8652@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDvOLBe1YZhBFsTWqLWKL3I3mobgAQIrjJAAEnJwAAAJN2aQAAQDNAAACRebA= References: <430FC6BDED356B4C8498F634416644A92694381B86@mail><1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381C2C@mail><1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381E9F@mail><4C729FEF.6020509@cisco.com><430FC6BDED356B4C8498F634416644A92694381F16@mail><4C72C9CA.3070304@cisco.com><430FC6BDED356B4C8498F634416644A92694381FDF@mail><4C72EFCC.2000107@cisco.com><430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <A11921905DA1564D9BCF64A6430A62390293A4A8@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> <A11921905DA1564D9BCF64A6430A62390293A4A9@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8652@ESESSCMS0356.eemea.ericsson.se> From: "Muthu ArulMozhi Perumal (mperumal)" <mperumal@cisco.com> To: "Christer Holmberg" <christer.holmberg@ericsson.com>, "Parthasarathi R (partr)" <partr@cisco.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com> X-OriginalArrivalTime: 25 Aug 2010 03:46:59.0933 (UTC) FILETIME=[2C07D8D0:01CB4408] Cc: dispatch@ietf.org, Hadriel Kaplan <HKaplan@acmepacket.com> Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Aug 2010 03:47:26 -0000 Can you please provide the pointer to the 3GPP spec describing this DTMF INFO package? thanks, Muthu |-----Original Message----- |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] |Sent: Wednesday, August 25, 2010 9:05 AM |To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) |Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal (mperumal) |Subject: RE: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package- |00.txt | | |Hi, | |>1) whether 3GPP DTMF Info package is in the state to be accepted as IETF |standards. | |The Info Package registration procedure requires an expert review, which |purpose is to ensure that the Info Package does not break the SIP protocol |etc. I assume such review will take place when the package is registered |with IANA. | |Regards, | |Christer | | | | |________________________________ | | From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] | Sent: Wed 8/25/2010 8:45 AM | To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) | Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal |(mperumal) | Subject: RE: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf- |package-00.txt | | | | | Hi, | | >In case IMS needs new INFO based DTMF relay mechanism, I agree that |it is the valid requirement and we need to evaluate it. Before concluding |about new | >INFO based mechanism in IMS, Please throw the light for not selecting |KPML in IMS. I'm comparing KPML vs INFO based mechanism as both are based on |SIP | >signaling based mechanism. KPML has limited deployment as mentioned |in Hadriel Info draft but new INFO package is yet to be defined. It is |better to have | >the single active IETF SIP signaling based dtmf-relay mechanism |rather than producing more standards wherein implementers will completely |confused which | >one to select. | > | >As Muthu mentioned, I also heard about KPML deployment issues but the |legacy INFO based dtmf-relay has lot more caveats. I guess that Info package |is | >designed as generic as KPML, and then both KPML and INFO may look |heavyweight. | | The 3GPP DTMF Info Package is very simple. | | Regards, | | Christer | | | | | ________________________________ | | From: dispatch-bounces@ietf.org on behalf of Paul Kyzivat |(pkyzivat) | Sent: Wed 8/25/2010 12:17 AM | To: Christer Holmberg | Cc: dispatch@ietf.org; Hadriel Kaplan | Subject: Re: [dispatch]I-D Action:draft-kaplan-dispatch-info- |dtmf-package-00.txt | | | | | | Christer Holmberg wrote: | > Hi, | > | > I think it is strange to reject something based on a claim |there already exists a number of legacy ways of there. Not everyone has |implemented the same (if any) of them, and the whole purpose of the Info |Package framework is to come up with a mechanism for which the usage can be |negotiated. | > | > And, as I said earlier, at least in IMS an Info Package is |being used for DTMF transport. It is currently defined in 3GPP |specifications, but there shouldn't be anything IMS specific about the |package itself. | | I wasn't asserting a general principle. | I was talking about this particular mechanism. | | If there is yet another dtmf package, then I guess we can |consider the | pros/cons of it. Those are probably best assessed by those who |use the | existing one and/or might use whatever info package you might |propose to | replace it. | | We clearly suffer from a surplus of ways to convey dtmf. | While its not impossible to argue than another one would |improve the | situation, it is going to be a hard sell. | | OTOH, the more there are the more case it makes for having an |SBC in the | path to "fix" the interoperability. We sell them, so maybe I |should be | cheering on every new one as a way to boost sales. | | Thanks, | Paul | | > Regards, | > | > Christer | > | > | > | >> -----Original Message----- | >> From: dispatch-bounces@ietf.org | >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul |Kyzivat | >> Sent: 24. elokuuta 2010 18:51 | >> To: Hadriel Kaplan | >> Cc: dispatch@ietf.org | >> Subject: Re: [dispatch] I-D | >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt | >> | >> Maybe we should ask our ADs if they have an opinion about |this. | >> | >> Thanks, | >> Paul | >> | >> Hadriel Kaplan wrote: | >>>> -----Original Message----- | >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] | >>>> Sent: Monday, August 23, 2010 6:02 PM | >>>> To: Hadriel Kaplan | >>>> | >>>> That reduces things somewhat. But if everybody that |supports the | >>>> package also supports the legacy approach, what is the |win? | >>> The legacy mode has no published standards document | >> defining it. I thought when the info-packages work was | >> started, DTMF-in-info was one of the main drivers. But I | >> take your point - if people would prefer to just document |it | >> as it is today (sans info-packages), I can change the draft | >> to just be that. I'm cool with either way (defining the | >> current dtmf-relay as a legacy mode was Option-2). | >>> -hadriel | >>> | >> _______________________________________________ | >> dispatch mailing list | >> dispatch@ietf.org | >> https://www.ietf.org/mailman/listinfo/dispatch | >> | _______________________________________________ | dispatch mailing list | dispatch@ietf.org | https://www.ietf.org/mailman/listinfo/dispatch | | | From christer.holmberg@ericsson.com Tue Aug 24 20:56:42 2010 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA673A6A3F for <dispatch@core3.amsl.com>; Tue, 24 Aug 2010 20:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omOaSdgMLj9o for <dispatch@core3.amsl.com>; Tue, 24 Aug 2010 20:56:41 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B16D83A6947 for <dispatch@ietf.org>; Tue, 24 Aug 2010 20:56:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-01-4c7494981886 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6B.4C.10125.894947C4; Wed, 25 Aug 2010 05:57:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 25 Aug 2010 05:57:11 +0200 From: Christer Holmberg <christer.holmberg@ericsson.com> To: "Muthu ArulMozhi Perumal (mperumal)" <mperumal@cisco.com>, "Parthasarathi R (partr)" <partr@cisco.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com> Date: Wed, 25 Aug 2010 05:57:08 +0200 Thread-Topic: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDvOLBe1YZhBFsTWqLWKL3I3mobgAQIrjJAAEnJwAAAJN2aQAAQDNAAACRebAAAEH1kA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851B8654@ESESSCMS0356.eemea.ericsson.se> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail><1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381C2C@mail><1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381E9F@mail><4C729FEF.6020509@cisco.com><430FC6BDED356B4C8498F634416644A92694381F16@mail><4C72C9CA.3070304@cisco.com><430FC6BDED356B4C8498F634416644A92694381FDF@mail><4C72EFCC.2000107@cisco.com><430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <A11921905DA1564D9BCF64A6430A62390293A4A8@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> <A11921905DA1564D9BCF64A6430A62390293A4A9@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8652@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C6538049202036C3F6D@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202036C3F6D@XMB-BGL-414.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: AAAAAA== Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Hadriel Kaplan <HKaplan@acmepacket.com> Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Aug 2010 03:56:42 -0000 Hi, The package definition can be found in Annex P of 3GPP TS 24.229: http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-a00.zip The MIME body used by the package to transport the digits is defined in Ann= ex G of 3GPP TS 29.163 (it re-uses a body used for overlap dialling, in cas= e the wording confuses):=20 http://www.3gpp.org/ftp/Specs/archive/29_series/29.163/29163-920.zip Regards, Christer > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 > Sent: 25. elokuuta 2010 6:47 > To: Christer Holmberg; Parthasarathi R (partr); Paul Kyzivat=20 > (pkyzivat) > Cc: dispatch@ietf.org; Hadriel Kaplan > Subject: RE:=20 > [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt >=20 > Can you please provide the pointer to the 3GPP spec=20 > describing this DTMF INFO package? >=20 > thanks, > Muthu >=20 > |-----Original Message----- > |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > |Sent: Wednesday, August 25, 2010 9:05 AM > |To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) > |Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal > (mperumal) > |Subject: RE: > [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package- > |00.txt > | > | > |Hi, > | > |>1) whether 3GPP DTMF Info package is in the state to be accepted as > IETF > |standards. > | > |The Info Package registration procedure requires an expert review, > which > |purpose is to ensure that the Info Package does not break the SIP > protocol > |etc. I assume such review will take place when the package is > registered > |with IANA. > | > |Regards, > | > |Christer > | > | > | > | > |________________________________ > | > | From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > | Sent: Wed 8/25/2010 8:45 AM > | To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) > | Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal > |(mperumal) > | Subject: RE: > [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf- > |package-00.txt > | > | > | > | > | Hi, > | > | >In case IMS needs new INFO based DTMF relay mechanism, I agree > that > |it is the valid requirement and we need to evaluate it. Before > concluding > |about new > | >INFO based mechanism in IMS, Please throw the light for not > selecting > |KPML in IMS. I'm comparing KPML vs INFO based mechanism as both are > based on > |SIP > | >signaling based mechanism. KPML has limited deployment as > mentioned > |in Hadriel Info draft but new INFO package is yet to be=20 > defined. It is=20 > |better to have > | >the single active IETF SIP signaling based dtmf-relay=20 > mechanism=20 > |rather than producing more standards wherein implementers will > completely > |confused which > | >one to select. > | > > | >As Muthu mentioned, I also heard about KPML deployment issues > but the > |legacy INFO based dtmf-relay has lot more caveats. I guess that Info > package > |is > | >designed as generic as KPML, and then both KPML and INFO may > look > |heavyweight. > | > | The 3GPP DTMF Info Package is very simple. > | > | Regards, > | > | Christer > | > | > | > | > | ________________________________ > | > | From: dispatch-bounces@ietf.org on behalf of Paul > Kyzivat > |(pkyzivat) > | Sent: Wed 8/25/2010 12:17 AM > | To: Christer Holmberg > | Cc: dispatch@ietf.org; Hadriel Kaplan > | Subject: Re: [dispatch]I-D > Action:draft-kaplan-dispatch-info- > |dtmf-package-00.txt > | > | > | > | > | > | Christer Holmberg wrote: > | > Hi, > | > > | > I think it is strange to reject something based on a > claim > |there already exists a number of legacy ways of there. Not=20 > everyone has=20 > |implemented the same (if any) of them, and the whole purpose of the > Info > |Package framework is to come up with a mechanism for which the usage > can be > |negotiated. > | > > | > And, as I said earlier, at least in IMS an Info > Package is > |being used for DTMF transport. It is currently defined in 3GPP=20 > |specifications, but there shouldn't be anything IMS specific=20 > about the=20 > |package itself. > | > | I wasn't asserting a general principle. > | I was talking about this particular mechanism. > | > | If there is yet another dtmf package, then I guess we > can > |consider the > | pros/cons of it. Those are probably best assessed by > those who > |use the > | existing one and/or might use whatever info package you > might > |propose to > | replace it. > | > | We clearly suffer from a surplus of ways to convey dtmf. > | While its not impossible to argue than another=20 > one would=20 > |improve the > | situation, it is going to be a hard sell. > | > | OTOH, the more there are the more case it makes for > having an > |SBC in the > | path to "fix" the interoperability. We sell them, so > maybe I > |should be > | cheering on every new one as a way to boost sales. > | > | Thanks, > | Paul > | > | > Regards, > | > > | > Christer > | > > | > > | > > | >> -----Original Message----- > | >> From: dispatch-bounces@ietf.org > | >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul=20 > |Kyzivat > | >> Sent: 24. elokuuta 2010 18:51 > | >> To: Hadriel Kaplan > | >> Cc: dispatch@ietf.org > | >> Subject: Re: [dispatch] I-D > | >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt > | >> > | >> Maybe we should ask our ADs if they have an opinion > about > |this. > | >> > | >> Thanks, > | >> Paul > | >> > | >> Hadriel Kaplan wrote: > | >>>> -----Original Message----- > | >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > | >>>> Sent: Monday, August 23, 2010 6:02 PM > | >>>> To: Hadriel Kaplan > | >>>> > | >>>> That reduces things somewhat. But if=20 > everybody that=20 > |supports the > | >>>> package also supports the legacy approach, what is > the > |win? > | >>> The legacy mode has no published standards document > | >> defining it. I thought when the info-packages work > was > | >> started, DTMF-in-info was one of the main drivers. > But I > | >> take your point - if people would prefer to just > document > |it > | >> as it is today (sans info-packages), I can change the > draft > | >> to just be that. I'm cool with either way (defining > the > | >> current dtmf-relay as a legacy mode was Option-2). > | >>> -hadriel > | >>> > | >> _______________________________________________ > | >> dispatch mailing list > | >> dispatch@ietf.org > | >> https://www.ietf.org/mailman/listinfo/dispatch > | >> > | _______________________________________________ > | dispatch mailing list > | dispatch@ietf.org > | https://www.ietf.org/mailman/listinfo/dispatch > | > | > | >=20 > = From partr@cisco.com Tue Aug 24 21:50:39 2010 Return-Path: <partr@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C4F3A6A96 for <dispatch@core3.amsl.com>; Tue, 24 Aug 2010 21:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.239 X-Spam-Level: X-Spam-Status: No, score=-9.239 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQm-LYsowJyP for <dispatch@core3.amsl.com>; Tue, 24 Aug 2010 21:50:36 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 60D293A6A8A for <dispatch@ietf.org>; Tue, 24 Aug 2010 21:50:36 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAFABI+dExAaMHG/2dsb2JhbACBQ54iVHGhPZwNhTcEhDOIMw X-IronPort-AV: E=Sophos;i="4.56,266,1280707200"; d="scan'208,217";a="235412557" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-3.cisco.com with ESMTP; 25 Aug 2010 04:51:08 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7P4oO5J016002; Wed, 25 Aug 2010 04:51:07 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 10:21:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB4411.1F7CADEF" Date: Wed, 25 Aug 2010 10:21:04 +0530 Message-ID: <A11921905DA1564D9BCF64A6430A62390293A4AC@XMB-BGL-411.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDvOLBe1YZhBFsTWqLWKL3I3mobgAQIrjJAAEnJwAAAJN2aQAAQDNAAAJ61h4= References: <430FC6BDED356B4C8498F634416644A92694381B86@mail><1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381C2C@mail><1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381E9F@mail><4C729FEF.6020509@cisco.com><430FC6BDED356B4C8498F634416644A92694381F16@mail><4C72C9CA.3070304@cisco.com><430FC6BDED356B4C8498F634416644A92694381FDF@mail><4C72EFCC.2000107@cisco.com><430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <A11921905DA1564D9BCF64A6430A62390293A4A8@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> <A11921905DA1564D9BCF64A6430A62390293A4A9@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8652@ESESSCMS0356.eemea.ericsson.se> From: "Parthasarathi R (partr)" <partr@cisco.com> To: "Christer Holmberg" <christer.holmberg@ericsson.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com> X-OriginalArrivalTime: 25 Aug 2010 04:51:04.0710 (UTC) FILETIME=[1FB24260:01CB4411] Cc: dispatch@ietf.org, Hadriel Kaplan <HKaplan@acmepacket.com> Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Aug 2010 04:50:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB4411.1F7CADEF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer, =20 I haven't seen reply to my second question: =20 "2) Whether current IETF standard (KPML) has to be deprecated for the = proposed DTMF Info packages. Both KPML, DTMF Info package are SIP = signaling based mechanism for DTMF relay." =20 It is not clear to me why IMS take different stance than current IETF = standard (KPML) for DTMF relay. In case of the analysis has done for not = selecting KPML in IMS, please let us know as it will help us to proceed = in the INFO based DTMF package direction in IETF. =20 Also Currently, IANA registration is yet to be done for DTMF Info = package and so, the modification is possible. =20 Thanks Partha ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wed 8/25/2010 9:04 AM To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal = (mperumal) Subject: RE: = [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Hi, >1) whether 3GPP DTMF Info package is in the state to be accepted as = IETF standards. The Info Package registration procedure requires an expert review, which = purpose is to ensure that the Info Package does not break the SIP = protocol etc. I assume such review will take place when the package is = registered with IANA. Regards, Christer ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wed 8/25/2010 8:45 AM To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal = (mperumal) Subject: RE: = [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt =20 =20 Hi, =20 >In case IMS needs new INFO based DTMF relay mechanism, I agree = that it is the valid requirement and we need to evaluate it. Before = concluding about new >INFO based mechanism in IMS, Please throw the light for not = selecting KPML in IMS. I'm comparing KPML vs INFO based mechanism as = both are based on SIP >signaling based mechanism. KPML has limited deployment as = mentioned in Hadriel Info draft but new INFO package is yet to be = defined. It is better to have >the single active IETF SIP signaling based dtmf-relay mechanism = rather than producing more standards wherein implementers will = completely confused which >one to select. > >As Muthu mentioned, I also heard about KPML deployment issues = but the legacy INFO based dtmf-relay has lot more caveats. I guess that = Info package is >designed as generic as KPML, and then both KPML and INFO may = look heavyweight. =20 The 3GPP DTMF Info Package is very simple. =20 Regards, =20 Christer =20 =20 =20 =20 ________________________________ =20 From: dispatch-bounces@ietf.org on behalf of Paul = Kyzivat (pkyzivat) Sent: Wed 8/25/2010 12:17 AM To: Christer Holmberg Cc: dispatch@ietf.org; Hadriel Kaplan Subject: Re: [dispatch]I-D = Action:draft-kaplan-dispatch-info-dtmf-package-00.txt =20 =20 =20 =20 =20 Christer Holmberg wrote: > Hi, > > I think it is strange to reject something based on a = claim there already exists a number of legacy ways of there. Not = everyone has implemented the same (if any) of them, and the whole = purpose of the Info Package framework is to come up with a mechanism for = which the usage can be negotiated. > > And, as I said earlier, at least in IMS an Info = Package is being used for DTMF transport. It is currently defined in = 3GPP specifications, but there shouldn't be anything IMS specific about = the package itself. =20 I wasn't asserting a general principle. I was talking about this particular mechanism. =20 If there is yet another dtmf package, then I guess we = can consider the pros/cons of it. Those are probably best assessed by = those who use the existing one and/or might use whatever info package you = might propose to replace it. =20 We clearly suffer from a surplus of ways to convey dtmf. While its not impossible to argue than another one would = improve the situation, it is going to be a hard sell. =20 OTOH, the more there are the more case it makes for = having an SBC in the path to "fix" the interoperability. We sell them, so = maybe I should be cheering on every new one as a way to boost sales. =20 Thanks, Paul =20 > Regards, > > Christer > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul = Kyzivat >> Sent: 24. elokuuta 2010 18:51 >> To: Hadriel Kaplan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] I-D >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >> >> Maybe we should ask our ADs if they have an opinion = about this. >> >> Thanks, >> Paul >> >> Hadriel Kaplan wrote: >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, August 23, 2010 6:02 PM >>>> To: Hadriel Kaplan >>>> >>>> That reduces things somewhat. But if everybody that = supports the >>>> package also supports the legacy approach, what is = the win? >>> The legacy mode has no published standards document >> defining it. I thought when the info-packages work = was >> started, DTMF-in-info was one of the main drivers. = But I >> take your point - if people would prefer to just = document it >> as it is today (sans info-packages), I can change the = draft >> to just be that. I'm cool with either way (defining = the >> current dtmf-relay as a legacy mode was Option-2). >>> -hadriel >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 =20 =20 ------_=_NextPart_001_01CB4411.1F7CADEF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML dir=3Dltr><HEAD><TITLE>RE: = [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt</TITLE= >=0A= <META content=3D"text/html; charset=3Dunicode" http-equiv=3DContent-Type>=0A= <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18928"></HEAD>=0A= <BODY>=0A= <DIV dir=3Dltr id=3DidOWAReplyText55242>=0A= <DIV dir=3Dltr><FONT color=3D#000000 size=3D2 face=3DArial>=0A= <P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><SPAN = style=3D"FONT-FAMILY: Arial; COLOR: black; FONT-SIZE: = 10pt">Christer,</SPAN><?xml:namespace prefix =3D o ns =3D = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></P>=0A= <P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><FONT size=3D3><FONT = face=3D"Times New Roman"> <o:p></o:p></FONT></FONT></P>=0A= <P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><SPAN = style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt">I haven't = seen reply to my second question:</SPAN><o:p></o:p></P>=0A= <P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><FONT size=3D3><FONT = face=3D"Times New Roman"> <o:p></o:p></FONT></FONT></P>=0A= <P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><SPAN = style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt">"2) Whether current IETF = standard (KPML) has to be deprecated for the proposed DTMF Info = packages. Both KPML, DTMF Info package are SIP signaling based mechanism = for DTMF relay."</SPAN><o:p></o:p></P>=0A= <P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><FONT size=3D3><FONT = face=3D"Times New Roman"> <o:p></o:p></FONT></FONT></P>=0A= <P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><SPAN = style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt">It is not clear to me why = IMS take different stance than current IETF standard (KPML) for DTMF = relay. In case of the analysis has done for not selecting KPML in IMS, = please let us know as it will help us to proceed in the INFO based DTMF = package direction in IETF.</SPAN></P>=0A= <P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><SPAN = style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt"></SPAN> </P>=0A= <P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><SPAN = style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN = style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt">Also Currently, IANA = registration is yet to be done for DTMF Info package and so, the = modification is possible.</SPAN></SPAN></P>=0A= <P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><FONT size=3D3><FONT = face=3D"Times New Roman"> <o:p></o:p></FONT></FONT></P>=0A= <P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><SPAN = style=3D"FONT-FAMILY: Arial; FONT-SIZE: = 10pt">Thanks</SPAN><o:p></o:p></P>=0A= <P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><SPAN = style=3D"FONT-FAMILY: Arial; FONT-SIZE: = 10pt">Partha</SPAN><o:p></o:p></P></FONT></DIV><FONT size=3D2 = face=3DArial></FONT></DIV>=0A= <DIV dir=3Dltr>=0A= <HR tabIndex=3D-1>=0A= </DIV>=0A= <DIV dir=3Dltr>=0A= <DIV dir=3Dltr><FONT size=3D2 face=3DTahoma><B>From:</B> Christer = Holmberg [mailto:christer.holmberg@ericsson.com]<BR><B>Sent:</B> Wed = 8/25/2010 9:04 AM<BR><B>To:</B> Parthasarathi R (partr); Paul Kyzivat = (pkyzivat)<BR><B>Cc:</B> dispatch@ietf.org; Hadriel Kaplan; Muthu = ArulMozhi Perumal (mperumal)<BR><B>Subject:</B> RE: = [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt<BR></F= ONT><BR></DIV></DIV>=0A= <DIV><BR>=0A= <P><FONT size=3D2>Hi,<BR><BR>>1) whether 3GPP DTMF Info package is in = the state to be accepted as IETF standards.<BR><BR>The Info Package = registration procedure requires an expert review, which purpose is to = ensure that the Info Package does not break the SIP protocol etc. I = assume such review will take place when the package is registered with = IANA.<BR><BR>Regards,<BR><BR>Christer<BR><BR><BR><BR><BR>________________= ________________<BR><BR>        From: = Christer Holmberg [<A = href=3D"mailto:christer.holmberg@ericsson.com">mailto:christer.holmberg@e= ricsson.com</A>]<BR>        Sent: Wed = 8/25/2010 8:45 AM<BR>        To: = Parthasarathi R (partr); Paul Kyzivat = (pkyzivat)<BR>        Cc: = dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal = (mperumal)<BR>        Subject: RE: = [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt<BR>&nb= sp;      <BR>     =   <BR><BR><BR>        = Hi,<BR>        =        <BR>    &nb= sp;   >In case IMS needs new INFO based DTMF relay = mechanism, I agree that it is the valid requirement and we need to = evaluate it. Before concluding about = new<BR>        >INFO based = mechanism in IMS, Please throw the light for not selecting KPML in IMS. = I'm comparing KPML vs INFO based mechanism as both are based on = SIP<BR>        >signaling based = mechanism. KPML has limited deployment as mentioned in Hadriel Info = draft but new INFO package is yet to be defined. It is better to = have<BR>        >the single active = IETF SIP signaling based dtmf-relay mechanism rather than producing more = standards wherein implementers will completely confused = which<BR>        >one to = select.<BR>        = ><BR>        >As Muthu = mentioned, I also heard about KPML deployment issues but the legacy INFO = based dtmf-relay has lot more caveats. I guess that Info package = is<BR>        >designed as generic = as KPML, and then both KPML and INFO may look = heavyweight.<BR>       <BR>  = ;      The 3GPP DTMF Info Package is very = simple.<BR>       <BR>  &nbs= p;     = Regards,<BR>       <BR>  &nb= sp;     = Christer<BR>       <BR>  &nb= sp;    <BR>       = <BR>        =       <BR>     &nb= sp;  = ________________________________<BR>      &= nbsp;<BR>        =         From: = dispatch-bounces@ietf.org on behalf of Paul Kyzivat = (pkyzivat)<BR>        =         Sent: Wed 8/25/2010 12:17 = AM<BR>        =         To: Christer = Holmberg<BR>        =         Cc: dispatch@ietf.org; = Hadriel Kaplan<BR>        =         Subject: Re: [dispatch]I-D = Action:draft-kaplan-dispatch-info-dtmf-package-00.txt<BR>  &nbs= p;     =       <BR>     &nb= sp;  =       <BR>     &nb= sp; <BR>       <BR>  &n= bsp;    <BR>       = ;         Christer Holmberg = wrote:<BR>        =         > = Hi,<BR>        =         = ><BR>        =         > I think it is strange to = reject something based on a claim there already exists a number of = legacy ways of there. Not everyone has implemented the same (if any) of = them, and the whole purpose of the Info Package framework is to come up = with a mechanism for which the usage can be = negotiated.<BR>        =         = ><BR>        =         > And, as I said earlier, = at least in IMS an Info Package is being used for DTMF transport. It is = currently defined in 3GPP specifications, but there shouldn't be = anything IMS specific about the package = itself.<BR>        =       <BR>     &nb= sp;          I wasn't asserting = a general principle.<BR>        =         I was talking about this = particular mechanism.<BR>        =       <BR>     &nb= sp;          If there is yet = another dtmf package, then I guess we can consider = the<BR>        =         pros/cons of it. Those are = probably best assessed by those who use = the<BR>        =         existing one and/or might use = whatever info package you might propose = to<BR>        =         replace = it.<BR>        =       <BR>     &nb= sp;          We clearly suffer = from a surplus of ways to convey = dtmf.<BR>        =         While its not impossible to = argue than another one would improve = the<BR>        =         situation, it is going to be = a hard sell.<BR>        =       <BR>     &nb= sp;          OTOH, the more = there are the more case it makes for having an SBC in = the<BR>        =         path to "fix" the = interoperability. We sell them, so maybe I should = be<BR>        =         cheering on every new one as = a way to boost sales.<BR>        =       <BR>     &nb= sp;  =             &= nbsp;   Thanks,<BR>        =             &= nbsp;   Paul<BR>        =       <BR>     &nb= sp;          > = Regards,<BR>        =         = ><BR>        =         > = Christer<BR>        =         = ><BR>        =         = ><BR>        =         = ><BR>        =         >> -----Original = Message-----<BR>        =         >> From: = dispatch-bounces@ietf.org<BR>        =         >> [<A = href=3D"mailto:dispatch-bounces@ietf.org">mailto:dispatch-bounces@ietf.or= g</A>] On Behalf Of Paul = Kyzivat<BR>        =         >> Sent: 24. elokuuta = 2010 18:51<BR>        =         >> To: Hadriel = Kaplan<BR>        =         >> Cc: = dispatch@ietf.org<BR>        =         >> Subject: Re: = [dispatch] I-D<BR>        =         >> = Action:draft-kaplan-dispatch-info-dtmf-package-00.txt<BR>  &nbs= p;             = >><BR>        =         >> Maybe we should ask = our ADs if they have an opinion about = this.<BR>        =         = >><BR>        =         = >>      = Thanks,<BR>        =         = >>      = Paul<BR>        =         = >><BR>        =         >> Hadriel Kaplan = wrote:<BR>        =         >>>> = -----Original Message-----<BR>        =         >>>> From: Paul = Kyzivat [<A = href=3D"mailto:pkyzivat@cisco.com">mailto:pkyzivat@cisco.com</A>]<BR>&nbs= p;       =         >>>> Sent: = Monday, August 23, 2010 6:02 = PM<BR>        =         >>>> To: Hadriel = Kaplan<BR>        =         = >>>><BR>        =         >>>> That reduces = things somewhat. But if everybody that supports = the<BR>        =         >>>> package also = supports the legacy approach, what is the = win?<BR>        =         >>> The legacy mode = has no published standards = document<BR>        =         >> defining it.  I = thought when the info-packages work = was<BR>        =         >> started, = DTMF-in-info was one of the main drivers.  But = I<BR>        =         >> take your point - if = people would prefer to just document = it<BR>        =         >> as it is today (sans = info-packages), I can change the = draft<BR>        =         >> to just be = that.  I'm cool with either way (defining = the<BR>        =         >> current dtmf-relay = as a legacy mode was = Option-2).<BR>        =         >>> = -hadriel<BR>        =         = >>><BR>        =         >> = _______________________________________________<BR>   &nbs= p;            >> = dispatch mailing list<BR>        =         >> = dispatch@ietf.org<BR>        =         >> <A = href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.= org/mailman/listinfo/dispatch</A><BR>      =           = >><BR>        =         = _______________________________________________<BR>   &nbs= p;            dispatch = mailing list<BR>        =         = dispatch@ietf.org<BR>        =         <A = href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.= org/mailman/listinfo/dispatch</A><BR>      =   =       <BR>     &nb= sp; <BR>       <BR><BR></FONT></P= ></DIV></BODY></HTML> ------_=_NextPart_001_01CB4411.1F7CADEF-- From christer.holmberg@ericsson.com Tue Aug 24 23:04:58 2010 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719363A68AD for <dispatch@core3.amsl.com>; Tue, 24 Aug 2010 23:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.355 X-Spam-Level: X-Spam-Status: No, score=-5.355 tagged_above=-999 required=5 tests=[AWL=1.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muQyN7iFquiC for <dispatch@core3.amsl.com>; Tue, 24 Aug 2010 23:04:52 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 1AFBE3A6805 for <dispatch@ietf.org>; Tue, 24 Aug 2010 23:04:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-f4-4c74b2a182f6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CA.C9.10125.1A2B47C4; Wed, 25 Aug 2010 08:05:22 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.104]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 25 Aug 2010 08:05:21 +0200 From: Christer Holmberg <christer.holmberg@ericsson.com> To: "Parthasarathi R (partr)" <partr@cisco.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com> Date: Wed, 25 Aug 2010 08:05:14 +0200 Thread-Topic: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDvOLBe1YZhBFsTWqLWKL3I3mobgAQIrjJAAEnJwAAAJN2aQAAQDNAAAJ61h4AAoqxIA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851B8690@ESESSCMS0356.eemea.ericsson.se> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail><1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381C2C@mail><1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381E9F@mail><4C729FEF.6020509@cisco.com><430FC6BDED356B4C8498F634416644A92694381F16@mail><4C72C9CA.3070304@cisco.com><430FC6BDED356B4C8498F634416644A92694381FDF@mail><4C72EFCC.2000107@cisco.com><430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <A11921905DA1564D9BCF64A6430A62390293A4A8@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> <A11921905DA1564D9BCF64A6430A62390293A4A9@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8652@ESESSCMS0356.eemea.ericsson.se> <A11921905DA1564D9BCF64A6430A62390293A4AC@XMB-BGL-411.cisco.com> In-Reply-To: <A11921905DA1564D9BCF64A6430A62390293A4AC@XMB-BGL-411.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: AAAAAA== Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Hadriel Kaplan <HKaplan@acmepacket.com> Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Aug 2010 06:04:59 -0000 Hi, >I haven't seen reply to my second question: > >"2) Whether current IETF standard (KPML) has to be deprecated for the prop= osed DTMF Info packages. Both KPML, DTMF Info package are SIP signaling bas= ed=20 >mechanism for DTMF relay." Personally I have no opinion on that. In my understanding the scope of KPML is wider than DTMF transport, so some= one may want to use it for something else. I have never seen any usage of, = or received a requirement to support, KPML, but that of course doesn't guar= antee that there aren't deployments out there. >It is not clear to me why IMS take different stance than current IETF stan= dard (KPML) for DTMF relay. In case of the analysis has done for not select= ing=20 >KPML in IMS, please let us know as it will help us to proceed in the INFO = based DTMF package direction in IETF. KPML vs INFO has been discussed many times, before we even started the work= on Info Packages. One issue people have is that it requires subscriptions,= and separate subscription dialogs (based on the dialog usage recommendatio= ns), which have resource impacts at least on stateful entities. >Also Currently, IANA registration is yet to be done for DTMF Info package = and so, the modification is possible. Sure. Any 3GPP member can bring change proposals. And, if we decide to specify a DTMF Info Package of our own (e.g. based on = Hadriel's proposal), any 3GPP member can, once it's down, propose to adopt = it for IMS. Regards, Christer ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wed 8/25/2010 9:04 AM To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal (mperumal) Subject: RE: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-0= 0.txt =09 =09 Hi, =09 >1) whether 3GPP DTMF Info package is in the state to be accepted as IETF = standards. =09 The Info Package registration procedure requires an expert review, which p= urpose is to ensure that the Info Package does not break the SIP protocol e= tc. I assume such review will take place when the package is registered wit= h IANA. =09 Regards, =09 Christer =09 =09 =09 =09 ________________________________ =09 From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wed 8/25/2010 8:45 AM To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal (mp= erumal) Subject: RE: [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-p= ackage-00.txt =20 =20 =09 =09 Hi, =20 >In case IMS needs new INFO based DTMF relay mechanism, I agree th= at it is the valid requirement and we need to evaluate it. Before concludin= g about new >INFO based mechanism in IMS, Please throw the light for not selec= ting KPML in IMS. I'm comparing KPML vs INFO based mechanism as both are ba= sed on SIP >signaling based mechanism. KPML has limited deployment as mention= ed in Hadriel Info draft but new INFO package is yet to be defined. It is b= etter to have >the single active IETF SIP signaling based dtmf-relay mechanism r= ather than producing more standards wherein implementers will completely co= nfused which >one to select. > >As Muthu mentioned, I also heard about KPML deployment issues but= the legacy INFO based dtmf-relay has lot more caveats. I guess that Info p= ackage is >designed as generic as KPML, and then both KPML and INFO may look= heavyweight. =20 The 3GPP DTMF Info Package is very simple. =20 Regards, =20 Christer =20 =20 =20 =20 ________________________________ =20 From: dispatch-bounces@ietf.org on behalf of Paul Kyzivat = (pkyzivat) Sent: Wed 8/25/2010 12:17 AM To: Christer Holmberg Cc: dispatch@ietf.org; Hadriel Kaplan Subject: Re: [dispatch]I-D Action:draft-kaplan-dispatch-in= fo-dtmf-package-00.txt =20 =20 =20 =20 =20 Christer Holmberg wrote: > Hi, > > I think it is strange to reject something based on a cla= im there already exists a number of legacy ways of there. Not everyone has = implemented the same (if any) of them, and the whole purpose of the Info Pa= ckage framework is to come up with a mechanism for which the usage can be n= egotiated. > > And, as I said earlier, at least in IMS an Info Package = is being used for DTMF transport. It is currently defined in 3GPP specifica= tions, but there shouldn't be anything IMS specific about the package itsel= f. =20 I wasn't asserting a general principle. I was talking about this particular mechanism. =20 If there is yet another dtmf package, then I guess we can = consider the pros/cons of it. Those are probably best assessed by those= who use the existing one and/or might use whatever info package you mi= ght propose to replace it. =20 We clearly suffer from a surplus of ways to convey dtmf. While its not impossible to argue than another one would i= mprove the situation, it is going to be a hard sell. =20 OTOH, the more there are the more case it makes for having= an SBC in the path to "fix" the interoperability. We sell them, so maybe= I should be cheering on every new one as a way to boost sales. =20 Thanks, Paul =20 > Regards, > > Christer > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Ky= zivat >> Sent: 24. elokuuta 2010 18:51 >> To: Hadriel Kaplan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] I-D >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >> >> Maybe we should ask our ADs if they have an opinion abo= ut this. >> >> Thanks, >> Paul >> >> Hadriel Kaplan wrote: >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, August 23, 2010 6:02 PM >>>> To: Hadriel Kaplan >>>> >>>> That reduces things somewhat. But if everybody that s= upports the >>>> package also supports the legacy approach, what is th= e win? >>> The legacy mode has no published standards document >> defining it. I thought when the info-packages work was >> started, DTMF-in-info was one of the main drivers. But= I >> take your point - if people would prefer to just docume= nt it >> as it is today (sans info-packages), I can change the d= raft >> to just be that. I'm cool with either way (defining th= e >> current dtmf-relay as a legacy mode was Option-2). >>> -hadriel >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 =20 =20 =09 =09 From john.elwell@siemens-enterprise.com Wed Aug 25 02:17:01 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118BF3A696E for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 02:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.741 X-Spam-Level: X-Spam-Status: No, score=-102.741 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEEbGvOXIP6B for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 02:16:59 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 958233A6AA5 for <dispatch@ietf.org>; Wed, 25 Aug 2010 02:16:57 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1276969; Wed, 25 Aug 2010 11:17:27 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 798C623F0278; Wed, 25 Aug 2010 11:17:27 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 25 Aug 2010 11:17:27 +0200 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Christer Holmberg <christer.holmberg@ericsson.com>, "Parthasarathi R (partr)" <partr@cisco.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com> Date: Wed, 25 Aug 2010 11:17:26 +0200 Thread-Topic: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDvOLBe1YZhBFsTWqLWKL3I3mobgAQIrjJAAEnJwAAAJN2aQAAQDNAAAJ61h4AAoqxIAAG5T/Q Message-ID: <A444A0F8084434499206E78C106220CA01C482BBD5@MCHP058A.global-ad.net> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail><1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381C2C@mail><1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381E9F@mail><4C729FEF.6020509@cisco.com><430FC6BDED356B4C8498F634416644A92694381F16@mail><4C72C9CA.3070304@cisco.com><430FC6BDED356B4C8498F634416644A92694381FDF@mail><4C72EFCC.2000107@cisco.com><430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <A11921905DA1564D9BCF64A6430A62390293A4A8@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> <A11921905DA1564D9BCF64A6430A62390293A4A9@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8652@ESESSCMS0356.eemea.ericsson.se> <A11921905DA1564D9BCF64A6430A62390293A4AC@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8690@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851B8690@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: "dispatch@ietf.org" <dispatch@ietf.org>, Hadriel Kaplan <HKaplan@acmepacket.com> Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Aug 2010 09:17:01 -0000 We had a lot of discussion on KPML versus INFO prior to commencing the info= -events work, and I think one of the issues was that KPML is fine if the re= cipient of information is off the path of the SIP dialog for the session co= ncerned, but was not optimised for use cases where an entity on the path ne= eds to receive the information. At the time there seemed to be a consensus = that DTMF would be a very likely candidate for an INFO package, should the = info-events work proceed. In fact, I don't recall many other candidates, so= DTMF seemed to be a prime driver for the info-events work. However, I don'= t think it was seen as a total replacement for KPML. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 25 August 2010 07:05 > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) > Cc: dispatch@ietf.org; Hadriel Kaplan > Subject: Re: [dispatch]=20 > I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt >=20 >=20 > Hi, >=20 > >I haven't seen reply to my second question: > > > >"2) Whether current IETF standard (KPML) has to be=20 > deprecated for the proposed DTMF Info packages. Both KPML,=20 > DTMF Info package are SIP signaling based=20 > >mechanism for DTMF relay." >=20 > Personally I have no opinion on that. >=20 > In my understanding the scope of KPML is wider than DTMF=20 > transport, so someone may want to use it for something else.=20 > I have never seen any usage of, or received a requirement to=20 > support, KPML, but that of course doesn't guarantee that=20 > there aren't deployments out there. >=20 > >It is not clear to me why IMS take different stance than=20 > current IETF standard (KPML) for DTMF relay. In case of the=20 > analysis has done for not selecting=20 > >KPML in IMS, please let us know as it will help us to=20 > proceed in the INFO based DTMF package direction in IETF. >=20 > KPML vs INFO has been discussed many times, before we even=20 > started the work on Info Packages. One issue people have is=20 > that it requires subscriptions, and separate subscription=20 > dialogs (based on the dialog usage recommendations), which=20 > have resource impacts at least on stateful entities. >=20 > >Also Currently, IANA registration is yet to be done for DTMF=20 > Info package and so, the modification is possible. >=20 > Sure. Any 3GPP member can bring change proposals. >=20 > And, if we decide to specify a DTMF Info Package of our own=20 > (e.g. based on Hadriel's proposal), any 3GPP member can, once=20 > it's down, propose to adopt it for IMS. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > ________________________________ >=20 > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wed 8/25/2010 9:04 AM > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) > Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi=20 > Perumal (mperumal) > Subject: RE:=20 > [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt > =09 > =09 >=20 >=20 > Hi, > =09 > >1) whether 3GPP DTMF Info package is in the state to=20 > be accepted as IETF standards. > =09 > The Info Package registration procedure requires an=20 > expert review, which purpose is to ensure that the Info=20 > Package does not break the SIP protocol etc. I assume such=20 > review will take place when the package is registered with IANA. > =09 > Regards, > =09 > Christer > =09 > =09 > =09 > =09 > ________________________________ > =09 > From: Christer Holmberg=20 > [mailto:christer.holmberg@ericsson.com] > Sent: Wed 8/25/2010 8:45 AM > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) > Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu=20 > ArulMozhi Perumal (mperumal) > Subject: RE:=20 > [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt > =20 > =20 > =09 > =09 > Hi, > =20 > >In case IMS needs new INFO based DTMF relay=20 > mechanism, I agree that it is the valid requirement and we=20 > need to evaluate it. Before concluding about new > >INFO based mechanism in IMS, Please throw the=20 > light for not selecting KPML in IMS. I'm comparing KPML vs=20 > INFO based mechanism as both are based on SIP > >signaling based mechanism. KPML has limited=20 > deployment as mentioned in Hadriel Info draft but new INFO=20 > package is yet to be defined. It is better to have > >the single active IETF SIP signaling based=20 > dtmf-relay mechanism rather than producing more standards=20 > wherein implementers will completely confused which > >one to select. > > > >As Muthu mentioned, I also heard about KPML=20 > deployment issues but the legacy INFO based dtmf-relay has=20 > lot more caveats. I guess that Info package is > >designed as generic as KPML, and then both=20 > KPML and INFO may look heavyweight. > =20 > The 3GPP DTMF Info Package is very simple. > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > =20 > ________________________________ > =20 > From: dispatch-bounces@ietf.org on=20 > behalf of Paul Kyzivat (pkyzivat) > Sent: Wed 8/25/2010 12:17 AM > To: Christer Holmberg > Cc: dispatch@ietf.org; Hadriel Kaplan > Subject: Re: [dispatch]I-D=20 > Action:draft-kaplan-dispatch-info-dtmf-package-00.txt > =20 > =20 > =20 > =20 > =20 > Christer Holmberg wrote: > > Hi, > > > > I think it is strange to reject=20 > something based on a claim there already exists a number of=20 > legacy ways of there. Not everyone has implemented the same=20 > (if any) of them, and the whole purpose of the Info Package=20 > framework is to come up with a mechanism for which the usage=20 > can be negotiated. > > > > And, as I said earlier, at least in=20 > IMS an Info Package is being used for DTMF transport. It is=20 > currently defined in 3GPP specifications, but there shouldn't=20 > be anything IMS specific about the package itself. > =20 > I wasn't asserting a general principle. > I was talking about this particular mechanism. > =20 > If there is yet another dtmf package,=20 > then I guess we can consider the > pros/cons of it. Those are probably=20 > best assessed by those who use the > existing one and/or might use whatever=20 > info package you might propose to > replace it. > =20 > We clearly suffer from a surplus of=20 > ways to convey dtmf. > While its not impossible to argue than=20 > another one would improve the > situation, it is going to be a hard sell. > =20 > OTOH, the more there are the more case=20 > it makes for having an SBC in the > path to "fix" the interoperability. We=20 > sell them, so maybe I should be > cheering on every new one as a way to=20 > boost sales. > =20 > Thanks, > Paul > =20 > > Regards, > > > > Christer > > > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org]=20 > On Behalf Of Paul Kyzivat > >> Sent: 24. elokuuta 2010 18:51 > >> To: Hadriel Kaplan > >> Cc: dispatch@ietf.org > >> Subject: Re: [dispatch] I-D > >>=20 > Action:draft-kaplan-dispatch-info-dtmf-package-00.txt > >> > >> Maybe we should ask our ADs if they=20 > have an opinion about this. > >> > >> Thanks, > >> Paul > >> > >> Hadriel Kaplan wrote: > >>>> -----Original Message----- > >>>> From: Paul Kyzivat=20 > [mailto:pkyzivat@cisco.com] > >>>> Sent: Monday, August 23, 2010 6:02 PM > >>>> To: Hadriel Kaplan > >>>> > >>>> That reduces things somewhat. But=20 > if everybody that supports the > >>>> package also supports the legacy=20 > approach, what is the win? > >>> The legacy mode has no published=20 > standards document > >> defining it. I thought when the=20 > info-packages work was > >> started, DTMF-in-info was one of the=20 > main drivers. But I > >> take your point - if people would=20 > prefer to just document it > >> as it is today (sans info-packages),=20 > I can change the draft > >> to just be that. I'm cool with=20 > either way (defining the > >> current dtmf-relay as a legacy mode=20 > was Option-2). > >>> -hadriel > >>> > >>=20 > _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >>=20 > https://www.ietf.org/mailman/listinfo/dispatch > >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > =20 > =20 > =20 > =09 > =09 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From pkyzivat@cisco.com Wed Aug 25 05:43:35 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7B53A6824 for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 05:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.496 X-Spam-Level: X-Spam-Status: No, score=-110.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5X68pNsscmhG for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 05:43:34 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9A9983A6AE6 for <dispatch@ietf.org>; Wed, 25 Aug 2010 05:43:33 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,268,1280707200"; d="scan'208";a="151706505" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 25 Aug 2010 12:44:05 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o7PCi5GC009472; Wed, 25 Aug 2010 12:44:05 GMT Message-ID: <4C751014.7020606@cisco.com> Date: Wed, 25 Aug 2010 08:44:04 -0400 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg <christer.holmberg@ericsson.com> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <A11921905DA1564D9BCF64A6430A62390293A4A8@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Hadriel Kaplan <HKaplan@acmepacket.com> Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Aug 2010 12:43:35 -0000 Can you share the details? Is it a clone of some other deployed mechanism? What Content-Type does it use? Thanks, Paul Christer Holmberg wrote: > Hi, > >> In case IMS needs new INFO based DTMF relay mechanism, I agree that it is the valid requirement and we need to evaluate it. Before concluding about new >> INFO based mechanism in IMS, Please throw the light for not selecting KPML in IMS. I'm comparing KPML vs INFO based mechanism as both are based on SIP >> signaling based mechanism. KPML has limited deployment as mentioned in Hadriel Info draft but new INFO package is yet to be defined. It is better to have >> the single active IETF SIP signaling based dtmf-relay mechanism rather than producing more standards wherein implementers will completely confused which >> one to select. >> >> As Muthu mentioned, I also heard about KPML deployment issues but the legacy INFO based dtmf-relay has lot more caveats. I guess that Info package is >> designed as generic as KPML, and then both KPML and INFO may look heavyweight. > > The 3GPP DTMF Info Package is very simple. > > Regards, > > Christer > > > > > ________________________________ > > From: dispatch-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) > Sent: Wed 8/25/2010 12:17 AM > To: Christer Holmberg > Cc: dispatch@ietf.org; Hadriel Kaplan > Subject: Re: [dispatch]I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt > > > > > > Christer Holmberg wrote: > > Hi, > > > > I think it is strange to reject something based on a claim there already exists a number of legacy ways of there. Not everyone has implemented the same (if any) of them, and the whole purpose of the Info Package framework is to come up with a mechanism for which the usage can be negotiated. > > > > And, as I said earlier, at least in IMS an Info Package is being used for DTMF transport. It is currently defined in 3GPP specifications, but there shouldn't be anything IMS specific about the package itself. > > I wasn't asserting a general principle. > I was talking about this particular mechanism. > > If there is yet another dtmf package, then I guess we can consider the > pros/cons of it. Those are probably best assessed by those who use the > existing one and/or might use whatever info package you might propose to > replace it. > > We clearly suffer from a surplus of ways to convey dtmf. > While its not impossible to argue than another one would improve the > situation, it is going to be a hard sell. > > OTOH, the more there are the more case it makes for having an SBC in the > path to "fix" the interoperability. We sell them, so maybe I should be > cheering on every new one as a way to boost sales. > > Thanks, > Paul > > > Regards, > > > > Christer > > > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 24. elokuuta 2010 18:51 > >> To: Hadriel Kaplan > >> Cc: dispatch@ietf.org > >> Subject: Re: [dispatch] I-D > >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt > >> > >> Maybe we should ask our ADs if they have an opinion about this. > >> > >> Thanks, > >> Paul > >> > >> Hadriel Kaplan wrote: > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Monday, August 23, 2010 6:02 PM > >>>> To: Hadriel Kaplan > >>>> > >>>> That reduces things somewhat. But if everybody that supports the > >>>> package also supports the legacy approach, what is the win? > >>> The legacy mode has no published standards document > >> defining it. I thought when the info-packages work was > >> started, DTMF-in-info was one of the main drivers. But I > >> take your point - if people would prefer to just document it > >> as it is today (sans info-packages), I can change the draft > >> to just be that. I'm cool with either way (defining the > >> current dtmf-relay as a legacy mode was Option-2). > >>> -hadriel > >>> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > From pkyzivat@cisco.com Wed Aug 25 06:08:06 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70E13A683C for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 06:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.497 X-Spam-Level: X-Spam-Status: No, score=-110.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5fg09SyWf6N for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 06:08:03 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2AD713A6AE4 for <dispatch@ietf.org>; Wed, 25 Aug 2010 06:08:00 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABeydExAZnwM/2dsb2JhbACgRHGfG5wKhTcEigM X-IronPort-AV: E=Sophos;i="4.56,268,1280707200"; d="scan'208";a="151718359" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Aug 2010 13:08:33 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7PD8Xg6008127; Wed, 25 Aug 2010 13:08:33 GMT Message-ID: <4C7515D1.80003@cisco.com> Date: Wed, 25 Aug 2010 09:08:33 -0400 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg <christer.holmberg@ericsson.com> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <A11921905DA1564D9BCF64A6430A62390293A4A8@XMB-BGL-411.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> <4C751014.7020606@cisco.com> In-Reply-To: <4C751014.7020606@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Hadriel Kaplan <HKaplan@acmepacket.com> Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Aug 2010 13:08:07 -0000 never mind. I found the references in later mails. Paul Kyzivat wrote: > Can you share the details? Is it a clone of some other deployed > mechanism? What Content-Type does it use? > > Thanks, > Paul > > Christer Holmberg wrote: >> Hi, >>> In case IMS needs new INFO based DTMF relay mechanism, I agree that >>> it is the valid requirement and we need to evaluate it. Before >>> concluding about new >>> INFO based mechanism in IMS, Please throw the light for not selecting >>> KPML in IMS. I'm comparing KPML vs INFO based mechanism as both are >>> based on SIP signaling based mechanism. KPML has limited deployment >>> as mentioned in Hadriel Info draft but new INFO package is yet to be >>> defined. It is better to have the single active IETF SIP signaling >>> based dtmf-relay mechanism rather than producing more standards >>> wherein implementers will completely confused which one to select. >>> As Muthu mentioned, I also heard about KPML deployment issues but the >>> legacy INFO based dtmf-relay has lot more caveats. I guess that Info >>> package is designed as generic as KPML, and then both KPML and INFO >>> may look heavyweight. >> >> The 3GPP DTMF Info Package is very simple. >> >> Regards, >> >> Christer >> >> >> >> >> ________________________________ >> >> From: dispatch-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) >> Sent: Wed 8/25/2010 12:17 AM >> To: Christer Holmberg >> Cc: dispatch@ietf.org; Hadriel Kaplan >> Subject: Re: [dispatch]I-D >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >> >> >> >> >> >> Christer Holmberg wrote: >> > Hi, >> > >> > I think it is strange to reject something based on a claim there >> already exists a number of legacy ways of there. Not everyone has >> implemented the same (if any) of them, and the whole purpose of the >> Info Package framework is to come up with a mechanism for which the >> usage can be negotiated. >> > >> > And, as I said earlier, at least in IMS an Info Package is being >> used for DTMF transport. It is currently defined in 3GPP >> specifications, but there shouldn't be anything IMS specific about the >> package itself. >> >> I wasn't asserting a general principle. >> I was talking about this particular mechanism. >> >> If there is yet another dtmf package, then I guess we can consider >> the >> pros/cons of it. Those are probably best assessed by those who use >> the >> existing one and/or might use whatever info package you might >> propose to >> replace it. >> >> We clearly suffer from a surplus of ways to convey dtmf. >> While its not impossible to argue than another one would improve the >> situation, it is going to be a hard sell. >> >> OTOH, the more there are the more case it makes for having an SBC >> in the >> path to "fix" the interoperability. We sell them, so maybe I >> should be >> cheering on every new one as a way to boost sales. >> >> Thanks, >> Paul >> >> > Regards, >> > >> > Christer >> > >> > > >> >> -----Original Message----- >> >> From: dispatch-bounces@ietf.org >> >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> >> Sent: 24. elokuuta 2010 18:51 >> >> To: Hadriel Kaplan >> >> Cc: dispatch@ietf.org >> >> Subject: Re: [dispatch] I-D >> >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >> >> >> >> Maybe we should ask our ADs if they have an opinion about this. >> >> >> >> Thanks, >> >> Paul >> >> >> >> Hadriel Kaplan wrote: >> >>>> -----Original Message----- >> >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >>>> Sent: Monday, August 23, 2010 6:02 PM >> >>>> To: Hadriel Kaplan >> >>>> >> >>>> That reduces things somewhat. But if everybody that supports the >> >>>> package also supports the legacy approach, what is the win? >> >>> The legacy mode has no published standards document >> >> defining it. I thought when the info-packages work was >> >> started, DTMF-in-info was one of the main drivers. But I >> >> take your point - if people would prefer to just document it >> >> as it is today (sans info-packages), I can change the draft >> >> to just be that. I'm cool with either way (defining the >> >> current dtmf-relay as a legacy mode was Option-2). >> >>> -hadriel >> >>> >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From allyn@cisco.com Wed Aug 25 15:08:17 2010 Return-Path: <allyn@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3503A63C9 for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 15:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ1A95OJR4oH for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 15:08:06 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8820E3A68B8 for <dispatch@ietf.org>; Wed, 25 Aug 2010 15:08:06 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAOIwdUyrR7Hu/2dsb2JhbACBQ55+caFDm3eFNwSEOog8 X-IronPort-AV: E=Sophos;i="4.56,270,1280707200"; d="scan'208,217";a="355352389" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 25 Aug 2010 22:08:39 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7PM8dt4023684; Wed, 25 Aug 2010 22:08:39 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 15:08:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB44A2.11DB42D8" x-cr-hashedpuzzle: BAmT Dnit GYds GlWd HeL5 IZak KqVA LVWJ MQmd NQFg PFYo QopG TV7P V1hI WS19 Wu5A; 2; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnADsAbQBhAHIAeQAuAGkAZQB0AGYALgBiAGEAcgBuAGUAcwBAAGcAbQBhAGkAbAAuAGMAbwBtAA==; Sosha1_v1; 7; {022E3E44-4CF3-4971-8810-B490F8B1FEE3}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 25 Aug 2010 22:08:31 GMT; VABlAGwAZQBwAHIAZQBzAGUAbgBjAGUAIABDAGgAYQByAHQAZQByACAAVgBlAHIAcwBpAG8AbgAgADMA x-cr-puzzleid: {022E3E44-4CF3-4971-8810-B490F8B1FEE3} Content-class: urn:content-classes:message Date: Wed, 25 Aug 2010 15:08:31 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Telepresence Charter Version 3 Thread-Index: ActEog2/Y4ucp0iGQOGgIL9SQKxcmA== From: "Allyn Romanow (allyn)" <allyn@cisco.com> To: "DISPATCH list" <dispatch@ietf.org> X-OriginalArrivalTime: 25 Aug 2010 22:08:39.0147 (UTC) FILETIME=[123B7BB0:01CB44A2] Subject: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Aug 2010 22:08:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB44A2.11DB42D8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, here is the 3rd version of the charter. =20 * It incorporates a number of useful editing comments. * The substantive issue on this draft concerned what was meant by=20 "Also not in scope is signaling to tell the originator to which receivers the media streams should be sent." =20 After further discussion with Peter and Steve, the main discussants on this, I've added to the list of what is included =20 *Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). =20 We interpreted the out of scope sentence to mean "Also not in scope is signaling to tell the originator to which IP addresses the media streams should be sent." =20 While this seemed okay, it was felt to be unnecessary. So it was left out of this version. =20 Thus we think we have "in" what counts - that the receiver might need to say which of several RTP streams it wants to receive. And if someone has something they want to exclude could they please try again to describe it? =20 OH- and for a name. How about CLUE?=20 =20 Comments? =20 Allyn =20 =20 Charter CLUE ControLling mUltiple streams for TElepresence or MUSCAT: MUlti-Stream Control Applied to Telepresence =20 =20 In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders,microphones and loudspeakers. =20 Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor in the inability of telepresence systems to interwork is that there is no standardized way to describe and negotiate the use of the multiple streams of audio and video that comprise the media flows. In addition, there is no standardized way to exchange semantic information about what each media stream represents. =20 =20 The WG will create specifications to enable communication of enough information about each media stream so that each receiving system or bridge system can make reasonable decisions about selecting and rendering media streams. This enables systems to make display choices that optimize the "just like being there" experience.=20 =20 This working group is chartered to specify the information about media streams from one endpoint to another endpoint or conference bridge including: =20 * Spatial relationships of cameras, displays, microphones, and speakers in relation to each other and to likely positions of participants =20 * Specific characteristics such as viewpoint, field of view/capture for camera/microphone/display/speaker so that senders and middleboxes can understand how best to compose streams for receivers and the receivers will know the characteristics of its=20 received streams =20 * Aspect ratio of cameras and displays =20 * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). =20 =20 Information between sources and sinks about media stream capabilities will be exchanged.=20 =20 The working group will define the semantics, syntax, and transport mechanism necessary for communicating the necessary information. It will consider whether the existing signaling mechanisms (e. g., SDP, BFCP) can be extended, or another messaging method should be used. =20 =20 The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and video streams for the current speaker. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. =20 =20 The focus of this work is on multiple audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. =20 Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. =20 This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster.=20 =20 Re-use of existing protocols and backwards compatibility with existing systems is an important factor for the working group to consider. The work will closely coordinate with the appropriate areas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. =20 Milestones =20 =20 Nov 2010 Submit information draft to IESG on use cases and requirements =20 Nov 2011 Submit standards track specification to IESG on indicating spatial relationships of screens, cameras (including variable field of view and orientation), speakers and microphones. This includes, semantics, language and transport. =20 Apr 2011 Submit standards track specification to IESG on indicating the "usage" of a stream as define in charter. =20 =20 =20 =20 =20 ------_=_NextPart_001_01CB44A2.11DB42D8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0in; margin-bottom:.0001pt; font-size:10.5pt; font-family:Consolas;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:Consolas;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:298077662; mso-list-type:hybrid; mso-list-template-ids:-1585140378 67698689 67698691 67698693 67698689 = 67698691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Symbol;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DWordSection1> <p class=3DMsoNormal>Folks, here is the 3<sup>rd</sup> version of the = charter.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo1'><![if !supportLists]><span style=3D'font-family:Symbol'><span = style=3D'mso-list:Ignore'>·<span style=3D'font:7.0pt "Times New = Roman"'>         </span></span></span><![endif]>It incorporates a number of useful = editing comments.<o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo1'><![if !supportLists]><span style=3D'font-family:Symbol'><span = style=3D'mso-list:Ignore'>·<span style=3D'font:7.0pt "Times New = Roman"'>         </span></span></span><![endif]>The substantive issue on this draft = concerned what was meant by <o:p></o:p></p> <p class=3DMsoNormal>  “Also not in scope is signaling = to tell the originator to which receivers the media streams should be = sent.”<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>After further discussion with Peter and Steve, the = main discussants on this, I’ve added to the list of what is = included<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoPlainText style=3D'margin-left:.5in'><span = style=3D'font-size:12.0pt; font-family:"Times New Roman","serif"'>*Which sources a receiver wants = to receive.  For example, it might want the source for the left = camera, or might want the source chosen by VAD (Voice Activity = Detection</span>).<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>We interpreted the out of scope sentence to = mean<o:p></o:p></p> <p class=3DMsoNormal>“Also not in scope is signaling to tell the = originator to which IP addresses the media streams should be = sent.”<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>While this seemed okay, it was felt to be = unnecessary. So it was left out of this version.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Thus we think we have “in” what counts = – that the receiver might need to say which of several RTP streams it = wants to receive. And if someone has something they want to exclude could they = please try again to describe it?<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>OH- and for a name. How about CLUE? <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Comments?<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Allyn<o:p></o:p></p> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Charter<o:p></o:p></p> <p class=3DMsoNormal>CLUE ControLling mUltiple streams for = TElepresence<o:p></o:p></p> <p class=3DMsoNormal>or<o:p></o:p></p> <p class=3DMsoNormal>MUSCAT: MUlti-Stream Control Applied to = Telepresence<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>In the context of this WG, the term telepresence is = used in a general manner to describe systems that provide high definition, high = quality audio/video enabling a "being-there" experience.  One = example is an immersive telepresence system using specially designed and special = purpose rooms with multiple displays permitting life size image reproduction = using multiple cameras, encoders, decoders,microphones and = loudspeakers.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Current telepresence systems are based on open = standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A = major factor in the inability of telepresence systems to interwork is that = there is no standardized way to describe and negotiate the use of the multiple = streams of audio and video that comprise the media flows.  In addition,  there is  no standardized way to exchange semantic = information about what each media stream represents.  <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>The WG will create specifications to enable = communication of enough information about each media stream so that each receiving system = or bridge system can make reasonable decisions about selecting and = rendering media streams. This enables systems to make display choices that optimize the "just like being there" experience. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>This working group is chartered to specify the = information about media streams from one endpoint to another endpoint or conference = bridge including:<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>* Spatial relationships of cameras, displays, = microphones, and<o:p></o:p></p> <p class=3DMsoNormal>  speakers in relation to each other and = to likely positions of<o:p></o:p></p> <p class=3DMsoNormal>  participants<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>* Specific characteristics such as viewpoint, field = of view/capture<o:p></o:p></p> <p class=3DMsoNormal>  for camera/microphone/display/speaker = so that senders and             =   <o:p></o:p></p> <p class=3DMsoNormal>  middleboxes can understand how best to = compose streams for<o:p></o:p></p> <p class=3DMsoNormal>  receivers and the receivers will know = the characteristics of its <o:p></o:p></p> <p class=3DMsoNormal>  received streams<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>* Aspect ratio of cameras and = displays<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoPlainText>* <span = style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>Which sources a receiver wants to receive.  For example, it might want = the source for the left camera, or might want the source chosen by VAD = (Voice Activity Detection</span>).<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Information between sources and sinks about media = stream capabilities will be exchanged. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>The working group will define the semantics, = syntax,  and transport mechanism necessary for communicating the necessary = information. It will consider whether the existing signaling mechanisms (e. g., SDP, = BFCP) can be extended, or another messaging method should be used. =  <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>The scope of the work includes describing = relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and = video streams for the current speaker. The scope includes both systems that = provide a fully immersive experience, and systems that interwork with them and = therefore need to understand the same multiple stream semantics. =  <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>The focus of this work is on multiple audio and = video streams.  Other media types may be considered, however development = of methodologies for them is not within the scope of this = work.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Interoperation with standards compliant systems is = required, such as SIP-based video conferencing systems.  However, backwards compatibility with existing non-standards compliant telepresence systems = is not required.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>This working group is not currently chartered to = work on issues of continuous conference control including: far end camera = control, indication of fast frame update for video codecs or other rapid = switches, floor control, conference roster. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Re-use of existing protocols and backwards = compatibility with existing systems is an important factor for the working group to = consider. The work will closely coordinate with the appropriate areas and working = groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and = SIPCORE.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal> Milestones  <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal> Nov 2010 Submit information draft to IESG on = use cases and requirements<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal> Nov 2011 Submit standards track specification = to IESG on indicating<o:p></o:p></p> <p class=3DMsoNormal>          spatial relationships of screens, cameras (including variable<o:p></o:p></p> <p class=3DMsoNormal>          field of = view and orientation), speakers and microphones. This<o:p></o:p></p> <p class=3DMsoNormal>          includes, = semantics, language and transport.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal> Apr 2011 Submit standards track specification = to IESG on indicating the<o:p></o:p></p> <p class=3DMsoNormal>         =  "usage" of a stream as define in charter.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p> = </o:p></span></p> </div> </body> </html> ------_=_NextPart_001_01CB44A2.11DB42D8-- From alex@vidyo.com Wed Aug 25 15:28:57 2010 Return-Path: <alex@vidyo.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34FF73A67B2 for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 15:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8-2LXzGc1OU for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 15:28:55 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 00B253A63C9 for <dispatch@ietf.org>; Wed, 25 Aug 2010 15:28:54 -0700 (PDT) Received: from st022.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 8076278CC8F; Wed, 25 Aug 2010 18:29:26 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from mx1.myoutlookonline.com (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 722BD78CCE8; Wed, 25 Aug 2010 18:29:25 -0400 (EDT) Received: from BH004.mail.lan ([10.110.21.104]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Aug 2010 18:28:14 -0400 Received: from HUB024.mail.lan ([10.110.17.24]) by BH004.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Aug 2010 18:28:21 -0400 Received: from BE235.mail.lan ([10.110.32.235]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Wed, 25 Aug 2010 18:28:26 -0400 From: Alex Eleftheriadis <alex@vidyo.com> To: "Allyn Romanow (allyn)" <allyn@cisco.com> Date: Wed, 25 Aug 2010 18:29:15 -0400 Thread-Topic: [dispatch] Telepresence Charter Version 3 Thread-Index: ActEpNUYIro5TmdESg+8c8sAX10PXQ== Message-ID: <8F26DC96-8F93-4AED-A6CB-195444FC3B44@vidyo.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> 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_8F26DC968F934AEDA6CB195444FC3B44vidyocom_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Aug 2010 22:28:21.0783 (UTC) FILETIME=[D3236A70:01CB44A4] Cc: DISPATCH list <dispatch@ietf.org> Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Aug 2010 22:28:57 -0000 --_000_8F26DC968F934AEDA6CB195444FC3B44vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Allyn, all. I raised the issue originally, and I am fine with the clarif= ication in the new version. Regarding the name, I will repeat my original preference for CLUE. Regards, Alex On Aug 26, 2010, at 1:08 AM, Allyn Romanow (allyn) wrote: Folks, here is the 3rd version of the charter. =95 It incorporates a number of useful editing comments. =95 The substantive issue on this draft concerned what was meant by =93Also not in scope is signaling to tell the originator to which receive= rs the media streams should be sent.=94 After further discussion with Peter and Steve, the main discussants on this= , I=92ve added to the list of what is included *Which sources a receiver wants to receive. For example, it might want the= source for the left camera, or might want the source chosen by VAD (Voice = Activity Detection). We interpreted the out of scope sentence to mean =93Also not in scope is signaling to tell the originator to which IP addres= ses the media streams should be sent.=94 While this seemed okay, it was felt to be unnecessary. So it was left out o= f this version. Thus we think we have =93in=94 what counts =96 that the receiver might need= to say which of several RTP streams it wants to receive. And if someone ha= s something they want to exclude could they please try again to describe it= ? OH- and for a name. How about CLUE? Comments? Allyn Charter CLUE ControLling mUltiple streams for TElepresence or MUSCAT: MUlti-Stream Control Applied to Telepresence In the context of this WG, the term telepresence is used in a general manne= r to describe systems that provide high definition, high quality audio/vide= o enabling a "being-there" experience. One example is an immersive telepre= sence system using specially designed and special purpose rooms with multip= le displays permitting life size image reproduction using multiple cameras,= encoders, decoders,microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, = H.264, the H.323 suite, however, they cannot easily interoperate with each = other without operator assistance and expensive additional equipment which = translates from one vendor to another. A major factor in the inability of t= elepresence systems to interwork is that there is no standardized way to de= scribe and negotiate the use of the multiple streams of audio and video tha= t comprise the media flows. In addition, there is no standardized way to= exchange semantic information about what each media stream represents. The WG will create specifications to enable communication of enough informa= tion about each media stream so that each receiving system or bridge system= can make reasonable decisions about selecting and rendering media streams.= This enables systems to make display choices that optimize the "just like = being there" experience. This working group is chartered to specify the information about media stre= ams from one endpoint to another endpoint or conference bridge including: * Spatial relationships of cameras, displays, microphones, and speakers in relation to each other and to likely positions of participants * Specific characteristics such as viewpoint, field of view/capture for camera/microphone/display/speaker so that senders and middleboxes can understand how best to compose streams for receivers and the receivers will know the characteristics of its received streams * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want th= e source for the left camera, or might want the source chosen by VAD (Voice= Activity Detection). Information between sources and sinks about media stream capabilities will = be exchanged. The working group will define the semantics, syntax, and transport mechani= sm necessary for communicating the necessary information. It will consider = whether the existing signaling mechanisms (e. g., SDP, BFCP) can be extende= d, or another messaging method should be used. The scope of the work includes describing relatively static relations betwe= en entities (participants and devices). It also includes handling more dyna= mic relationships, such as identifying the audio and video streams for the = current speaker. The scope includes both systems that provide a fully immer= sive experience, and systems that interwork with them and therefore need to= understand the same multiple stream semantics. The focus of this work is on multiple audio and video streams. Other media= types may be considered, however development of methodologies for them is = not within the scope of this work. Interoperation with standards compliant systems is required, such as SIP-ba= sed video conferencing systems. However, backwards compatibility with exis= ting non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuo= us conference control including: far end camera control, indication of fast= frame update for video codecs or other rapid switches, floor control, conf= erence roster. Re-use of existing protocols and backwards compatibility with existing syst= ems is an important factor for the working group to consider. The work will= closely coordinate with the appropriate areas and working groups including= OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Milestones Nov 2010 Submit information draft to IESG on use cases and requirements Nov 2011 Submit standards track specification to IESG on indicating spatial relationships of screens, cameras (including variable field of view and orientation), speakers and microphones. This includes, semantics, language and transport. Apr 2011 Submit standards track specification to IESG on indicating the "usage" of a stream as define in charter. _______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch --_000_8F26DC968F934AEDA6CB195444FC3B44vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html><head><base href=3D"x-msg://244/"></head><body style=3D"word-wrap: br= eak-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = ">Hi Allyn, all. I raised the issue originally, and I am fine with the clar= ification in the new version.  <div><br></div><div>Regarding the name,= I will repeat my original preference for CLUE. </div><div><br></div><= div>Regards,</div><div><br></div><div>Alex</div><div><br><div><div>On Aug 2= 6, 2010, at 1:08 AM, Allyn Romanow (allyn) wrote:</div><br class=3D"Apple-i= nterchange-newline"><blockquote type=3D"cite"><span class=3D"Apple-style-sp= an" style=3D"border-collapse: separate; font-family: Helvetica; font-style:= normal; font-variant: normal; font-weight: normal; letter-spacing: normal;= line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; w= hite-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal= -spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decoratio= ns-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-wid= th: 0px; font-size: medium; "><div lang=3D"EN-US" link=3D"blue" vlink=3D"pu= rple"><div class=3D"WordSection1" style=3D"page: WordSection1; "><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Folks, he= re is the 3<sup>rd</sup><span class=3D"Apple-converted-space"> </span>= version of the charter.<o:p></o:p></div><div style=3D"margin-top: 0in; marg= in-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; text-inde= nt: -0.25in; "><span style=3D"font-family: Symbol; "><span>=B7<span style= =3D"font: normal normal normal 7pt/normal 'Times New Roman'; ">  =       <span class=3D"Apple-converted-space">&= nbsp;</span></span></span></span>It incorporates a number of useful editing= comments.<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in= ; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family= : 'Times New Roman', serif; text-indent: -0.25in; "><span style=3D"font-fam= ily: Symbol; "><span>=B7<span style=3D"font: normal normal normal 7pt/norma= l 'Times New Roman'; ">        <spa= n class=3D"Apple-converted-space"> </span></span></span></span>The sub= stantive issue on this draft concerned what was meant by<o:p></o:p></div><d= iv style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; ma= rgin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">&= nbsp; =93Also not in scope is signaling to tell the originator to whic= h receivers the media streams should be sent.=94<o:p></o:p></div><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p>&nbs= p;</o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bott= om: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Ro= man', serif; ">After further discussion with Peter and Steve, the main disc= ussants on this, I=92ve added to the list of what is included<o:p></o:p></d= iv><div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001p= t; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif= ; "><o:p> </o:p></div><div style=3D"margin-top: 0in; margin-right: 0in= ; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 10.5pt; font-fami= ly: Consolas; "><span style=3D"font-size: 12pt; font-family: 'Times New Rom= an', serif; ">*Which sources a receiver wants to receive.  For example= , it might want the source for the left camera, or might want the source ch= osen by VAD (Voice Activity Detection</span>).<o:p></o:p></div><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p>&nbs= p;</o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bott= om: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Ro= man', serif; ">We interpreted the out of scope sentence to mean<o:p></o:p><= /div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.000= 1pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', ser= if; ">=93Also not in scope is signaling to tell the originator to which IP = addresses the media streams should be sent.=94<o:p></o:p></div><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p>&nbs= p;</o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bott= om: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Ro= man', serif; ">While this seemed okay, it was felt to be unnecessary. So it= was left out of this version.<o:p></o:p></div><div style=3D"margin-top: 0i= n; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size:= 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div= style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; marg= in-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Thu= s we think we have =93in=94 what counts =96 that the receiver might need to= say which of several RTP streams it wants to receive. And if someone has s= omething they want to exclude could they please try again to describe it?<o= :p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bot= tom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New R= oman', serif; "><o:p> </o:p></div><div style=3D"margin-top: 0in; margi= n-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; f= ont-family: 'Times New Roman', serif; ">OH- and for a name. How about CLUE?= <o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-b= ottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New= Roman', serif; "><o:p> </o:p></div><div style=3D"margin-top: 0in; mar= gin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt;= font-family: 'Times New Roman', serif; ">Comments?<o:p></o:p></div><div st= yle=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-= left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p>&= nbsp;</o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-b= ottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New= Roman', serif; ">Allyn<o:p></o:p></div><div style=3D"margin-top: 0in; marg= in-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; "> <o:p></o:p></div><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p>&nbs= p;</o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bott= om: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Ro= man', serif; ">Charter<o:p></o:p></div><div style=3D"margin-top: 0in; margi= n-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; f= ont-family: 'Times New Roman', serif; ">CLUE ControLling mUltiple streams f= or TElepresence<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right= : 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-fam= ily: 'Times New Roman', serif; ">or<o:p></o:p></div><div style=3D"margin-to= p: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-= size: 12pt; font-family: 'Times New Roman', serif; ">MUSCAT: MUlti-Stream C= ontrol Applied to Telepresence<o:p></o:p></div><div style=3D"margin-top: 0i= n; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size:= 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div= style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; marg= in-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:= p> </o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margi= n-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times = New Roman', serif; ">In the context of this WG, the term telepresence is us= ed in a general manner to describe systems that provide high definition, hi= gh quality audio/video enabling a "being-there" experience.  One examp= le is an immersive telepresence system using specially designed and special= purpose rooms with multiple displays permitting life size image reproducti= on using multiple cameras, encoders, decoders,microphones and loudspeakers.= <o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-b= ottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New= Roman', serif; "><o:p> </o:p></div><div style=3D"margin-top: 0in; mar= gin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt;= font-family: 'Times New Roman', serif; ">Current telepresence systems are = based on open standards such as RTP, SIP, H.264, the H.323 suite, however, = they cannot easily interoperate with each other without operator assistance= and expensive additional equipment which translates from one vendor to ano= ther. A major factor in the inability of telepresence systems to interwork = is that there is no standardized way to describe and negotiate the use of t= he multiple streams of audio and video that comprise the media flows.  = ;In addition,  there is  no standardized way to exchange sem= antic information about what each media stream represents.  <o:p></o:p= ></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0= 001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', s= erif; "><o:p> </o:p></div><div style=3D"margin-top: 0in; margin-right:= 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-fami= ly: 'Times New Roman', serif; ">The WG will create specifications to enable= communication of enough information about each media stream so that each r= eceiving system or bridge system can make reasonable decisions about select= ing and rendering media streams. This enables systems to make display choic= es that optimize the "just like being there" experience. <o:p></o:p></= div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001= pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', seri= f; "><o:p> </o:p></div><div style=3D"margin-top: 0in; margin-right: 0i= n; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family:= 'Times New Roman', serif; ">This working group is chartered to specify the= information about media streams from one endpoint to another endpoint or c= onference bridge including:<o:p></o:p></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12= pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div st= yle=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-= left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">* Spat= ial relationships of cameras, displays, microphones, and<o:p></o:p></div><d= iv style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; ma= rgin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">&= nbsp; speakers in relation to each other and to likely positions of<o:= p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bott= om: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Ro= man', serif; ">  participants<o:p></o:p></div><div style=3D"margi= n-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; f= ont-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p><= /div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.000= 1pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', ser= if; ">* Specific characteristics such as viewpoint, field of view/capture<o= :p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bot= tom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New R= oman', serif; ">  for camera/microphone/display/speaker so that s= enders and               <o:p></o:p= ></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0= 001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', s= erif; ">  middleboxes can understand how best to compose streams = for<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margi= n-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times = New Roman', serif; ">  receivers and the receivers will know the = characteristics of its <o:p></o:p></div><div style=3D"margin-top: 0in;= margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 1= 2pt; font-family: 'Times New Roman', serif; ">  received streams<= o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bo= ttom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New = Roman', serif; "><o:p> </o:p></div><div style=3D"margin-top: 0in; marg= in-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; ">* Aspect ratio of cameras and disp= lays<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; marg= in-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times= New Roman', serif; "><o:p> </o:p></div><div style=3D"margin-top: 0in;= margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 1= 0.5pt; font-family: Consolas; ">*<span class=3D"Apple-converted-space">&nbs= p;</span><span style=3D"font-size: 12pt; font-family: 'Times New Roman', se= rif; ">Which sources a receiver wants to receive.  For example, it mig= ht want the source for the left camera, or might want the source chosen by = VAD (Voice Activity Detection</span>).<o:p></o:p></div><div style=3D"margin= -top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; fo= nt-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></= div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001= pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', seri= f; "><o:p> </o:p></div><div style=3D"margin-top: 0in; margin-right: 0i= n; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family:= 'Times New Roman', serif; ">Information between sources and sinks about me= dia stream capabilities will be exchanged. <o:p></o:p></div><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p>&nbs= p;</o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bott= om: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Ro= man', serif; ">The working group will define the semantics, syntax,  a= nd transport mechanism necessary for communicating the necessary informatio= n. It will consider whether the existing signaling mechanisms (e. g., SDP, = BFCP) can be extended, or another messaging method should be used.  <o= :p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bot= tom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New R= oman', serif; "><o:p> </o:p></div><div style=3D"margin-top: 0in; margi= n-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; f= ont-family: 'Times New Roman', serif; ">The scope of the work includes desc= ribing relatively static relations between entities (participants and devic= es). It also includes handling more dynamic relationships, such as identify= ing the audio and video streams for the current speaker. The scope includes= both systems that provide a fully immersive experience, and systems that i= nterwork with them and therefore need to understand the same multiple strea= m semantics.  <o:p></o:p></div><div style=3D"margin-top: 0in; margin-r= ight: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font= -family: 'Times New Roman', serif; "><o:p> </o:p></div><div style=3D"m= argin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0i= n; font-size: 12pt; font-family: 'Times New Roman', serif; ">The focus of t= his work is on multiple audio and video streams.  Other media types ma= y be considered, however development of methodologies for them is not withi= n the scope of this work.<o:p></o:p></div><div style=3D"margin-top: 0in; ma= rgin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt= ; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div styl= e=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-le= ft: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Interope= ration with standards compliant systems is required, such as SIP-based vide= o conferencing systems.  However, backwards compatibility with existin= g non-standards compliant telepresence systems is not required.<o:p></o:p><= /div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.000= 1pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', ser= if; "><o:p> </o:p></div><div style=3D"margin-top: 0in; margin-right: 0= in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family= : 'Times New Roman', serif; ">This working group is not currently chartered= to work on issues of continuous conference control including: far end came= ra control, indication of fast frame update for video codecs or other rapid= switches, floor control, conference roster.<o:p></o:p></div><div style=3D"= margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0= in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </= o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: = 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman'= , serif; ">Re-use of existing protocols and backwards compatibility with ex= isting systems is an important factor for the working group to consider. Th= e work will closely coordinate with the appropriate areas and working group= s including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE.<o:p></o:p>= </div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.00= 01pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', se= rif; "><o:p> </o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-famil= y: 'Times New Roman', serif; "> Milestones  <o:p></o:p></div><div= style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; marg= in-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:= p> </o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margi= n-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times = New Roman', serif; "> Nov 2010 Submit information draft to IESG on use= cases and requirements<o:p></o:p></div><div style=3D"margin-top: 0in; marg= in-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "> Nov= 2011 Submit standards track specification to IESG on indicating<o:p></o:p>= </div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.00= 01pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', se= rif; ">          spatial relationships of scr= eens, cameras (including variable<o:p></o:p></div><div style=3D"margin-top:= 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-si= ze: 12pt; font-family: 'Times New Roman', serif; ">     &nbs= p;    field of view and orientation), speakers and microphones. T= his<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margi= n-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times = New Roman', serif; ">          includes, sema= ntics, language and transport.<o:p></o:p></div><div style=3D"margin-top: 0i= n; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size:= 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div= style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; marg= in-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">&nb= sp;Apr 2011 Submit standards track specification to IESG on indicating the<= o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bo= ttom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New = Roman', serif; ">          "usage" of a strea= m as define in charter.<o:p></o:p></div><div style=3D"margin-top: 0in; marg= in-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "> <o:= p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bott= om: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Ro= man', serif; "><o:p> </o:p></div><div style=3D"margin-top: 0in; margin= -right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; fo= nt-family: 'Times New Roman', serif; "><o:p> </o:p></div><div style=3D= "margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: = 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style= =3D"font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p><= /span></div></div>_______________________________________________<br>dispat= ch mailing list<br><a href=3D"mailto:dispatch@ietf.org" style=3D"color: blu= e; text-decoration: underline; ">dispatch@ietf.org</a><br><a href=3D"https:= //www.ietf.org/mailman/listinfo/dispatch" style=3D"color: blue; text-decora= tion: underline; ">https://www.ietf.org/mailman/listinfo/dispatch</a><br></= div></span></blockquote></div><br></div></body></html>= --_000_8F26DC968F934AEDA6CB195444FC3B44vidyocom_-- From pkyzivat@cisco.com Wed Aug 25 16:55:19 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E023A68D2 for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 16:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.501 X-Spam-Level: X-Spam-Status: No, score=-110.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Myb6z4F9TxDV for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 16:55:17 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 298963A6B58 for <dispatch@ietf.org>; Wed, 25 Aug 2010 16:55:16 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,271,1280707200"; d="scan'208";a="151759309" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Aug 2010 23:55:43 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7PNthgC007153; Wed, 25 Aug 2010 23:55:43 GMT Message-ID: <4C75AD7F.7070202@cisco.com> Date: Wed, 25 Aug 2010 19:55:43 -0400 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Allyn Romanow (allyn)" <allyn@cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: DISPATCH list <dispatch@ietf.org> Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Aug 2010 23:55:19 -0000 Seems good to me. I have no preference on WG name. Thanks, Paul Allyn Romanow (allyn) wrote: > Folks, here is the 3^rd version of the charter. > > > > · It incorporates a number of useful editing comments. > > · The substantive issue on this draft concerned what was meant by > > “Also not in scope is signaling to tell the originator to which > receivers the media streams should be sent.” > > > > After further discussion with Peter and Steve, the main discussants on > this, I’ve added to the list of what is included > > > > *Which sources a receiver wants to receive. For example, it might want > the source for the left camera, or might want the source chosen by VAD > (Voice Activity Detection). > > > > We interpreted the out of scope sentence to mean > > “Also not in scope is signaling to tell the originator to which IP > addresses the media streams should be sent.” > > > > While this seemed okay, it was felt to be unnecessary. So it was left > out of this version. > > > > Thus we think we have “in” what counts – that the receiver might need to > say which of several RTP streams it wants to receive. And if someone has > something they want to exclude could they please try again to describe it? > > > > OH- and for a name. How about CLUE? > > > > Comments? > > > > Allyn > > > > > > Charter > > CLUE ControLling mUltiple streams for TElepresence > > or > > MUSCAT: MUlti-Stream Control Applied to Telepresence > > > > > > In the context of this WG, the term telepresence is used in a general > manner to describe systems that provide high definition, high quality > audio/video enabling a "being-there" experience. One example is an > immersive telepresence system using specially designed and special > purpose rooms with multiple displays permitting life size image > reproduction using multiple cameras, encoders, decoders,microphones and > loudspeakers. > > > > Current telepresence systems are based on open standards such as RTP, > SIP, H.264, the H.323 suite, however, they cannot easily interoperate > with each other without operator assistance and expensive additional > equipment which translates from one vendor to another. A major factor in > the inability of telepresence systems to interwork is that there is no > standardized way to describe and negotiate the use of the multiple > streams of audio and video that comprise the media flows. In addition, > there is no standardized way to exchange semantic information about > what each media stream represents. > > > > The WG will create specifications to enable communication of enough > information about each media stream so that each receiving system or > bridge system can make reasonable decisions about selecting and > rendering media streams. This enables systems to make display choices > that optimize the "just like being there" experience. > > > > This working group is chartered to specify the information about media > streams from one endpoint to another endpoint or conference bridge > including: > > > > * Spatial relationships of cameras, displays, microphones, and > > speakers in relation to each other and to likely positions of > > participants > > > > * Specific characteristics such as viewpoint, field of view/capture > > for camera/microphone/display/speaker so that senders and > > middleboxes can understand how best to compose streams for > > receivers and the receivers will know the characteristics of its > > received streams > > > > * Aspect ratio of cameras and displays > > > > * Which sources a receiver wants to receive. For example, it might want > the source for the left camera, or might want the source chosen by VAD > (Voice Activity Detection). > > > > > > Information between sources and sinks about media stream capabilities > will be exchanged. > > > > The working group will define the semantics, syntax, and transport > mechanism necessary for communicating the necessary information. It will > consider whether the existing signaling mechanisms (e. g., SDP, BFCP) > can be extended, or another messaging method should be used. > > > > The scope of the work includes describing relatively static relations > between entities (participants and devices). It also includes handling > more dynamic relationships, such as identifying the audio and video > streams for the current speaker. The scope includes both systems that > provide a fully immersive experience, and systems that interwork with > them and therefore need to understand the same multiple stream semantics. > > > > The focus of this work is on multiple audio and video streams. Other > media types may be considered, however development of methodologies for > them is not within the scope of this work. > > > > Interoperation with standards compliant systems is required, such as > SIP-based video conferencing systems. However, backwards compatibility > with existing non-standards compliant telepresence systems is not required. > > > > This working group is not currently chartered to work on issues of > continuous conference control including: far end camera control, > indication of fast frame update for video codecs or other rapid > switches, floor control, conference roster. > > > > Re-use of existing protocols and backwards compatibility with existing > systems is an important factor for the working group to consider. The > work will closely coordinate with the appropriate areas and working > groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. > > > > Milestones > > > > Nov 2010 Submit information draft to IESG on use cases and requirements > > > > Nov 2011 Submit standards track specification to IESG on indicating > > spatial relationships of screens, cameras (including variable > > field of view and orientation), speakers and microphones. This > > includes, semantics, language and transport. > > > > Apr 2011 Submit standards track specification to IESG on indicating the > > "usage" of a stream as define in charter. > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Wed Aug 25 22:56:25 2010 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73A13A6A85 for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 22:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 208BKkoil2p8 for <dispatch@core3.amsl.com>; Wed, 25 Aug 2010 22:56:14 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DA9BD3A6A6D for <dispatch@ietf.org>; Wed, 25 Aug 2010 22:56:13 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 26 Aug 2010 01:56:44 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 26 Aug 2010 01:56:44 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: "Allyn Romanow (allyn)" <allyn@cisco.com>, DISPATCH list <dispatch@ietf.org> Date: Thu, 26 Aug 2010 01:56:41 -0400 Thread-Topic: Telepresence Charter Version 3 Thread-Index: ActEog2/Y4ucp0iGQOGgIL9SQKxcmAAN3OoQ Message-ID: <430FC6BDED356B4C8498F634416644A9269441348B@mail> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> 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_430FC6BDED356B4C8498F634416644A9269441348Bmail_" MIME-Version: 1.0 Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Aug 2010 05:56:26 -0000 --_000_430FC6BDED356B4C8498F634416644A9269441348Bmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You could also do: MALT - Multi-stream Application Language for Telepresence, or maybe Multi-s= tream Attributes for Lifelike Telepresence COCKTAIL - Communication and Correlation of Key Telepresence Attributes for= Interoperable Links MAITAI - Multi-stream Attributes for Improving Telepresence Application Int= eroperability TEQUILA - Telepresence Encoding of QUalifiers for Interoperable Lifelike Ap= plications MOJITO - Multi-stream Orientation for Joining of Interoperable Telepresence= Operations I'm getting too thirsty to continue... -hadriel ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Allyn Romanow (allyn) Sent: Wednesday, August 25, 2010 6:09 PM To: DISPATCH list Subject: [dispatch] Telepresence Charter Version 3 Folks, here is the 3rd version of the charter. * It incorporates a number of useful editing comments. * The substantive issue on this draft concerned what was meant by "Also not in scope is signaling to tell the originator to which receivers= the media streams should be sent." After further discussion with Peter and Steve, the main discussants on this= , I've added to the list of what is included *Which sources a receiver wants to receive. For example, it might want the= source for the left camera, or might want the source chosen by VAD (Voice = Activity Detection). We interpreted the out of scope sentence to mean "Also not in scope is signaling to tell the originator to which IP addresse= s the media streams should be sent." While this seemed okay, it was felt to be unnecessary. So it was left out o= f this version. Thus we think we have "in" what counts - that the receiver might need to sa= y which of several RTP streams it wants to receive. And if someone has some= thing they want to exclude could they please try again to describe it? OH- and for a name. How about CLUE? Comments? Allyn Charter CLUE ControLling mUltiple streams for TElepresence or MUSCAT: MUlti-Stream Control Applied to Telepresence In the context of this WG, the term telepresence is used in a general manne= r to describe systems that provide high definition, high quality audio/vide= o enabling a "being-there" experience. One example is an immersive telepre= sence system using specially designed and special purpose rooms with multip= le displays permitting life size image reproduction using multiple cameras,= encoders, decoders,microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, = H.264, the H.323 suite, however, they cannot easily interoperate with each = other without operator assistance and expensive additional equipment which = translates from one vendor to another. A major factor in the inability of t= elepresence systems to interwork is that there is no standardized way to de= scribe and negotiate the use of the multiple streams of audio and video tha= t comprise the media flows. In addition, there is no standardized way to= exchange semantic information about what each media stream represents. The WG will create specifications to enable communication of enough informa= tion about each media stream so that each receiving system or bridge system= can make reasonable decisions about selecting and rendering media streams.= This enables systems to make display choices that optimize the "just like = being there" experience. This working group is chartered to specify the information about media stre= ams from one endpoint to another endpoint or conference bridge including: * Spatial relationships of cameras, displays, microphones, and speakers in relation to each other and to likely positions of participants * Specific characteristics such as viewpoint, field of view/capture for camera/microphone/display/speaker so that senders and middleboxes can understand how best to compose streams for receivers and the receivers will know the characteristics of its received streams * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want th= e source for the left camera, or might want the source chosen by VAD (Voice= Activity Detection). Information between sources and sinks about media stream capabilities will = be exchanged. The working group will define the semantics, syntax, and transport mechani= sm necessary for communicating the necessary information. It will consider = whether the existing signaling mechanisms (e. g., SDP, BFCP) can be extende= d, or another messaging method should be used. The scope of the work includes describing relatively static relations betwe= en entities (participants and devices). It also includes handling more dyna= mic relationships, such as identifying the audio and video streams for the = current speaker. The scope includes both systems that provide a fully immer= sive experience, and systems that interwork with them and therefore need to= understand the same multiple stream semantics. The focus of this work is on multiple audio and video streams. Other media= types may be considered, however development of methodologies for them is = not within the scope of this work. Interoperation with standards compliant systems is required, such as SIP-ba= sed video conferencing systems. However, backwards compatibility with exis= ting non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuo= us conference control including: far end camera control, indication of fast= frame update for video codecs or other rapid switches, floor control, conf= erence roster. Re-use of existing protocols and backwards compatibility with existing syst= ems is an important factor for the working group to consider. The work will= closely coordinate with the appropriate areas and working groups including= OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Milestones Nov 2010 Submit information draft to IESG on use cases and requirements Nov 2011 Submit standards track specification to IESG on indicating spatial relationships of screens, cameras (including variable field of view and orientation), speakers and microphones. This includes, semantics, language and transport. Apr 2011 Submit standards track specification to IESG on indicating the "usage" of a stream as define in charter. --_000_430FC6BDED356B4C8498F634416644A9269441348Bmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40" xmlns:ns0=3D"http://schemas.microsoft.com/office/2004/12/omml"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"PlaceT= ype"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"PlaceName"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!--a:link {mso-style-priority:99;} span.MSOHYPERLINK {mso-style-priority:99;} a:visited {mso-style-priority:99;} span.MSOHYPERLINKFOLLOWED {mso-style-priority:99;} p.MSOPLAINTEXT {mso-style-priority:99;} li.MSOPLAINTEXT {mso-style-priority:99;} div.MSOPLAINTEXT {mso-style-priority:99;} p.MSOLISTPARAGRAPH {mso-style-priority:34;} li.MSOLISTPARAGRAPH {mso-style-priority:34;} div.MSOLISTPARAGRAPH {mso-style-priority:34;} span.PLAINTEXTCHAR {mso-style-priority:99;} /* Font Definitions */ @font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} @font-face {font-family:"\@MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {margin:0in; margin-bottom:.0001pt; font-size:10.5pt; font-family:Consolas;} span.PlainTextChar {font-family:Consolas;} p.msolistparagraph, li.msolistparagraph, div.msolistparagraph {margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle20 {mso-style-type:personal; font-family:Calibri; color:windowtext;} span.EmailStyle21 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:298077662; mso-list-type:hybrid; mso-list-template-ids:-1585140378 67698689 67698691 67698693 67698689 6769= 8691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Symbol;} @list l0:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>You could also do:<o:p></o:p></span></= font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>MALT – Multi-stream Application = Language for Telepresence, or <st1:place w:st=3D"on"><st1:PlaceName w:st=3D"on">mayb= e</st1:PlaceName> <st1:PlaceType w:st=3D"on">Multi-stream</st1:PlaceType></st1:place> Attrib= utes for Lifelike Telepresence<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>COCKTAIL – Communication and Correlation of Key Telepresence Attributes for Interoperable Links<o:p></o:= p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>MAITAI – Multi-stream Attributes= for Improving Telepresence Application Interoperability<o:p></o:p></span></font= ></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>TEQUILA – Telepresence Encoding = of QUalifiers for Interoperable Lifelike Applications<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>MOJITO – Multi-stream Orientatio= n for Joining of Interoperable Telepresence Operations<o:p></o:p></span></font></= p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>I’m getting too thirsty to conti= nue…<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>-hadriel<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt'> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Allyn Romanow (allyn)<br= > <b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, August 25, = 2010 6:09 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> DISPATCH list<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> [dispatch] Telepres= ence Charter Version 3</span></font><o:p></o:p></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>Folks, here is the 3<sup>rd</sup> version of the charter.<o:p></o:p= ></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3Dmsolistparagraph style=3D'text-indent:-.25in;mso-list:l0 level1 = lfo2'><![if !supportLists]><font size=3D3 face=3DSymbol><span style=3D'font-size:12.0pt;font-family:Symbol'>= <span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>     </span></fo= nt></span></span></font><![endif]>It incorporates a number of useful editing comments.<o:p></o:p></p> <p class=3Dmsolistparagraph style=3D'text-indent:-.25in;mso-list:l0 level1 = lfo2'><![if !supportLists]><font size=3D3 face=3DSymbol><span style=3D'font-size:12.0pt;font-family:Symbol'>= <span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>     </span></fo= nt></span></span></font><![endif]>The substantive issue on this draft concerned what was meant by <o:p></o:p></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>  “Also not in scope is signaling to tell the originator to which receivers the media streams should be sent.”<o:p>= </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>After further discussion with Peter and Steve, the main discussants= on this, I’ve added to the list of what is included<o:p></o:p></span></f= ont></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoPlainText style=3D'margin-left:.5in'><font size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt;font-family:"Times= New Roman"'>*Which sources a receiver wants to receive.  For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection</span></font>).<o:p></o:p></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>We interpreted the out of scope sentence to mean<o:p></o:p></span><= /font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>“Also not in scope is signaling to tell the originator to whi= ch IP addresses the media streams should be sent.”<o:p></o:p></span></fo= nt></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>While this seemed okay, it was felt to be unnecessary. So it was le= ft out of this version.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>Thus we think we have “in” what counts – that the receiver might need to say which of several RTP streams it wants to receive= . And if someone has something they want to exclude could they please try aga= in to describe it?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>OH- and for a name. How about CLUE? <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>Comments?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>Allyn<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'> <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>Charter<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>CLUE ControLling mUltiple streams for TElepresence<o:p></o:p></span= ></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>or<o:p></o:p></span></font></p> <p class=3DMsoNormal><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font siz= e=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>MUSCAT</span></= font></st1:place></st1:City>: MUlti-Stream Control Applied to Telepresence<o:p></o:p></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>In the context of this WG, the term telepresence is used in a gener= al manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience.  One exampl= e is an immersive telepresence system using specially designed and special purpo= se rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders,microphones and loudspeakers.<o:p></o:= p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>Current telepresence systems are based on open standards such as RT= P, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with = each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor in the inability of telepresence systems to interwork is that there is no standardized way to describe and negotiate the use of the multiple streams of audio and video t= hat comprise the media flows.  In addition,  there is  no standardized way to exchange semantic information about what each medi= a stream represents.  <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>The WG will create specifications to enable communication of enough information about each media stream so that each receiving system or bridge system can make reasonable decisions about selecting and rendering media streams. This enables systems to make display choices that optimize the "just like being there" experience. <o:p></o:p></span></font= ></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>This working group is chartered to specify the information about me= dia streams from one endpoint to another endpoint or conference bridge includin= g:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>* Spatial relationships of cameras, displays, microphones, and<o:p>= </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>  speakers in relation to each other and to likely positi= ons of<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>  participants<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>* Specific characteristics such as viewpoint, field of view/capture= <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>  for camera/microphone/display/speaker so that senders a= nd               <o:p></o:p></span></f= ont></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>  middleboxes can understand how best to compose streams = for<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>  receivers and the receivers will know the characteristi= cs of its <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>  received streams<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>* Aspect ratio of cameras and displays<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3DConsolas><span style=3D'font-= size:10.5pt'>* </span></font><font size=3D3 face=3D"Times New Roman"><span style=3D'font-s= ize:12.0pt; font-family:"Times New Roman"'>Which sources a receiver wants to receive.&n= bsp; For example, it might want the source for the left camera, or might want th= e source chosen by VAD (Voice Activity Detection</span></font>).<o:p></o:p></= p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>Information between sources and sinks about media stream capabiliti= es will be exchanged. <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>The working group will define the semantics, syntax,  and transport mechanism necessary for communicating the necessary information. = It will consider whether the existing signaling mechanisms (e. g., SDP, BFCP) = can be extended, or another messaging method should be used.  <o:p></o:p><= /span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>The scope of the work includes describing relatively static relatio= ns between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and video streams for = the current speaker. The scope includes both systems that provide a fully immer= sive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics.  <o:p></o:p></span></fo= nt></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>The focus of this work is on multiple audio and video streams.  Other media types may be considered, however development of methodolo= gies for them is not within the scope of this work.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>Interoperation with standards compliant systems is required, such a= s SIP-based video conferencing systems.  However, backwards compatibilit= y with existing non-standards compliant telepresence systems is not required.= <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication= of fast frame update for video codecs or other rapid switches, floor control, conference roster. <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>Re-use of existing protocols and backwards compatibility with exist= ing systems is an important factor for the working group to consider. The work = will closely coordinate with the appropriate areas and working groups including = OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE.<o:p></o:p></span></font></= p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'> Milestones  <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'> Nov 2010 Submit information draft to IESG on use cases and requirements<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'> Nov 2011 Submit standards track specification to IESG on indi= cating<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>          spatial relationships of screens, cameras (including variable<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>          field of view and orientati= on), speakers and microphones. This<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>          includes, semantics, langua= ge and transport.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'> Apr 2011 Submit standards track specification to IESG on indicating the<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'>          "usage" of a stre= am as define in charter.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'> <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DCalibri><span style=3D'font-size= :11.0pt; font-family:Calibri'><o:p> </o:p></span></font></p> </div> </div> </body> </html> --_000_430FC6BDED356B4C8498F634416644A9269441348Bmail_-- From john.elwell@siemens-enterprise.com Thu Aug 26 00:26:02 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98963A6A69 for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 00:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.739 X-Spam-Level: X-Spam-Status: No, score=-102.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO-8x5P-Z1U5 for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 00:26:01 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 073A13A6844 for <dispatch@ietf.org>; Thu, 26 Aug 2010 00:26:00 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1289661; Thu, 26 Aug 2010 09:26:32 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 472191EB82AB; Thu, 26 Aug 2010 09:26:32 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 26 Aug 2010 09:26:32 +0200 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: "Allyn Romanow (allyn)" <allyn@cisco.com>, DISPATCH list <dispatch@ietf.org> Date: Thu, 26 Aug 2010 09:26:31 +0200 Thread-Topic: Telepresence Charter Version 3 Thread-Index: ActEog2/Y4ucp0iGQOGgIL9SQKxcmAATUSvg Message-ID: <A444A0F8084434499206E78C106220CA01C482C0DB@MCHP058A.global-ad.net> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.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 Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Aug 2010 07:26:03 -0000 Allyn, Should it be made clear that the work should be based on SIP/SDP (+RTP/H.26= 4, of course)? Since both SIP and H.323 are mentioned in the second paragra= ph, the only CLUE to the work being SIP/SDP-based is the mention of SIPCORE= and MMUSIC later. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) > Sent: 25 August 2010 23:09 > To: DISPATCH list > Subject: [dispatch] Telepresence Charter Version 3 >=20 > Folks, here is the 3rd version of the charter. >=20 > =20 >=20 > * It incorporates a number of useful editing comments. >=20 > * The substantive issue on this draft concerned what=20 > was meant by=20 >=20 > "Also not in scope is signaling to tell the originator to=20 > which receivers the media streams should be sent." >=20 > =20 >=20 > After further discussion with Peter and Steve, the main=20 > discussants on this, I've added to the list of what is included >=20 > =20 >=20 > *Which sources a receiver wants to receive. For example, it=20 > might want the source for the left camera, or might want the=20 > source chosen by VAD (Voice Activity Detection). >=20 > =20 >=20 > We interpreted the out of scope sentence to mean >=20 > "Also not in scope is signaling to tell the originator to=20 > which IP addresses the media streams should be sent." >=20 > =20 >=20 > While this seemed okay, it was felt to be unnecessary. So it=20 > was left out of this version. >=20 > =20 >=20 > Thus we think we have "in" what counts - that the receiver=20 > might need to say which of several RTP streams it wants to=20 > receive. And if someone has something they want to exclude=20 > could they please try again to describe it? >=20 > =20 >=20 > OH- and for a name. How about CLUE?=20 >=20 > =20 >=20 > Comments? >=20 > =20 >=20 > Allyn >=20 > =20 >=20 > =20 >=20 > Charter >=20 > CLUE ControLling mUltiple streams for TElepresence >=20 > or >=20 > MUSCAT: MUlti-Stream Control Applied to Telepresence >=20 > =20 >=20 > =20 >=20 > In the context of this WG, the term telepresence is used in a=20 > general manner to describe systems that provide high=20 > definition, high quality audio/video enabling a "being-there"=20 > experience. One example is an immersive telepresence system=20 > using specially designed and special purpose rooms with=20 > multiple displays permitting life size image reproduction=20 > using multiple cameras, encoders, decoders,microphones and=20 > loudspeakers. >=20 > =20 >=20 > Current telepresence systems are based on open standards such=20 > as RTP, SIP, H.264, the H.323 suite, however, they cannot=20 > easily interoperate with each other without operator=20 > assistance and expensive additional equipment which=20 > translates from one vendor to another. A major factor in the=20 > inability of telepresence systems to interwork is that there=20 > is no standardized way to describe and negotiate the use of=20 > the multiple streams of audio and video that comprise the=20 > media flows. In addition, there is no standardized way to=20 > exchange semantic information about what each media stream=20 > represents. =20 >=20 > =20 >=20 > The WG will create specifications to enable communication of=20 > enough information about each media stream so that each=20 > receiving system or bridge system can make reasonable=20 > decisions about selecting and rendering media streams. This=20 > enables systems to make display choices that optimize the=20 > "just like being there" experience.=20 >=20 > =20 >=20 > This working group is chartered to specify the information=20 > about media streams from one endpoint to another endpoint or=20 > conference bridge including: >=20 > =20 >=20 > * Spatial relationships of cameras, displays, microphones, and >=20 > speakers in relation to each other and to likely positions of >=20 > participants >=20 > =20 >=20 > * Specific characteristics such as viewpoint, field of view/capture >=20 > for camera/microphone/display/speaker so that senders and =20 > =20 >=20 > middleboxes can understand how best to compose streams for >=20 > receivers and the receivers will know the characteristics of its=20 >=20 > received streams >=20 > =20 >=20 > * Aspect ratio of cameras and displays >=20 > =20 >=20 > * Which sources a receiver wants to receive. For example, it=20 > might want the source for the left camera, or might want the=20 > source chosen by VAD (Voice Activity Detection). >=20 > =20 >=20 > =20 >=20 > Information between sources and sinks about media stream=20 > capabilities will be exchanged.=20 >=20 > =20 >=20 > The working group will define the semantics, syntax, and=20 > transport mechanism necessary for communicating the necessary=20 > information. It will consider whether the existing signaling=20 > mechanisms (e. g., SDP, BFCP) can be extended, or another=20 > messaging method should be used. =20 >=20 > =20 >=20 > The scope of the work includes describing relatively static=20 > relations between entities (participants and devices). It=20 > also includes handling more dynamic relationships, such as=20 > identifying the audio and video streams for the current=20 > speaker. The scope includes both systems that provide a fully=20 > immersive experience, and systems that interwork with them=20 > and therefore need to understand the same multiple stream semantics. =20 >=20 > =20 >=20 > The focus of this work is on multiple audio and video=20 > streams. Other media types may be considered, however=20 > development of methodologies for them is not within the scope=20 > of this work. >=20 > =20 >=20 > Interoperation with standards compliant systems is required,=20 > such as SIP-based video conferencing systems. However,=20 > backwards compatibility with existing non-standards compliant=20 > telepresence systems is not required. >=20 > =20 >=20 > This working group is not currently chartered to work on=20 > issues of continuous conference control including: far end=20 > camera control, indication of fast frame update for video=20 > codecs or other rapid switches, floor control, conference roster.=20 >=20 > =20 >=20 > Re-use of existing protocols and backwards compatibility with=20 > existing systems is an important factor for the working group=20 > to consider. The work will closely coordinate with the=20 > appropriate areas and working groups including OPS Area, AVT,=20 > MMUSIC, MEDIACTRL, XCON, and SIPCORE. >=20 > =20 >=20 > Milestones =20 >=20 > =20 >=20 > Nov 2010 Submit information draft to IESG on use cases and=20 > requirements >=20 > =20 >=20 > Nov 2011 Submit standards track specification to IESG on indicating >=20 > spatial relationships of screens, cameras=20 > (including variable >=20 > field of view and orientation), speakers and=20 > microphones. This >=20 > includes, semantics, language and transport. >=20 > =20 >=20 > Apr 2011 Submit standards track specification to IESG on=20 > indicating the >=20 > "usage" of a stream as define in charter. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > = From spromano@unina.it Thu Aug 26 00:36:58 2010 Return-Path: <spromano@unina.it> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6659F3A6954 for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 00:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.72 X-Spam-Level: X-Spam-Status: No, score=-98.72 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga2c-iny4YGb for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 00:36:55 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by core3.amsl.com (Postfix) with ESMTP id D9E543A679F for <dispatch@ietf.org>; Thu, 26 Aug 2010 00:36:54 -0700 (PDT) Received: from [1.197.211.131] ([94.163.116.156]) (authenticated bits=0) by smtp2.unina.it (8.14.0/8.14.0) with ESMTP id o7Q7anm6002963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Aug 2010 09:36:52 +0200 References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> Mime-Version: 1.0 (iPhone Mail 8A306) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-8--441669290 Message-Id: <BA243A0E-A19B-4AC3-BF82-56C605A572BE@unina.it> X-Mailer: iPhone Mail (8A306) From: Simon Pietro Romano <spromano@unina.it> Date: Thu, 26 Aug 2010 09:36:37 +0200 To: "Allyn Romanow (allyn)" <allyn@cisco.com> Cc: DISPATCH list <dispatch@ietf.org> Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Aug 2010 07:36:58 -0000 --Apple-Mail-8--441669290 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ho Allyn, I like the charter as it is now. I would just clarify the definition of the t= hird milestone (April 2011), on the 'usage' of a stream. As to the name, bot= h proposals are ok, even though I have a slight preference for MUSCAT over C= LUE. Simon Il giorno 26/ago/2010, alle ore 00:08, "Allyn Romanow (allyn)" <allyn@cisco.= com> ha scritto: > Folks, here is the 3rd version of the charter. >=20 > =20 >=20 > =C2=B7 It incorporates a number of useful editing comments. >=20 > =C2=B7 The substantive issue on this draft concerned what was mean= t by >=20 > =E2=80=9CAlso not in scope is signaling to tell the originator to which r= eceivers the media streams should be sent.=E2=80=9D >=20 > =20 >=20 > After further discussion with Peter and Steve, the main discussants on thi= s, I=E2=80=99ve added to the list of what is included >=20 > =20 >=20 > *Which sources a receiver wants to receive. For example, it might want th= e source for the left camera, or might want the source chosen by VAD (Voice A= ctivity Detection). >=20 > =20 >=20 > We interpreted the out of scope sentence to mean >=20 > =E2=80=9CAlso not in scope is signaling to tell the originator to which IP= addresses the media streams should be sent.=E2=80=9D >=20 > =20 >=20 > While this seemed okay, it was felt to be unnecessary. So it was left out o= f this version. >=20 > =20 >=20 > Thus we think we have =E2=80=9Cin=E2=80=9D what counts =E2=80=93 that the r= eceiver might need to say which of several RTP streams it wants to receive. A= nd if someone has something they want to exclude could they please try again= to describe it? >=20 > =20 >=20 > OH- and for a name. How about CLUE? >=20 > =20 >=20 > Comments? >=20 > =20 >=20 > Allyn >=20 > =20 >=20 > =20 >=20 > Charter >=20 > CLUE ControLling mUltiple streams for TElepresence >=20 > or >=20 > MUSCAT: MUlti-Stream Control Applied to Telepresence >=20 > =20 >=20 > =20 >=20 > In the context of this WG, the term telepresence is used in a general mann= er to describe systems that provide high definition, high quality audio/vide= o enabling a "being-there" experience. One example is an immersive telepres= ence system using specially designed and special purpose rooms with multiple= displays permitting life size image reproduction using multiple cameras, en= coders, decoders,microphones and loudspeakers. >=20 > =20 >=20 > Current telepresence systems are based on open standards such as RTP, SIP,= H.264, the H.323 suite, however, they cannot easily interoperate with each o= ther without operator assistance and expensive additional equipment which tr= anslates from one vendor to another. A major factor in the inability of tele= presence systems to interwork is that there is no standardized way to descri= be and negotiate the use of the multiple streams of audio and video that com= prise the media flows. In addition, there is no standardized way to excha= nge semantic information about what each media stream represents. =20 >=20 > =20 >=20 > The WG will create specifications to enable communication of enough inform= ation about each media stream so that each receiving system or bridge system= can make reasonable decisions about selecting and rendering media streams. T= his enables systems to make display choices that optimize the "just like bei= ng there" experience.=20 >=20 > =20 >=20 > This working group is chartered to specify the information about media str= eams from one endpoint to another endpoint or conference bridge including: >=20 > =20 >=20 > * Spatial relationships of cameras, displays, microphones, and >=20 > speakers in relation to each other and to likely positions of >=20 > participants >=20 > =20 >=20 > * Specific characteristics such as viewpoint, field of view/capture >=20 > for camera/microphone/display/speaker so that senders and =20= >=20 > middleboxes can understand how best to compose streams for >=20 > receivers and the receivers will know the characteristics of its=20 >=20 > received streams >=20 > =20 >=20 > * Aspect ratio of cameras and displays >=20 > =20 >=20 > * Which sources a receiver wants to receive. For example, it might want t= he source for the left camera, or might want the source chosen by VAD (Voice= Activity Detection). >=20 > =20 >=20 > =20 >=20 > Information between sources and sinks about media stream capabilities will= be exchanged.=20 >=20 > =20 >=20 > The working group will define the semantics, syntax, and transport mechan= ism necessary for communicating the necessary information. It will consider w= hether the existing signaling mechanisms (e. g., SDP, BFCP) can be extended,= or another messaging method should be used. =20 >=20 > =20 >=20 > The scope of the work includes describing relatively static relations betw= een entities (participants and devices). It also includes handling more dyna= mic relationships, such as identifying the audio and video streams for the c= urrent speaker. The scope includes both systems that provide a fully immersi= ve experience, and systems that interwork with them and therefore need to un= derstand the same multiple stream semantics. =20 >=20 > =20 >=20 > The focus of this work is on multiple audio and video streams. Other medi= a types may be considered, however development of methodologies for them is n= ot within the scope of this work. >=20 > =20 >=20 > Interoperation with standards compliant systems is required, such as SIP-b= ased video conferencing systems. However, backwards compatibility with exis= ting non-standards compliant telepresence systems is not required. >=20 > =20 >=20 > This working group is not currently chartered to work on issues of continu= ous conference control including: far end camera control, indication of fast= frame update for video codecs or other rapid switches, floor control, confe= rence roster. >=20 > =20 >=20 > Re-use of existing protocols and backwards compatibility with existing sys= tems is an important factor for the working group to consider. The work will= closely coordinate with the appropriate areas and working groups including O= PS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. >=20 > =20 >=20 > Milestones =20 >=20 > =20 >=20 > Nov 2010 Submit information draft to IESG on use cases and requirements >=20 > =20 >=20 > Nov 2011 Submit standards track specification to IESG on indicating >=20 > spatial relationships of screens, cameras (including variable >=20 > field of view and orientation), speakers and microphones. This >=20 > includes, semantics, language and transport. >=20 > =20 >=20 > Apr 2011 Submit standards track specification to IESG on indicating the >=20 > "usage" of a stream as define in charter. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-8--441669290 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8 <html><body bgcolor="#FFFFFF"><div>Ho Allyn,</div><div><br></div><div>I like the charter as it is now. I would just clarify the definition of the third milestone (April 2011), on the 'usage' of a stream. As to the name, both proposals are ok, even though I have a slight preference for MUSCAT over CLUE.</div><div><br></div><div>Simon<br><br>Il giorno 26/ago/2010, alle ore 00:08, "Allyn Romanow (allyn)" <<a href="mailto:allyn@cisco.com">allyn@cisco.com</a>> ha scritto:<br><br></div><div></div><blockquote type="cite"><div> <div class="WordSection1"> <p class="MsoNormal">Folks, here is the 3<sup>rd</sup> version of the charter.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">         </span></span></span>It incorporates a number of useful editing comments.<o:p></o:p></p> <p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">         </span></span></span>The substantive issue on this draft concerned what was meant by <o:p></o:p></p> <p class="MsoNormal">  â€œAlso not in scope is signaling to tell the originator to which receivers the media streams should be sent.â€<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">After further discussion with Peter and Steve, the main discussants on this, I’ve added to the list of what is included<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoPlainText" style="margin-left:.5in"><span style="font-size:12.0pt; font-family:"Times New Roman","serif"">*Which sources a receiver wants to receive.  For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection</span>).<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">We interpreted the out of scope sentence to mean<o:p></o:p></p> <p class="MsoNormal">“Also not in scope is signaling to tell the originator to which IP addresses the media streams should be sent.â€<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">While this seemed okay, it was felt to be unnecessary. So it was left out of this version.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Thus we think we have “in†what counts – that the receiver might need to say which of several RTP streams it wants to receive. And if someone has something they want to exclude could they please try again to describe it?<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">OH- and for a name. How about CLUE? <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Comments?<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Allyn<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Charter<o:p></o:p></p> <p class="MsoNormal">CLUE ControLling mUltiple streams for TElepresence<o:p></o:p></p> <p class="MsoNormal">or<o:p></o:p></p> <p class="MsoNormal">MUSCAT: MUlti-Stream Control Applied to Telepresence<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience.  One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders,microphones and loudspeakers.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor in the inability of telepresence systems to interwork is that there is no standardized way to describe and negotiate the use of the multiple streams of audio and video that comprise the media flows.  In addition,  there is  no standardized way to exchange semantic information about what each media stream represents.  <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">The WG will create specifications to enable communication of enough information about each media stream so that each receiving system or bridge system can make reasonable decisions about selecting and rendering media streams. This enables systems to make display choices that optimize the "just like being there" experience. <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">This working group is chartered to specify the information about media streams from one endpoint to another endpoint or conference bridge including:<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">* Spatial relationships of cameras, displays, microphones, and<o:p></o:p></p> <p class="MsoNormal">  speakers in relation to each other and to likely positions of<o:p></o:p></p> <p class="MsoNormal">  participants<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">* Specific characteristics such as viewpoint, field of view/capture<o:p></o:p></p> <p class="MsoNormal">  for camera/microphone/display/speaker so that senders and               <o:p></o:p></p> <p class="MsoNormal">  middleboxes can understand how best to compose streams for<o:p></o:p></p> <p class="MsoNormal">  receivers and the receivers will know the characteristics of its <o:p></o:p></p> <p class="MsoNormal">  received streams<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">* Aspect ratio of cameras and displays<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoPlainText">* <span style="font-size:12.0pt;font-family:"Times New Roman","serif"">Which sources a receiver wants to receive.  For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection</span>).<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Information between sources and sinks about media stream capabilities will be exchanged. <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">The working group will define the semantics, syntax,  and transport mechanism necessary for communicating the necessary information. It will consider whether the existing signaling mechanisms (e. g., SDP, BFCP) can be extended, or another messaging method should be used.  <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and video streams for the current speaker. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics.  <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">The focus of this work is on multiple audio and video streams.  Other media types may be considered, however development of methodologies for them is not within the scope of this work.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems.  However, backwards compatibility with existing non-standards compliant telepresence systems is not required.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster. <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Re-use of existing protocols and backwards compatibility with existing systems is an important factor for the working group to consider. The work will closely coordinate with the appropriate areas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"> Milestones  <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"> Nov 2010 Submit information draft to IESG on use cases and requirements<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"> Nov 2011 Submit standards track specification to IESG on indicating<o:p></o:p></p> <p class="MsoNormal">          spatial relationships of screens, cameras (including variable<o:p></o:p></p> <p class="MsoNormal">          field of view and orientation), speakers and microphones. This<o:p></o:p></p> <p class="MsoNormal">          includes, semantics, language and transport.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"> Apr 2011 Submit standards track specification to IESG on indicating the<o:p></o:p></p> <p class="MsoNormal">          "usage" of a stream as define in charter.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p> </div> </div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>dispatch mailing list</span><br><span><a href="mailto:dispatch@ietf.org">dispatch@ietf.org</a></span><br><span><a href="https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.org/mailman/listinfo/dispatch</a></span><br></div></blockquote></body></html> --Apple-Mail-8--441669290-- From lorenzo@meetecho.com Thu Aug 26 02:06:47 2010 Return-Path: <lorenzo@meetecho.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D943A6862 for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 02:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.593 X-Spam-Level: X-Spam-Status: No, score=-3.593 tagged_above=-999 required=5 tests=[AWL=-2.874, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VegEfueqX4B for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 02:06:46 -0700 (PDT) Received: from smtplq02.aruba.it (smtplq-out6.aruba.it [62.149.158.26]) by core3.amsl.com (Postfix) with SMTP id 983493A691B for <dispatch@ietf.org>; Thu, 26 Aug 2010 02:06:45 -0700 (PDT) Received: (qmail 16505 invoked by uid 89); 26 Aug 2010 09:07:07 -0000 Received: from unknown (HELO smtp5.aruba.it) (62.149.128.201) by smtplq02.aruba.it with SMTP; 26 Aug 2010 09:07:07 -0000 Received: (qmail 30067 invoked by uid 89); 26 Aug 2010 09:07:07 -0000 Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@79.53.62.50) by smtp5.ad.aruba.it with SMTP; 26 Aug 2010 09:07:06 -0000 Date: Thu, 26 Aug 2010 11:00:06 +0200 From: Lorenzo Miniero <lorenzo@meetecho.com> To: Simon Pietro Romano <spromano@unina.it> Message-Id: <20100826110006.17f14d4a.lorenzo@meetecho.com> In-Reply-To: <BA243A0E-A19B-4AC3-BF82-56C605A572BE@unina.it> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> <BA243A0E-A19B-4AC3-BF82-56C605A572BE@unina.it> Organization: Meetecho X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: DISPATCH list <dispatch@ietf.org> Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Aug 2010 09:06:47 -0000 Hi Allyn, I'm ok with the charter as well. I'd only suggest making it clearer that the backwards compatibility with existing systems/protocols the WG would like to achieve is limited to standard solutions, otherwise it might look like a conflict with the previous sentence about non-standard systems retro-compatibility being out of scope. L. On Thu, 26 Aug 2010 09:36:37 +0200 Simon Pietro Romano <spromano@unina.it> wrote: > Ho Allyn, > > I like the charter as it is now. I would just clarify the definition of the third milestone (April 2011), on the 'usage' of a stream. As to the name, both proposals are ok, even though I have a slight preference for MUSCAT over CLUE. > > Simon > > Il giorno 26/ago/2010, alle ore 00:08, "Allyn Romanow (allyn)" <allyn@cisco.com> ha scritto: > > > Folks, here is the 3rd version of the charter. > > > > > > > > · It incorporates a number of useful editing comments. > > > > · The substantive issue on this draft concerned what was meant by > > > > “Also not in scope is signaling to tell the originator to which receivers the media streams should be sent.†> > > > > > > > After further discussion with Peter and Steve, the main discussants on this, I’ve added to the list of what is included > > > > > > > > *Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). > > > > > > > > We interpreted the out of scope sentence to mean > > > > “Also not in scope is signaling to tell the originator to which IP addresses the media streams should be sent.†> > > > > > > > While this seemed okay, it was felt to be unnecessary. So it was left out of this version. > > > > > > > > Thus we think we have “in†what counts – that the receiver might need to say which of several RTP streams it wants to receive. And if someone has something they want to exclude could they please try again to describe it? > > > > > > > > OH- and for a name. How about CLUE? > > > > > > > > Comments? > > > > > > > > Allyn > > > > > > > > > > > > Charter > > > > CLUE ControLling mUltiple streams for TElepresence > > > > or > > > > MUSCAT: MUlti-Stream Control Applied to Telepresence > > > > > > > > > > > > In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders,microphones and loudspeakers. > > > > > > > > Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor in the inability of telepresence systems to interwork is that there is no standardized way to describe and negotiate the use of the multiple streams of audio and video that comprise the media flows. In addition, there is no standardized way to exchange semantic information about what each media stream represents. > > > > > > > > The WG will create specifications to enable communication of enough information about each media stream so that each receiving system or bridge system can make reasonable decisions about selecting and rendering media streams. This enables systems to make display choices that optimize the "just like being there" experience. > > > > > > > > This working group is chartered to specify the information about media streams from one endpoint to another endpoint or conference bridge including: > > > > > > > > * Spatial relationships of cameras, displays, microphones, and > > > > speakers in relation to each other and to likely positions of > > > > participants > > > > > > > > * Specific characteristics such as viewpoint, field of view/capture > > > > for camera/microphone/display/speaker so that senders and > > > > middleboxes can understand how best to compose streams for > > > > receivers and the receivers will know the characteristics of its > > > > received streams > > > > > > > > * Aspect ratio of cameras and displays > > > > > > > > * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). > > > > > > > > > > > > Information between sources and sinks about media stream capabilities will be exchanged. > > > > > > > > The working group will define the semantics, syntax, and transport mechanism necessary for communicating the necessary information. It will consider whether the existing signaling mechanisms (e. g., SDP, BFCP) can be extended, or another messaging method should be used. > > > > > > > > The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and video streams for the current speaker. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. > > > > > > > > The focus of this work is on multiple audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. > > > > > > > > Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. > > > > > > > > This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster. > > > > > > > > Re-use of existing protocols and backwards compatibility with existing systems is an important factor for the working group to consider. The work will closely coordinate with the appropriate areas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. > > > > > > > > Milestones > > > > > > > > Nov 2010 Submit information draft to IESG on use cases and requirements > > > > > > > > Nov 2011 Submit standards track specification to IESG on indicating > > > > spatial relationships of screens, cameras (including variable > > > > field of view and orientation), speakers and microphones. This > > > > includes, semantics, language and transport. > > > > > > > > Apr 2011 Submit standards track specification to IESG on indicating the > > > > "usage" of a stream as define in charter. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch -- Lorenzo Miniero <lorenzo@meetecho.com> From partr@cisco.com Thu Aug 26 04:30:25 2010 Return-Path: <partr@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BFA73A6AB0 for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 04:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.936 X-Spam-Level: X-Spam-Status: No, score=-9.936 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkBzjSPgXJc4 for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 04:30:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AA98B3A6AC3 for <dispatch@ietf.org>; Thu, 26 Aug 2010 04:30:22 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANvsdUxAaMHG/2dsb2JhbACgQ3GeKptjhTcEhDiIPQ X-IronPort-AV: E=Sophos;i="4.56,273,1280707200"; d="scan'208";a="579038354" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 26 Aug 2010 11:30:49 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7QBTab8014328; Thu, 26 Aug 2010 11:30:47 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 17:00:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Aug 2010 17:00:42 +0530 Message-ID: <A11921905DA1564D9BCF64A6430A623902F982AD@XMB-BGL-411.cisco.com> In-Reply-To: <A444A0F8084434499206E78C106220CA01C482BBD5@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActDvOLBe1YZhBFsTWqLWKL3I3mobgAQIrjJAAEnJwAAAJN2aQAAQDNAAAJ61h4AAoqxIAAG5T/QADbHKDA= References: <430FC6BDED356B4C8498F634416644A92694381B86@mail><1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381C2C@mail><1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381E9F@mail><4C729FEF.6020509@cisco.com><430FC6BDED356B4C8498F634416644A92694381F16@mail><4C72C9CA.3070304@cisco.com><430FC6BDED356B4C8498F634416644A92694381FDF@mail><4C72EFCC.2000107@cisco.com><430FC6BDED356B4C8498F634416644A92694382179@mail><4C73EA66.4000305@cisco.com><7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se><4C7413D9.80804@cisco.com><A11921905DA1564D9BCF64A6430A62390293A4A8@XMB-BGL-411.cisco.com><7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se><A11921905DA1564D9BCF64A6430A62390293A4A9@XMB-BGL-411.cisco.com><7F2072F1E0DE894DA4B517B93C6A05851B8652@ESESSCMS0356.eemea.ericsson.se><A11921905DA1564D9BCF64A6430A62390293A4AC@XMB-BGL-411.cisco.com> <7F2072F1E0D E894DA4B 517B93C6A058 51B8690@ESESSCMS0356.eemea.ericsson.se> <A444A0F8084434499206E78C106220CA01C482BBD5@MCHP058A.global-ad.net> From: "Parthasarathi R (partr)" <partr@cisco.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com>, "Christer Holmberg" <christer.holmberg@ericsson.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com> X-OriginalArrivalTime: 26 Aug 2010 11:30:42.0835 (UTC) FILETIME=[1E2F8630:01CB4512] Cc: dispatch@ietf.org, Hadriel Kaplan <HKaplan@acmepacket.com> Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Aug 2010 11:30:25 -0000 Christer/Jonn, Thanks for the explanation. From your mails, I'm getting the feel that KPML is good for off the path of SIP dialog and INFO DTMF-relay package outperforms in case the same dialog is used for signaling based DTMF-relay as well as other signaling services.=20 Hadriel, Current text in the draft mention that KPML is not adopted as KPML has less deployment which may not be appropriate. It will be good in case draft introduction section mention the technical advantage of using INFO dtmf package over KPML.=20 Thanks Partha -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Wednesday, August 25, 2010 2:47 PM To: Christer Holmberg; Parthasarathi R (partr); Paul Kyzivat (pkyzivat) Cc: dispatch@ietf.org; Hadriel Kaplan Subject: RE: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt We had a lot of discussion on KPML versus INFO prior to commencing the info-events work, and I think one of the issues was that KPML is fine if the recipient of information is off the path of the SIP dialog for the session concerned, but was not optimised for use cases where an entity on the path needs to receive the information. At the time there seemed to be a consensus that DTMF would be a very likely candidate for an INFO package, should the info-events work proceed. In fact, I don't recall many other candidates, so DTMF seemed to be a prime driver for the info-events work. However, I don't think it was seen as a total replacement for KPML. John > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 25 August 2010 07:05 > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) > Cc: dispatch@ietf.org; Hadriel Kaplan > Subject: Re: [dispatch] > I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt >=20 >=20 > Hi, >=20 > >I haven't seen reply to my second question: > > > >"2) Whether current IETF standard (KPML) has to be > deprecated for the proposed DTMF Info packages. Both KPML, DTMF Info=20 > package are SIP signaling based > >mechanism for DTMF relay." >=20 > Personally I have no opinion on that. >=20 > In my understanding the scope of KPML is wider than DTMF transport, so > someone may want to use it for something else. > I have never seen any usage of, or received a requirement to support,=20 > KPML, but that of course doesn't guarantee that there aren't=20 > deployments out there. >=20 > >It is not clear to me why IMS take different stance than > current IETF standard (KPML) for DTMF relay. In case of the analysis=20 > has done for not selecting > >KPML in IMS, please let us know as it will help us to > proceed in the INFO based DTMF package direction in IETF. >=20 > KPML vs INFO has been discussed many times, before we even started the > work on Info Packages. One issue people have is that it requires=20 > subscriptions, and separate subscription dialogs (based on the dialog=20 > usage recommendations), which have resource impacts at least on=20 > stateful entities. >=20 > >Also Currently, IANA registration is yet to be done for DTMF > Info package and so, the modification is possible. >=20 > Sure. Any 3GPP member can bring change proposals. >=20 > And, if we decide to specify a DTMF Info Package of our own (e.g.=20 > based on Hadriel's proposal), any 3GPP member can, once it's down,=20 > propose to adopt it for IMS. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > ________________________________ >=20 > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wed 8/25/2010 9:04 AM > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) > Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal=20 > (mperumal) > Subject: RE:=20 > [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt > =09 > =09 >=20 >=20 > Hi, > =09 > >1) whether 3GPP DTMF Info package is in the state to be accepted as=20 > IETF standards. > =09 > The Info Package registration procedure requires an expert review,=20 > which purpose is to ensure that the Info Package does not break the=20 > SIP protocol etc. I assume such review will take place when the=20 > package is registered with IANA. > =09 > Regards, > =09 > Christer > =09 > =09 > =09 > =09 > ________________________________ > =09 > From: Christer Holmberg > [mailto:christer.holmberg@ericsson.com] > Sent: Wed 8/25/2010 8:45 AM > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) > Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi=20 > Perumal (mperumal) > Subject: RE:=20 > [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt > =20 > =20 > =09 > =09 > Hi, > =20 > >In case IMS needs new INFO based DTMF relay mechanism, I=20 > agree that it is the valid requirement and we need to evaluate it.=20 > Before concluding about new > >INFO based mechanism in IMS, Please throw the light for not=20 > selecting KPML in IMS. I'm comparing KPML vs INFO based mechanism as=20 > both are based on SIP > >signaling based mechanism. KPML has limited deployment as=20 > mentioned in Hadriel Info draft but new INFO package is yet to be=20 > defined. It is better to have > >the single active IETF SIP signaling based dtmf-relay=20 > mechanism rather than producing more standards wherein implementers=20 > will completely confused which > >one to select. > > > >As Muthu mentioned, I also heard about KPML deployment=20 > issues but the legacy INFO based dtmf-relay has lot more caveats. I=20 > guess that Info package is > >designed as generic as KPML, and then both KPML and INFO may=20 > look heavyweight. > =20 > The 3GPP DTMF Info Package is very simple. > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > =20 > ________________________________ > =20 > From: dispatch-bounces@ietf.org on behalf of Paul=20 > Kyzivat (pkyzivat) > Sent: Wed 8/25/2010 12:17 AM > To: Christer Holmberg > Cc: dispatch@ietf.org; Hadriel Kaplan > Subject: Re: [dispatch]I-D=20 > Action:draft-kaplan-dispatch-info-dtmf-package-00.txt > =20 > =20 > =20 > =20 > =20 > Christer Holmberg wrote: > > Hi, > > > > I think it is strange to reject something based on=20 > a claim there already exists a number of legacy ways of there. Not=20 > everyone has implemented the same (if any) of them, and the whole=20 > purpose of the Info Package framework is to come up with a mechanism=20 > for which the usage can be negotiated. > > > > And, as I said earlier, at least in IMS an Info=20 > Package is being used for DTMF transport. It is currently defined in=20 > 3GPP specifications, but there shouldn't be anything IMS specific=20 > about the package itself. > =20 > I wasn't asserting a general principle. > I was talking about this particular mechanism. > =20 > If there is yet another dtmf package, then I guess we=20 > can consider the > pros/cons of it. Those are probably best assessed by=20 > those who use the > existing one and/or might use whatever info package=20 > you might propose to > replace it. > =20 > We clearly suffer from a surplus of ways to convey=20 > dtmf. > While its not impossible to argue than another one=20 > would improve the > situation, it is going to be a hard sell. > =20 > OTOH, the more there are the more case it makes for=20 > having an SBC in the > path to "fix" the interoperability. We sell them, so=20 > maybe I should be > cheering on every new one as a way to boost sales. > =20 > Thanks, > Paul > =20 > > Regards, > > > > Christer > > > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] > On Behalf Of Paul Kyzivat > >> Sent: 24. elokuuta 2010 18:51 > >> To: Hadriel Kaplan > >> Cc: dispatch@ietf.org > >> Subject: Re: [dispatch] I-D > >> > Action:draft-kaplan-dispatch-info-dtmf-package-00.txt > >> > >> Maybe we should ask our ADs if they have an=20 > opinion about this. > >> > >> Thanks, > >> Paul > >> > >> Hadriel Kaplan wrote: > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Monday, August 23, 2010 6:02 PM > >>>> To: Hadriel Kaplan > >>>> > >>>> That reduces things somewhat. But if everybody=20 > that supports the > >>>> package also supports the legacy approach, what=20 > is the win? > >>> The legacy mode has no published standards=20 > document > >> defining it. I thought when the info-packages=20 > work was > >> started, DTMF-in-info was one of the main drivers. =20 > But I > >> take your point - if people would prefer to just=20 > document it > >> as it is today (sans info-packages), I can change=20 > the draft > >> to just be that. I'm cool with either way=20 > (defining the > >> current dtmf-relay as a legacy mode was Option-2). > >>> -hadriel > >>> > >> > _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> > https://www.ietf.org/mailman/listinfo/dispatch > >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > =20 > =20 > =20 > =09 > =09 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From richard@shockey.us Thu Aug 26 05:35:19 2010 Return-Path: <richard@shockey.us> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553C13A6ADA for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 05:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xremomv9573x for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 05:34:43 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 197E83A6A8F for <dispatch@ietf.org>; Thu, 26 Aug 2010 05:34:42 -0700 (PDT) Received: (qmail 30804 invoked by uid 0); 26 Aug 2010 12:36:34 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 26 Aug 2010 12:36:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=S3cOpcEVpJ8CnbGoyKZd1udduUUfZm1q+hqXSUImEviHxPmubUwn827m9UWCBQcRmSLt43eFUPTEFXYdkd6hh3lJx/NvIDKcMbzSDgQsIbgihMUqr7mbMqycfSltRKGt; Received: from pool-173-79-200-247.washdc.fios.verizon.net ([173.79.200.247] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from <richard@shockey.us>) id 1Oobfm-0007IJ-Rd; Thu, 26 Aug 2010 06:35:15 -0600 From: "Richard Shockey" <richard@shockey.us> To: "'Hadriel Kaplan'" <HKaplan@acmepacket.com>, "'Allyn Romanow \(allyn\)'" <allyn@cisco.com>, "'DISPATCH list'" <dispatch@ietf.org> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> <430FC6BDED356B4C8498F634416644A9269441348B@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A9269441348B@mail> Date: Thu, 26 Aug 2010 08:35:12 -0400 Message-ID: <000501cb451b$21a3d650$64eb82f0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CB44F9.9A923650" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActEog2/Y4ucp0iGQOGgIL9SQKxcmAAN3OoQABBj0RA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.200.247 authed with richard@shockey.us} Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Aug 2010 12:35:19 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CB44F9.9A923650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit COCKTAIL . From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Thursday, August 26, 2010 1:57 AM To: Allyn Romanow (allyn); DISPATCH list Subject: Re: [dispatch] Telepresence Charter Version 3 You could also do: MALT - Multi-stream Application Language for Telepresence, or maybe Multi-stream Attributes for Lifelike Telepresence COCKTAIL - Communication and Correlation of Key Telepresence Attributes for Interoperable Links MAITAI - Multi-stream Attributes for Improving Telepresence Application Interoperability TEQUILA - Telepresence Encoding of QUalifiers for Interoperable Lifelike Applications MOJITO - Multi-stream Orientation for Joining of Interoperable Telepresence Operations I'm getting too thirsty to continue. -hadriel _____ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) Sent: Wednesday, August 25, 2010 6:09 PM To: DISPATCH list Subject: [dispatch] Telepresence Charter Version 3 Folks, here is the 3rd version of the charter. . It incorporates a number of useful editing comments. . The substantive issue on this draft concerned what was meant by "Also not in scope is signaling to tell the originator to which receivers the media streams should be sent." After further discussion with Peter and Steve, the main discussants on this, I've added to the list of what is included *Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). We interpreted the out of scope sentence to mean "Also not in scope is signaling to tell the originator to which IP addresses the media streams should be sent." While this seemed okay, it was felt to be unnecessary. So it was left out of this version. Thus we think we have "in" what counts - that the receiver might need to say which of several RTP streams it wants to receive. And if someone has something they want to exclude could they please try again to describe it? OH- and for a name. How about CLUE? Comments? Allyn Charter CLUE ControLling mUltiple streams for TElepresence or MUSCAT: MUlti-Stream Control Applied to Telepresence In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders,microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor in the inability of telepresence systems to interwork is that there is no standardized way to describe and negotiate the use of the multiple streams of audio and video that comprise the media flows. In addition, there is no standardized way to exchange semantic information about what each media stream represents. The WG will create specifications to enable communication of enough information about each media stream so that each receiving system or bridge system can make reasonable decisions about selecting and rendering media streams. This enables systems to make display choices that optimize the "just like being there" experience. This working group is chartered to specify the information about media streams from one endpoint to another endpoint or conference bridge including: * Spatial relationships of cameras, displays, microphones, and speakers in relation to each other and to likely positions of participants * Specific characteristics such as viewpoint, field of view/capture for camera/microphone/display/speaker so that senders and middleboxes can understand how best to compose streams for receivers and the receivers will know the characteristics of its received streams * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). Information between sources and sinks about media stream capabilities will be exchanged. The working group will define the semantics, syntax, and transport mechanism necessary for communicating the necessary information. It will consider whether the existing signaling mechanisms (e. g., SDP, BFCP) can be extended, or another messaging method should be used. The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and video streams for the current speaker. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. The focus of this work is on multiple audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster. Re-use of existing protocols and backwards compatibility with existing systems is an important factor for the working group to consider. The work will closely coordinate with the appropriate areas and working groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Milestones Nov 2010 Submit information draft to IESG on use cases and requirements Nov 2011 Submit standards track specification to IESG on indicating spatial relationships of screens, cameras (including variable field of view and orientation), speakers and microphones. This includes, semantics, language and transport. Apr 2011 Submit standards track specification to IESG on indicating the "usage" of a stream as define in charter. ------=_NextPart_000_0006_01CB44F9.9A923650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0in; margin-bottom:.0001pt; font-size:10.5pt; font-family:Consolas;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:Consolas;} span.plaintextchar0 {mso-style-name:plaintextchar; mso-style-priority:99; font-family:Consolas;} span.EmailStyle21 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle22 {mso-style-type:personal; font-family:"Arial","sans-serif"; color:navy;} span.EmailStyle23 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:298077662; mso-list-type:hybrid; mso-list-template-ids:-1585140378 67698689 67698691 67698693 67698689 = 67698691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Symbol;} @list l0:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>COCKTAIL …<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt = 0in 0in 0in'> <p class=3DMsoNormal><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>= </b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] <b>On = Behalf Of </b>Hadriel Kaplan<br> <b>Sent:</b> Thursday, August 26, 2010 1:57 AM<br> <b>To:</b> Allyn Romanow (allyn); DISPATCH list<br> <b>Subject:</b> Re: [dispatch] Telepresence Charter Version = 3<o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:navy'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:navy'>You could also do:<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:navy'>MALT – Multi-stream Application Language for = Telepresence, or maybe Multi-stream Attributes for Lifelike Telepresence<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:navy'>COCKTAIL – Communication and Correlation of Key = Telepresence Attributes for Interoperable Links<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:navy'>MAITAI – Multi-stream Attributes for Improving = Telepresence Application Interoperability<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:navy'>TEQUILA – Telepresence Encoding of QUalifiers for = Interoperable Lifelike Applications<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:navy'>MOJITO – Multi-stream Orientation for Joining of = Interoperable Telepresence Operations<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:navy'>I’m getting too thirsty to = continue…<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:navy'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:navy'>-hadriel<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:navy'><o:p> </o:p></span></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in = 0in 4.0pt'> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'> <hr size=3D2 width=3D"100%" align=3Dcenter> </div> <p class=3DMsoNormal><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>= </b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] <b>On Behalf Of </b>Allyn Romanow = (allyn)<br> <b>Sent:</b> Wednesday, August 25, 2010 6:09 PM<br> <b>To:</b> DISPATCH list<br> <b>Subject:</b> [dispatch] Telepresence Charter Version = 3</span><o:p></o:p></p> </div> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Folks, here is the 3<sup>rd</sup> version of the = charter.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo2'><![if !supportLists]><span style=3D'font-family:Symbol'><span = style=3D'mso-list:Ignore'>·<span style=3D'font:7.0pt "Times New = Roman"'>       = </span></span></span><![endif]>It incorporates a number of useful editing comments.<o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo2'><![if !supportLists]><span style=3D'font-family:Symbol'><span = style=3D'mso-list:Ignore'>·<span style=3D'font:7.0pt "Times New = Roman"'>       = </span></span></span><![endif]>The substantive issue on this draft concerned what was meant by = <o:p></o:p></p> <p class=3DMsoNormal>  “Also not in scope is signaling = to tell the originator to which receivers the media streams should be = sent.”<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>After further discussion with Peter and Steve, the = main discussants on this, I’ve added to the list of what is = included<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoPlainText style=3D'margin-left:.5in'><span = style=3D'font-size:12.0pt; font-family:"Times New Roman","serif"'>*Which sources a receiver wants = to receive.  For example, it might want the source for the left = camera, or might want the source chosen by VAD (Voice Activity = Detection</span>).<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>We interpreted the out of scope sentence to = mean<o:p></o:p></p> <p class=3DMsoNormal>“Also not in scope is signaling to tell the = originator to which IP addresses the media streams should be = sent.”<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>While this seemed okay, it was felt to be = unnecessary. So it was left out of this version.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Thus we think we have “in” what counts = – that the receiver might need to say which of several RTP streams it wants to receive. And = if someone has something they want to exclude could they please try again = to describe it?<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>OH- and for a name. How about CLUE? <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Comments?<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Allyn<o:p></o:p></p> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Charter<o:p></o:p></p> <p class=3DMsoNormal>CLUE ControLling mUltiple streams for = TElepresence<o:p></o:p></p> <p class=3DMsoNormal>or<o:p></o:p></p> <p class=3DMsoNormal>MUSCAT: MUlti-Stream Control Applied to = Telepresence<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>In the context of this WG, the term telepresence is = used in a general manner to describe systems that provide high definition, high = quality audio/video enabling a "being-there" experience.  One = example is an immersive telepresence system using specially designed and special = purpose rooms with multiple displays permitting life size image reproduction = using multiple cameras, encoders, decoders,microphones and = loudspeakers.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Current telepresence systems are based on open = standards such as RTP, SIP, H.264, the H.323 suite, however, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A = major factor in the inability of telepresence systems to interwork is that = there is no standardized way to describe and negotiate the use of the multiple = streams of audio and video that comprise the media flows.  In addition,  there is  no standardized way to exchange semantic = information about what each media stream represents.  <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>The WG will create specifications to enable = communication of enough information about each media stream so that each receiving system = or bridge system can make reasonable decisions about selecting and = rendering media streams. This enables systems to make display choices that optimize the "just like being there" experience. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>This working group is chartered to specify the = information about media streams from one endpoint to another endpoint or conference = bridge including:<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>* Spatial relationships of cameras, displays, = microphones, and<o:p></o:p></p> <p class=3DMsoNormal>  speakers in relation to each other and = to likely positions of<o:p></o:p></p> <p class=3DMsoNormal>  participants<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>* Specific characteristics such as viewpoint, field = of view/capture<o:p></o:p></p> <p class=3DMsoNormal>  for camera/microphone/display/speaker = so that senders and             =   <o:p></o:p></p> <p class=3DMsoNormal>  middleboxes can understand how best to = compose streams for<o:p></o:p></p> <p class=3DMsoNormal>  receivers and the receivers will know = the characteristics of its <o:p></o:p></p> <p class=3DMsoNormal>  received streams<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>* Aspect ratio of cameras and = displays<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoPlainText>* <span = style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>Which sources a receiver wants to receive.  For example, it might want = the source for the left camera, or might want the source chosen by VAD = (Voice Activity Detection</span>).<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Information between sources and sinks about media = stream capabilities will be exchanged. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>The working group will define the semantics, = syntax,  and transport mechanism necessary for communicating the necessary = information. It will consider whether the existing signaling mechanisms (e. g., SDP, = BFCP) can be extended, or another messaging method should be used. =  <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>The scope of the work includes describing = relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and = video streams for the current speaker. The scope includes both systems that = provide a fully immersive experience, and systems that interwork with them and = therefore need to understand the same multiple stream semantics. =  <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>The focus of this work is on multiple audio and = video streams.  Other media types may be considered, however development = of methodologies for them is not within the scope of this = work.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Interoperation with standards compliant systems is = required, such as SIP-based video conferencing systems.  However, backwards compatibility with existing non-standards compliant telepresence systems = is not required.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>This working group is not currently chartered to = work on issues of continuous conference control including: far end camera = control, indication of fast frame update for video codecs or other rapid = switches, floor control, conference roster. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Re-use of existing protocols and backwards = compatibility with existing systems is an important factor for the working group to = consider. The work will closely coordinate with the appropriate areas and working = groups including OPS Area, AVT, MMUSIC, MEDIACTRL, XCON, and = SIPCORE.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal> Milestones  <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal> Nov 2010 Submit information draft to IESG on = use cases and requirements<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal> Nov 2011 Submit standards track specification = to IESG on indicating<o:p></o:p></p> <p class=3DMsoNormal>          spatial relationships of screens, cameras (including variable<o:p></o:p></p> <p class=3DMsoNormal>          field of = view and orientation), speakers and microphones. This<o:p></o:p></p> <p class=3DMsoNormal>          includes, = semantics, language and transport.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal> Apr 2011 Submit standards track specification = to IESG on indicating the<o:p></o:p></p> <p class=3DMsoNormal>         =  "usage" of a stream as define in charter.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal> <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p> = </o:p></span></p> </div> </div> </body> </html> ------=_NextPart_000_0006_01CB44F9.9A923650-- From fluffy@cisco.com Thu Aug 26 08:53:25 2010 Return-Path: <fluffy@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8953A6852 for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 08:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.511 X-Spam-Level: X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXsCrakCtjwz for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 08:53:20 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 55E873A687C for <dispatch@ietf.org>; Thu, 26 Aug 2010 08:53:20 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,274,1280707200"; d="scan'208";a="274791282" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 26 Aug 2010 15:53:53 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7QFrpcg025915; Thu, 26 Aug 2010 15:53:51 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> Date: Thu, 26 Aug 2010 09:53:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5141CABF-6718-40AD-8BB8-38B4938FBB1A@cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> To: Allyn Romanow (allyn) <allyn@cisco.com> X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list <dispatch@ietf.org> Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Aug 2010 15:53:26 -0000 I think this charter has some pretty serious issues with being way to = wide open on what the scope is. The fact we are actually discussing if = we need to add in "Also not in scope is signaling to tell the = originator to which IP addresses the media streams should be sent=94 = should be a huge hint that we have the scope much too broad. As I said a = week ago ....=20 Begin forwarded message: > From: Cullen Jennings <fluffy@cisco.com> > Date: August 18, 2010 11:16:22 AM MDT > Main point: > When I read this charter and ask myself what is out of scope, it seems = that anything that is "the information about media streams from one = endpoint to another endpoint or conference bridge including" would be in = scope. I realize a few more things are taken our of scope later but the = resulting space includes just about everything that MMUSIC does, and = much of what SIP does. Because of the "anything and everything" approach = I don't think this is a charter that will result in work that gets done = quickly. =46rom the point of view of being broad enough to do the need = work, I think it's fine but from the point of view of being narrow = enough to limit the work to something that is possible to complete, it = seems pretty bad. I suspect that IESG would likely look at this as a = "blank cheque" charter and ask for some changes to it. My suggestion = would be just to change the "including (but not limited to):" in 3rd = paragraph to be=20 >=20 > This working group is chartered to specify the following information = about media streams from one endpoint to another endpoint: >=20 Note I am not arguing that there any given piece of work you should not = do - I'm just encouraging you to say what problems you are going to do. I would encourage you to specify what this working group is going to do, = like you have in the bullet points, and stop leaving it open to do = anything including the stuff in bullet points. We should do our best to = avoid charters that are so unspecific that they overlap with existing = WGs in ways that leave huge questions about which WG a new piece of work = should go to.=20 Cullen <with my DISPATCH co-chair hat on> From allyn@cisco.com Thu Aug 26 09:35:54 2010 Return-Path: <allyn@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41EB3A6A47 for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 09:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.436 X-Spam-Level: X-Spam-Status: No, score=-10.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47tTGXWIuc2E for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 09:35:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1BA003A69F2 for <dispatch@ietf.org>; Thu, 26 Aug 2010 09:35:37 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFc0dkyrRN+J/2dsb2JhbACgSXGhAJtmhTcEhDqIPg X-IronPort-AV: E=Sophos;i="4.56,274,1280707200"; d="scan'208";a="579183558" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 26 Aug 2010 16:36:09 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7QGa9qR009443; Thu, 26 Aug 2010 16:36:09 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 09:36:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Aug 2010 09:36:08 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE8A5@xmb-sjc-221.amer.cisco.com> In-Reply-To: <A444A0F8084434499206E78C106220CA01C482C0DB@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Telepresence Charter Version 3 Thread-Index: ActEog2/Y4ucp0iGQOGgIL9SQKxcmAATUSvgABMXwFA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> <A444A0F8084434499206E78C106220CA01C482C0DB@MCHP058A.global-ad.net> From: "Allyn Romanow (allyn)" <allyn@cisco.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com> X-OriginalArrivalTime: 26 Aug 2010 16:36:09.0638 (UTC) FILETIME=[C9CFBC60:01CB453C] Cc: IETF DISPATCH list <dispatch@ietf.org> Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Aug 2010 16:35:54 -0000 Hi John, Good catch. I thought we had done this earlier, but it isn't there now. How is this text? The WG will create specifications for SIP-based conferencing systems to enable communication of=20 enough information about each media stream so that each=20 receiving system or bridge system can make reasonable=20 decisions about selecting and rendering media streams. This=20 enables systems to make display choices that optimize the=20 "just like being there" experience.=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Thursday, August 26, 2010 12:27 AM > To: Allyn Romanow (allyn); DISPATCH list > Subject: RE: Telepresence Charter Version 3 >=20 > Allyn, >=20 > Should it be made clear that the work should be based on=20 > SIP/SDP (+RTP/H.264, of course)? Since both SIP and H.323 are=20 > mentioned in the second paragraph, the only CLUE to the work=20 > being SIP/SDP-based is the mention of SIPCORE and MMUSIC later. >=20 > John >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn=20 > Romanow (allyn) > > Sent: 25 August 2010 23:09 > > To: DISPATCH list > > Subject: [dispatch] Telepresence Charter Version 3 > >=20 > > Folks, here is the 3rd version of the charter. > >=20 > > =20 > >=20 > > * It incorporates a number of useful editing comments. > >=20 > > * The substantive issue on this draft concerned what=20 > > was meant by > >=20 > > "Also not in scope is signaling to tell the originator to which=20 > > receivers the media streams should be sent." > >=20 > > =20 > >=20 > > After further discussion with Peter and Steve, the main=20 > discussants on=20 > > this, I've added to the list of what is included > >=20 > > =20 > >=20 > > *Which sources a receiver wants to receive. For example, it might=20 > > want the source for the left camera, or might want the=20 > source chosen=20 > > by VAD (Voice Activity Detection). > >=20 > > =20 > >=20 > > We interpreted the out of scope sentence to mean > >=20 > > "Also not in scope is signaling to tell the originator to which IP=20 > > addresses the media streams should be sent." > >=20 > > =20 > >=20 > > While this seemed okay, it was felt to be unnecessary. So=20 > it was left=20 > > out of this version. > >=20 > > =20 > >=20 > > Thus we think we have "in" what counts - that the receiver=20 > might need=20 > > to say which of several RTP streams it wants to receive. And if=20 > > someone has something they want to exclude could they=20 > please try again=20 > > to describe it? > >=20 > > =20 > >=20 > > OH- and for a name. How about CLUE?=20 > >=20 > > =20 > >=20 > > Comments? > >=20 > > =20 > >=20 > > Allyn > >=20 > > =20 > >=20 > > =20 > >=20 > > Charter > >=20 > > CLUE ControLling mUltiple streams for TElepresence > >=20 > > or > >=20 > > MUSCAT: MUlti-Stream Control Applied to Telepresence > >=20 > > =20 > >=20 > > =20 > >=20 > > In the context of this WG, the term telepresence is used in=20 > a general=20 > > manner to describe systems that provide high definition,=20 > high quality=20 > > audio/video enabling a "being-there" > > experience. One example is an immersive telepresence system using=20 > > specially designed and special purpose rooms with multiple displays=20 > > permitting life size image reproduction using multiple cameras,=20 > > encoders, decoders,microphones and loudspeakers. > >=20 > > =20 > >=20 > > Current telepresence systems are based on open standards such=20 > > as RTP, SIP, H.264, the H.323 suite, however, they cannot=20 > > easily interoperate with each other without operator=20 > > assistance and expensive additional equipment which=20 > > translates from one vendor to another. A major factor in the=20 > > inability of telepresence systems to interwork is that there=20 > > is no standardized way to describe and negotiate the use of=20 > > the multiple streams of audio and video that comprise the=20 > > media flows. In addition, there is no standardized way to=20 > > exchange semantic information about what each media stream=20 > > represents. =20 > >=20 > > =20 > >=20 > > The WG will create specifications to enable communication of=20 > > enough information about each media stream so that each=20 > > receiving system or bridge system can make reasonable=20 > > decisions about selecting and rendering media streams. This=20 > > enables systems to make display choices that optimize the=20 > > "just like being there" experience.=20 > >=20 > > =20 > >=20 > > This working group is chartered to specify the information=20 > > about media streams from one endpoint to another endpoint or=20 > > conference bridge including: > >=20 > > =20 > >=20 > > * Spatial relationships of cameras, displays, microphones, and > >=20 > > speakers in relation to each other and to likely positions of > >=20 > > participants > >=20 > > =20 > >=20 > > * Specific characteristics such as viewpoint, field of view/capture > >=20 > > for camera/microphone/display/speaker so that senders and =20 > > =20 > >=20 > > middleboxes can understand how best to compose streams for > >=20 > > receivers and the receivers will know the characteristics of its=20 > >=20 > > received streams > >=20 > > =20 > >=20 > > * Aspect ratio of cameras and displays > >=20 > > =20 > >=20 > > * Which sources a receiver wants to receive. For example, it=20 > > might want the source for the left camera, or might want the=20 > > source chosen by VAD (Voice Activity Detection). > >=20 > > =20 > >=20 > > =20 > >=20 > > Information between sources and sinks about media stream=20 > > capabilities will be exchanged.=20 > >=20 > > =20 > >=20 > > The working group will define the semantics, syntax, and=20 > > transport mechanism necessary for communicating the necessary=20 > > information. It will consider whether the existing signaling=20 > > mechanisms (e. g., SDP, BFCP) can be extended, or another=20 > > messaging method should be used. =20 > >=20 > > =20 > >=20 > > The scope of the work includes describing relatively static=20 > > relations between entities (participants and devices). It=20 > > also includes handling more dynamic relationships, such as=20 > > identifying the audio and video streams for the current=20 > > speaker. The scope includes both systems that provide a fully=20 > > immersive experience, and systems that interwork with them=20 > > and therefore need to understand the same multiple stream=20 > semantics. =20 > >=20 > > =20 > >=20 > > The focus of this work is on multiple audio and video=20 > > streams. Other media types may be considered, however=20 > > development of methodologies for them is not within the scope=20 > > of this work. > >=20 > > =20 > >=20 > > Interoperation with standards compliant systems is required,=20 > > such as SIP-based video conferencing systems. However,=20 > > backwards compatibility with existing non-standards compliant=20 > > telepresence systems is not required. > >=20 > > =20 > >=20 > > This working group is not currently chartered to work on=20 > > issues of continuous conference control including: far end=20 > > camera control, indication of fast frame update for video=20 > > codecs or other rapid switches, floor control, conference roster.=20 > >=20 > > =20 > >=20 > > Re-use of existing protocols and backwards compatibility with=20 > > existing systems is an important factor for the working group=20 > > to consider. The work will closely coordinate with the=20 > > appropriate areas and working groups including OPS Area, AVT,=20 > > MMUSIC, MEDIACTRL, XCON, and SIPCORE. > >=20 > > =20 > >=20 > > Milestones =20 > >=20 > > =20 > >=20 > > Nov 2010 Submit information draft to IESG on use cases and=20 > > requirements > >=20 > > =20 > >=20 > > Nov 2011 Submit standards track specification to IESG on indicating > >=20 > > spatial relationships of screens, cameras=20 > > (including variable > >=20 > > field of view and orientation), speakers and=20 > > microphones. This > >=20 > > includes, semantics, language and transport. > >=20 > > =20 > >=20 > > Apr 2011 Submit standards track specification to IESG on=20 > > indicating the > >=20 > > "usage" of a stream as define in charter. > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > >=20 >=20 From tme@americafree.tv Thu Aug 26 11:13:53 2010 Return-Path: <tme@americafree.tv> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A413A69D5 for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 11:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTSWovoyjrRq for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 11:13:48 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 587973A689E for <dispatch@ietf.org>; Thu, 26 Aug 2010 11:13:48 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id E3C7F89C2677; Thu, 26 Aug 2010 14:14:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks <tme@americafree.tv> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE8A5@xmb-sjc-221.amer.cisco.com> Date: Thu, 26 Aug 2010 14:14:18 -0400 Content-Transfer-Encoding: 7bit Message-Id: <36D05F94-0BD6-464F-B309-F6BB6BFBE352@americafree.tv> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> <A444A0F8084434499206E78C106220CA01C482C0DB@MCHP058A.global-ad.net> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE8A5@xmb-sjc-221.amer.cisco.com> To: "Allyn Romanow (allyn)" <allyn@cisco.com> X-Mailer: Apple Mail (2.1081) Cc: IETF DISPATCH list <dispatch@ietf.org> Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Aug 2010 18:13:54 -0000 WFN - in fact, I really like this. Marshall On Aug 26, 2010, at 12:36 PM, Allyn Romanow (allyn) wrote: > > Hi John, > Good catch. I thought we had done this earlier, but it isn't there now. > > How is this text? > > > The WG will create specifications for SIP-based conferencing systems to > enable communication of > enough information about each media stream so that each > receiving system or bridge system can make reasonable > decisions about selecting and rendering media streams. This > enables systems to make display choices that optimize the > "just like being there" experience. > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Thursday, August 26, 2010 12:27 AM >> To: Allyn Romanow (allyn); DISPATCH list >> Subject: RE: Telepresence Charter Version 3 >> >> Allyn, >> >> Should it be made clear that the work should be based on >> SIP/SDP (+RTP/H.264, of course)? Since both SIP and H.323 are >> mentioned in the second paragraph, the only CLUE to the work >> being SIP/SDP-based is the mention of SIPCORE and MMUSIC later. >> >> John >> >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn >> Romanow (allyn) >>> Sent: 25 August 2010 23:09 >>> To: DISPATCH list >>> Subject: [dispatch] Telepresence Charter Version 3 >>> >>> Folks, here is the 3rd version of the charter. >>> >>> >>> >>> * It incorporates a number of useful editing comments. >>> >>> * The substantive issue on this draft concerned what >>> was meant by >>> >>> "Also not in scope is signaling to tell the originator to which >>> receivers the media streams should be sent." >>> >>> >>> >>> After further discussion with Peter and Steve, the main >> discussants on >>> this, I've added to the list of what is included >>> >>> >>> >>> *Which sources a receiver wants to receive. For example, it might >>> want the source for the left camera, or might want the >> source chosen >>> by VAD (Voice Activity Detection). >>> >>> >>> >>> We interpreted the out of scope sentence to mean >>> >>> "Also not in scope is signaling to tell the originator to which IP >>> addresses the media streams should be sent." >>> >>> >>> >>> While this seemed okay, it was felt to be unnecessary. So >> it was left >>> out of this version. >>> >>> >>> >>> Thus we think we have "in" what counts - that the receiver >> might need >>> to say which of several RTP streams it wants to receive. And if >>> someone has something they want to exclude could they >> please try again >>> to describe it? >>> >>> >>> >>> OH- and for a name. How about CLUE? >>> >>> >>> >>> Comments? >>> >>> >>> >>> Allyn >>> >>> >>> >>> >>> >>> Charter >>> >>> CLUE ControLling mUltiple streams for TElepresence >>> >>> or >>> >>> MUSCAT: MUlti-Stream Control Applied to Telepresence >>> >>> >>> >>> >>> >>> In the context of this WG, the term telepresence is used in >> a general >>> manner to describe systems that provide high definition, >> high quality >>> audio/video enabling a "being-there" >>> experience. One example is an immersive telepresence system using >>> specially designed and special purpose rooms with multiple displays >>> permitting life size image reproduction using multiple cameras, >>> encoders, decoders,microphones and loudspeakers. >>> >>> >>> >>> Current telepresence systems are based on open standards such >>> as RTP, SIP, H.264, the H.323 suite, however, they cannot >>> easily interoperate with each other without operator >>> assistance and expensive additional equipment which >>> translates from one vendor to another. A major factor in the >>> inability of telepresence systems to interwork is that there >>> is no standardized way to describe and negotiate the use of >>> the multiple streams of audio and video that comprise the >>> media flows. In addition, there is no standardized way to >>> exchange semantic information about what each media stream >>> represents. >>> >>> >>> >>> The WG will create specifications to enable communication of >>> enough information about each media stream so that each >>> receiving system or bridge system can make reasonable >>> decisions about selecting and rendering media streams. This >>> enables systems to make display choices that optimize the >>> "just like being there" experience. >>> >>> >>> >>> This working group is chartered to specify the information >>> about media streams from one endpoint to another endpoint or >>> conference bridge including: >>> >>> >>> >>> * Spatial relationships of cameras, displays, microphones, and >>> >>> speakers in relation to each other and to likely positions of >>> >>> participants >>> >>> >>> >>> * Specific characteristics such as viewpoint, field of view/capture >>> >>> for camera/microphone/display/speaker so that senders and >>> >>> >>> middleboxes can understand how best to compose streams for >>> >>> receivers and the receivers will know the characteristics of its >>> >>> received streams >>> >>> >>> >>> * Aspect ratio of cameras and displays >>> >>> >>> >>> * Which sources a receiver wants to receive. For example, it >>> might want the source for the left camera, or might want the >>> source chosen by VAD (Voice Activity Detection). >>> >>> >>> >>> >>> >>> Information between sources and sinks about media stream >>> capabilities will be exchanged. >>> >>> >>> >>> The working group will define the semantics, syntax, and >>> transport mechanism necessary for communicating the necessary >>> information. It will consider whether the existing signaling >>> mechanisms (e. g., SDP, BFCP) can be extended, or another >>> messaging method should be used. >>> >>> >>> >>> The scope of the work includes describing relatively static >>> relations between entities (participants and devices). It >>> also includes handling more dynamic relationships, such as >>> identifying the audio and video streams for the current >>> speaker. The scope includes both systems that provide a fully >>> immersive experience, and systems that interwork with them >>> and therefore need to understand the same multiple stream >> semantics. >>> >>> >>> >>> The focus of this work is on multiple audio and video >>> streams. Other media types may be considered, however >>> development of methodologies for them is not within the scope >>> of this work. >>> >>> >>> >>> Interoperation with standards compliant systems is required, >>> such as SIP-based video conferencing systems. However, >>> backwards compatibility with existing non-standards compliant >>> telepresence systems is not required. >>> >>> >>> >>> This working group is not currently chartered to work on >>> issues of continuous conference control including: far end >>> camera control, indication of fast frame update for video >>> codecs or other rapid switches, floor control, conference roster. >>> >>> >>> >>> Re-use of existing protocols and backwards compatibility with >>> existing systems is an important factor for the working group >>> to consider. The work will closely coordinate with the >>> appropriate areas and working groups including OPS Area, AVT, >>> MMUSIC, MEDIACTRL, XCON, and SIPCORE. >>> >>> >>> >>> Milestones >>> >>> >>> >>> Nov 2010 Submit information draft to IESG on use cases and >>> requirements >>> >>> >>> >>> Nov 2011 Submit standards track specification to IESG on indicating >>> >>> spatial relationships of screens, cameras >>> (including variable >>> >>> field of view and orientation), speakers and >>> microphones. This >>> >>> includes, semantics, language and transport. >>> >>> >>> >>> Apr 2011 Submit standards track specification to IESG on >>> indicating the >>> >>> "usage" of a stream as define in charter. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From john.elwell@siemens-enterprise.com Thu Aug 26 11:24:20 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20EEA3A689E for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 11:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.737 X-Spam-Level: X-Spam-Status: No, score=-102.737 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD-uV6fM7XPX for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 11:24:18 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3B5EF3A6826 for <dispatch@ietf.org>; Thu, 26 Aug 2010 11:24:17 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1300460; Thu, 26 Aug 2010 20:24:29 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 844D21EB82AB; Thu, 26 Aug 2010 20:24:29 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 26 Aug 2010 20:24:29 +0200 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: "Allyn Romanow (allyn)" <allyn@cisco.com> Date: Thu, 26 Aug 2010 20:24:28 +0200 Thread-Topic: [dispatch] Telepresence Charter Version 3 Thread-Index: ActFSoJWkOqvT7KfQq+Gh+9t2H2CaAAAV2zQ Message-ID: <A444A0F8084434499206E78C106220CA01C4873D29@MCHP058A.global-ad.net> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> <A444A0F8084434499206E78C106220CA01C482C0DB@MCHP058A.global-ad.net> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE8A5@xmb-sjc-221.amer.cisco.com> <36D05F94-0BD6-464F-B309-F6BB6BFBE352@americafree.tv> In-Reply-To: <36D05F94-0BD6-464F-B309-F6BB6BFBE352@americafree.tv> 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: IETF DISPATCH list <dispatch@ietf.org> Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Aug 2010 18:24:20 -0000 That's fine. John =20 > -----Original Message----- > From: Marshall Eubanks [mailto:tme@americafree.tv]=20 > Sent: 26 August 2010 19:14 > To: Allyn Romanow (allyn) > Cc: Elwell, John; IETF DISPATCH list > Subject: Re: [dispatch] Telepresence Charter Version 3 >=20 > WFN - in fact, I really like this. >=20 > Marshall >=20 > On Aug 26, 2010, at 12:36 PM, Allyn Romanow (allyn) wrote: >=20 > >=20 > > Hi John, > > Good catch. I thought we had done this earlier, but it=20 > isn't there now. > >=20 > > How is this text? > >=20 > >=20 > > The WG will create specifications for SIP-based=20 > conferencing systems to > > enable communication of=20 > > enough information about each media stream so that each=20 > > receiving system or bridge system can make reasonable=20 > > decisions about selecting and rendering media streams. This=20 > > enables systems to make display choices that optimize the=20 > > "just like being there" experience.=20 > >=20 > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > >> Sent: Thursday, August 26, 2010 12:27 AM > >> To: Allyn Romanow (allyn); DISPATCH list > >> Subject: RE: Telepresence Charter Version 3 > >>=20 > >> Allyn, > >>=20 > >> Should it be made clear that the work should be based on=20 > >> SIP/SDP (+RTP/H.264, of course)? Since both SIP and H.323 are=20 > >> mentioned in the second paragraph, the only CLUE to the work=20 > >> being SIP/SDP-based is the mention of SIPCORE and MMUSIC later. > >>=20 > >> John > >>=20 > >>=20 > >>> -----Original Message----- > >>> From: dispatch-bounces@ietf.org > >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn=20 > >> Romanow (allyn) > >>> Sent: 25 August 2010 23:09 > >>> To: DISPATCH list > >>> Subject: [dispatch] Telepresence Charter Version 3 > >>>=20 > >>> Folks, here is the 3rd version of the charter. > >>>=20 > >>>=20 > >>>=20 > >>> * It incorporates a number of useful editing comments. > >>>=20 > >>> * The substantive issue on this draft concerned what=20 > >>> was meant by > >>>=20 > >>> "Also not in scope is signaling to tell the originator to which=20 > >>> receivers the media streams should be sent." > >>>=20 > >>>=20 > >>>=20 > >>> After further discussion with Peter and Steve, the main=20 > >> discussants on=20 > >>> this, I've added to the list of what is included > >>>=20 > >>>=20 > >>>=20 > >>> *Which sources a receiver wants to receive. For example,=20 > it might=20 > >>> want the source for the left camera, or might want the=20 > >> source chosen=20 > >>> by VAD (Voice Activity Detection). > >>>=20 > >>>=20 > >>>=20 > >>> We interpreted the out of scope sentence to mean > >>>=20 > >>> "Also not in scope is signaling to tell the originator to=20 > which IP=20 > >>> addresses the media streams should be sent." > >>>=20 > >>>=20 > >>>=20 > >>> While this seemed okay, it was felt to be unnecessary. So=20 > >> it was left=20 > >>> out of this version. > >>>=20 > >>>=20 > >>>=20 > >>> Thus we think we have "in" what counts - that the receiver=20 > >> might need=20 > >>> to say which of several RTP streams it wants to receive. And if=20 > >>> someone has something they want to exclude could they=20 > >> please try again=20 > >>> to describe it? > >>>=20 > >>>=20 > >>>=20 > >>> OH- and for a name. How about CLUE?=20 > >>>=20 > >>>=20 > >>>=20 > >>> Comments? > >>>=20 > >>>=20 > >>>=20 > >>> Allyn > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> Charter > >>>=20 > >>> CLUE ControLling mUltiple streams for TElepresence > >>>=20 > >>> or > >>>=20 > >>> MUSCAT: MUlti-Stream Control Applied to Telepresence > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> In the context of this WG, the term telepresence is used in=20 > >> a general=20 > >>> manner to describe systems that provide high definition,=20 > >> high quality=20 > >>> audio/video enabling a "being-there" > >>> experience. One example is an immersive telepresence=20 > system using=20 > >>> specially designed and special purpose rooms with=20 > multiple displays=20 > >>> permitting life size image reproduction using multiple cameras,=20 > >>> encoders, decoders,microphones and loudspeakers. > >>>=20 > >>>=20 > >>>=20 > >>> Current telepresence systems are based on open standards such=20 > >>> as RTP, SIP, H.264, the H.323 suite, however, they cannot=20 > >>> easily interoperate with each other without operator=20 > >>> assistance and expensive additional equipment which=20 > >>> translates from one vendor to another. A major factor in the=20 > >>> inability of telepresence systems to interwork is that there=20 > >>> is no standardized way to describe and negotiate the use of=20 > >>> the multiple streams of audio and video that comprise the=20 > >>> media flows. In addition, there is no standardized way to=20 > >>> exchange semantic information about what each media stream=20 > >>> represents. =20 > >>>=20 > >>>=20 > >>>=20 > >>> The WG will create specifications to enable communication of=20 > >>> enough information about each media stream so that each=20 > >>> receiving system or bridge system can make reasonable=20 > >>> decisions about selecting and rendering media streams. This=20 > >>> enables systems to make display choices that optimize the=20 > >>> "just like being there" experience.=20 > >>>=20 > >>>=20 > >>>=20 > >>> This working group is chartered to specify the information=20 > >>> about media streams from one endpoint to another endpoint or=20 > >>> conference bridge including: > >>>=20 > >>>=20 > >>>=20 > >>> * Spatial relationships of cameras, displays, microphones, and > >>>=20 > >>> speakers in relation to each other and to likely positions of > >>>=20 > >>> participants > >>>=20 > >>>=20 > >>>=20 > >>> * Specific characteristics such as viewpoint, field of=20 > view/capture > >>>=20 > >>> for camera/microphone/display/speaker so that senders and =20 > >>>=20 > >>>=20 > >>> middleboxes can understand how best to compose streams for > >>>=20 > >>> receivers and the receivers will know the characteristics of its=20 > >>>=20 > >>> received streams > >>>=20 > >>>=20 > >>>=20 > >>> * Aspect ratio of cameras and displays > >>>=20 > >>>=20 > >>>=20 > >>> * Which sources a receiver wants to receive. For example, it=20 > >>> might want the source for the left camera, or might want the=20 > >>> source chosen by VAD (Voice Activity Detection). > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> Information between sources and sinks about media stream=20 > >>> capabilities will be exchanged.=20 > >>>=20 > >>>=20 > >>>=20 > >>> The working group will define the semantics, syntax, and=20 > >>> transport mechanism necessary for communicating the necessary=20 > >>> information. It will consider whether the existing signaling=20 > >>> mechanisms (e. g., SDP, BFCP) can be extended, or another=20 > >>> messaging method should be used. =20 > >>>=20 > >>>=20 > >>>=20 > >>> The scope of the work includes describing relatively static=20 > >>> relations between entities (participants and devices). It=20 > >>> also includes handling more dynamic relationships, such as=20 > >>> identifying the audio and video streams for the current=20 > >>> speaker. The scope includes both systems that provide a fully=20 > >>> immersive experience, and systems that interwork with them=20 > >>> and therefore need to understand the same multiple stream=20 > >> semantics. =20 > >>>=20 > >>>=20 > >>>=20 > >>> The focus of this work is on multiple audio and video=20 > >>> streams. Other media types may be considered, however=20 > >>> development of methodologies for them is not within the scope=20 > >>> of this work. > >>>=20 > >>>=20 > >>>=20 > >>> Interoperation with standards compliant systems is required,=20 > >>> such as SIP-based video conferencing systems. However,=20 > >>> backwards compatibility with existing non-standards compliant=20 > >>> telepresence systems is not required. > >>>=20 > >>>=20 > >>>=20 > >>> This working group is not currently chartered to work on=20 > >>> issues of continuous conference control including: far end=20 > >>> camera control, indication of fast frame update for video=20 > >>> codecs or other rapid switches, floor control, conference roster.=20 > >>>=20 > >>>=20 > >>>=20 > >>> Re-use of existing protocols and backwards compatibility with=20 > >>> existing systems is an important factor for the working group=20 > >>> to consider. The work will closely coordinate with the=20 > >>> appropriate areas and working groups including OPS Area, AVT,=20 > >>> MMUSIC, MEDIACTRL, XCON, and SIPCORE. > >>>=20 > >>>=20 > >>>=20 > >>> Milestones =20 > >>>=20 > >>>=20 > >>>=20 > >>> Nov 2010 Submit information draft to IESG on use cases and=20 > >>> requirements > >>>=20 > >>>=20 > >>>=20 > >>> Nov 2011 Submit standards track specification to IESG on=20 > indicating > >>>=20 > >>> spatial relationships of screens, cameras=20 > >>> (including variable > >>>=20 > >>> field of view and orientation), speakers and=20 > >>> microphones. This > >>>=20 > >>> includes, semantics, language and transport. > >>>=20 > >>>=20 > >>>=20 > >>> Apr 2011 Submit standards track specification to IESG on=20 > >>> indicating the > >>>=20 > >>> "usage" of a stream as define in charter. > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 > = From allyn@cisco.com Thu Aug 26 15:38:50 2010 Return-Path: <allyn@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C789F3A68D8 for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 15:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.454 X-Spam-Level: X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5b3perK7Uq9 for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 15:38:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 15CEB3A6837 for <dispatch@ietf.org>; Thu, 26 Aug 2010 15:38:48 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO2JdkyrR7Hu/2dsb2JhbACgU3GjO5wAhTcEhDqIPg X-IronPort-AV: E=Sophos;i="4.56,276,1280707200"; d="scan'208";a="579355629" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 26 Aug 2010 22:39:20 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7QMdKFK016233; Thu, 26 Aug 2010 22:39:20 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 15:39:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Aug 2010 15:39:19 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FEB21@xmb-sjc-221.amer.cisco.com> In-Reply-To: <5141CABF-6718-40AD-8BB8-38B4938FBB1A@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Telepresence Charter Version 3 Thread-Index: ActFNuVOJfX41wneSPW4t8iSNZv3WAANuYIA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> <5141CABF-6718-40AD-8BB8-38B4938FBB1A@cisco.com> From: "Allyn Romanow (allyn)" <allyn@cisco.com> To: "Cullen Jennings (fluffy)" <fluffy@cisco.com> X-OriginalArrivalTime: 26 Aug 2010 22:39:20.0524 (UTC) FILETIME=[863110C0:01CB456F] Cc: DISPATCH list <dispatch@ietf.org> Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Aug 2010 22:38:51 -0000 Hi Cullen, In order to restrict the scope of the charter, how would it be to replace This working group is chartered to specify the information about media streams from one endpoint to another endpoint or conference bridge including: By your suggested sentence This working group is chartered to specify the following information about media streams from one endpoint to another endpoint: ? Allyn -----Original Message----- From: Cullen Jennings (fluffy)=20 Sent: Thursday, August 26, 2010 8:54 AM To: Allyn Romanow (allyn) Cc: DISPATCH list; Mary Barnes Subject: Re: Telepresence Charter Version 3 I think this charter has some pretty serious issues with being way to wide open on what the scope is. The fact we are actually discussing if we need to add in "Also not in scope is signaling to tell the originator to which IP addresses the media streams should be sent" should be a huge hint that we have the scope much too broad. As I said a week ago ....=20 Begin forwarded message: > From: Cullen Jennings <fluffy@cisco.com> > Date: August 18, 2010 11:16:22 AM MDT > Main point: > When I read this charter and ask myself what is out of scope, it seems that anything that is "the information about media streams from one endpoint to another endpoint or conference bridge including" would be in scope. I realize a few more things are taken our of scope later but the resulting space includes just about everything that MMUSIC does, and much of what SIP does. Because of the "anything and everything" approach I don't think this is a charter that will result in work that gets done quickly. From the point of view of being broad enough to do the need work, I think it's fine but from the point of view of being narrow enough to limit the work to something that is possible to complete, it seems pretty bad. I suspect that IESG would likely look at this as a "blank cheque" charter and ask for some changes to it. My suggestion would be just to change the "including (but not limited to):" in 3rd paragraph to be=20 >=20 > This working group is chartered to specify the following information about media streams from one endpoint to another endpoint: >=20 Note I am not arguing that there any given piece of work you should not do - I'm just encouraging you to say what problems you are going to do. I would encourage you to specify what this working group is going to do, like you have in the bullet points, and stop leaving it open to do anything including the stuff in bullet points. We should do our best to avoid charters that are so unspecific that they overlap with existing WGs in ways that leave huge questions about which WG a new piece of work should go to.=20 Cullen <with my DISPATCH co-chair hat on> From allyn@cisco.com Thu Aug 26 16:30:15 2010 Return-Path: <allyn@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60753A6835 for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 16:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AesMMWJbOiY for <dispatch@core3.amsl.com>; Thu, 26 Aug 2010 16:30:09 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C499E3A6407 for <dispatch@ietf.org>; Thu, 26 Aug 2010 16:30:07 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE+WdkyrR7Ht/2dsb2JhbACgVHGkI5wJhTcEhDqIPg X-IronPort-AV: E=Sophos;i="4.56,276,1280707200"; d="scan'208";a="235704544" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 26 Aug 2010 23:30:39 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7QNUdPr007102; Thu, 26 Aug 2010 23:30:39 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 16:30:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Aug 2010 16:30:38 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FEB70@xmb-sjc-221.amer.cisco.com> In-Reply-To: <5141CABF-6718-40AD-8BB8-38B4938FBB1A@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Telepresence Charter Version 3 Thread-Index: ActFNuVOJfX41wneSPW4t8iSNZv3WAAP3SZg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> <5141CABF-6718-40AD-8BB8-38B4938FBB1A@cisco.com> From: "Allyn Romanow (allyn)" <allyn@cisco.com> To: "Cullen Jennings (fluffy)" <fluffy@cisco.com> X-OriginalArrivalTime: 26 Aug 2010 23:30:39.0534 (UTC) FILETIME=[B16CB4E0:01CB4576] Cc: DISPATCH list <dispatch@ietf.org> Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Aug 2010 23:30:15 -0000 WRT my previous note suggesting the change to Cullen's sentence,=20 people should be clear that everything not in the charter is out of scope.=20 So please think about anything that you think we need to cover which is not now explicitly called out in the charter. thanks -----Original Message----- From: Cullen Jennings (fluffy)=20 Sent: Thursday, August 26, 2010 8:54 AM To: Allyn Romanow (allyn) Cc: DISPATCH list; Mary Barnes Subject: Re: Telepresence Charter Version 3 I think this charter has some pretty serious issues with being way to wide open on what the scope is. The fact we are actually discussing if we need to add in "Also not in scope is signaling to tell the originator to which IP addresses the media streams should be sent" should be a huge hint that we have the scope much too broad. As I said a week ago ....=20 Begin forwarded message: > From: Cullen Jennings <fluffy@cisco.com> > Date: August 18, 2010 11:16:22 AM MDT > Main point: > When I read this charter and ask myself what is out of scope, it seems that anything that is "the information about media streams from one endpoint to another endpoint or conference bridge including" would be in scope. I realize a few more things are taken our of scope later but the resulting space includes just about everything that MMUSIC does, and much of what SIP does. Because of the "anything and everything" approach I don't think this is a charter that will result in work that gets done quickly. From the point of view of being broad enough to do the need work, I think it's fine but from the point of view of being narrow enough to limit the work to something that is possible to complete, it seems pretty bad. I suspect that IESG would likely look at this as a "blank cheque" charter and ask for some changes to it. My suggestion would be just to change the "including (but not limited to):" in 3rd paragraph to be=20 >=20 > This working group is chartered to specify the following information about media streams from one endpoint to another endpoint: >=20 Note I am not arguing that there any given piece of work you should not do - I'm just encouraging you to say what problems you are going to do. I would encourage you to specify what this working group is going to do, like you have in the bullet points, and stop leaving it open to do anything including the stuff in bullet points. We should do our best to avoid charters that are so unspecific that they overlap with existing WGs in ways that leave huge questions about which WG a new piece of work should go to.=20 Cullen <with my DISPATCH co-chair hat on> From dwing@cisco.com Fri Aug 27 14:09:29 2010 Return-Path: <dwing@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED77B3A68DA for <dispatch@core3.amsl.com>; Fri, 27 Aug 2010 14:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.627 X-Spam-Level: X-Spam-Status: No, score=-110.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUGtw8TcsWbJ for <dispatch@core3.amsl.com>; Fri, 27 Aug 2010 14:09:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C16053A67B5 for <dispatch@ietf.org>; Fri, 27 Aug 2010 14:09:19 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,280,1280707200"; d="scan'208";a="246473653" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 27 Aug 2010 21:09:51 +0000 Received: from dwingWS ([10.21.78.156]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7RL9pUq004116; Fri, 27 Aug 2010 21:09:51 GMT From: "Dan Wing" <dwing@cisco.com> To: "'DISPATCH list'" <dispatch@ietf.org> Date: Fri, 27 Aug 2010 14:09:51 -0700 Message-ID: <06b201cb462c$30ade840$9209b8c0$@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: ActGLDB6zGp/AdvKRF6bxyeAj4GNPA== Content-Language: en-us Cc: 'Andrew Yourtchenko' <ayourtch@cisco.com> Subject: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Aug 2010 21:09:29 -0000 At IETF78 we had a Bar BoF discussing why folks don't like ICE for doing connectivity checks for dual-stack hosts. The outcome of this Bar BoF was an idea that Andrew and I wrote up, Abstract: During the migration from IPv4 to IPv6, it is anticipated that an IPv6 path might be broken for a variety of reasons, causing endpoints to not receive RTP data. Connectivity checks would detect and avoid the user noticing such a problem, but there is industry reluctance to implement connectivity checks. This document describes a mechanism allowing dual-stack SIP endpoints to attempt communications over IPv6 and fall back to IPv4 if the IPv6 path is not working. The mechanism does not require connectivity checks. http://tools.ietf.org/html/draft-wing-dispatch-v6-migration I didn't know where to best send this (MMUSIC did ICE, BEHAVE did ICE's connectivity checking protocols), so I'm trying DISPATCH because this is mostly about how dual-stack SIP endpoints can avoid IPv6 network breakage. Comments welcome. -d From rbarnes@bbn.com Fri Aug 27 14:45:34 2010 Return-Path: <rbarnes@bbn.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99503A683E for <dispatch@core3.amsl.com>; Fri, 27 Aug 2010 14:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+15GjsiN6xA for <dispatch@core3.amsl.com>; Fri, 27 Aug 2010 14:45:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 974853A6828 for <dispatch@ietf.org>; Fri, 27 Aug 2010 14:45:33 -0700 (PDT) Received: from [128.89.253.212] (port=63117 helo=[172.27.16.50]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Op6kP-0002hj-Kv; Fri, 27 Aug 2010 17:46:05 -0400 Message-Id: <AFE30F4B-6226-4931-ACA4-F320B649063D@bbn.com> From: "Richard L. Barnes" <rbarnes@bbn.com> To: Dan Wing <dwing@cisco.com> In-Reply-To: <06b201cb462c$30ade840$9209b8c0$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 27 Aug 2010 17:46:05 -0400 References: <06b201cb462c$30ade840$9209b8c0$@com> X-Mailer: Apple Mail (2.936) Cc: 'DISPATCH list' <dispatch@ietf.org>, 'Andrew Yourtchenko' <ayourtch@cisco.com> Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Aug 2010 21:45:34 -0000 > This document describes a mechanism allowing dual-stack SIP > endpoints > to attempt communications over IPv6 and fall back to IPv4 if the > IPv6 > path is not working. The mechanism does not require connectivity > checks. Possibly dumb question: Isn't trying IPv6 and falling back to IPv4 effectively a connectivity check? --Richard From dwing@cisco.com Fri Aug 27 17:15:19 2010 Return-Path: <dwing@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613873A676A for <dispatch@core3.amsl.com>; Fri, 27 Aug 2010 17:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.625 X-Spam-Level: X-Spam-Status: No, score=-110.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmQqgbkOgfM8 for <dispatch@core3.amsl.com>; Fri, 27 Aug 2010 17:15:15 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 21D3D3A677C for <dispatch@ietf.org>; Fri, 27 Aug 2010 17:15:14 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,281,1280707200"; d="scan'208";a="356029378" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 28 Aug 2010 00:15:46 +0000 Received: from dwingWS (sjc-vpn6-1359.cisco.com [10.21.125.79]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o7S0FkOw021289; Sat, 28 Aug 2010 00:15:46 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Richard L. Barnes'" <rbarnes@bbn.com> References: <06b201cb462c$30ade840$9209b8c0$@com> <AFE30F4B-6226-4931-ACA4-F320B649063D@bbn.com> In-Reply-To: <AFE30F4B-6226-4931-ACA4-F320B649063D@bbn.com> Date: Fri, 27 Aug 2010 17:15:46 -0700 Message-ID: <070b01cb4646$295b5ea0$7c121be0$@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: ActGMVaScDkzPWHbTUyXYTtvTwMnlAAFKxBw Content-Language: en-us Cc: 'DISPATCH list' <dispatch@ietf.org>, 'Andrew Yourtchenko' <ayourtch@cisco.com> Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 28 Aug 2010 00:15:19 -0000 > > This document describes a mechanism allowing dual-stack SIP > > endpoints > > to attempt communications over IPv6 and fall back to IPv4 if the > > IPv6 > > path is not working. The mechanism does not require connectivity > > checks. > > Possibly dumb question: Isn't trying IPv6 and falling back to IPv4 > effectively a connectivity check? "Connectivity check" is what ICE does, with a STUN request/response exchange. This does something less. I call it "not a connectivity check"; if there is a better term, I'm game to change the terminology. -d From fluffy@cisco.com Sat Aug 28 06:27:13 2010 Return-Path: <fluffy@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1303A6827 for <dispatch@core3.amsl.com>; Sat, 28 Aug 2010 06:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.348 X-Spam-Level: X-Spam-Status: No, score=-110.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybj6AtUA0NK0 for <dispatch@core3.amsl.com>; Sat, 28 Aug 2010 06:27:12 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 031DE3A6826 for <dispatch@ietf.org>; Sat, 28 Aug 2010 06:27:12 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,283,1280707200"; d="scan'208";a="246618365" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 28 Aug 2010 13:27:44 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7SDRg6o024025; Sat, 28 Aug 2010 13:27:42 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings <fluffy@cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FEB21@xmb-sjc-221.amer.cisco.com> Date: Sat, 28 Aug 2010 07:27:42 -0600 Content-Transfer-Encoding: 7bit Message-Id: <752D7A28-0F54-445B-BA89-C2C67B754B4E@cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> <5141CABF-6718-40AD-8BB8-38B4938FBB1A@cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FEB21@xmb-sjc-221.amer.cisco.com> To: Allyn Romanow (allyn) <allyn@cisco.com> X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list <dispatch@ietf.org> Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 28 Aug 2010 13:27:13 -0000 Yah, I think that would solve my biggest concern about it. On Aug 26, 2010, at 4:39 PM, Allyn Romanow (allyn) wrote: > Hi Cullen, > > In order to restrict the scope of the charter, how would it be to > replace > > This working group is chartered to specify the information about > media streams from one endpoint to another endpoint or conference > bridge including: > > By your suggested sentence > > This working group is chartered to specify the following > information about media streams from one endpoint to another > endpoint: > ? > > > > > Allyn > > -----Original Message----- > From: Cullen Jennings (fluffy) > Sent: Thursday, August 26, 2010 8:54 AM > To: Allyn Romanow (allyn) > Cc: DISPATCH list; Mary Barnes > Subject: Re: Telepresence Charter Version 3 > > > I think this charter has some pretty serious issues with being way to > wide open on what the scope is. The fact we are actually discussing if > we need to add in "Also not in scope is signaling to tell the > originator to which IP addresses the media streams should be sent" > should be a huge hint that we have the scope much too broad. As I said a > week ago .... > > Begin forwarded message: > >> From: Cullen Jennings <fluffy@cisco.com> >> Date: August 18, 2010 11:16:22 AM MDT > >> Main point: >> When I read this charter and ask myself what is out of scope, it seems > that anything that is "the information about media streams from one > endpoint to another endpoint or conference bridge including" would be in > scope. I realize a few more things are taken our of scope later but the > resulting space includes just about everything that MMUSIC does, and > much of what SIP does. Because of the "anything and everything" approach > I don't think this is a charter that will result in work that gets done > quickly. From the point of view of being broad enough to do the need > work, I think it's fine but from the point of view of being narrow > enough to limit the work to something that is possible to complete, it > seems pretty bad. I suspect that IESG would likely look at this as a > "blank cheque" charter and ask for some changes to it. My suggestion > would be just to change the "including (but not limited to):" in 3rd > paragraph to be >> >> This working group is chartered to specify the following information > about media streams from one endpoint to another endpoint: >> > > Note I am not arguing that there any given piece of work you should not > do - I'm just encouraging you to say what problems you are going to do. > > I would encourage you to specify what this working group is going to do, > like you have in the bullet points, and stop leaving it open to do > anything including the stuff in bullet points. We should do our best to > avoid charters that are so unspecific that they overlap with existing > WGs in ways that leave huge questions about which WG a new piece of work > should go to. > > Cullen <with my DISPATCH co-chair hat on> > > Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From rbarnes@bbn.com Sat Aug 28 07:19:29 2010 Return-Path: <rbarnes@bbn.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EFD3A68EC for <dispatch@core3.amsl.com>; Sat, 28 Aug 2010 07:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmq-bAidPHta for <dispatch@core3.amsl.com>; Sat, 28 Aug 2010 07:19:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 7BD063A6869 for <dispatch@ietf.org>; Sat, 28 Aug 2010 07:19:28 -0700 (PDT) Received: from [128.89.254.55] (port=63611 helo=[172.27.16.50]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1OpMGF-0001su-T9; Sat, 28 Aug 2010 10:20:00 -0400 Message-Id: <2BF8C828-2BE1-42A1-AE7D-402D78568FE6@bbn.com> From: "Richard L. Barnes" <rbarnes@bbn.com> To: "Dan Wing" <dwing@cisco.com> In-Reply-To: <070b01cb4646$295b5ea0$7c121be0$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 28 Aug 2010 10:19:58 -0400 References: <06b201cb462c$30ade840$9209b8c0$@com> <AFE30F4B-6226-4931-ACA4-F320B649063D@bbn.com> <070b01cb4646$295b5ea0$7c121be0$@com> X-Mailer: Apple Mail (2.936) Cc: 'DISPATCH list' <dispatch@ietf.org>, 'Andrew Yourtchenko' <ayourtch@cisco.com> Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 28 Aug 2010 14:19:29 -0000 Ok, I get that "connectivity check" is a reserved word for ICE. But I'm still not understanding how you're going to do thing more efficiently. Looking at Figure 3 in RFC 5245, it looks like a connectivity check on a candidate pair (i.e., the peers IPv6 addresses) is four packets, two request/response pairs. Are people really complaining about one RTT of latency, or is there something extra I'm missing here? Now that I've read the draft, a couple of specific comments: -- It seems like you're just trading bandwidth for latency. Are the people complaining about a 1 RTT delay going to tolerate a doubling of bandwidth or a risk of loss (in the sharing scheme)? -- Your technique covers the case where IPv6 works but not IPv4, but the narrative text doesn't mention it (there are really 16 cases: 2 peers x 2 directions x 2 protocols x 2 states -- 15 if you ignore the case where nothing works :) ) --Richard On Aug 27, 2010, at 8:15 PM, Dan Wing wrote: >>> This document describes a mechanism allowing dual-stack SIP >>> endpoints >>> to attempt communications over IPv6 and fall back to IPv4 if the >>> IPv6 >>> path is not working. The mechanism does not require connectivity >>> checks. >> >> Possibly dumb question: Isn't trying IPv6 and falling back to IPv4 >> effectively a connectivity check? > > "Connectivity check" is what ICE does, with a STUN request/response > exchange. This does something less. I call it "not a connectivity > check"; if there is a better term, I'm game to change the terminology. > > -d > > From dwing@cisco.com Sun Aug 29 21:38:55 2010 Return-Path: <dwing@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEEB03A691D for <dispatch@core3.amsl.com>; Sun, 29 Aug 2010 21:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.276 X-Spam-Level: X-Spam-Status: No, score=-110.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fHGUfg4qhhG for <dispatch@core3.amsl.com>; Sun, 29 Aug 2010 21:38:50 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 189623A691B for <dispatch@ietf.org>; Sun, 29 Aug 2010 21:38:49 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,290,1280707200"; d="scan'208";a="178656158" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 30 Aug 2010 04:39:20 +0000 Received: from dwingWS (sjc-vpn6-660.cisco.com [10.21.122.148]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7U4dK8j010264; Mon, 30 Aug 2010 04:39:20 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Richard L. Barnes'" <rbarnes@bbn.com> References: <06b201cb462c$30ade840$9209b8c0$@com> <AFE30F4B-6226-4931-ACA4-F320B649063D@bbn.com> <070b01cb4646$295b5ea0$7c121be0$@com> <2BF8C828-2BE1-42A1-AE7D-402D78568FE6@bbn.com> In-Reply-To: <2BF8C828-2BE1-42A1-AE7D-402D78568FE6@bbn.com> Date: Sun, 29 Aug 2010 21:39:20 -0700 Message-ID: <08d201cb47fd$4ff62320$efe26960$@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: ActGvBwiNPnfbk1OTOay08yvBt+jFgBQAoZg Content-Language: en-us Cc: 'DISPATCH list' <dispatch@ietf.org>, 'Andrew Yourtchenko' <ayourtch@cisco.com> Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 30 Aug 2010 04:38:55 -0000 > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com] > Sent: Saturday, August 28, 2010 7:20 AM > To: Dan Wing > Cc: 'DISPATCH list'; 'Andrew Yourtchenko' > Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without > Connectivity Checks > > Ok, I get that "connectivity check" is a reserved word for ICE. But > I'm still not understanding how you're going to do thing more > efficiently. Looking at Figure 3 in RFC 5245, it looks like a > connectivity check on a candidate pair (i.e., the peers IPv6 > addresses) is four packets, two request/response pairs. Are people > really complaining about one RTT of latency, or is there something > extra I'm missing here? At the Bar BoF in Masstrict, nobody mentioned the round trip. The round trip isn't a problem, anyway -- due to how calls are set up and when ICE messages are sent, the connectivity round trip can be performed without delaying call setup or delaying ringing. The complaints, as I heard them, were as described in the I-D: "However, ICE is considered overkill for the problem of migrating to IPv6 because of the overhead of timers, interaction with existing media state machines, and CPU impact of SHA1 on large devices processing many sessions and on small devices." The purpose of the I-D is not to bash ICE, nor to agree with the reasons ICE has not (yet) enjoyed significant deployment. Rather, the world is running out of IPv4 addresses, and a lot of networks are transitioning to IPv6. It is important that, during that transition, we don't cause a worse user experience with dual-stack endpoints compared to IPv4-only endpoints. Otherwise users will blame their failed calls on IPv6 when they notice an IPv4-only endpoint (on the same network) working fine. > Now that I've read the draft, a couple of specific comments: > > -- It seems like you're just trading bandwidth for latency. Are the > people complaining about a 1 RTT delay going to tolerate a doubling of > bandwidth or a risk of loss (in the sharing scheme)? I don't know. That's why I wrote this I-D -- to initiate discussion. There is a "Note:" in the draft that mentions another technique that does not double bandwidth, in which nn% of packets are sent over IPvX and the others are sent over IPvY. > -- Your technique covers the case where IPv6 works but not IPv4, but > the narrative text doesn't mention it (there are really 16 cases: 2 > peers x 2 directions x 2 protocols x 2 states -- 15 if you ignore the > case where nothing works :) ) We can make things more complex and deal with RTP, RTCP, IPv4 failing (but IPv6 working), and so on. But keeping the initial draft simple so everyone can get their heads around it seemed most critical when I wrote it. And the combinations grow even faster when considering audio+video, or audio+video+screensharing. -d > --Richard > > > On Aug 27, 2010, at 8:15 PM, Dan Wing wrote: > > >>> This document describes a mechanism allowing dual-stack SIP > >>> endpoints > >>> to attempt communications over IPv6 and fall back to IPv4 if the > >>> IPv6 > >>> path is not working. The mechanism does not require connectivity > >>> checks. > >> > >> Possibly dumb question: Isn't trying IPv6 and falling back to IPv4 > >> effectively a connectivity check? > > > > "Connectivity check" is what ICE does, with a STUN request/response > > exchange. This does something less. I call it "not a connectivity > > check"; if there is a better term, I'm game to change the > terminology. > > > > -d > > > > From kpfleming@digium.com Mon Aug 30 06:22:12 2010 Return-Path: <kpfleming@digium.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84ACB3A680B for <dispatch@core3.amsl.com>; Mon, 30 Aug 2010 06:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njLfg1vjKovV for <dispatch@core3.amsl.com>; Mon, 30 Aug 2010 06:22:11 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 1DDA13A680A for <dispatch@ietf.org>; Mon, 30 Aug 2010 06:22:11 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from <kpfleming@digium.com>) id 1Oq4Jt-0003X7-Pm; Mon, 30 Aug 2010 08:22:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id B239BD8195; Mon, 30 Aug 2010 08:22:41 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8dBi45F0J3X; Mon, 30 Aug 2010 08:22:41 -0500 (CDT) Received: from [172.19.1.105] (173-24-201-108.client.mchsi.com [173.24.201.108]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id DC34CD8194; Mon, 30 Aug 2010 08:22:40 -0500 (CDT) Message-ID: <4C7BB09F.8020302@digium.com> Date: Mon, 30 Aug 2010 08:22:39 -0500 From: "Kevin P. Fleming" <kpfleming@digium.com> Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Dan Wing <dwing@cisco.com> References: <06b201cb462c$30ade840$9209b8c0$@com> In-Reply-To: <06b201cb462c$30ade840$9209b8c0$@com> X-Enigmail-Version: 1.0.1 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'DISPATCH list' <dispatch@ietf.org>, 'Andrew Yourtchenko' <ayourtch@cisco.com> Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 30 Aug 2010 13:22:12 -0000 On 08/27/2010 04:09 PM, Dan Wing wrote: > At IETF78 we had a Bar BoF discussing why folks don't like ICE for doing > connectivity checks for dual-stack hosts. The outcome of this Bar BoF was > an idea that Andrew and I wrote up, > > Abstract: > During the migration from IPv4 to IPv6, it is anticipated that an > IPv6 path might be broken for a variety of reasons, causing endpoints > to not receive RTP data. Connectivity checks would detect and avoid > the user noticing such a problem, but there is industry reluctance to > implement connectivity checks. > > This document describes a mechanism allowing dual-stack SIP endpoints > to attempt communications over IPv6 and fall back to IPv4 if the IPv6 > path is not working. The mechanism does not require connectivity > checks. > > http://tools.ietf.org/html/draft-wing-dispatch-v6-migration > > I didn't know where to best send this (MMUSIC did ICE, BEHAVE did ICE's > connectivity checking protocols), so I'm trying DISPATCH because this is > mostly about how dual-stack SIP endpoints can avoid IPv6 network breakage. For SIP servers that are controlling media gateway devices, this could be rather hard to implement. When media gateway devices are upgraded to support IPv6, they'll be dual-stack like the controlling entity, which is adequate to be able to send and receive media streams over IPv6. However, in my experience dealing with media gateways, they generally do *not* have the ability to direct a media stream to two destinations simultaneously unless a conference bridge of some sort is involved... and that will result in the two streams being independent (thus having different sequence numbers and timestamps). It's already going to be hard enough to get STUN support implemented in gateways so that SIP servers can use them to do ICE connectivity checks; this seems like it would be even more work for gateway implementors to build, not less. I can sympathize with the desire to have a simpler mechanism for doing *only* v4/v6 path selection, but since either method will require implementors of media endpoints to develop the required support, I'd rather push them towards implementing STUN. The SHA-1 overhead for a few packets at the beginning of a session seems (to me, anyway) to be far less CPU burden than the low bitrate codec (or modem) that the gateway will eventually be operating on that channel anyway. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From partr@cisco.com Mon Aug 30 09:51:03 2010 Return-Path: <partr@cisco.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B4D3A6837; Mon, 30 Aug 2010 09:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.287 X-Spam-Level: X-Spam-Status: No, score=-9.287 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iewwSj5unsHd; Mon, 30 Aug 2010 09:51:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 076363A6841; Mon, 30 Aug 2010 09:50:36 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgIAOV9e0yrR7H+/2dsb2JhbACTJoUYAYc3S3GhXJs7hTcEhDmIRA X-IronPort-AV: E=Sophos;i="4.56,293,1280707200"; d="scan'208,217";a="275346263" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 30 Aug 2010 16:51:07 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7UGp58k010748; Mon, 30 Aug 2010 16:51:06 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Aug 2010 22:21:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB4863.88D4CDFE" Date: Mon, 30 Aug 2010 22:21:04 +0530 Message-ID: <A11921905DA1564D9BCF64A6430A62390293A4B3@XMB-BGL-411.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Resource availability Event package Thread-Index: ActITqjnejR+Z0DIROGgppf59yc2GgAE/EYL References: <20100830142058.6A0EA3A69B8@core3.amsl.com> From: "Parthasarathi R (partr)" <partr@cisco.com> To: <dispatch@ietf.org> X-OriginalArrivalTime: 30 Aug 2010 16:51:04.0732 (UTC) FILETIME=[88FB3DC0:01CB4863] Cc: sip-ops@ietf.org, sip-overload@ietf.org, mediactrl@ietf.org Subject: [dispatch] SIP Resource availability Event package X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/dispatch> List-Post: <mailto:dispatch@ietf.org> List-Help: <mailto:dispatch-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 30 Aug 2010 16:51:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB4863.88D4CDFE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Resource availability information from SIP devices improves the = manageability of SIP devices by providing a framework for multiple = applications like Resource utilization monitoring, overload handling in = SIP based media servers.=20 This draft was discussed in IETF-78 SoC WG and considered as outside the = scope of SOC as it focus on SIP overload based on non-critical resources = like DS0, DSP. By looking at the mediactrl WG charter and working = documents, I doubt that this draft will falls under current media-ctrl = work. As this draft helps in SIP based devices manageability, I looked = for SIP manageability related WG but Sip-ops mailing alias only exists = and there is no WG associated with it. So, I'm putting this document in = dispatch WG for further proceedings.=20 Abstract is as follows: "Collecting Resource availability information in Session Initiation = Protocol (SIP) devices in real time helps in better manageability of = resources in the SIP network. Resource availability monitoring in SIP = devices helps administrator to take informed decision and corrective = measures to tackle under or over resource utilization in the network. = Resource availability information can also be used for SIP overload = control in SIP based Media servers by passing resource demand vector = between devices. This document defines resource availability XML = document and the mechanisms that can be used to exchange the document = between SIP entities." The draft is available at = http://datatracker.ietf.org/doc/draft-partha-dispatch-resource-availabili= ty/ = <http://datatracker.ietf.org/doc/draft-partha-dispatch-resource-availabil= ity/> . Could you please provide your valuable comments. Thanks Partha ________________________________ From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Mon 8/30/2010 7:50 PM To: Parthasarathi R (partr) Cc: Sheshadri Shalya (svshesha) Subject: New Version Notification for = draft-partha-dispatch-resource-availability-00=20 A new version of I-D, draft-partha-dispatch-resource-availability-00.txt = has been successfully submitted by Parthasarathi R and posted to the = IETF repository. Filename: draft-partha-dispatch-resource-availability Revision: 00 Title: Session Initiation Protocol (SIP) Resource availability = Event package Creation_date: 2010-08-30 WG ID: Independent Submission Number_of_pages: 17 Abstract: Collecting Resource availability information in Session Initiation Protocol (SIP) devices in real time helps in better managebility of resources in the SIP network. Resource availability monitoring in SIP devices helps administrator to take informed decision and corrective measures to tackle under or over resource utilization in the network. Resource availability information can also be used for SIP overload control in SIP based Media servers by passing resource demand vector between devices. This document defines resource availability XML document and the mechanisms that can be used to exchange the document between SIP entities. = =20 The IETF Secretariat. ------_=_NextPart_001_01CB4863.88D4CDFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML dir=3Dltr><HEAD><TITLE>New Version Notification for = draft-partha-dispatch-resource-availability-00=0A= =0A= =0A= =0A=
=0A=
=0A=
=0A=

Resource availability information from SIP devices improves the = manageability of SIP devices by providing a framework for multiple = applications like Resource utilization monitoring, overload handling in = SIP based media servers.

=0A=

This draft was discussed in IETF-78 SoC WG and considered as outside = the scope of SOC as it focus on SIP overload based on non-critical = resources like DS0, DSP. By looking at the mediactrl WG charter and = working documents, I doubt that this draft will falls under current = media-ctrl work. As this draft helps in SIP based devices manageability, = I looked for SIP manageability related WG but Sip-ops mailing alias only = exists and there is no WG associated with it. So, I'm putting this = document in dispatch WG for further proceedings.

=0A=

Abstract is as follows:

=0A=

"Collecting Resource availability information in Session Initiation = Protocol (SIP) devices in real time helps in better manageability of = resources in the SIP network. Resource availability monitoring in SIP = devices helps administrator to take informed decision and corrective = measures to tackle under or over resource utilization in the network. = Resource availability information can also be used for SIP overload = control in SIP based Media servers by passing resource demand vector = between devices. This document defines resource availability XML = document and the mechanisms that can be used to exchange the document = between SIP entities."

=0A=

=0A=

The draft is available at http://datatracker.ietf.org/doc/draft-partha-dispatch-resource-= availability/. Could you please provide your valuable comments.

=0A=

Thanks

=0A=

Partha

=0A=


=0A=

=0A= From: IETF I-D Submission Tool = [mailto:idsubmission@ietf.org]
Sent: Mon 8/30/2010 7:50 = PM
To: Parthasarathi R (partr)
Cc: Sheshadri Shalya = (svshesha)
Subject: New Version Notification for = draft-partha-dispatch-resource-availability-00 =

=0A=

=0A=

A new version of I-D, = draft-partha-dispatch-resource-availability-00.txt has been successfully = submitted by Parthasarathi R and posted to the IETF = repository.

Filename:        = draft-partha-dispatch-resource-availability
Revision:   = ;     00
Title:  =          Session Initiation = Protocol (SIP) Resource availability Event = package
Creation_date:   2010-08-30
WG ID:  =          Independent = Submission
Number_of_pages: 17

Abstract:
Collecting = Resource availability information in Session Initiation
Protocol = (SIP) devices in real time helps in better managebility of
resources = in the SIP network.  Resource availability monitoring in
SIP = devices helps administrator to take informed decision and
corrective = measures to tackle under or over resource utilization in
the = network.  Resource availability information can also be used = for
SIP overload control in SIP based Media servers by passing = resource
demand vector between devices.  This document defines = resource
availability XML document and the mechanisms that can be = used to
exchange the document between SIP = entities.
          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          


= The IETF Secretariat.


------_=_NextPart_001_01CB4863.88D4CDFE-- From spromano@unina.it Mon Aug 30 12:19:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84A5D3A6863 for ; Mon, 30 Aug 2010 12:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.118 X-Spam-Level: X-Spam-Status: No, score=-98.118 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjBwUQvjfUPz for ; Mon, 30 Aug 2010 12:19:32 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by core3.amsl.com (Postfix) with ESMTP id 559093A6837 for ; Mon, 30 Aug 2010 12:19:30 -0700 (PDT) Received: from [192.168.1.101] (adsl-ull-19-164.46-151.net24.it [151.46.164.19]) (authenticated bits=0) by smtp2.unina.it (8.14.0/8.14.0) with ESMTP id o7UJJrW2009965 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Aug 2010 21:19:54 +0200 Message-ID: <4C7C0457.9070008@unina.it> Date: Mon, 30 Aug 2010 21:19:51 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Mary Barnes , Cullen Jennings References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------060205070607060301030300" Cc: DISPATCH Subject: Re: [dispatch] [RAI] Reminder: DISPATCH deadlines for IETF-79 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 19:19:34 -0000 This is a multi-part message in MIME format. --------------060205070607060301030300 Content-Type: multipart/alternative; boundary="------------060602070102070406070104" --------------060602070102070406070104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear chairs and all, please find attached a proposal submission related to a topic that I called DCON and which stands for Distributed Conferencing. I hope that with XCON which is close to successfully concluding its work, the time is now ripe for focusing on how to improve its scalability through distribution of components/responsibilities. I am sending a drafty draft of DCON's potential charter, just to give you some initial material to debate. I'm looking forward to receiving your feedback. Cheers, Simon Il 13/08/2010 18.37, Mary Barnes ha scritto: > Hi all, > > Just a reminder that the first deadline for IETF-79 for the DISPATCH > WG topics is two weeks from Monday. > > Regards, > Mary. > > On Thu, Jul 29, 2010 at 10:20 AM, Mary Barnes > > wrote: > > Hi folks, > > The following summarizes the deadlines for topics for DISPATCH for > IETF-79: > > * August 30, 2010. Cutoff date to notify the chairs/DISPATCH WG of > plans to submit a proposal. [Two weeks prior to BoF proposal > deadline] > > * Sept. 6, 2010. Cutoff for charter proposals for topics. [One > week prior to BoF proposal deadline] > > > * Sept. 20, 2010. Topics that are to be the focus of IETF-79 > are announced. > [One week before deadline to request WG slots] > > * Oct. 18th, 2010. -00 draft deadline. > > * Oct. 25th, 2010. Draft deadline. > > These deadlines have been published on the DISPATCH WG wiki page: > http://trac.tools.ietf.org/wg/dispatch/trac/wiki > > Note that these dates are closer to the end of the meeting than > those for IETF-78 because there is just over 3 months between the > end of IETF-78 and beginning of IETF-79 (versus the 4 months we > had between this meeting and Anaheim). > Note that registration and WG/Bof scheduling for IETF-79 starts on > August 9th: > http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF79 > > DISPATCH sets the first deadline such that it's still possible to > request a BoF for topics that may be wider in scope and require > broader community review. The deadlines for BoFs are set by the > leadership so that there is time to consider BoFs in the > scheduling. Also, as Gonzalo noted in a separate email, WGs need > to have a draft charter at the time they request a WG slot. > Further information on the motivation for the DISPATCH planning > model is provided in the wiki. > > Regards, > Mary > DISPATCH WG co-chair > > > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai > -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --------------060602070102070406070104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear chairs and all,

please find attached a proposal submission related to a topic that I called DCON and which stands for Distributed Conferencing. I hope that with XCON which is close to successfully concluding its work, the time is now ripe for focusing on how to improve its scalability through distribution of components/responsibilities. I am sending a drafty draft of DCON's potential charter, just to give you some initial material to debate. I'm looking forward to receiving your feedback.

Cheers,

Simon

Il 13/08/2010 18.37, Mary Barnes ha scritto:
Hi all, 

Just a reminder that the first deadline for IETF-79 for the DISPATCH WG topics is two weeks from Monday.  

Regards,
Mary. 

On Thu, Jul 29, 2010 at 10:20 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Hi folks,

The following summarizes the deadlines for topics for DISPATCH for IETF-79:

* August 30, 2010. Cutoff date to notify the chairs/DISPATCH WG of
  plans to submit a proposal. [Two weeks prior to BoF proposal deadline]

* Sept. 6, 2010. Cutoff for charter proposals for topics. [One week prior to BoF proposal deadline]


* Sept. 20, 2010. Topics that are to be the focus of IETF-79 are announced.
  [One week before deadline to request WG slots]

* Oct. 18th, 2010. -00 draft deadline.

* Oct. 25th, 2010. Draft deadline.

These deadlines have been published on the DISPATCH WG wiki page:
http://trac.tools.ietf.org/wg/dispatch/trac/wiki 

Note that these dates are closer to the end of the meeting than those for IETF-78  because there is just over 3 months between the end of IETF-78 and beginning of IETF-79 (versus the 4 months we had between this meeting and Anaheim). 
 
Note that registration and WG/Bof scheduling for IETF-79 starts on August 9th:

DISPATCH sets the first deadline such that it's still possible to request a BoF for topics that may be wider in scope and require broader community review.  The deadlines for BoFs are set by the leadership so that there is time to consider BoFs in the scheduling. Also, as Gonzalo noted in a separate email, WGs need to have a draft charter at the time they request a WG slot.  Further information on the motivation for the DISPATCH planning model  is provided in the wiki.

Regards,
Mary
DISPATCH WG co-chair



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

-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/
--------------060602070102070406070104-- --------------060205070607060301030300 Content-Type: text/plain; name="DCON-CharterProposal.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="DCON-CharterProposal.txt" - Decription of Working Group The focus of this Working Group is to develop a standard solution for sca= lable conferencing over the Internet. The WG will define a standard suite= of protocols for distributed conferencing and will draw inspiration from= the work carried out in the XCON working group, which has defined a comp= lete architecture for centralized conferencing. DCON is based on the ide= a that a distributed conference can be setup by appropriately orchestrating the op= eration of a number of XCON focus elements, each in charge of managing a = certain number of participants. Interaction between each participant and = the corresponding conference focus will be entirely based on the standard= XCON framework, whereas inter-focus interaction will be defined by this = WG. In the DCON architecture a number of entities are used to manage conferen= ce setup in the presence of clients which are distributed across a geogra= phical network. Each managing entity plays the role of a conference focus as de= fined in the XCON working group documents. Indeed, each XCON focus will b= e in charge of managing a certain number of clients falling under its own= "realm". In order to move the XCON scope towards a distributed environm= ent, we will introduce inter-focus coordination, which is needed to effec= tively setup and manage conference instantiation and coordination. As in= the centralized case, we will define logical entities and naming conv= entions. An appropriate data model for distributed conferencing will be = potentially defined and will extend, when needed, the XCON data model. F= urthermore, we will propose the adoption of a suitable set of protocols w= hich are complementary to the call signaling protocols and are needed to = support advanced conferencing applications. The WG will basically need to introduce two major functions: (i) a coordi= nation level among conference focus entities; (ii) a way to effectively d= istribute conference state information. As to the first point above, the= coordination level is needed in order to manage a distributed conference= along its entire life-cycle. For instance, once a user decides to create= a new conference, the corresponding conference focus has to distribute c= onference information to all other foci, in such a way as to enable other= potential participants to retrieve the needed data and possibly subscrib= e to the event. The WG will make the assumption that all the operations n= eeded inside a single conference cloud are managed via the protocols an= d interfaces defined inside the XCON working group. Hence, each single c= loud will keep on being based on a star-topology graph for all what conce= rns the call signaling part. The various available stars will then be con= nected through an upper-layer topology providing inter-focus communicatio= n. The overall topology of the distributed conferencing scenario will lo= ok like an overlay network of focus entities, each managing an underlying= "centralized" conferencing island. The WG will envisage the possibility = to exploit extended Instant Messaging (IM) protocols (e.g. XMPP) for inte= r-focus communication. As to the second point mentioned above, it looks clear that a way to prop= agate information about conferences is needed when switching the view fro= m a centralized to a distributed perspective. Indeed, whenever a new con= ference is created (or an active conference changes its state) such an ev= ent has to be communicated to all interested (or active) participants. G= iven the intrinsic nature of the distributed framework (which actually ex= pands the centralized one through the introduction of an overlay network = of focus entities), the actual flow of information will always foresee = the interaction among conference focus entities for both conference infor= mation exchanging and state changes notifications. The same obviously ap= plies also to the involved natively centralized protocols defined in the = XCON framework. A suitable mechanism will be defined by the WG, allowing= for the dispatching of such centralized messages across the DCON network= =2E The mechanism in question must be fully compliant with the existing o= peration of XCON clouds, which must keep their local participants total= ly unaware of the potential distributed nature of conferences. Conference= state propagation will take place in a number of alternative ways. For = instance, each focus might flood the received information across an inter= -focus communication mesh, thus guaranteeing that potential participants = belonging to heterogeneous islands can be reached. In such case, focus e= ntities are "stateful", i.e. each of them stores information about curren= t sessions and forwards such information to all peering entities in order= to get them up-to-date with respect to available conference sessions.=20 On the other hand, a distributed repository might be employed for the sak= e of storing conference information. Focus entities would access such re= pository, both to publish (either upon creation of a new conference, or t= o notify a change in the state of an active conference) and to retrieve i= nformation about active conferences (e.g. when a new participant wants to= access the list of ongoing/scheduled conference sessions he might be int= erested to join). In this last case, focus entities are "stateless". Fin= ally, the WG will evaluate the benefits deriving from the adoption of a p= ure peer-to-peer approach for the purpose of conference state information= spreading. The deliverables for the group will be: - A Framework for Distributed Conferencing (backward-compatible with XCON= in the single-cloud case) - A survey of potential solutions to the construction and maintainance of= a DCON conference repository (stateless, stateful, based on flooding, p2= p, etc.) - Requirements for an XCON-DCON Synchronization Protocol (XDSP) - Specification of the XDSP - DCON call-flows draft (involving the use of XDSP) - Goals and Milestones February 2011 --> Submit Framework document for publication as PS April 2011 --> Submit XDSP Requirements document for publication as Infor= mational June 2011 --> Submit survey of solutions for the DCON conference reposito= ry for publication as Informational September 2011 --> Submit XDSP Specification document for publication as = PS January 2012 --> Submit DCON call flows draft for publication as Informat= ional --------------060205070607060301030300-- From bernard_aboba@hotmail.com Mon Aug 30 13:39:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011853A6814 for ; Mon, 30 Aug 2010 13:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.352 X-Spam-Level: X-Spam-Status: No, score=-100.352 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWY0hCDWcfCx for ; Mon, 30 Aug 2010 13:39:51 -0700 (PDT) Received: from blu0-omc4-s25.blu0.hotmail.com (blu0-omc4-s25.blu0.hotmail.com [65.55.111.164]) by core3.amsl.com (Postfix) with ESMTP id 526F03A6874 for ; Mon, 30 Aug 2010 13:39:36 -0700 (PDT) Received: from BLU137-DS11 ([65.55.111.137]) by blu0-omc4-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Aug 2010 13:40:07 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 30 Aug 2010 15:40:44 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01CB4859.B5AB1B10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActIg54xh46/uggIR460ip3ORFknXg== Content-Language: en-us X-OriginalArrivalTime: 30 Aug 2010 20:40:07.0569 (UTC) FILETIME=[8859C010:01CB4883] Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 20:39:53 -0000 ------=_NextPart_000_002B_01CB4859.B5AB1B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kevin Fleming said: " I can sympathize with the desire to have a simpler mechanism for doing *only* v4/v6 path selection, but since either method will require implementers of media endpoints to develop the required support, I'd rather push them towards implementing STUN. The SHA-1 overhead for a few packets at the beginning of a session seems (to me, anyway) to be far less CPU burden than the low bitrate codec (or modem) that the gateway will eventually be operating on that channel anyway." [BA] The first question to ask is whether the general topic (Migration of SIP to IPv6 Media) is worth focusing on. I believe that it is. ICE has substantial deployment today on IPv4 (several million hosts now run it on a regular basis), and I agree with Kevin that some simplifications/adjustments are probably needed for v4/v6 path selection, if only to update the thinking based on our current knowledge of potential IPv6 transition scenarios and routing/performance issues. I also agree with Kevin that SHA-1 overhead is not really much of an issue. As for the proposed solution, it's not clear to me how well it will work in some of the IPv6 transition scenarios now under discussion (such as an IPv6-only smartphone attempting to communicate with an IPv4-only device via NAT64). ------=_NextPart_000_002B_01CB4859.B5AB1B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kevin Fleming said:

 

" I can sympathize with the desire to have = a simpler mechanism for doing *only* v4/v6 path selection, but since either method = will require implementers of media endpoints to develop the required support, = I'd rather push them towards implementing STUN. The SHA-1 overhead for a few = packets at the beginning of a session seems (to me, anyway) to be far less CPU = burden than the low bitrate codec (or modem) that the gateway will eventually = be operating on that channel anyway."

 

[BA]  The first question to ask is whether = the general topic (Migration of SIP to IPv6 Media) is worth focusing = on.  I believe that it is.  ICE has substantial deployment today on IPv4 = (several million hosts now run it on a regular basis),  and I agree with = Kevin that some simplifications/adjustments are probably needed for v4/v6 path = selection, if only to update the thinking based on our current knowledge of potential = IPv6 transition scenarios and routing/performance issues.  I also agree = with Kevin that SHA-1 overhead is not really much of an issue.  =

 

As for the proposed solution, it's not clear to = me how well it will work in some of the IPv6 transition scenarios now under = discussion (such as an IPv6-only smartphone attempting to communicate with an = IPv4-only device via NAT64). 

 

------=_NextPart_000_002B_01CB4859.B5AB1B10-- From HKaplan@acmepacket.com Mon Aug 30 14:17:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D775A3A687D for ; Mon, 30 Aug 2010 14:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUr2WY5u-WZg for ; Mon, 30 Aug 2010 14:17:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 430733A688E for ; Mon, 30 Aug 2010 14:17:14 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 30 Aug 2010 17:17:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 30 Aug 2010 17:17:27 -0400 From: Hadriel Kaplan To: Bernard Aboba Date: Mon, 30 Aug 2010 17:17:26 -0400 Thread-Topic: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks Thread-Index: ActIiL8CThFLTOt4QCWRY46sNHc1Tg== Message-ID: <5345DA88-8ECD-494C-99E5-5A40382A431C@acmepacket.com> References: 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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 21:17:21 -0000 Think of this from the perspective of a PSTN Gateway. PSTN Gateways handle= thousands or tens of thousands of calls or more. Sure, if they happen to = have SRTP hardware, and their architecture/implementation happens to be abl= e to use that hardware for SHA-1 in STUN checks, then they may be able to d= o it without impact. Or they can burn DSP cycles, if they happen to have D= SPs that can do it.=20 And then there are all the vendors who make B2BUAs that try to avoid using = DSPs for calls but would be the media IP relay (like transcoder-free MSCs, = SBCs, BGFs, etc.). And what great benefit does the operator of such gateways/b2bua's get that = they didn't have before? It doesn't suddenly secure the media - only real = SRTP does that. It doesn't allow them to suddenly support both IPv4 and IP= v6 - they can already do that, by simply using the same transport family fo= r the media as they did the signaling. (i.e., pick one before the INVITE is= sent/answered) No, what we're trying to do is let them figure out which t= ransport is actually working for the media plane, because we're worried IPv= 6 will have issues. Cool. So why do we need SHA-1 to do that, exactly? I= t's like saying to do HTTP over IPv6 you need to do TLS. -hadriel On Aug 30, 2010, at 4:40 PM, Bernard Aboba wrote: > Kevin Fleming said: > =20 > " I can sympathize with the desire to have a simpler mechanism for doing = *only* v4/v6 path selection, but since either method will require implement= ers of media endpoints to develop the required support, I'd rather push the= m towards implementing STUN. The SHA-1 overhead for a few packets at the be= ginning of a session seems (to me, anyway) to be far less CPU burden than t= he low bitrate codec (or modem) that the gateway will eventually be operati= ng on that channel anyway." > =20 > [BA] The first question to ask is whether the general topic (Migration o= f SIP to IPv6 Media) is worth focusing on. I believe that it is. ICE has = substantial deployment today on IPv4 (several million hosts now run it on a= regular basis), and I agree with Kevin that some simplifications/adjustme= nts are probably needed for v4/v6 path selection, if only to update the thi= nking based on our current knowledge of potential IPv6 transition scenarios= and routing/performance issues. I also agree with Kevin that SHA-1 overhe= ad is not really much of an issue.=20 > =20 > As for the proposed solution, it's not clear to me how well it will work = in some of the IPv6 transition scenarios now under discussion (such as an I= Pv6-only smartphone attempting to communicate with an IPv4-only device via = NAT64).=20 > =20 > From kpfleming@digium.com Mon Aug 30 15:07:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB623A69F6 for ; Mon, 30 Aug 2010 15:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bReUnmCAEP+3 for ; Mon, 30 Aug 2010 15:07:20 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id DFFB23A68DD for ; Mon, 30 Aug 2010 15:07:19 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1OqCW6-0001Gl-PO for dispatch@ietf.org; Mon, 30 Aug 2010 17:07:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id B1D9FD8195 for ; Mon, 30 Aug 2010 17:07:50 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUe5l++FQ0Jo for ; Mon, 30 Aug 2010 17:07:50 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 1691BD8192 for ; Mon, 30 Aug 2010 17:07:50 -0500 (CDT) Message-ID: <4C7C2BB5.5010000@digium.com> Date: Mon, 30 Aug 2010 17:07:49 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: dispatch@ietf.org References: <5345DA88-8ECD-494C-99E5-5A40382A431C@acmepacket.com> In-Reply-To: <5345DA88-8ECD-494C-99E5-5A40382A431C@acmepacket.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 22:07:21 -0000 On 08/30/2010 04:17 PM, Hadriel Kaplan wrote: > > Think of this from the perspective of a PSTN Gateway. PSTN Gateways handle thousands or tens of thousands of calls or more. Sure, if they happen to have SRTP hardware, and their architecture/implementation happens to be able to use that hardware for SHA-1 in STUN checks, then they may be able to do it without impact. Or they can burn DSP cycles, if they happen to have DSPs that can do it. > > And then there are all the vendors who make B2BUAs that try to avoid using DSPs for calls but would be the media IP relay (like transcoder-free MSCs, SBCs, BGFs, etc.). > > And what great benefit does the operator of such gateways/b2bua's get that they didn't have before? It doesn't suddenly secure the media - only real SRTP does that. It doesn't allow them to suddenly support both IPv4 and IPv6 - they can already do that, by simply using the same transport family for the media as they did the signaling. (i.e., pick one before the INVITE is sent/answered) No, what we're trying to do is let them figure out which transport is actually working for the media plane, because we're worried IPv6 will have issues. Cool. So why do we need SHA-1 to do that, exactly? It's like saying to do HTTP over IPv6 you need to do TLS. Just to be clear; I was not proposing that SHA-1 was a part of the solution to the problem here, just that STUN can be the solution and ICE usage of it happens to employ SHA-1 because it uses message integrity checking. For this application, STUN could be used without message integrity checking, because the application itself is already subject to various forms of well known attacks (any RTP implementation that supports media latching is subject to them). My concern is really based on those exact PSTN gateways that you mention... unless we aren't expecting the massive installed base of them to upgrade to IPv6 at all, it would be surprising to me if the media transport stacks on those gateways could handle generating and receiving duplicate media streams for the same session without significant redesign. Using STUN as a mechanism for a connectivity check seems to be a simpler route, as it is done prior to the media stream even being established, and doesn't even have to involve the DSPs in the gateway at all, since the number of packets involved is so low (so the general purpose processor in the gateway can use a presumably less efficient mechanism to transmit and receive packets on the selected ports for a session). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From bernard_aboba@hotmail.com Mon Aug 30 15:49:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7E73A6814 for ; Mon, 30 Aug 2010 15:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.649 X-Spam-Level: X-Spam-Status: No, score=-101.649 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1qSqtazX1kD for ; Mon, 30 Aug 2010 15:49:14 -0700 (PDT) Received: from blu0-omc4-s14.blu0.hotmail.com (blu0-omc4-s14.blu0.hotmail.com [65.55.111.153]) by core3.amsl.com (Postfix) with ESMTP id CA45C3A68AE for ; Mon, 30 Aug 2010 15:49:13 -0700 (PDT) Received: from BLU137-DS4 ([65.55.111.137]) by blu0-omc4-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Aug 2010 15:49:45 -0700 X-Originating-IP: [131.107.0.102] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Hadriel Kaplan'" References: <5345DA88-8ECD-494C-99E5-5A40382A431C@acmepacket.com> In-Reply-To: <5345DA88-8ECD-494C-99E5-5A40382A431C@acmepacket.com> Date: Mon, 30 Aug 2010 15:49:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActIiL8CThFLTOt4QCWRY46sNHc1TgACl/Ug Content-Language: en-us X-OriginalArrivalTime: 30 Aug 2010 22:49:45.0268 (UTC) FILETIME=[A4386F40:01CB4895] Cc: dispatch@ietf.org Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 22:49:15 -0000 As you said, SHA-1 isn't required the media connectivity test, but comes in as part of STUN support. My problem is that the document appears to only consider "pure" IPv6 scenarios where STUN might not be needed, but doesn't consider more complex transition scenarios like NAT64, DSLITE, etc. It seems to me that the scenario discussion is an important one to have upfront. -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Monday, August 30, 2010 2:17 PM To: Bernard Aboba Cc: dispatch@ietf.org Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks Think of this from the perspective of a PSTN Gateway. PSTN Gateways handle thousands or tens of thousands of calls or more. Sure, if they happen to have SRTP hardware, and their architecture/implementation happens to be able to use that hardware for SHA-1 in STUN checks, then they may be able to do it without impact. Or they can burn DSP cycles, if they happen to have DSPs that can do it. And then there are all the vendors who make B2BUAs that try to avoid using DSPs for calls but would be the media IP relay (like transcoder-free MSCs, SBCs, BGFs, etc.). And what great benefit does the operator of such gateways/b2bua's get that they didn't have before? It doesn't suddenly secure the media - only real SRTP does that. It doesn't allow them to suddenly support both IPv4 and IPv6 - they can already do that, by simply using the same transport family for the media as they did the signaling. (i.e., pick one before the INVITE is sent/answered) No, what we're trying to do is let them figure out which transport is actually working for the media plane, because we're worried IPv6 will have issues. Cool. So why do we need SHA-1 to do that, exactly? It's like saying to do HTTP over IPv6 you need to do TLS. -hadriel On Aug 30, 2010, at 4:40 PM, Bernard Aboba wrote: > Kevin Fleming said: > > " I can sympathize with the desire to have a simpler mechanism for doing *only* v4/v6 path selection, but since either method will require implementers of media endpoints to develop the required support, I'd rather push them towards implementing STUN. The SHA-1 overhead for a few packets at the beginning of a session seems (to me, anyway) to be far less CPU burden than the low bitrate codec (or modem) that the gateway will eventually be operating on that channel anyway." > > [BA] The first question to ask is whether the general topic (Migration of SIP to IPv6 Media) is worth focusing on. I believe that it is. ICE has substantial deployment today on IPv4 (several million hosts now run it on a regular basis), and I agree with Kevin that some simplifications/adjustments are probably needed for v4/v6 path selection, if only to update the thinking based on our current knowledge of potential IPv6 transition scenarios and routing/performance issues. I also agree with Kevin that SHA-1 overhead is not really much of an issue. > > As for the proposed solution, it's not clear to me how well it will work in some of the IPv6 transition scenarios now under discussion (such as an IPv6-only smartphone attempting to communicate with an IPv4-only device via NAT64). > > From gonzalo.camarillo@ericsson.com Tue Aug 31 00:33:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45333A68A3 for ; Tue, 31 Aug 2010 00:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdgGMVMDOPi2 for ; Tue, 31 Aug 2010 00:33:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 68BA53A67B7 for ; Tue, 31 Aug 2010 00:33:37 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-88-4c7cb06f8215 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 68.F9.06895.F60BC7C4; Tue, 31 Aug 2010 09:34:08 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Aug 2010 09:34:08 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Aug 2010 09:34:07 +0200 Message-ID: <4C7CB06F.3000503@ericsson.com> Date: Tue, 31 Aug 2010 10:34:07 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "dispatch@ietf.org" References: <04CAD96D4C5A3D48B1919248A8FE0D540CB60046@xmb-sjc-215.amer.cisco.com> <4C4FDB44.6070805@ericsson.com> In-Reply-To: <4C4FDB44.6070805@ericsson.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2010 07:34:07.0466 (UTC) FILETIME=[E526DCA0:01CB48DE] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 07:33:39 -0000 Hi, we have not seen any comments on this topic (HTTP streaming). However, many people were on vacation in August. Please, send your comments to this list. Thanks, Gonzalo On 28/07/2010 10:24 AM, Gonzalo Camarillo wrote: > Hi, > > yes, to be clear, the idea is not to only discuss this draft. The idea > is to discuss what can be done in the HTTP streaming area at the IETF (I > have changes the subject of this email). > > As Ali pointed out below, this is an important area that is advancing > fast. So, we would like to get your input sooner rather than later. > > Thanks, > > Gonzalo > > > On 28/07/2010 12:15 AM, Ali C. Begen (abegen) wrote: >> (Responding to Gonzalo's email) >> >> I read this draft, but I won't comment on the draft here. Rather, I would like to understand the goal(s) of this draft. >> >> HTTP streaming, as noted by the draft, has been around for some time now and there are already multiple products available. Many groups besides IETF have shown interest in this topic and worked towards producing their own specs in the past year. Just last week, MPEG also joined the club and has started evaluating the received proposals. >> >> Sure, we can discuss some of the design issues here at IETF. But, do we want to achieve more than that? If yes, we should be aware of the time pressure. >> >> -acbegen >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From gonzalo.camarillo@ericsson.com Tue Aug 31 03:26:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E22B3A67AB for ; Tue, 31 Aug 2010 03:26:56 -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.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+qvdad4a6ty for ; Tue, 31 Aug 2010 03:26:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 156643A679F for ; Tue, 31 Aug 2010 03:26:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-06-4c7cd90cebee Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0F.43.10125.C09DC7C4; Tue, 31 Aug 2010 12:27:24 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Aug 2010 12:27:24 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Aug 2010 12:27:23 +0200 Message-ID: <4C7CD90B.3030101@ericsson.com> Date: Tue, 31 Aug 2010 13:27:23 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> In-Reply-To: <4C73EA66.4000305@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2010 10:27:23.0512 (UTC) FILETIME=[19AD9780:01CB48F7] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] I-D Action:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 10:26:56 -0000 Hi, what we need to discuss here is what is our final goal. Adding three new documents (the existing Cisco way, the existing 3GPP way, and the improved INFO-based way) describing how to carry DTMF may not be the best way forward. Let's focus on discussing the current situation, what problems or issues need to be resolved, and the requirements we need to meet. Let's be pragmatic and produce something that will actually improve the current situation out there. Thanks, Gonzalo On 24/08/2010 6:51 PM, Paul Kyzivat wrote: > Maybe we should ask our ADs if they have an opinion about this. > > Thanks, > Paul > > Hadriel Kaplan wrote: >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Monday, August 23, 2010 6:02 PM >>> To: Hadriel Kaplan >>> >>> That reduces things somewhat. But if everybody that supports the package >>> also supports the legacy approach, what is the win? >> >> The legacy mode has no published standards document defining it. I thought when the info-packages work was started, DTMF-in-info was one of the main drivers. But I take your point - if people would prefer to just document it as it is today (sans info-packages), I can change the draft to just be that. I'm cool with either way (defining the current dtmf-relay as a legacy mode was Option-2). >> >> -hadriel >> > From peter.musgrave@magorcorp.com Tue Aug 31 03:47:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C62D3A6893 for ; Tue, 31 Aug 2010 03:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.892 X-Spam-Level: X-Spam-Status: No, score=-99.892 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVb0gpkCr6-6 for ; Tue, 31 Aug 2010 03:47:09 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3A6563A679F for ; Tue, 31 Aug 2010 03:47:07 -0700 (PDT) Received: by wyi11 with SMTP id 11so8234144wyi.31 for ; Tue, 31 Aug 2010 03:47:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.3.19 with SMTP id 19mr1468420weg.108.1283251395398; Tue, 31 Aug 2010 03:43:15 -0700 (PDT) Received: by 10.216.184.147 with HTTP; Tue, 31 Aug 2010 03:43:15 -0700 (PDT) In-Reply-To: <4C7C0457.9070008@unina.it> References: <4C7C0457.9070008@unina.it> Date: Tue, 31 Aug 2010 06:43:15 -0400 Message-ID: From: Peter Musgrave To: Simon Pietro Romano Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] [RAI] Reminder: DISPATCH deadlines for IETF-79 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 10:47:10 -0000 Hi Simon, This is indeed an interesting topic. How does what you are proposing relate to the approach in DisCo (https://datatracker.ietf.org/doc/draft-knauf-p2psip-disco/) ? (I see significant overlap - and I like the use of RELOAD in DisCO, since it is a rich NAT/security aware mechanism for building distributed conferencing) Regards, Peter Musgrave On Mon, Aug 30, 2010 at 3:19 PM, Simon Pietro Romano wr= ote: > Dear chairs and all, > > please find attached a proposal submission related to a topic that I call= ed > DCON and which stands for Distributed Conferencing. I hope that with XCON > which is close to successfully concluding its work, the time is now ripe = for > focusing on how to improve its scalability through distribution of > components/responsibilities. I am sending a drafty draft of DCON's potent= ial > charter, just to give you some initial material to debate. I'm looking > forward to receiving your feedback. > > Cheers, > > Simon > > Il 13/08/2010 18.37, Mary Barnes ha scritto: > > Hi all, > Just a reminder that the first deadline for IETF-79 for the DISPATCH WG > topics is two weeks from Monday. > Regards, > Mary. > > On Thu, Jul 29, 2010 at 10:20 AM, Mary Barnes > wrote: >> >> Hi folks, >> The following summarizes the deadlines for topics for DISPATCH for >> IETF-79: >> * August 30, 2010. Cutoff date to notify the chairs/DISPATCH WG of >> =A0=A0plans to submit a proposal. [Two weeks prior to BoF proposal deadl= ine] >> >> * Sept. 6, 2010. Cutoff for charter proposals for topics. [One week prio= r >> to BoF proposal deadline] >> >> * Sept. 20, 2010. Topics that are to be the focus of IETF-79 >> are=A0announced. >> =A0=A0[One week before deadline to request WG=A0slots] >> >> * Oct. 18th, 2010. -00 draft deadline. >> >> * Oct. 25th, 2010. Draft deadline. >> >> These deadlines have been published on the DISPATCH WG wiki page: >> http://trac.tools.ietf.org/wg/dispatch/trac/wiki >> Note that these dates are closer to the end of the meeting than those fo= r >> IETF-78 =A0because there is just over 3 months between the end of IETF-7= 8 and >> beginning of IETF-79 (versus the 4 months we had between this meeting an= d >> Anaheim). >> >> Note that registration and WG/Bof scheduling for IETF-79 starts on Augus= t >> 9th: >> http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF79 >> DISPATCH sets the first deadline such that it's still possible to reques= t >> a BoF for topics that may be wider in scope and require broader communit= y >> review. =A0The deadlines for BoFs are set by the leadership so that ther= e is >> time to consider BoFs in the scheduling. Also, as Gonzalo noted in a >> separate email, WGs need to have a draft charter at the time they reques= t a >> WG slot. =A0Further information on the motivation for the DISPATCH plann= ing >> model =A0is provided in the wiki. >> Regards, >> Mary >> DISPATCH WG co-chair > > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai > > > -- > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Science Department > Phone: +39 081 7683823 -- Fax: +39 081 7684219 > e-mail: spromano@unina.it > http://www.comics.unina.it/simonpietro.romano > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From HKaplan@acmepacket.com Tue Aug 31 06:42:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B388B3A6947 for ; Tue, 31 Aug 2010 06:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZrOgXCW3TPB for ; Tue, 31 Aug 2010 06:42:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2A0793A680B for ; Tue, 31 Aug 2010 06:42:46 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 31 Aug 2010 09:43:16 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 31 Aug 2010 09:43:14 -0400 From: Hadriel Kaplan To: "Kevin P. Fleming" Date: Tue, 31 Aug 2010 09:43:11 -0400 Thread-Topic: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks Thread-Index: ActJEnVPe6O1Mt5yTcqXrngFLpcDpw== Message-ID: <1A507F83-384E-4AF7-AC19-257DD9D5E669@acmepacket.com> References: <5345DA88-8ECD-494C-99E5-5A40382A431C@acmepacket.com> <4C7C2BB5.5010000@digium.com> In-Reply-To: <4C7C2BB5.5010000@digium.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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 13:42:48 -0000 Yeah, I was only responding in reference to the SHA-1 work for the STUN che= cks. I can't figure out if Dan's draft is any better/worse than just STUN = connectivity checks without SHA-1. -hadriel On Aug 30, 2010, at 6:07 PM, Kevin P. Fleming wrote: > On 08/30/2010 04:17 PM, Hadriel Kaplan wrote: >>=20 >> Think of this from the perspective of a PSTN Gateway. PSTN Gateways han= dle thousands or tens of thousands of calls or more. Sure, if they happen = to have SRTP hardware, and their architecture/implementation happens to be = able to use that hardware for SHA-1 in STUN checks, then they may be able t= o do it without impact. Or they can burn DSP cycles, if they happen to hav= e DSPs that can do it.=20 >>=20 >> And then there are all the vendors who make B2BUAs that try to avoid usi= ng DSPs for calls but would be the media IP relay (like transcoder-free MSC= s, SBCs, BGFs, etc.). >>=20 >> And what great benefit does the operator of such gateways/b2bua's get th= at they didn't have before? It doesn't suddenly secure the media - only re= al SRTP does that. It doesn't allow them to suddenly support both IPv4 and= IPv6 - they can already do that, by simply using the same transport family= for the media as they did the signaling. (i.e., pick one before the INVITE= is sent/answered) No, what we're trying to do is let them figure out whic= h transport is actually working for the media plane, because we're worried = IPv6 will have issues. Cool. So why do we need SHA-1 to do that, exactly?= It's like saying to do HTTP over IPv6 you need to do TLS. >=20 > Just to be clear; I was not proposing that SHA-1 was a part of the > solution to the problem here, just that STUN can be the solution and ICE > usage of it happens to employ SHA-1 because it uses message integrity > checking. For this application, STUN could be used without message > integrity checking, because the application itself is already subject to > various forms of well known attacks (any RTP implementation that > supports media latching is subject to them). >=20 > My concern is really based on those exact PSTN gateways that you > mention... unless we aren't expecting the massive installed base of them > to upgrade to IPv6 at all, it would be surprising to me if the media > transport stacks on those gateways could handle generating and receiving > duplicate media streams for the same session without significant > redesign. Using STUN as a mechanism for a connectivity check seems to be > a simpler route, as it is done prior to the media stream even being > established, and doesn't even have to involve the DSPs in the gateway at > all, since the number of packets involved is so low (so the general > purpose processor in the gateway can use a presumably less efficient > mechanism to transmit and receive packets on the selected ports for a > session). >=20 > --=20 > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mlm.michael.miller@gmail.com Tue Aug 31 14:34:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE803A684D; Tue, 31 Aug 2010 14:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[AWL=1.799, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFYp-QU+nelh; Tue, 31 Aug 2010 14:34:22 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 27AC13A682B; Tue, 31 Aug 2010 14:34:22 -0700 (PDT) Received: by yxl31 with SMTP id 31so1629019yxl.31 for ; Tue, 31 Aug 2010 14:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :x-mailer:from:subject:date:to; bh=9CXFTLynHfqFjDSTZ9JLyt7x0Y95j0ZCrRwyhRhD37U=; b=aTgz3TF9PZAAf9qoGV3ChYotlGj3pDptWeLfgdq1L6q4MiW7Ifv8Kkh7hJOZ8WEjmh TG0waD7ERJWDJT2bm1UnKczilBuVXgiIkMKdhLu3LNunFOmQ8ccoVGWUAOYi9Uq7zefw K2cA8xvMNiiJOnqTd++srVIcEOvViZs9Le6Z0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=xDLVwo9jw1Y86QC5DdKw6QluAIxGRpPsqJTqUPvaM9LV9YV6xIzNj6CEW92u8bDReD JGbfM/ae80VIdL7JKxkB9w/1ptusuLndeFXUH5EbOAqLNNAhmOMobyga4ET8Cl37FTy5 zh/CNDtsaP3fwL+QKpSJlL57rmneQ4x7cARgk= Received: by 10.100.164.5 with SMTP id m5mr7157847ane.147.1283290492452; Tue, 31 Aug 2010 14:34:52 -0700 (PDT) Received: from [10.80.93.206] (mobile-166-137-136-115.mycingular.net [166.137.136.115]) by mx.google.com with ESMTPS id w6sm15292659anb.23.2010.08.31.14.34.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 31 Aug 2010 14:34:51 -0700 (PDT) References: <20100830142058.6A0EA3A69B8@core3.amsl.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A306) Content-Type: multipart/alternative; boundary=Apple-Mail-26-40632250 Message-Id: <5D9746F9-9D36-4482-8B61-94AED338EDE2@gmail.com> Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (8A306) From: Michael Miller Date: Tue, 31 Aug 2010 17:35:05 -0400 To: "Parthasarathi R (partr)" Cc: "sip-ops@ietf.org" , "" , "sip-overload@ietf.org" , "mediactrl@ietf.org" Subject: Re: [dispatch] SIP Resource availability Event package X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 21:34:24 -0000 --Apple-Mail-26-40632250 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This draft looks pretty good. Should there be language that saids management= servers are alerted of critical conditions or is that outside of this draft= ? Michael L. Miller Sent from my Mobile Device On Aug 30, 2010, at 12:51 PM, "Parthasarathi R (partr)" wr= ote: > Resource availability information from SIP devices improves the manageabil= ity of SIP devices by providing a framework for multiple applications like R= esource utilization monitoring, overload handling in SIP based media servers= . >=20 > This draft was discussed in IETF-78 SoC WG and considered as outside the s= cope of SOC as it focus on SIP overload based on non-critical resources like= DS0, DSP. By looking at the mediactrl WG charter and working documents, I d= oubt that this draft will falls under current media-ctrl work. As this draft= helps in SIP based devices manageability, I looked for SIP manageability re= lated WG but Sip-ops mailing alias only exists and there is no WG associated= with it. So, I'm putting this document in dispatch WG for further proceedin= gs. >=20 > Abstract is as follows: >=20 > "Collecting Resource availability information in Session Initiation Protoc= ol (SIP) devices in real time helps in better manageability of resources in t= he SIP network. Resource availability monitoring in SIP devices helps admini= strator to take informed decision and corrective measures to tackle under or= over resource utilization in the network. Resource availability information= can also be used for SIP overload control in SIP based Media servers by pas= sing resource demand vector between devices. This document defines resource a= vailability XML document and the mechanisms that can be used to exchange the= document between SIP entities." >=20 > The draft is available at http://datatracker.ietf.org/doc/draft-partha-dis= patch-resource-availability/. Could you please provide your valuable comment= s. >=20 > Thanks >=20 > Partha >=20 >=20 > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Mon 8/30/2010 7:50 PM > To: Parthasarathi R (partr) > Cc: Sheshadri Shalya (svshesha) > Subject: New Version Notification for draft-partha-dispatch-resource-avail= ability-00=20 >=20 >=20 > A new version of I-D, draft-partha-dispatch-resource-availability-00.txt h= as been successfully submitted by Parthasarathi R and posted to the IETF rep= ository. >=20 > Filename: draft-partha-dispatch-resource-availability > Revision: 00 > Title: Session Initiation Protocol (SIP) Resource availability E= vent package > Creation_date: 2010-08-30 > WG ID: Independent Submission > Number_of_pages: 17 >=20 > Abstract: > Collecting Resource availability information in Session Initiation > Protocol (SIP) devices in real time helps in better managebility of > resources in the SIP network. Resource availability monitoring in > SIP devices helps administrator to take informed decision and > corrective measures to tackle under or over resource utilization in > the network. Resource availability information can also be used for > SIP overload control in SIP based Media servers by passing resource > demand vector between devices. This document defines resource > availability XML document and the mechanisms that can be used to > exchange the document between SIP entities. > = =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-26-40632250 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This draft looks pretty good. Should th= ere be language that saids management servers are alerted of critical condit= ions or is that outside of this draft?

Michael L. Miller<= /div>
Sent from my Mobile Device

On Aug 30, 2010, at= 12:51 PM, "Parthasarathi R (partr)" <= partr@cisco.com> wrote:

Resource availability information from SIP devices improves the manageabi= lity of SIP devices by providing a framework for multiple applications like R= esource utilization monitoring, overload handling in SIP based media servers= .

This draft was discussed in IETF-78 SoC WG and considered as outside the s= cope of SOC as it focus on SIP overload based on non-critical resources like= DS0, DSP. By looking at the mediactrl WG charter and working documents, I d= oubt that this draft will falls under current media-ctrl work. As this draft= helps in SIP based devices manageability, I looked for SIP manageability re= lated WG but Sip-ops mailing alias only exists and there is no WG associated= with it. So, I'm putting this document in dispatch WG for further proceedin= gs.

Abstract is as follows:

"Collecting Resource availability information in Session Initiation Proto= col (SIP) devices in real time helps in better manageability of resources in= the SIP network. Resource availability monitoring in SIP devices helps admi= nistrator to take informed decision and corrective measures to tackle under o= r over resource utilization in the network. Resource availability informatio= n can also be used for SIP overload control in SIP based Media servers by pa= ssing resource demand vector between devices. This document defines resource= availability XML document and the mechanisms that can be used to exchange t= he document between SIP entities."

The draft is available at http://datatracker.= ietf.org/doc/draft-partha-dispatch-resource-availability/= . Could you please prov= ide your valuable comments.

Thanks

Partha


From: IETF I-D Submission Tool [mail= to:idsubmission@ietf.org]
Sent: Mon 8/30/2010 7:50 PM
To: Parthasarathi R (partr)
Cc: Sheshadri Shalya (svshesha)
Su= bject: New Version Notification for draft-partha-dispatch-resource-avail= ability-00


A new version of I-D, draft-partha-dispatch-resource-ava= ilability-00.txt has been successfully submitted by Parthasarathi R and post= ed to the IETF repository.

Filename:     &nb= sp;  draft-partha-dispatch-resource-availability
Revision: &nbs= p;      00
Title:      =      Session Initiation Protocol (SIP) Resource availabi= lity Event package
Creation_date:   2010-08-30
WG ID:  &= nbsp;        Independent Submission
Nu= mber_of_pages: 17

Abstract:
Collecting Resource availability infor= mation in Session Initiation
Protocol (SIP) devices in real time helps in= better managebility of
resources in the SIP network.  Resource avai= lability monitoring in
SIP devices helps administrator to take informed d= ecision and
corrective measures to tackle under or over resource utilizat= ion in
the network.  Resource availability information can also be u= sed for
SIP overload control in SIP based Media servers by passing resour= ce
demand vector between devices.  This document defines resourceavailability XML document and the mechanisms that can be used to
exchang= e the document between SIP entities.
      =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;           

The IETF Secretariat.


<= blockquote type=3D"cite">
________________________________________= _______
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/lis= tinfo/dispatch
= --Apple-Mail-26-40632250-- From gerardmxf@yahoo.co.uk Tue Aug 31 19:15:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F063A6A20 for ; Tue, 31 Aug 2010 19:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBoKIVmhGiK2 for ; Tue, 31 Aug 2010 19:15:01 -0700 (PDT) Received: from web24003.mail.ird.yahoo.com (web24003.mail.ird.yahoo.com [87.248.114.90]) by core3.amsl.com (Postfix) with SMTP id 5BE023A6A1E for ; Tue, 31 Aug 2010 19:15:00 -0700 (PDT) Received: (qmail 32717 invoked by uid 60001); 1 Sep 2010 02:15:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1283307328; bh=uZXyDrjTCDuBNsVYvx9dpSeT4CBP27yh1ri6mVt65as=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RReiyG2R/QtabEhhvsjR41C3UgL+vqV4AiyRlruOgQhvi6ApXMHVg1CAQeUbUWi6hMMn52hLFbGVYI4PiJ/D8Tr7IxRASrgCpzBn9MXtM8emktRsY+y+yuezaC64MsVxPEY8vpAtoVMF4BbW0SfSXcxtQqD1yyanMu6LNu/iPeQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1El4bEsc3yx6420VRNDO03rQoMvuc+Dt+wMdkG4P/zsYJqiWnV8HIQTGaKeP0DuUr7JspWDZfe48KmMcTEZQ5BB6eRpw8FNJl31Rx8KGHoUhHlLKKzKzcRGMjoJGx1q5ura5amLqC8NCEShX7YjSDC7JEVQr5oi7bCj57JV1s+0=; Message-ID: <361654.31400.qm@web24003.mail.ird.yahoo.com> X-YMail-OSG: QSUs5d0VM1lDl6bd1RGbuevFbtiDz3Xn8.yHYGUOKHVGBF9 MrudlbSLoHZHuxgADFdDgHsAxYYzH8GCQHwm8VBFAv8toC04aQ1qfgPIaSzX s9OpT_g.K6xxcd6qqXGUoW6KphoKfnqwj4ZikI4m3IoMBZcj4obGz13EMATJ 47e7OAoojXU5EXeWr2PSzLC7JBgLe2N_Y3LQ9U_bF0EyL.70Rb5XwDo.TZYs _4hHLxvZL9b_TMKEfltQABrqEtuvEDxpIQG.OvQyJH3auxaROiQ5MaWieXf4 SIzPS_TWnyae8GOQ6SNIy0Xy2VZ4JxGNBz2jS Received: from [99.113.35.251] by web24003.mail.ird.yahoo.com via HTTP; Wed, 01 Sep 2010 02:15:28 GMT X-Mailer: YahooMailRC/470 YahooMailWebService/0.8.105.279950 References: <04CAD96D4C5A3D48B1919248A8FE0D540CB60046@xmb-sjc-215.amer.cisco.com> <4C4FDB44.6070805@ericsson.com> <4C7CB06F.3000503@ericsson.com> Date: Wed, 1 Sep 2010 02:15:28 +0000 (GMT) From: Gerard Fernando To: Gonzalo Camarillo , "dispatch@ietf.org" In-Reply-To: <4C7CB06F.3000503@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1424013836-1283307328=:31400" Cc: Gerard.M.X.Fernando@zte.com.cn Subject: Re: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 02:15:06 -0000 --0-1424013836-1283307328=:31400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello,=0A=0AI also agree with you that it's not the content of the ID that = one should =0Adiscuss at this point, instead it is more the direction or po= licy of IETF with =0Aregard to this important subject. Being new to the DIS= PATCH WG discussions I'm =0Anot sure whether this has been discussed in the= last few months. =0A=0A=0ASeveral other SDO's (MPEG, 3GPP and Open IPTV F= orum) have been very active in =0Aspec. development, and there seems to be = a large degree of coordination between =0Athose SDO's. Has there been any c= oordination between them and IETF? After all... =0Ait is HTTP 1.1 that form= s the basis for those efforts!=0A=0AIt is important to understand the polic= y of IETF with regard to such efforts. I =0Ahope that IETF does have a role= to play with this activity, and would at the =0Aminimum set some guideline= s.=0A=0AThanks=0A=0AGerard=0A----------=0A=0AGerard Fernando=0AZTE Corporat= ion=0A=0A=0A=0A________________________________=0AFrom: Gonzalo Camarillo <= Gonzalo.Camarillo@ericsson.com>=0ATo: "dispatch@ietf.org" =0ASent: Tue, 31 August, 2010 0:34:07=0ASubject: Re: [dispatch] HTTP stre= aming WAS (Re: I-D =0AAction:draft-wu-http-streaming-optimization-ps-00.txt= )=0A=0AHi,=0A=0Awe have not seen any comments on this topic (HTTP streaming= ). However,=0Amany people were on vacation in August. Please, send your com= ments to=0Athis list.=0A=0AThanks,=0A=0AGonzalo=0A=0AOn 28/07/2010 10:24 AM= , Gonzalo Camarillo wrote:=0A> Hi,=0A> =0A> yes, to be clear, the idea is n= ot to only discuss this draft. The idea=0A> is to discuss what can be done = in the HTTP streaming area at the IETF (I=0A> have changes the subject of t= his email).=0A> =0A> As Ali pointed out below, this is an important area th= at is advancing=0A> fast. So, we would like to get your input sooner rather= than later.=0A> =0A> Thanks,=0A> =0A> Gonzalo=0A> =0A> =0A> On 28/07/2010 = 12:15 AM, Ali C. Begen (abegen) wrote:=0A>> (Responding to Gonzalo's email)= =0A>>=0A>> I read this draft, but I won't comment on the draft here. Rather= , I would like =0A>>to understand the goal(s) of this draft.=0A>>=0A>> HTTP= streaming, as noted by the draft, has been around for some time now and = =0A>>there are already multiple products available. Many groups besides IET= F have =0A>>shown interest in this topic and worked towards producing their= own specs in the =0A>>past year. Just last week, MPEG also joined the club= and has started evaluating =0A>>the received proposals.=0A>>=0A>> Sure, we= can discuss some of the design issues here at IETF. But, do we want to =0A= >>achieve more than that? If yes, we should be aware of the time pressure.= =0A>>=0A>> -acbegen =0A>> _______________________________________________= =0A>> dispatch mailing list=0A>> dispatch@ietf.org=0A>> https://www.ietf.or= g/mailman/listinfo/dispatch=0A>>=0A> =0A=0A________________________________= _______________=0Adispatch mailing list=0Adispatch@ietf.org=0Ahttps://www.i= etf.org/mailman/listinfo/dispatch=0A --0-1424013836-1283307328=:31400 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello,

I also agree with you that it's not the con= tent of the ID that one should discuss at this point, instead it is more th= e direction or policy of IETF with regard to this important subject. Being = new to the DISPATCH WG discussions I'm not sure whether this has been discu= ssed in the last few months. 

Several other SDO's (MPEG, 3GPP = and Open IPTV Forum) have been very active in spec. development, and there = seems to be a large degree of coordination between those SDO's. Has there b= een any coordination between them and IETF? After all... it is HTTP 1.1 tha= t forms the basis for those efforts!

It is important to understand t= he policy of IETF with regard to such efforts. I hope that IETF does have a role to play with this activity, and would at the minimum set some guideli= nes.

Thanks

Gerard
----------

Gerard Fernando
ZT= E Corporation

<= b>From: Gonzalo Camarillo <= ;Gonzalo.Camarillo@ericsson.com>
Sent: Tue, 31 August, 2010 0:34:07<= br>Subject: Re: [dispatch]= HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps= -00.txt)

Hi,

we have not seen any comments on this top= ic (HTTP streaming). However,
many people were on vacation in August. Pl= ease, send your comments to
this list.

Thanks,

Gonzalo
=
On 28/07/2010 10:24 AM, Gonzalo Camarillo wrote:
> Hi,
>
>= yes, to be clear, the idea is not to only discuss this draft. The idea
= > is to discuss what can be done in the HTTP streaming area at the IETF = (I
> have changes the subject of this email).
>
> As Ali= pointed out below, this is an important area that is advancing
> fas= t. So, we would like to get your input sooner rather than later.
> > Thanks,
>
> Gonzalo
>
>
> On 28/07/= 2010 12:15 AM, Ali C. Begen (abegen) wrote:
>> (Responding to Gonz= alo's email)
>>
>> I read this draft, but I won't comment= on the draft here. Rather, I would like to understand the goal(s) of this = draft.
>>
>> HTTP streaming, as noted by the draft, has b= een around for some time now and there are already multiple products availa= ble. Many groups besides IETF have shown interest in this topic and worked towards producing their own specs in the past year. Just last week,= MPEG also joined the club and has started evaluating the received proposal= s.
>>
>> Sure, we can discuss some of the design issues h= ere at IETF. But, do we want to achieve more than that? If yes, we should b= e aware of the time pressure.
>>
>> -acbegen
>>= _______________________________________________
>> dispatch maili= ng list
>> dispatch@ietf.org
>> https://www.ietf.org= /mailman/listinfo/dispatch
>>
>

________________= _______________________________
dispatch mailing list
dispatch@ietf.or= g
https://www.ietf.org/mailman/listinfo/dispatch
=0A
--0-1424013836-1283307328=:31400-- From partr@cisco.com Tue Aug 31 20:34:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742CD3A68E2; Tue, 31 Aug 2010 20:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.189 X-Spam-Level: X-Spam-Status: No, score=-9.189 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEBxODF1bRt9; Tue, 31 Aug 2010 20:34:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 531A03A68D0; Tue, 31 Aug 2010 20:34:55 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgGAIdmfUxAaMHG/2dsb2JhbACPYINhhRoBhzdKcaMpnBiFNwSEO4hR X-IronPort-AV: E=Sophos;i="4.56,301,1280707200"; d="scan'208,217";a="581580691" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2010 03:35:24 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o813ZN3r000827; Wed, 1 Sep 2010 03:35:23 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Sep 2010 09:05:22 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB4986.B51BFFC5" Date: Wed, 1 Sep 2010 09:05:22 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP Resource availability Event package Thread-Index: ActJVHS+ebQI6RTDRGi7fyArDuPY7QAMOJfF References: <20100830142058.6A0EA3A69B8@core3.amsl.com> <5D9746F9-9D36-4482-8B61-94AED338EDE2@gmail.com> From: "Parthasarathi R (partr)" To: "Michael Miller" X-OriginalArrivalTime: 01 Sep 2010 03:35:22.0830 (UTC) FILETIME=[B56A9EE0:01CB4986] Cc: sip-ops@ietf.org, dispatch@ietf.org, sip-overload@ietf.org, mediactrl@ietf.org Subject: Re: [dispatch] SIP Resource availability Event package X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 03:34:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB4986.B51BFFC5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael, =20 Thanks for the comment. In the draft, Almost-out-of-resource element for = the particular resource has to be used whenever the resource is reaching = the critical condition (threshold) and it is explained in sec 5.4.1. = Almost-out-of-resource indication provides the alert to the = administrator about overuse of the specific resource in a particular = device. I'll add the text in the resource availability indication = mechanism for providing more clarity. =20 Thanks Partha ________________________________ From: Michael Miller [mailto:mlm.michael.miller@gmail.com] Sent: Wed 9/1/2010 3:05 AM To: Parthasarathi R (partr) Cc: ; sip-ops@ietf.org; sip-overload@ietf.org; = mediactrl@ietf.org Subject: Re: [dispatch] SIP Resource availability Event package This draft looks pretty good. Should there be language that saids = management servers are alerted of critical conditions or is that outside = of this draft? Michael L. Miller Sent from my Mobile Device On Aug 30, 2010, at 12:51 PM, "Parthasarathi R (partr)" = wrote: =09 Resource availability information from SIP devices improves the = manageability of SIP devices by providing a framework for multiple = applications like Resource utilization monitoring, overload handling in = SIP based media servers.=20 This draft was discussed in IETF-78 SoC WG and considered as outside = the scope of SOC as it focus on SIP overload based on non-critical = resources like DS0, DSP. By looking at the mediactrl WG charter and = working documents, I doubt that this draft will falls under current = media-ctrl work. As this draft helps in SIP based devices manageability, = I looked for SIP manageability related WG but Sip-ops mailing alias only = exists and there is no WG associated with it. So, I'm putting this = document in dispatch WG for further proceedings.=20 Abstract is as follows: "Collecting Resource availability information in Session Initiation = Protocol (SIP) devices in real time helps in better manageability of = resources in the SIP network. Resource availability monitoring in SIP = devices helps administrator to take informed decision and corrective = measures to tackle under or over resource utilization in the network. = Resource availability information can also be used for SIP overload = control in SIP based Media servers by passing resource demand vector = between devices. This document defines resource availability XML = document and the mechanisms that can be used to exchange the document = between SIP entities." =09 The draft is available at = http://datatracker.ietf.org/doc/draft-partha-dispatch-resource-availabili= ty/ = . Could you please provide your valuable comments. Thanks Partha =09 =09 ________________________________ From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Mon 8/30/2010 7:50 PM To: Parthasarathi R (partr) Cc: Sheshadri Shalya (svshesha) Subject: New Version Notification for = draft-partha-dispatch-resource-availability-00=20 =09 =09 =09 A new version of I-D, = draft-partha-dispatch-resource-availability-00.txt has been successfully = submitted by Parthasarathi R and posted to the IETF repository. =09 Filename: draft-partha-dispatch-resource-availability Revision: 00 Title: Session Initiation Protocol (SIP) Resource = availability Event package Creation_date: 2010-08-30 WG ID: Independent Submission Number_of_pages: 17 =09 Abstract: Collecting Resource availability information in Session Initiation Protocol (SIP) devices in real time helps in better managebility of resources in the SIP network. Resource availability monitoring in SIP devices helps administrator to take informed decision and corrective measures to tackle under or over resource utilization in the network. Resource availability information can also be used for SIP overload control in SIP based Media servers by passing resource demand vector between devices. This document defines resource availability XML document and the mechanisms that can be used to exchange the document between SIP entities. = =20 =09 =09 The IETF Secretariat. =09 =09 =09 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =09 ------_=_NextPart_001_01CB4986.B51BFFC5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Michael,
=0A=
 
=0A=
Thanks for the comment. In = the draft, Almost-out-of-resource element for the = particular resource has to be used whenever the resource is = reaching the critical condition (threshold) and it is explained in = sec 5.4.1. Almost-out-of-resource indication provides the alert to = the administrator about overuse of the specific resource in a = particular device. I'll add the text in the resource availability = indication mechanism for providing more clarity.
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=

=0A=
=0A= From: Michael Miller = [mailto:mlm.michael.miller@gmail.com]
Sent: Wed 9/1/2010 3:05 = AM
To: Parthasarathi R (partr)
Cc: = <dispatch@ietf.org>; sip-ops@ietf.org; sip-overload@ietf.org; = mediactrl@ietf.org
Subject: Re: [dispatch] SIP Resource = availability Event package

=0A=
=0A=
This draft looks pretty good. Should there be language that saids = management servers are alerted of critical conditions or is that outside = of this draft?
=0A=

=0A=
Michael L. Miller
=0A=
Sent from my Mobile Device
=0A=

On Aug 30, 2010, at 12:51 PM, "Parthasarathi R (partr)" <partr@cisco.com> = wrote:

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=

Resource availability information from SIP devices improves the = manageability of SIP devices by providing a framework for multiple = applications like Resource utilization monitoring, overload handling in = SIP based media servers.

=0A=

This draft was discussed in IETF-78 SoC WG and considered as outside = the scope of SOC as it focus on SIP overload based on non-critical = resources like DS0, DSP. By looking at the mediactrl WG charter and = working documents, I doubt that this draft will falls under current = media-ctrl work. As this draft helps in SIP based devices manageability, = I looked for SIP manageability related WG but Sip-ops mailing alias only = exists and there is no WG associated with it. So, I'm putting this = document in dispatch WG for further proceedings.

=0A=

Abstract is as follows:

=0A=

"Collecting Resource availability information in Session Initiation = Protocol (SIP) devices in real time helps in better manageability of = resources in the SIP network. Resource availability monitoring in SIP = devices helps administrator to take informed decision and corrective = measures to tackle under or over resource utilization in the network. = Resource availability information can also be used for SIP overload = control in SIP based Media servers by passing resource demand vector = between devices. This document defines resource availability XML = document and the mechanisms that can be used to exchange the document = between SIP entities."

=0A=

=0A=

The draft is available at http://datatracker.ietf.org/doc/draft-partha-dispatch-resource-= availability/. Could you please provide your valuable = comments.

=0A=

Thanks

=0A=

Partha

=0A=


=0A=
=0A= From: IETF I-D Submission Tool = [mailto:idsubmission@ietf.org]
Sent: Mon 8/30/2010 7:50 = PM
To: Parthasarathi R (partr)
Cc: Sheshadri Shalya = (svshesha)
Subject: New Version Notification for = draft-partha-dispatch-resource-availability-00

=0A=

=0A=

=0A=

A new version of I-D, = draft-partha-dispatch-resource-availability-00.txt has been successfully = submitted by Parthasarathi R and posted to the IETF = repository.

Filename:        = draft-partha-dispatch-resource-availability
Revision:   = ;     00
Title:  =          Session Initiation = Protocol (SIP) Resource availability Event = package
Creation_date:   2010-08-30
WG ID:  =          Independent = Submission
Number_of_pages: 17

Abstract:
Collecting = Resource availability information in Session Initiation
Protocol = (SIP) devices in real time helps in better managebility of
resources = in the SIP network.  Resource availability monitoring in
SIP = devices helps administrator to take informed decision and
corrective = measures to tackle under or over resource utilization in
the = network.  Resource availability information can also be used = for
SIP overload control in SIP based Media servers by passing = resource
demand vector between devices.  This document defines = resource
availability XML document and the mechanisms that can be = used to
exchange the document between SIP = entities.
          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          


= The IETF Secretariat.


=0A=
=0A=
_______________________________________________
dispatch mailing list
dispatch@ietf.org
<= A = href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.= org/mailman/listinfo/dispatch
------_=_NextPart_001_01CB4986.B51BFFC5-- From christer.holmberg@ericsson.com Tue Aug 31 23:56:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9317B3A6AE2 for ; Tue, 31 Aug 2010 23:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.026 X-Spam-Level: X-Spam-Status: No, score=-5.026 tagged_above=-999 required=5 tests=[AWL=0.973, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfRezYcfIvZ9 for ; Tue, 31 Aug 2010 23:56:14 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 26BF23A67B4 for ; Tue, 31 Aug 2010 23:56:13 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-fa-4c7df92bb632 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6F.DE.10125.B29FD7C4; Wed, 1 Sep 2010 08:56:43 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.78]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 1 Sep 2010 08:56:43 +0200 From: Christer Holmberg To: "Allyn Romanow (allyn)" Date: Wed, 1 Sep 2010 08:56:42 +0200 Thread-Topic: Telepresence Charter Version 3 Thread-Index: ActFNuVOJfX41wneSPW4t8iSNZv3WAAP3SZgAQsZVXA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850150D9BD@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FE615@xmb-sjc-221.amer.cisco.com> <5141CABF-6718-40AD-8BB8-38B4938FBB1A@cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FEB70@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC023FEB70@xmb-sjc-221.amer.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: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] Telepresence Charter Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 06:56:18 -0000 Hi, =20 A question for clarification. =20 The proposed charter says that there exists telepresence systems based on d= ifferent standards (SIP, H.xxx etc), and that today expensive interworking equipment is required in order for these systems to interop. =20 But, how can you prevent such interworking? If whatever we specify is suppo= sed to be backward compatible with standards compliant systems, you cannot = assume that every system will support e.g. SIP. =20 Regards, =20 Christer =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) > Sent: 27. elokuuta 2010 2:31 > To: Cullen Jennings (fluffy) > Cc: DISPATCH list > Subject: Re: [dispatch] Telepresence Charter Version 3 >=20 > WRT my previous note suggesting the change to Cullen's=20 > sentence, people should be clear that everything not in the=20 > charter is out of scope.=20 > So please think about anything that you think we need to=20 > cover which is not now explicitly called out in the charter. >=20 > thanks >=20 > -----Original Message----- > From: Cullen Jennings (fluffy) > Sent: Thursday, August 26, 2010 8:54 AM > To: Allyn Romanow (allyn) > Cc: DISPATCH list; Mary Barnes > Subject: Re: Telepresence Charter Version 3 >=20 >=20 > I think this charter has some pretty serious issues with being way to > wide open on what the scope is. The fact we are actually discussing if > we need to add in "Also not in scope is signaling to tell the > originator to which IP addresses the media streams should be sent" > should be a huge hint that we have the scope much too broad.=20 > As I said a > week ago ....=20 >=20 > Begin forwarded message: >=20 > > From: Cullen Jennings > > Date: August 18, 2010 11:16:22 AM MDT >=20 > > Main point: > > When I read this charter and ask myself what is out of=20 > scope, it seems > that anything that is "the information about media streams from one > endpoint to another endpoint or conference bridge including"=20 > would be in > scope. I realize a few more things are taken our of scope=20 > later but the > resulting space includes just about everything that MMUSIC does, and > much of what SIP does. Because of the "anything and=20 > everything" approach > I don't think this is a charter that will result in work that=20 > gets done > quickly. From the point of view of being broad enough to do the need > work, I think it's fine but from the point of view of being narrow > enough to limit the work to something that is possible to complete, it > seems pretty bad. I suspect that IESG would likely look at this as a > "blank cheque" charter and ask for some changes to it. My suggestion > would be just to change the "including (but not limited to):" in 3rd > paragraph to be=20 > >=20 > > This working group is chartered to specify the following information > about media streams from one endpoint to another endpoint: > >=20 >=20 > Note I am not arguing that there any given piece of work you=20 > should not > do - I'm just encouraging you to say what problems you are=20 > going to do. >=20 > I would encourage you to specify what this working group is=20 > going to do, > like you have in the bullet points, and stop leaving it open to do > anything including the stuff in bullet points. We should do=20 > our best to > avoid charters that are so unspecific that they overlap with existing > WGs in ways that leave huge questions about which WG a new=20 > piece of work > should go to.=20 >=20 > Cullen >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > =