From gonzalo.camarillo@ericsson.com Thu Mar 1 03:14:58 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854AB21F86A0 for ; Thu, 1 Mar 2012 03:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.252 X-Spam-Level: X-Spam-Status: No, score=-110.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeGhY6B1Rujv for ; Thu, 1 Mar 2012 03:14:58 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A9DC921F8673 for ; Thu, 1 Mar 2012 03:14:57 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-10-4f4f5a2b5c93 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3A.BA.27041.B2A5F4F4; Thu, 1 Mar 2012 12:14:51 +0100 (CET) Received: from [131.160.36.168] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Mar 2012 12:14:51 +0100 Message-ID: <4F4F5A2B.6060901@ericsson.com> Date: Thu, 1 Mar 2012 13:14:51 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: DISPATCH References: <4F467798.1060805@ericsson.com> In-Reply-To: <4F467798.1060805@ericsson.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:14:58 -0000 Hi, it seems there is rough consensus to use INSIPID as the acronym for this WG. Additionally, it seems explicit enough for people to remember what the WG is about. INSIPID: INtermediary-safe SIP session ID Thanks Dean! :-) Cheers, Gonzalo On 23/02/2012 7:30 PM, Gonzalo Camarillo wrote: > Folks, > > as you know, we are in the process of chartering the SIP Session ID WG. > As usual, we need an acronym for this new group. Any suggestions? > > Note that I will be making a decision about this real soon. I will take > into consideration all the input I receive before that. > > Cheers, > > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From gonzalo.camarillo@ericsson.com Thu Mar 1 03:23:14 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EBB21F8667 for ; Thu, 1 Mar 2012 03:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.257 X-Spam-Level: X-Spam-Status: No, score=-110.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTrLxL8tutqR for ; Thu, 1 Mar 2012 03:23:14 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA2C21F859B for ; Thu, 1 Mar 2012 03:23:13 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-0c-4f4f5c213336 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B5.BC.01970.12C5F4F4; Thu, 1 Mar 2012 12:23:13 +0100 (CET) Received: from [131.160.36.168] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Mar 2012 12:23:06 +0100 Message-ID: <4F4F5C19.9070607@ericsson.com> Date: Thu, 1 Mar 2012 13:23:05 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Charter process for the INSIPID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:23:15 -0000 Folks, Robert and I have been working on a charter proposal for the INSIPID WG. This is the proposal that we have sent for review to the IESG and IAB: http://www.ietf.org/iesg/evaluation/sessionid-charter.txt We believe this proposal represents the consensus of the group. Note that we have left out some comments that failed to get rough consensus on this list. >From now on, I will be taking care of the chartering process for this WG. Today, I will discuss the charter proposal with the IESG and, if everything goes OK, we will be sending it for external review shortly. If you have further comments on the charter proposal, please send them as part of its external review, which will be announced on the IETF announcement list as usual. Also, I am going to be requesting the creation of the insipid mailing list. Cheers, Gonzalo From Peter.Dawes@vodafone.com Thu Mar 1 03:56:49 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907AC21F85A4 for ; Thu, 1 Mar 2012 03:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfWsHGM1WvwN for ; Thu, 1 Mar 2012 03:56:49 -0800 (PST) Received: from mailout04.vodafone.com (mailout04.vodafone.com [195.232.224.73]) by ietfa.amsl.com (Postfix) with ESMTP id A123821F858D for ; Thu, 1 Mar 2012 03:56:48 -0800 (PST) Received: from mailint04 (localhost [127.0.0.1]) by mailout04 (Postfix) with ESMTP id 3FF00132995 for ; Thu, 1 Mar 2012 12:56:46 +0100 (CET) Received: from avoexs02.internal.vodafone.com (unknown [145.230.4.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint04 (Postfix) with ESMTPS id 30B061326B8; Thu, 1 Mar 2012 12:56:46 +0100 (CET) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 12:56:19 +0100 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_01CCF7A2.50A95F8E" Date: Thu, 1 Mar 2012 12:56:18 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Media Plane Security draft-dawes-dispatch-mediasec-parameter-05 Thread-Index: Acz3olAJ6Pyn3sn6SZmN0imdS6zIKw== From: "Dawes, Peter, VF-Group" To: X-OriginalArrivalTime: 01 Mar 2012 11:56:19.0887 (UTC) FILETIME=[50C6CBF0:01CCF7A2] Cc: fluffy@cisco.com, mary.barnes@polycom.com Subject: [dispatch] Media Plane Security draft-dawes-dispatch-mediasec-parameter-05 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:56:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF7A2.50A95F8E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, I would like to try to progress discussion of http://www.ietf.org/id/draft-dawes-dispatch-mediasec-parameter-05.txt, which proposes negotiation of security for the media plane by extending an existing RFC (RFC 3329) that applies to the signalling plane. This draft is also 3GPP related. =20 One way to provide security on the media plane of a session set up using SIP is using DTLS-SRTP but this solution was not chosen by the 3GPP security group for the reasons in clause 1.1.2.2 of draft-dawes-dispatch-mediasec-parameter-05 and also because it was considered very difficult to use in a terminal to access network edge mode. =20 >From previous discussion on this e-mail list, the issues to resolve seem to be 1) DTLS-SRTP already exists so should IETF describe an alternative? 2) questions about using media security between a UA and a media gateway at the access network edge versus end-to-end, i.e.=20 =20 |UA| ----encrypted media---- | Access Edge Media Gateway | ----unencrypted media---- |Access Edge Media Gateway| ----encrypted media---- |UA| =20 The draft itself tries to answer these concerns (in the sub-clauses of 1.1 in particular) and previous comments on this topic can be found by looking for Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 on dates: =20 Jun 15 2010 May 20 - 27 2010 May 07 2010 April 27 - May 03 2010 =20 As a first step, I would be interested to hear whether anyone still objects in principle to progressing this draft for reasons 1) or 2) above or any other reason? Regards, Peter =20 ------_=_NextPart_001_01CCF7A2.50A95F8E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = All,

I would like to try = to progress discussion of = http://www.ietf.org/id/draft-dawes-dispatch-mediasec-parameter-05.txt, = which proposes negotiation of security for the media plane by extending = an existing RFC (RFC 3329) that applies to the signalling plane. This = draft is also 3GPP related.

 

One way to provide = security on the media plane of a session set up using SIP is using = DTLS-SRTP but this solution was not chosen by the 3GPP security group = for the reasons in clause 1.1.2.2 of = draft-dawes-dispatch-mediasec-parameter-05 and also because it was = considered very difficult to use in a terminal to access network edge = mode.

 

From previous = discussion on this e-mail list, the issues to resolve seem to be 1) = DTLS-SRTP already exists so should IETF describe an alternative? 2) = questions about using media security between a UA and a media gateway at = the access network edge versus end-to-end, i.e.

        <= /p>

|UA| ----encrypted = media---- | Access Edge Media Gateway | ----unencrypted media---- = |Access Edge Media Gateway| ----encrypted media---- = |UA|

 

The draft itself = tries to answer these concerns (in the sub-clauses of 1.1 in particular) = and previous comments on this topic can be found by looking for Subject: = Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 on = dates:

 

Jun 15 = 2010

May 20 - 27 = 2010

May 07 = 2010

April 27 - May 03 = 2010

 

As a first step, I = would be interested to hear whether anyone still objects in principle to = progressing this draft for reasons 1) or 2) above or any other = reason?

=

Regards,

Peter

 

------_=_NextPart_001_01CCF7A2.50A95F8E-- From sohel_khan777@yahoo.com Thu Mar 1 14:28:20 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BC921E838E for ; Thu, 1 Mar 2012 14:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLxoA42i7MG5 for ; Thu, 1 Mar 2012 14:28:19 -0800 (PST) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with SMTP id 254CA21E836D for ; Thu, 1 Mar 2012 14:28:19 -0800 (PST) Received: from [98.139.215.142] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2012 22:28:13 -0000 Received: from [98.139.212.242] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2012 22:28:13 -0000 Received: from [127.0.0.1] by omp1051.mail.bf1.yahoo.com with NNFMP; 01 Mar 2012 22:28:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 648114.65859.bm@omp1051.mail.bf1.yahoo.com Received: (qmail 27404 invoked by uid 60001); 1 Mar 2012 22:28:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1330640893; bh=uVTowWUiB+PP5jONdv1McEPzgC0QgE/+uD3oUhVoUM8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=d0k81pESF6I5092lruODNjD9en237IUlssGtsGX2lcXI4PNAQ6DZVRODrsVdO8n0W0Bt6bgtKnBglRVIDtan1zxWTSocjSfm7g+E5BgYaazv4eG6do+OfWSMkN5UvBgtbx7VR4//Ei2J9iwlcn8fUS6jlJHTb6rTUzihSExkm10= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=46td7BQ+BBnOtKfOnfQg4gyAMuXn7ifUPeycO2QwSc9VqGAbv5c20oBRy6kw7tLKm+dkLuQ0DQ4pbrVV0rxTbetvCsguSl+taEvNSD9JmxC8bb9R7B7iYzTuTHmbd1ivniVmSvl+n0Qu867QGb54QaIH2FId0cjVCHqukerL6ho=; X-YMail-OSG: TLlUTbUVM1lOn6SF2TAA3cUDLYz05S7OnfTK5TGCumAx0XY 0SQDHLdAsse7tHhrRiAzy2ihkaxxUUJ6RMDkAsb48jup0Aw.AT8jByajJfy_ YR5M7HBUOllUosN6XgQeMZCIKFB0N2ZBpaNoPSY.P0BcQeusBE6XxJlbwTlF RsgN9EagjXr51FGPgYidZOBntqPtc8tXcJFRKke28Jhb4H3sJbgUvoy_WcAB O4IDQl45DJXGWV2NFbdrAtBsr3hWU0iHxiL5obBUE1Ner8DNkkTFsJarStn4 4L.jZ27Gdjh9nyORIYZKhyq4jvUvRP4OKy8D8UXgNjZxL00RHcY5ViPup77M qvBAYckPs8fKSq9oI.1pfyABCw7XN94DRzAPWkGesaMoFTpnQX42iSDHRwYO l25.OE619hAlHMviK94IVqGlNkk40lImYvrDiKYU6gmdq.FpFGzQfh2o_aV0 cXxbXz6jwS2zRiRMzYg-- Received: from [69.241.19.12] by web162003.mail.bf1.yahoo.com via HTTP; Thu, 01 Mar 2012 14:28:12 PST X-Mailer: YahooMailWebService/0.8.116.338427 Message-ID: <1330640892.23608.YahooMailNeo@web162003.mail.bf1.yahoo.com> Date: Thu, 1 Mar 2012 14:28:12 -0800 (PST) From: Sohel Khan To: "dispatch@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1705842018-933661546-1330640892=:23608" Subject: [dispatch] Proposal: ESPID Sequence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:28:20 -0000 --1705842018-933661546-1330640892=:23608 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We are proposing a small charter to develop a SIP standard to=0Aadd a SIP S= equence header. Kindly review the charter. appreciate your=0Afeedback.=0A= =C2=A0=0ASIP Loop among SIP providers is a growing phenomenon. =C2=A0For=0A= example, SIP request messages traverse various providers and loop back to= =0Aprevious providers due to the parity of the routing vectors. In another= =0Aexample, SIP messages traverse multiple service providers in a loop beca= use of=0Athe origination-destination session forwarding to each other. SIP = loops are=0Aoften amplified causing operational disruption in the SIP netwo= rks.=0A=C2=A0=0AIn the absence of B2BUA in session paths or a presence of a= =0Astandard SIP compliant B2BUA that does not remove/reset SIP parameters, = many of=0Athe current SIP headers can aid in detecting multi-provider loop.= These headers=0Ahave some limitations. For example, an optimum default val= ue for Max-Forwards=0Ais hard to determine since the number of nodes in the= session path is time/path=0Avariant depending on the origination-destinati= on route vector among SIP=0Aproviders. SIP History-Info is another header t= hat also aid in detecting loop=0Aamong multiple SIP providers. SIP History-= Info depicts node information in the=0Asession path. The parameter in the= =C2=A0History-Info is not often the fixed=0Asize; thus, it is difficult to = extract providers' names.=C2=A0A SIP request may traverse a set of nodes in= a=0Aservice provider=E2=80=99s network, may loop around the world, and may= enter the=0Aprevious SIP providers=E2=80=99 networks in a different set of= nodes; thus, the new=0Anodes may not know that the call had traversed=C2= =A0the same SIP providers'=0Anetworks in the past.=0A=C2=A0=0A=C2=A0The cha= rter is to develop=0Aan Encrypted SIP Provider Identity (ESPID) Sequence he= ader such that a provider=0Acan detect itself-only, while maintaining priva= cy and preserving SIP=0Aflexibility such as call forwarding. The ESPID sequ= ence contains identity of=0ASIP Providers in the order a session has propag= ated through the SIP providers.=0AA SIP provider shall only be able to dete= ct its own identity in the sequence. A=0ASIP provider wishing not to disclo= se its identity to other providers shall be=0Aable to encrypt its identity.= A SIP provider not wishing to include its=0Ainformation in the sequence ma= y do so by not adding any information. Inclusion=0Aof the ESPID header is m= andatory. A SIP provider shall not remove the ESPID=0Aheader from a SIP mes= sage traversing its network. =C2=A0=0A=C2=A0=0ASIP Provider ID (SPID) stand= ard development is outside the scope=0Aof this charter. =C2=A0ESPID activit= y will coordinate with SPID activity=0Adeveloped through SPID charter.=0A= =C2=A0=0ARegards,=0ASohel Khan --1705842018-933661546-1330640892=:23608 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A
=0A=0A 
=0A=0A
SIP Loop among SIP providers is = a growing phenomenon.  For=0Aexample, SIP request messages traverse va= rious providers and loop back to=0Aprevious providers due to the parity of = the routing vectors. In another=0Aexample, SIP messages traverse multiple s= ervice providers in a loop because of=0Athe origination-destination session= forwarding to each other. SIP loops are=0Aoften amplified causing operatio= nal disruption in the SIP networks.
=0A=0A
 
=0A=0A
= In the absence of B2BUA in session paths or a presence of a=0Astandard SIP = compliant B2BUA that does not remove/reset SIP parameters, many of=0Athe cu= rrent SIP headers can aid in detecting multi-provider loop. These headers= =0Ahave some limitations. For example, an optimum default value for Max-For= wards=0Ais hard to determine since the number of nodes in the session path = is time/path=0Avariant depending on the origination-destination route vecto= r among SIP=0Aproviders. SIP History-Info is another header that also aid i= n detecting loop=0Aamong multiple SIP providers. SIP History-Info depicts n= ode information in the=0Asession path. The parameter in the History-In= fo is not often the fixed=0Asize; thus, it is difficult to extract provider= s' names. A SIP request may trav= erse a set of nodes in a=0Aservice provider=E2=80=99s network, may loop aro= und the world, and may enter the=0Aprevious SIP providers=E2=80=99 networks= in a different set of nodes; thus, the new=0Anodes may not know that the c= all had traversed the same SIP providers'=0Anetworks in the past.=
=0A=0A
 
=0A=0A
 The = charter is to develop=0Aan Encrypted SIP Provider Identity (ESPID) Sequence= header such that a provider=0Acan detect itself-only, while maintaining pr= ivacy and preserving SIP=0Aflexibility such as call forwarding. The ESPID s= equence contains identity of=0ASIP Providers in the order a session has pro= pagated through the SIP providers.=0AA SIP provider shall only be able to d= etect its own identity in the sequence. A=0ASIP provider wishing not to dis= close its identity to other providers shall be=0Aable to encrypt its identi= ty. A SIP provider not wishing to include its=0Ainformation in the sequence= may do so by not adding any information. Inclusion=0Aof the ESPID header i= s mandatory. A SIP provider shall not remove the ESPID=0Aheader from a SIP = message traversing its network.  <= /o:p>
=0A=0A
 
=0A=0A
SIP Provide= r ID (SPID) standard development is outside the scope=0Aof this charter. &n= bsp;ESPID activity will coordinate with SPID activity=0Adeveloped through S= PID charter.
=0A=0A
 
Regards,
Sohel Khan
--1705842018-933661546-1330640892=:23608-- From pravindran@sonusnet.com Thu Mar 1 16:53:54 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8136E21E80CD for ; Thu, 1 Mar 2012 16:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkcwLm7bqjI9 for ; Thu, 1 Mar 2012 16:53:53 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2A63621E8066 for ; Thu, 1 Mar 2012 16:53:52 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q220sdXl021202; Thu, 1 Mar 2012 19:54:39 -0500 Received: from USMA-EX-HUB1.sonusnet.com ([66.203.90.16]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 19:53:50 -0500 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 1 Mar 2012 19:53:52 -0500 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Fri, 2 Mar 2012 06:23:46 +0530 From: "Ravindran, Parthasarathi" To: Sohel Khan , "dispatch@ietf.org" Thread-Topic: [dispatch] Proposal: ESPID Sequence Charter Thread-Index: AQHM9/qg7BXA/RIoY0aHTre38cUC5JZWLSDw Date: Fri, 2 Mar 2012 00:53:45 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E142044@inba-mail02.sonusnet.com> References: <1330640892.23608.YahooMailNeo@web162003.mail.bf1.yahoo.com> In-Reply-To: <1330640892.23608.YahooMailNeo@web162003.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E142044inbamail02sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2012 00:53:50.0396 (UTC) FILETIME=[EEA58FC0:01CCF80E] Subject: Re: [dispatch] Proposal: ESPID Sequence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 00:53:54 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E142044inbamail02sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29oZWwsDQoNClBsZWFzZSBsZXQgbWUga25vdyB3aGV0aGVyIFNlc3Npb24gaWQgbWVudGlvbnMg aW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtaXBtYy1zZXNzaW9uLWlk LTAzIGhlbHBzIHRvIHNvbHZlIHRoZSBzYW1lIGlzc3VlLg0KDQpCZWNhdXNlIHNlc3Npb24taWQg YWxzbyB0cmF2ZXJzZXMgdGhyb3VnaCBhbGwgQjJCVUEuDQoNClRoYW5rcw0KUGFydGhhDQoNCkZy b206IGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgU29oZWwgS2hhbg0KU2VudDogRnJpZGF5LCBNYXJjaCAwMiwg MjAxMiAzOjU4IEFNDQpUbzogZGlzcGF0Y2hAaWV0Zi5vcmcNClN1YmplY3Q6IFtkaXNwYXRjaF0g UHJvcG9zYWw6IEVTUElEIFNlcXVlbmNlIENoYXJ0ZXINCg0KV2UgYXJlIHByb3Bvc2luZyBhIHNt YWxsIGNoYXJ0ZXIgdG8gZGV2ZWxvcCBhIFNJUCBzdGFuZGFyZCB0byBhZGQgYSBTSVAgU2VxdWVu Y2UgaGVhZGVyLiBLaW5kbHkgcmV2aWV3IHRoZSBjaGFydGVyLiBhcHByZWNpYXRlIHlvdXIgZmVl ZGJhY2suDQoNClNJUCBMb29wIGFtb25nIFNJUCBwcm92aWRlcnMgaXMgYSBncm93aW5nIHBoZW5v bWVub24uICBGb3IgZXhhbXBsZSwgU0lQIHJlcXVlc3QgbWVzc2FnZXMgdHJhdmVyc2UgdmFyaW91 cyBwcm92aWRlcnMgYW5kIGxvb3AgYmFjayB0byBwcmV2aW91cyBwcm92aWRlcnMgZHVlIHRvIHRo ZSBwYXJpdHkgb2YgdGhlIHJvdXRpbmcgdmVjdG9ycy4gSW4gYW5vdGhlciBleGFtcGxlLCBTSVAg bWVzc2FnZXMgdHJhdmVyc2UgbXVsdGlwbGUgc2VydmljZSBwcm92aWRlcnMgaW4gYSBsb29wIGJl Y2F1c2Ugb2YgdGhlIG9yaWdpbmF0aW9uLWRlc3RpbmF0aW9uIHNlc3Npb24gZm9yd2FyZGluZyB0 byBlYWNoIG90aGVyLiBTSVAgbG9vcHMgYXJlIG9mdGVuIGFtcGxpZmllZCBjYXVzaW5nIG9wZXJh dGlvbmFsIGRpc3J1cHRpb24gaW4gdGhlIFNJUCBuZXR3b3Jrcy4NCg0KSW4gdGhlIGFic2VuY2Ug b2YgQjJCVUEgaW4gc2Vzc2lvbiBwYXRocyBvciBhIHByZXNlbmNlIG9mIGEgc3RhbmRhcmQgU0lQ IGNvbXBsaWFudCBCMkJVQSB0aGF0IGRvZXMgbm90IHJlbW92ZS9yZXNldCBTSVAgcGFyYW1ldGVy cywgbWFueSBvZiB0aGUgY3VycmVudCBTSVAgaGVhZGVycyBjYW4gYWlkIGluIGRldGVjdGluZyBt dWx0aS1wcm92aWRlciBsb29wLiBUaGVzZSBoZWFkZXJzIGhhdmUgc29tZSBsaW1pdGF0aW9ucy4g Rm9yIGV4YW1wbGUsIGFuIG9wdGltdW0gZGVmYXVsdCB2YWx1ZSBmb3IgTWF4LUZvcndhcmRzIGlz IGhhcmQgdG8gZGV0ZXJtaW5lIHNpbmNlIHRoZSBudW1iZXIgb2Ygbm9kZXMgaW4gdGhlIHNlc3Np b24gcGF0aCBpcyB0aW1lL3BhdGggdmFyaWFudCBkZXBlbmRpbmcgb24gdGhlIG9yaWdpbmF0aW9u LWRlc3RpbmF0aW9uIHJvdXRlIHZlY3RvciBhbW9uZyBTSVAgcHJvdmlkZXJzLiBTSVAgSGlzdG9y eS1JbmZvIGlzIGFub3RoZXIgaGVhZGVyIHRoYXQgYWxzbyBhaWQgaW4gZGV0ZWN0aW5nIGxvb3Ag YW1vbmcgbXVsdGlwbGUgU0lQIHByb3ZpZGVycy4gU0lQIEhpc3RvcnktSW5mbyBkZXBpY3RzIG5v ZGUgaW5mb3JtYXRpb24gaW4gdGhlIHNlc3Npb24gcGF0aC4gVGhlIHBhcmFtZXRlciBpbiB0aGUg SGlzdG9yeS1JbmZvIGlzIG5vdCBvZnRlbiB0aGUgZml4ZWQgc2l6ZTsgdGh1cywgaXQgaXMgZGlm ZmljdWx0IHRvIGV4dHJhY3QgcHJvdmlkZXJzJyBuYW1lcy4gQSBTSVAgcmVxdWVzdCBtYXkgdHJh dmVyc2UgYSBzZXQgb2Ygbm9kZXMgaW4gYSBzZXJ2aWNlIHByb3ZpZGVy4oCZcyBuZXR3b3JrLCBt YXkgbG9vcCBhcm91bmQgdGhlIHdvcmxkLCBhbmQgbWF5IGVudGVyIHRoZSBwcmV2aW91cyBTSVAg cHJvdmlkZXJz4oCZIG5ldHdvcmtzIGluIGEgZGlmZmVyZW50IHNldCBvZiBub2RlczsgdGh1cywg dGhlIG5ldyBub2RlcyBtYXkgbm90IGtub3cgdGhhdCB0aGUgY2FsbCBoYWQgdHJhdmVyc2VkIHRo ZSBzYW1lIFNJUCBwcm92aWRlcnMnIG5ldHdvcmtzIGluIHRoZSBwYXN0Lg0KDQogVGhlIGNoYXJ0 ZXIgaXMgdG8gZGV2ZWxvcCBhbiBFbmNyeXB0ZWQgU0lQIFByb3ZpZGVyIElkZW50aXR5IChFU1BJ RCkgU2VxdWVuY2UgaGVhZGVyIHN1Y2ggdGhhdCBhIHByb3ZpZGVyIGNhbiBkZXRlY3QgaXRzZWxm LW9ubHksIHdoaWxlIG1haW50YWluaW5nIHByaXZhY3kgYW5kIHByZXNlcnZpbmcgU0lQIGZsZXhp YmlsaXR5IHN1Y2ggYXMgY2FsbCBmb3J3YXJkaW5nLiBUaGUgRVNQSUQgc2VxdWVuY2UgY29udGFp bnMgaWRlbnRpdHkgb2YgU0lQIFByb3ZpZGVycyBpbiB0aGUgb3JkZXIgYSBzZXNzaW9uIGhhcyBw cm9wYWdhdGVkIHRocm91Z2ggdGhlIFNJUCBwcm92aWRlcnMuIEEgU0lQIHByb3ZpZGVyIHNoYWxs IG9ubHkgYmUgYWJsZSB0byBkZXRlY3QgaXRzIG93biBpZGVudGl0eSBpbiB0aGUgc2VxdWVuY2Uu IEEgU0lQIHByb3ZpZGVyIHdpc2hpbmcgbm90IHRvIGRpc2Nsb3NlIGl0cyBpZGVudGl0eSB0byBv dGhlciBwcm92aWRlcnMgc2hhbGwgYmUgYWJsZSB0byBlbmNyeXB0IGl0cyBpZGVudGl0eS4gQSBT SVAgcHJvdmlkZXIgbm90IHdpc2hpbmcgdG8gaW5jbHVkZSBpdHMgaW5mb3JtYXRpb24gaW4gdGhl IHNlcXVlbmNlIG1heSBkbyBzbyBieSBub3QgYWRkaW5nIGFueSBpbmZvcm1hdGlvbi4gSW5jbHVz aW9uIG9mIHRoZSBFU1BJRCBoZWFkZXIgaXMgbWFuZGF0b3J5LiBBIFNJUCBwcm92aWRlciBzaGFs bCBub3QgcmVtb3ZlIHRoZSBFU1BJRCBoZWFkZXIgZnJvbSBhIFNJUCBtZXNzYWdlIHRyYXZlcnNp bmcgaXRzIG5ldHdvcmsuDQoNClNJUCBQcm92aWRlciBJRCAoU1BJRCkgc3RhbmRhcmQgZGV2ZWxv cG1lbnQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBjaGFydGVyLiAgRVNQSUQgYWN0aXZp dHkgd2lsbCBjb29yZGluYXRlIHdpdGggU1BJRCBhY3Rpdml0eSBkZXZlbG9wZWQgdGhyb3VnaCBT UElEIGNoYXJ0ZXIuDQoNClJlZ2FyZHMsDQpTb2hlbCBLaGFuDQo= --_000_387F9047F55E8C42850AD6B3A7A03C6C0E142044inbamail02sonus_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U29oZWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2UgbGV0IG1lIGtu b3cgd2hldGhlciBTZXNzaW9uIGlkIG1lbnRpb25zIGluDQo8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1pcG1jLXNlc3Npb24taWQtMDMiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLWlwbWMtc2Vzc2lvbi1pZC0wMzwvYT4gaGVscHMg dG8gc29sdmUgdGhlIHNhbWUgaXNzdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZWNhdXNlIHNlc3Npb24taWQgYWxz byB0cmF2ZXJzZXMgdGhyb3VnaCBhbGwgQjJCVUEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaXNwYXRj aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Tb2hlbCBLaGFuPGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMDIsIDIwMTIgMzo1OCBBTTxicj4NCjxiPlRvOjwv Yj4gZGlzcGF0Y2hAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2Rpc3BhdGNoXSBQcm9w b3NhbDogRVNQSUQgU2VxdWVuY2UgQ2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDU0NTQ1Ij5XZSBhcmUgcHJvcG9zaW5nIGEgc21hbGwg Y2hhcnRlciB0byBkZXZlbG9wIGEgU0lQIHN0YW5kYXJkIHRvIGFkZCBhIFNJUCBTZXF1ZW5jZSBo ZWFkZXIuIEtpbmRseSByZXZpZXcgdGhlIGNoYXJ0ZXIuIGFwcHJlY2lhdGUgeW91ciBmZWVkYmFj ay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDU0NTQ1Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzQ1NDU0NSI+U0lQIExvb3AgYW1vbmcgU0lQIHByb3ZpZGVycyBp cyBhIGdyb3dpbmcgcGhlbm9tZW5vbi4gJm5ic3A7Rm9yIGV4YW1wbGUsIFNJUCByZXF1ZXN0IG1l c3NhZ2VzIHRyYXZlcnNlIHZhcmlvdXMgcHJvdmlkZXJzIGFuZCBsb29wIGJhY2sgdG8gcHJldmlv dXMgcHJvdmlkZXJzDQogZHVlIHRvIHRoZSBwYXJpdHkgb2YgdGhlIHJvdXRpbmcgdmVjdG9ycy4g SW4gYW5vdGhlciBleGFtcGxlLCBTSVAgbWVzc2FnZXMgdHJhdmVyc2UgbXVsdGlwbGUgc2Vydmlj ZSBwcm92aWRlcnMgaW4gYSBsb29wIGJlY2F1c2Ugb2YgdGhlIG9yaWdpbmF0aW9uLWRlc3RpbmF0 aW9uIHNlc3Npb24gZm9yd2FyZGluZyB0byBlYWNoIG90aGVyLiBTSVAgbG9vcHMgYXJlIG9mdGVu IGFtcGxpZmllZCBjYXVzaW5nIG9wZXJhdGlvbmFsIGRpc3J1cHRpb24gaW4NCiB0aGUgU0lQIG5l dHdvcmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NTQ1NDUiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDU0NTQ1Ij5JbiB0aGUgYWJzZW5jZSBvZiBCMkJVQSBp biBzZXNzaW9uIHBhdGhzIG9yIGEgcHJlc2VuY2Ugb2YgYSBzdGFuZGFyZCBTSVAgY29tcGxpYW50 IEIyQlVBIHRoYXQgZG9lcyBub3QgcmVtb3ZlL3Jlc2V0IFNJUCBwYXJhbWV0ZXJzLCBtYW55IG9m IHRoZSBjdXJyZW50DQogU0lQIGhlYWRlcnMgY2FuIGFpZCBpbiBkZXRlY3RpbmcgbXVsdGktcHJv dmlkZXIgbG9vcC4gVGhlc2UgaGVhZGVycyBoYXZlIHNvbWUgbGltaXRhdGlvbnMuIEZvciBleGFt cGxlLCBhbiBvcHRpbXVtIGRlZmF1bHQgdmFsdWUgZm9yIE1heC1Gb3J3YXJkcyBpcyBoYXJkIHRv IGRldGVybWluZSBzaW5jZSB0aGUgbnVtYmVyIG9mIG5vZGVzIGluIHRoZSBzZXNzaW9uIHBhdGgg aXMgdGltZS9wYXRoIHZhcmlhbnQgZGVwZW5kaW5nIG9uIHRoZSBvcmlnaW5hdGlvbi1kZXN0aW5h dGlvbg0KIHJvdXRlIHZlY3RvciBhbW9uZyBTSVAgcHJvdmlkZXJzLiBTSVAgSGlzdG9yeS1JbmZv IGlzIGFub3RoZXIgaGVhZGVyIHRoYXQgYWxzbyBhaWQgaW4gZGV0ZWN0aW5nIGxvb3AgYW1vbmcg bXVsdGlwbGUgU0lQIHByb3ZpZGVycy4gU0lQIEhpc3RvcnktSW5mbyBkZXBpY3RzIG5vZGUgaW5m b3JtYXRpb24gaW4gdGhlIHNlc3Npb24gcGF0aC4gVGhlIHBhcmFtZXRlciBpbiB0aGUmbmJzcDtI aXN0b3J5LUluZm8gaXMgbm90IG9mdGVuIHRoZSBmaXhlZCBzaXplOw0KIHRodXMsIGl0IGlzIGRp ZmZpY3VsdCB0byBleHRyYWN0IHByb3ZpZGVycycgbmFtZXMuJm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5BIFNJUCByZXF1ZXN0IG1heSB0cmF2ZXJzZSBhIHNldCBvZiBub2RlcyBp biBhIHNlcnZpY2UgcHJvdmlkZXLigJlzIG5ldHdvcmssIG1heSBsb29wIGFyb3VuZCB0aGUgd29y bGQsIGFuZCBtYXkgZW50ZXIgdGhlIHByZXZpb3VzIFNJUCBwcm92aWRlcnPigJkNCiBuZXR3b3Jr cyBpbiBhIGRpZmZlcmVudCBzZXQgb2Ygbm9kZXM7IHRodXMsIHRoZSBuZXcgbm9kZXMgbWF5IG5v dCBrbm93IHRoYXQgdGhlIGNhbGwgaGFkIHRyYXZlcnNlZCZuYnNwO3RoZSBzYW1lIFNJUCBwcm92 aWRlcnMnIG5ldHdvcmtzIGluIHRoZSBwYXN0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDU0NTQ1 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDU0NTQ1Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzQ1NDU0NSI+Jm5ic3A7VGhlIGNoYXJ0ZXIgaXMgdG8gZGV2ZWxv cCBhbiBFbmNyeXB0ZWQgU0lQIFByb3ZpZGVyIElkZW50aXR5IChFU1BJRCkgU2VxdWVuY2UgaGVh ZGVyIHN1Y2ggdGhhdCBhIHByb3ZpZGVyIGNhbiBkZXRlY3QgaXRzZWxmLW9ubHksIHdoaWxlIG1h aW50YWluaW5nIHByaXZhY3kNCiBhbmQgcHJlc2VydmluZyBTSVAgZmxleGliaWxpdHkgc3VjaCBh cyBjYWxsIGZvcndhcmRpbmcuIFRoZSBFU1BJRCBzZXF1ZW5jZSBjb250YWlucyBpZGVudGl0eSBv ZiBTSVAgUHJvdmlkZXJzIGluIHRoZSBvcmRlciBhIHNlc3Npb24gaGFzIHByb3BhZ2F0ZWQgdGhy b3VnaCB0aGUgU0lQIHByb3ZpZGVycy4gQSBTSVAgcHJvdmlkZXIgc2hhbGwgb25seSBiZSBhYmxl IHRvIGRldGVjdCBpdHMgb3duIGlkZW50aXR5IGluIHRoZSBzZXF1ZW5jZS4gQSBTSVANCiBwcm92 aWRlciB3aXNoaW5nIG5vdCB0byBkaXNjbG9zZSBpdHMgaWRlbnRpdHkgdG8gb3RoZXIgcHJvdmlk ZXJzIHNoYWxsIGJlIGFibGUgdG8gZW5jcnlwdCBpdHMgaWRlbnRpdHkuIEEgU0lQIHByb3ZpZGVy IG5vdCB3aXNoaW5nIHRvIGluY2x1ZGUgaXRzIGluZm9ybWF0aW9uIGluIHRoZSBzZXF1ZW5jZSBt YXkgZG8gc28gYnkgbm90IGFkZGluZyBhbnkgaW5mb3JtYXRpb24uIEluY2x1c2lvbiBvZiB0aGUg RVNQSUQgaGVhZGVyIGlzIG1hbmRhdG9yeS4NCiBBIFNJUCBwcm92aWRlciBzaGFsbCBub3QgcmVt b3ZlIHRoZSBFU1BJRCBoZWFkZXIgZnJvbSBhIFNJUCBtZXNzYWdlIHRyYXZlcnNpbmcgaXRzIG5l dHdvcmsuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NTQ1NDUiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDU0NTQ1Ij5TSVAgUHJvdmlkZXIgSUQgKFNQ SUQpIHN0YW5kYXJkIGRldmVsb3BtZW50IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgY2hh cnRlci4gJm5ic3A7RVNQSUQgYWN0aXZpdHkgd2lsbCBjb29yZGluYXRlIHdpdGggU1BJRCBhY3Rp dml0eSBkZXZlbG9wZWQgdGhyb3VnaA0KIFNQSUQgY2hhcnRlci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPGJy Pg0KU29oZWwgS2hhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_387F9047F55E8C42850AD6B3A7A03C6C0E142044inbamail02sonus_-- From sohel_khan777@yahoo.com Fri Mar 2 13:13:09 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED8821E805F for ; Fri, 2 Mar 2012 13:13:09 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z0YoBFG45dB for ; Fri, 2 Mar 2012 13:13:08 -0800 (PST) Received: from nm4-vm0.bullet.mail.bf1.yahoo.com (nm4-vm0.bullet.mail.bf1.yahoo.com [98.139.213.129]) by ietfa.amsl.com (Postfix) with SMTP id 2884921E8019 for ; Fri, 2 Mar 2012 13:13:08 -0800 (PST) Received: from [98.139.215.142] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 02 Mar 2012 21:13:03 -0000 Received: from [98.139.212.224] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 02 Mar 2012 21:13:03 -0000 Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP; 02 Mar 2012 21:13:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 335121.95052.bm@omp1033.mail.bf1.yahoo.com Received: (qmail 79455 invoked by uid 60001); 2 Mar 2012 21:13:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1330722783; bh=n8X7REP7UcNchMHtyFokBBHt93EeJbfGb1VWyqyGICQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=opdWVhrXuMOnnfGMAtJiqH2kd81HarZd9VVLNvbD3l7WjKELVIfJj5IFSgHsyohTzG60ZLYCqr79b9mFpHBL5QcXRSO4N/yxYZVIfAz/KwIubmyOMYAYjX8I9oFkEpdFJ4QsxSmB9v1rCFhX3/pVhGU39I/Te9JUoy/Vh8efWtM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=svL5dA2vDmIuxuZbsaZfnejaOVcqvYtD5T2N9pc91YX1yB6PSJBL0dfstFavalx/PXTc/pWtDf77u086BngnE2mR5AHgjiQSbBd/OfLREBpkTY2IpLIZi5jQBncFtx4onalSYnIXG8NDgVsZFT9IilH00PM+rVnWfJI+fpYjX2Q=; X-YMail-OSG: heDfvw0VM1n9SIDjnPpzuFzWZsW1_f6okXh4DGIv_umDdwR UepdquX44uNjZDEpU0pQzYO7NOXEFpPH7CJOPSp2O3.JJq8QUvUcEpufUQkU 2zE_2Hql6.MoB4a9qfA4gyiI6YPCXus.8uSgXR8oaX1aEagskvmSe79jmOHq 2gK8f9KPZvBC.8tflRuMm6ixEL9exGhs3JBCZ5SAK09wfMhzJPd3gn1A27v9 zoxik4RXa71XdbzEHrA9jUfG0elB7cmUhGC4JeAgFLMGFxtF26ZMEAQuowcG PhbW.5rcaMh7msckNGogFf2n2OIadHM890A4MbF.CHl5l6Xv3ho7X6IYOag_ 494xOYkJfz1Ulu1H3TBtY_muCEnjhi4gSXEaqxOyHTwLXdXvcZjz_NxD4R5M F29QkRuTy5Pjd1r0.CP8guUEQezBgU1FRcmgPWuAdwprvpJWHB7Fd7V5Ybw_ Jqp5Mp5SQelXPIciMmfY2SLIuSo4UcWP5B16FWED9igQD1A6wnA1n4_af Received: from [50.77.82.185] by web162002.mail.bf1.yahoo.com via HTTP; Fri, 02 Mar 2012 13:13:03 PST X-Mailer: YahooMailWebService/0.8.116.338427 References: <1330640892.23608.YahooMailNeo@web162003.mail.bf1.yahoo.com> <387F9047F55E8C42850AD6B3A7A03C6C0E142044@inba-mail02.sonusnet.com> Message-ID: <1330722783.74700.YahooMailNeo@web162002.mail.bf1.yahoo.com> Date: Fri, 2 Mar 2012 13:13:03 -0800 (PST) From: Sohel Khan To: "Ravindran, Parthasarathi" , "dispatch@ietf.org" In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E142044@inba-mail02.sonusnet.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4756291-184301799-1330722783=:74700" Subject: Re: [dispatch] Proposal: ESPID Sequence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 21:13:09 -0000 --4756291-184301799-1330722783=:74700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Partha.=0AA large SIP provider network consists of a large number of= entry and exit nodes.=0AIn an absence of B2BUA, if an unaltered session ID= contains a fixed size numerical value that could be used to identify a SIP= Service provider by any entry and exit nodes of the SIP provider network, = then it will suffice. However, the size and value of the session id may gro= w as SIP request traverses through network to network adding each provider = ID; thus, should we use the session ID when when its end-to-end uniqueness = has importance?=0A=C2=A0=0ARegards,=0ASohel Khan=0A=0A=0A__________________= ______________=0A From: "Ravindran, Parthasarathi" =0ATo: Sohel Khan ; "dispatch@ietf.org" =0ASent: Thursday, March 1, 2012 7:53 PM=0ASubject: RE: [dispatc= h] Proposal: ESPID Sequence Charter=0A =0A=0A =0ASohel,=0A=C2=A0=0APlease l= et me know whether Session id mentions in http://tools.ietf.org/html/draft-= jones-ipmc-session-id-03 helps to solve the same issue.=0A=C2=A0=0ABecause = session-id also traverses through all B2BUA.=0A=C2=A0=0AThanks=0APartha=0A= =C2=A0=0AFrom:dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On Behalf Of Sohel Khan=0ASent: Friday, March 02, 2012 3:58 AM=0ATo: dispat= ch@ietf.org=0ASubject: [dispatch] Proposal: ESPID Sequence Charter=0A=C2=A0= =0AWe are proposing a small charter to develop a SIP standard to add a SIP = Sequence header. Kindly review the charter. appreciate your feedback.=0A=C2= =A0=0ASIP Loop among SIP providers is a growing phenomenon. =C2=A0For examp= le, SIP request messages traverse various providers and loop back to previo= us providers due to the parity of the routing vectors. In another example, = SIP messages traverse multiple service providers in a loop because of the o= rigination-destination session forwarding to each other. SIP loops are ofte= n amplified causing operational disruption in the SIP networks.=0A=C2=A0=0A= In the absence of B2BUA in session paths or a presence of a standard SIP co= mpliant B2BUA that does not remove/reset SIP parameters, many of the curren= t SIP headers can aid in detecting multi-provider loop. These headers have = some limitations. For example, an optimum default value for Max-Forwards is= hard to determine since the number of nodes in the session path is time/pa= th variant depending on the origination-destination route vector among SIP = providers. SIP History-Info is another header that also aid in detecting lo= op among multiple SIP providers. SIP History-Info depicts node information = in the session path. The parameter in the=C2=A0History-Info is not often th= e fixed size; thus, it is difficult to extract providers' names.=C2=A0A SIP= request may traverse a set of nodes in a service provider=E2=80=99s networ= k, may loop around the world, and may enter the previous SIP providers=E2= =80=99 networks in a different set of nodes; thus, the new nodes may not kn= ow that the call had traversed=C2=A0the same SIP providers' networks in the past.=0A= =C2=A0=0A=C2=A0The charter is to develop an Encrypted SIP Provider Identity= (ESPID) Sequence header such that a provider can detect itself-only, while= maintaining privacy and preserving SIP flexibility such as call forwarding= . The ESPID sequence contains identity of SIP Providers in the order a sess= ion has propagated through the SIP providers. A SIP provider shall only be = able to detect its own identity in the sequence. A SIP provider wishing not= to disclose its identity to other providers shall be able to encrypt its i= dentity. A SIP provider not wishing to include its information in the seque= nce may do so by not adding any information. Inclusion of the ESPID header = is mandatory. A SIP provider shall not remove the ESPID header from a SIP m= essage traversing its network. =C2=A0=0A=C2=A0=0ASIP Provider ID (SPID) sta= ndard development is outside the scope of this charter. =C2=A0ESPID activit= y will coordinate with SPID activity developed through SPID charter.=0A=C2= =A0=0ARegards,=0ASohel Khan --4756291-184301799-1330722783=:74700 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Par= tha.
A large SIP provider network consists of a larg= e number of entry and exit nodes.
In an absence of B= 2BUA, if an unaltered session ID contains a fixed size numerical value that= could be used to identify a SIP Service provider by any entry and exit nod= es of the SIP provider network, then it will suffice. However, the size and= value of the session id may grow as SIP request traverses through network = to network adding each provider ID; thus, should we use the session ID when= when its end-to-end uniqueness has importance?
 
Regards,
Sohel Khan
From: "Ravindran, Parthasarathi" = <pravindran@sonusnet.com>
T= o: Sohel Khan <sohel_khan777@yahoo.com>; "dispatch@ietf.or= g" <dispatch@ietf.org>
Sen= t: Thursday, March 1, 2012 7:53 PM
Subject: RE: [dispatch] Proposal: ESPID Sequence Ch= arter

=0A=0A =0A =0A=0A=0A=0A
=0A
Sohel, =0A
 
=0A
Please let me know wheth= er Session id mentions in=0Ahttp://tools.ietf= .org/html/draft-jones-ipmc-session-id-03 helps to solve the same issue.=
=0A
 
=0A
Because sessio= n-id also traverses through all B2BUA.
=0A
 
=0A
Thanks
=0A
Partha =0A
 
=0A
=0A
=0A
=0AFrom:= dispatch-bounces@ietf.org [ma= ilto:dispatch-bounces@ietf.org]=0AOn Behalf Of Sohel Khan
=0AS= ent: Friday, March 02, 2012 3:58 AM
=0ATo: dispatch@ietf.org<= br>=0ASubject: [dispatch] Proposal: ESPID Sequence Charter =0A
=0A
=0A
 
= =0A
=0A
=0A
=0A
We are proposing a small c= harter to develop a SIP standard to add a SIP Sequence header. Kindly revie= w the charter. appreciate your feedback.
=0A
=0A
=0A<= div class=3D"yiv133490967MsoNormal" style=3D"background:white;"> 
= =0A
=0A
=0A
SIP Loop among SIP providers is a= growing phenomenon.  For example, SIP request messages traverse vario= us providers and loop back to previous providers=0A due to the parity of th= e routing vectors. In another example, SIP messages traverse multiple servi= ce providers in a loop because of the origination-destination session forwa= rding to each other. SIP loops are often amplified causing operational disr= uption in=0A the SIP networks.
=0A
=0A
=0A
 
=0A=0A
=0A
In the absence of B2BUA in session paths o= r a presence of a standard SIP compliant B2BUA that does not remove/reset S= IP parameters, many of the current=0A SIP headers can aid in detecting mult= i-provider loop. These headers have some limitations. For example, an optim= um default value for Max-Forwards is hard to determine since the number of = nodes in the session path is time/path variant depending on the origination= -destination=0A route vector among SIP providers. SIP History-Info is anoth= er header that also aid in detecting loop among multiple SIP providers. SIP= History-Info depicts node information in the session path. The parameter i= n the History-Info is not often the fixed size;=0A thus, it is difficu= lt to extract providers' names. A = SIP request may traverse a set of nodes in a service provider=E2=80=99s net= work, may loop around the world, and may enter the previous SIP providers= =E2=80=99=0A networks in a different set of nodes; thus, the new nodes may = not know that the call had traversed the same SIP providers' networks = in the past.
=0A
= =0A
=0A
 <= /span>
=0A
=0A
=0A
 The charter is = to develop an Encrypted SIP Provider Identity (ESPID) Sequence header such = that a provider can detect itself-only, while maintaining privacy=0A and pr= eserving SIP flexibility such as call forwarding. The ESPID sequence contai= ns identity of SIP Providers in the order a session has propagated through = the SIP providers. A SIP provider shall only be able to detect its own iden= tity in the sequence. A SIP=0A provider wishing not to disclose its identit= y to other providers shall be able to encrypt its identity. A SIP provider = not wishing to include its information in the sequence may do so by not add= ing any information. Inclusion of the ESPID header is mandatory.=0A A SIP p= rovider shall not remove the ESPID header from a SIP message traversing its= network.  
=0A
=0A
=0A
 =
=0A
=0A
=0ASIP Provider ID (SPID) standard development is outside = the scope of this charter.  ESPID activity will coordinate with SPID a= ctivity developed through=0A SPID charter.
=0A
=0A
= =0A
=0A
 
=0A
=0A
=0A
Regards,
=0ASohel Khan
=0A
=0A
=0A<= /div>=0A
=0A
=0A=0A


--4756291-184301799-1330722783=:74700-- From pkyzivat@alum.mit.edu Fri Mar 2 13:25:32 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFA921E806C for ; Fri, 2 Mar 2012 13:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2N+2O0Np-H0 for ; Fri, 2 Mar 2012 13:25:31 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id DE95B21E8019 for ; Fri, 2 Mar 2012 13:25:29 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id gkA81i0081wpRvQ53lRWqN; Fri, 02 Mar 2012 21:25:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id glRW1i00P07duvL3elRWZW; Fri, 02 Mar 2012 21:25:30 +0000 Message-ID: <4F513AC8.6050906@alum.mit.edu> Date: Fri, 02 Mar 2012 16:25:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <1330640892.23608.YahooMailNeo@web162003.mail.bf1.yahoo.com> In-Reply-To: <1330640892.23608.YahooMailNeo@web162003.mail.bf1.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] Proposal: ESPID Sequence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 21:25:32 -0000 I disagree with the concept being proposed here. I'm still waiting for an explanation for why the existing mechanisms for loop detection aren't sufficient to solve the problem here. But even if there is some inadequacy, then it should be solved in general, not just for loops through multiple service providers. There is really nothing special about loops through SPs. Thanks, Paul On 3/1/12 5:28 PM, Sohel Khan wrote: > We are proposing a small charter to develop a SIP standard to add a SIP > Sequence header. Kindly review the charter. appreciate your feedback. > SIP Loop among SIP providers is a growing phenomenon. For example, SIP > request messages traverse various providers and loop back to previous > providers due to the parity of the routing vectors. In another example, > SIP messages traverse multiple service providers in a loop because of > the origination-destination session forwarding to each other. SIP loops > are often amplified causing operational disruption in the SIP networks. > In the absence of B2BUA in session paths or a presence of a standard SIP > compliant B2BUA that does not remove/reset SIP parameters, many of the > current SIP headers can aid in detecting multi-provider loop. These > headers have some limitations. For example, an optimum default value for > Max-Forwards is hard to determine since the number of nodes in the > session path is time/path variant depending on the > origination-destination route vector among SIP providers. SIP > History-Info is another header that also aid in detecting loop among > multiple SIP providers. SIP History-Info depicts node information in the > session path. The parameter in the History-Info is not often the fixed > size; thus, it is difficult to extract providers' names. A SIP request > may traverse a set of nodes in a service provider’s network, may loop > around the world, and may enter the previous SIP providers’ networks in > a different set of nodes; thus, the new nodes may not know that the call > had traversed the same SIP providers' networks in the past. > The charter is to develop an Encrypted SIP Provider Identity (ESPID) > Sequence header such that a provider can detect itself-only, while > maintaining privacy and preserving SIP flexibility such as call > forwarding. The ESPID sequence contains identity of SIP Providers in the > order a session has propagated through the SIP providers. A SIP provider > shall only be able to detect its own identity in the sequence. A SIP > provider wishing not to disclose its identity to other providers shall > be able to encrypt its identity. A SIP provider not wishing to include > its information in the sequence may do so by not adding any information. > Inclusion of the ESPID header is mandatory. A SIP provider shall not > remove the ESPID header from a SIP message traversing its network. > SIP Provider ID (SPID) standard development is outside the scope of this > charter. ESPID activity will coordinate with SPID activity developed > through SPID charter. > Regards, > Sohel Khan > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Mon Mar 5 10:04:54 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B0D21F87EA for ; Mon, 5 Mar 2012 10:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.705 X-Spam-Level: X-Spam-Status: No, score=-102.705 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5P-hptmqTIQC for ; Mon, 5 Mar 2012 10:04:54 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id C1B0D21F8777 for ; Mon, 5 Mar 2012 10:04:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD3/VE/GmAcF/2dsb2JhbABDDrRhgQeBfQEBAQECARIVE0QLAgEIDQEHIRAyJQEBBAESCBqHYAWjaJQUj3pjBIhQknGKD4IsVQ X-IronPort-AV: E=Sophos;i="4.73,535,1325480400"; d="scan'208";a="295146202" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Mar 2012 13:04:51 -0500 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Mar 2012 12:57:26 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Mon, 5 Mar 2012 13:04:47 -0500 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , "dispatch@ietf.org" Date: Mon, 5 Mar 2012 13:04:47 -0500 Thread-Topic: [dispatch] Proposal: ESPID Sequence Charter Thread-Index: Acz4uwPX097OMZWSR+uzgSZyHZOBbwCPY2/M Message-ID: References: <1330640892.23608.YahooMailNeo@web162003.mail.bf1.yahoo.com>, <4F513AC8.6050906@alum.mit.edu> In-Reply-To: <4F513AC8.6050906@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Proposal: ESPID Sequence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:04:54 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > I disagree with the concept being proposed here. >=20 > I'm still waiting for an explanation for why the existing mechanisms for > loop detection aren't sufficient to solve the problem here. But even if > there is some inadequacy, then it should be solved in general, not just > for loops through multiple service providers. There is really nothing > special about loops through SPs. I'm with Paul here. The real problem is that the SIP loop-prevention mechanisms often don't work when network elements: (1) hide the path the call has traversed (2) are B2BUAs One consequence of this is that in many cases a call can loop between two service providers and not be detected. But there are many somewhat more complex situations that also loop. The proposed charter assumes that the desired anti-looping mechanism would be some form of list of the service providers that the call has traversed. But many of the more complex scenarious would *not* be detected by a "list of traversed service providers" mechanism (unless it was so aggressive that it flagged similar, non-looping calls). Here is one: Users A and C are served by service provider P. Users B and D are served by service provider Q. User B has forwarded his phone to user C. User C has forwarded his phone to user D. User A calls user B. The route of the call is: A->P->Q->B->Q->P->C->P->Q->D At D, the call has traversed P three times and has traversed Q three times. It has been routed based on three different phone numbers. If user D's phone rings, this call is valid and should succeed. If user D has forwarded his phone to user A, the call is looped and should fail. No doubt the problem needs to be solved. But we need to start by studing it, and determining a mechanism that works in all the cases that our customers will shortly be exercising. The current charter specifies a mechanism, and that mechanism will not work. Dale From jon.peterson@neustar.biz Mon Mar 5 13:51:06 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ED221F8776 for ; Mon, 5 Mar 2012 13:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.93 X-Spam-Level: X-Spam-Status: No, score=-104.93 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzaJmAlv3Mfs for ; Mon, 5 Mar 2012 13:51:06 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B1A1821F8794 for ; Mon, 5 Mar 2012 13:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1330984413; x=1646341142; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=yEUM3Gd27ZZFgvqloiRZx PXWWdhbg68TGV2FqwaU5+A=; b=oTPwONozDpK3Bw3nfKGufju+zBzMq+SMVIezb A0wBlWRlVrSkyRlmem4UM1E0mNamnJqGoepXiheXAyXp1OkwA== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.6389324; Mon, 05 Mar 2012 16:53:32 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 5 Mar 2012 16:51:02 -0500 From: "Peterson, Jon" To: "dispatch@ietf.org" Date: Mon, 5 Mar 2012 16:51:00 -0500 Thread-Topic: New Proposal for Telephone-Related Queries Thread-Index: AQHM+xQ7UaE2MYlCb0+6Ly0bNplLXw== Message-ID: <55A5A9A87506CB4BA580BF9D531957DA239D6332@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: VB4h2d/xjP5oTNrFddvNSg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:51:07 -0000 I have a proposal to bounce off the group. Basically, this is a re-examinat= ion of some of the problems we've previously considered in the telephony-sp= ecific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through disc= ussions in the past couple years, it's become clear that we would need to s= ignificantly extend ENUM to get it to handle all of the sorts of sources, s= ubjects, and attributes that people want to factor into queries about telep= hone number routing and administration. Most of these discussions have gott= en wrapped around the axle on questions of the underlying syntax and semant= ics of the DNS, which were a good match for the original vision of a public= , user-driven ENUM, but don't seem to be such a good match for the uses peo= ple actually want to make of these protocols, in federated, service-provide= r-driven environments like those envisioned in SPEERMINT and provisioned in= DRINKS. While the discussion may have died down a bit, the requirements th= at motivated the discussion definitely aren't going away. Rather than continue to debate the applicability of the DNS and the probity= of various extensions to it, we might make more progress if we work toward= s agreement on the semantics of queries for telephone-related data independ= ently of any underlying protocols. In other words, focus on what kinds of q= uestions about telephone numbers we want to be able to ask, and what kinds = of information needs to go into the answers, and incorporate all this into = an abstract data model. So for example, we know that we want to be able to = express the source of a request in a query. What do we mean by source? I ca= n think of a bunch of different kinds of source: the logical originator of = the query (the administrative entity asking), the logical identity of any i= ntermediary or aggregator forwarding the query, or even the point at the ne= twork from which the call originates (the originating trunk group, SBC or w= hat have you). All three of those concepts of source seem important when it= comes to answering questions about telephone numbers, so a data model woul= d treat those as separate elements which can vary independently - then we c= an then try to figure out what's mandatory or optional, etc. We follow this= same method for all the elements of queries and responses. Figure out what= the attributes are of telephone numbers that we care about, sort them into= buckets of routing data and administrative data, and so on. Once we have an agreement on the data model, then people can map the model = to whatever underlying protocol they'd like - or just build it into a web A= PI, or what have you. Those proposals could advance as separate documents. = Having that flexibility would make it a lot easier to figure out what we re= ally want the questions and answers to be, rather than thinking about what = they realistically can be within the constraints of some existing underlyin= g protocol. That's the idea. I'm not going to present a proposed charter for work or an= ything like that in Paris, but I am interested in hearing if people think t= his is a promising approach, and if so, perhaps we'd put a charter on the a= genda for Vancouver. I have however submitted a -00 draft for this time whi= ch gives a high-level proposal for a data model and at least enumerates wha= t some of the elements might be that would be populated in queries and resp= onses. This is a pretty broad sketch, but it should convey the basic idea. = You can check it out here: https://exchcas.va.neustar.com/owa/thoughts about the direction or the spec= ifics of the data model are welcome. Thanks! Jon Peterson NeuStar, Inc.= From jon.peterson@neustar.biz Mon Mar 5 14:05:06 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF31A21F8862 for ; Mon, 5 Mar 2012 14:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.711 X-Spam-Level: X-Spam-Status: No, score=-105.711 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5FQJieVJc30 for ; Mon, 5 Mar 2012 14:05:04 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4A90C21F8849 for ; Mon, 5 Mar 2012 14:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1330985252; x=1646341142; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=bsbY/d/HQ3tcyneKLsLgY a2P8bw5RGgDRYA2fQU4cRQ=; b=fbVl11z5bXEbcUKnOvN2QVFUpBNg2xm5uU5ka 7TXoxUPebkxYOhR+2ljr3E0OmKU4IXLruI6xUArY3xVBFlqSw== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.6389921; Mon, 05 Mar 2012 17:07:31 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 5 Mar 2012 17:05:00 -0500 From: "Peterson, Jon" To: "'dispatch@ietf.org'" Date: Mon, 5 Mar 2012 17:04:59 -0500 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: AQHM+xQ7UaE2MYlCb0+6Ly0bNplLX5ZcQduA Message-ID: <55A5A9A87506CB4BA580BF9D531957DA23914ED0@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: hQ74oOOljM0k4TYXdSZRRA== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:05:06 -0000 Ck9vcHMsIHNvcnJ5LCBteSBtYWlsZXIgZGlkIG5vdCBsaWtlIHRoZSBVUkwgSSBzdWJtaXR0ZWQu IFRoZSBjb3JyZWN0IFVSTCBmb3IgdGhlIGRyYWZ0IGlzOgoKaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtcGV0ZXJzb24tdGVycS8KCkpvbiBQZXRlcnNvbgpOZXVzdGFyLCBJ bmMuCgoNCg0KIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAJUGV0ZXJzb24sIEpv biBbbWFpbHRvOmpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpel0NClNlbnQ6CU1vbmRheSwgTWFyY2gg MDUsIDIwMTIgMDQ6NTEgUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzoJZGlzcGF0Y2hAaWV0 Zi5vcmcNClN1YmplY3Q6CVtkaXNwYXRjaF0gTmV3IFByb3Bvc2FsIGZvciBUZWxlcGhvbmUtUmVs YXRlZCBRdWVyaWVzDQoNCg0KSSBoYXZlIGEgcHJvcG9zYWwgdG8gYm91bmNlIG9mZiB0aGUgZ3Jv dXAuIEJhc2ljYWxseSwgdGhpcyBpcyBhIHJlLWV4YW1pbmF0aW9uIG9mIHNvbWUgb2YgdGhlIHBy b2JsZW1zIHdlJ3ZlIHByZXZpb3VzbHkgY29uc2lkZXJlZCBpbiB0aGUgdGVsZXBob255LXNwZWNp ZmljIGNsdXN0ZXIgb2Ygd29yayBzdXJyb3VuZGluZyBFTlVNLCBEUklOS1MgYW5kIFNQRUVSTUlO VC4gVGhyb3VnaCBkaXNjdXNzaW9ucyBpbiB0aGUgcGFzdCBjb3VwbGUgeWVhcnMsIGl0J3MgYmVj b21lIGNsZWFyIHRoYXQgd2Ugd291bGQgbmVlZCB0byBzaWduaWZpY2FudGx5IGV4dGVuZCBFTlVN IHRvIGdldCBpdCB0byBoYW5kbGUgYWxsIG9mIHRoZSBzb3J0cyBvZiBzb3VyY2VzLCBzdWJqZWN0 cywgYW5kIGF0dHJpYnV0ZXMgdGhhdCBwZW9wbGUgd2FudCB0byBmYWN0b3IgaW50byBxdWVyaWVz IGFib3V0IHRlbGVwaG9uZSBudW1iZXIgcm91dGluZyBhbmQgYWRtaW5pc3RyYXRpb24uIE1vc3Qg b2YgdGhlc2UgZGlzY3Vzc2lvbnMgaGF2ZSBnb3R0ZW4gd3JhcHBlZCBhcm91bmQgdGhlIGF4bGUg b24gcXVlc3Rpb25zIG9mIHRoZSB1bmRlcmx5aW5nIHN5bnRheCBhbmQgc2VtYW50aWNzIG9mIHRo ZSBETlMsIHdoaWNoIHdlcmUgYSBnb29kIG1hdGNoIGZvciB0aGUgb3JpZ2luYWwgdmlzaW9uIG9m IGEgcHVibGljLCB1c2VyLWRyaXZlbiBFTlVNLCBidXQgZG9uJ3Qgc2VlbSB0byBiZSBzdWNoIGEg Z29vZCBtYXRjaCBmb3IgdGhlIHVzZXMgcGVvcGxlIGFjdHVhbGx5IHdhbnQgdG8gbWFrZSBvZiB0 aGVzZSBwcm90b2NvbHMsIGluIGZlZGVyYXRlZCwgc2VydmljZS1wcm92aWRlci1kcml2ZW4gZW52 aXJvbm1lbnRzIGxpa2UgdGhvc2UgZW52aXNpb25lZCBpbiBTUEVFUk1JTlQgYW5kIHByb3Zpc2lv bmVkIGluIERSSU5LUy4gV2hpbGUgdGhlIGRpc2N1c3Npb24gbWF5IGhhdmUgZGllZCBkb3duIGEg Yml0LCB0aGUgcmVxdWlyZW1lbnRzIHRoYXQgbW90aXZhdGVkIHRoDQogZSBkaXNjdXNzaW9uIGRl ZmluaXRlbHkgYXJlbid0IGdvaW5nIGF3YXkuDQoNClJhdGhlciB0aGFuIGNvbnRpbnVlIHRvIGRl YmF0ZSB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgRE5TIGFuZCB0aGUgcHJvYml0eSBvZiB2YXJp b3VzIGV4dGVuc2lvbnMgdG8gaXQsIHdlIG1pZ2h0IG1ha2UgbW9yZSBwcm9ncmVzcyBpZiB3ZSB3 b3JrIHRvd2FyZHMgYWdyZWVtZW50IG9uIHRoZSBzZW1hbnRpY3Mgb2YgcXVlcmllcyBmb3IgdGVs ZXBob25lLXJlbGF0ZWQgZGF0YSBpbmRlcGVuZGVudGx5IG9mIGFueSB1bmRlcmx5aW5nIHByb3Rv Y29scy4gSW4gb3RoZXIgd29yZHMsIGZvY3VzIG9uIHdoYXQga2luZHMgb2YgcXVlc3Rpb25zIGFi b3V0IHRlbGVwaG9uZSBudW1iZXJzIHdlIHdhbnQgdG8gYmUgYWJsZSB0byBhc2ssIGFuZCB3aGF0 IGtpbmRzIG9mIGluZm9ybWF0aW9uIG5lZWRzIHRvIGdvIGludG8gdGhlIGFuc3dlcnMsIGFuZCBp bmNvcnBvcmF0ZSBhbGwgdGhpcyBpbnRvIGFuIGFic3RyYWN0IGRhdGEgbW9kZWwuIFNvIGZvciBl eGFtcGxlLCB3ZSBrbm93IHRoYXQgd2Ugd2FudCB0byBiZSBhYmxlIHRvIGV4cHJlc3MgdGhlIHNv dXJjZSBvZiBhIHJlcXVlc3QgaW4gYSBxdWVyeS4gV2hhdCBkbyB3ZSBtZWFuIGJ5IHNvdXJjZT8g SSBjYW4gdGhpbmsgb2YgYSBidW5jaCBvZiBkaWZmZXJlbnQga2luZHMgb2Ygc291cmNlOiB0aGUg bG9naWNhbCBvcmlnaW5hdG9yIG9mIHRoZSBxdWVyeSAodGhlIGFkbWluaXN0cmF0aXZlIGVudGl0 eSBhc2tpbmcpLCB0aGUgbG9naWNhbCBpZGVudGl0eSBvZiBhbnkgaW50ZXJtZWRpYXJ5IG9yIGFn Z3JlZ2F0b3IgZm9yd2FyZGluZyB0aGUgcXVlcnksIG9yIGV2ZW4gdGhlIHBvaW50IGF0IHRoZSBu ZXR3b3JrIGZyb20gd2hpY2ggdGhlIGNhbGwgb3JpZ2luYXRlcyAodGhlIG9yaWdpbmF0aW5nIHRy dW5rIGdyb3VwLCBTQkMgb3Igd2hhdCBoYXZlIHlvdSkuIEFsbCB0aHJlZSBvZiB0aG9zZSBjb25j ZXB0cyBvZiBzb3VyY2Ugc2VlbSBpbXBvcnRhbnQgd2hlbiBpdCBjb21lcyB0byBhbnN3ZQ0KIHJp bmcgcXVlc3Rpb25zIGFib3V0IHRlbGVwaG9uZSBudW1iZXJzLCBzbyBhIGRhdGEgbW9kZWwgd291 bGQgdHJlYXQgdGhvc2UgYXMgc2VwYXJhdGUgZWxlbWVudHMgd2hpY2ggY2FuIHZhcnkgaW5kZXBl bmRlbnRseSAtIHRoZW4gd2UgY2FuIHRoZW4gdHJ5IHRvIGZpZ3VyZSBvdXQgd2hhdCdzIG1hbmRh dG9yeSBvciBvcHRpb25hbCwgZXRjLiBXZSBmb2xsb3cgdGhpcyBzYW1lIG1ldGhvZCBmb3IgYWxs IHRoZSBlbGVtZW50cyBvZiBxdWVyaWVzIGFuZCByZXNwb25zZXMuIEZpZ3VyZSBvdXQgd2hhdCB0 aGUgYXR0cmlidXRlcyBhcmUgb2YgdGVsZXBob25lIG51bWJlcnMgdGhhdCB3ZSBjYXJlIGFib3V0 LCBzb3J0IHRoZW0gaW50byBidWNrZXRzIG9mIHJvdXRpbmcgZGF0YSBhbmQgYWRtaW5pc3RyYXRp dmUgZGF0YSwgYW5kIHNvIG9uLg0KDQpPbmNlIHdlIGhhdmUgYW4gYWdyZWVtZW50IG9uIHRoZSBk YXRhIG1vZGVsLCB0aGVuIHBlb3BsZSBjYW4gbWFwIHRoZSBtb2RlbCB0byB3aGF0ZXZlciB1bmRl cmx5aW5nIHByb3RvY29sIHRoZXknZCBsaWtlIC0gb3IganVzdCBidWlsZCBpdCBpbnRvIGEgd2Vi IEFQSSwgb3Igd2hhdCBoYXZlIHlvdS4gVGhvc2UgcHJvcG9zYWxzIGNvdWxkIGFkdmFuY2UgYXMg c2VwYXJhdGUgZG9jdW1lbnRzLiBIYXZpbmcgdGhhdCBmbGV4aWJpbGl0eSB3b3VsZCBtYWtlIGl0 IGEgbG90IGVhc2llciB0byBmaWd1cmUgb3V0IHdoYXQgd2UgcmVhbGx5IHdhbnQgdGhlIHF1ZXN0 aW9ucyBhbmQgYW5zd2VycyB0byBiZSwgcmF0aGVyIHRoYW4gdGhpbmtpbmcgYWJvdXQgd2hhdCB0 aGV5IHJlYWxpc3RpY2FsbHkgY2FuIGJlIHdpdGhpbiB0aGUgY29uc3RyYWludHMgb2Ygc29tZSBl eGlzdGluZyB1bmRlcmx5aW5nIHByb3RvY29sLg0KDQpUaGF0J3MgdGhlIGlkZWEuIEknbSBub3Qg Z29pbmcgdG8gcHJlc2VudCBhIHByb3Bvc2VkIGNoYXJ0ZXIgZm9yIHdvcmsgb3IgYW55dGhpbmcg bGlrZSB0aGF0IGluIFBhcmlzLCBidXQgSSBhbSBpbnRlcmVzdGVkIGluIGhlYXJpbmcgaWYgcGVv cGxlIHRoaW5rIHRoaXMgaXMgYSBwcm9taXNpbmcgYXBwcm9hY2gsIGFuZCBpZiBzbywgcGVyaGFw cyB3ZSdkIHB1dCBhIGNoYXJ0ZXIgb24gdGhlIGFnZW5kYSBmb3IgVmFuY291dmVyLiBJIGhhdmUg aG93ZXZlciBzdWJtaXR0ZWQgYSAtMDAgZHJhZnQgZm9yIHRoaXMgdGltZSB3aGljaCBnaXZlcyBh IGhpZ2gtbGV2ZWwgcHJvcG9zYWwgZm9yIGEgZGF0YSBtb2RlbCBhbmQgYXQgbGVhc3QgZW51bWVy YXRlcyB3aGF0IHNvbWUgb2YgdGhlIGVsZW1lbnRzIG1pZ2h0IGJlIHRoYXQgd291bGQgYmUgcG9w dWxhdGVkIGluIHF1ZXJpZXMgYW5kIHJlc3BvbnNlcy4gVGhpcyBpcyBhIHByZXR0eSBicm9hZCBz a2V0Y2gsIGJ1dCBpdCBzaG91bGQgY29udmV5IHRoZSBiYXNpYyBpZGVhLiBZb3UgY2FuIGNoZWNr IGl0IG91dCBoZXJlOg0KaHR0cHM6Ly9leGNoY2FzLnZhLm5ldXN0YXIuY29tL293YS90aG91Z2h0 cyBhYm91dCB0aGUgZGlyZWN0aW9uIG9yIHRoZSBzcGVjaWZpY3Mgb2YgdGhlIGRhdGEgbW9kZWwg YXJlIHdlbGNvbWUuIFRoYW5rcyENCg0KSm9uIFBldGVyc29uDQpOZXVTdGFyLCBJbmMuDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGlzcGF0Y2ggbWFp bGluZyBsaXN0DQpkaXNwYXRjaEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kaXNwYXRjaA0K From sohel_khan777@yahoo.com Mon Mar 5 14:21:57 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401FE21E804E for ; Mon, 5 Mar 2012 14:21:57 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiyUD4Hq7kPG for ; Mon, 5 Mar 2012 14:21:56 -0800 (PST) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by ietfa.amsl.com (Postfix) with SMTP id 9E88521E804B for ; Mon, 5 Mar 2012 14:21:55 -0800 (PST) Received: from [98.139.212.149] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 05 Mar 2012 22:21:52 -0000 Received: from [98.139.212.241] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 05 Mar 2012 22:21:52 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 05 Mar 2012 22:21:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 474550.53237.bm@omp1050.mail.bf1.yahoo.com Received: (qmail 20174 invoked by uid 60001); 5 Mar 2012 22:21:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1330986112; bh=TRrgRqEgCGrXWSMxiSjGs/lsm/+8VvaHEojMi37DqO4=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=QBf69F84jRtAbv97dOIDZkdT8WuahpWw+G71tuU7A+L3bid5k8hC4f1SywvKFzzwR4i6iJS5YmLKO/Jj9qsbdYm9Jl7ppWntIjVLnffZuCFl/bX7pvqXf3zcj2EGWu3LPMp045a4s61cF2FPQFuXIDvhxNVLlBuyqXF55DnMrAA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=K/eDnquypECmFQQk1+pjGVmh9kinLBD0zSNu4h366Rvu+RC8AfLc7h/qpZA55aVOU0NDBscFkKbfDQnTl2o4kYJ9Yk+juoE41aB2tmB0yDVUihc/pb4Xl267/9pKikAWLhDAmCB/ER6usb0pfenVgL31ZEy4h4a/pzIBiUy7cB0=; X-YMail-OSG: U26WIIgVM1mJyfVDqV7yNB56gOXk7xKpEHZWHX3lrNyYSwm 8vbePcs0j.feK35sq.ImoCs3GFK1YW0ydjmy56NRM_9W0lFugegRAUoZSkjT oMREZypitxfIqNSaKbo_5v3A9f3r_WlyA.rRyhbJ3u8j7krG6WmLZR4OVyHE UNvFyrq29qd97bm0cVisPVrhVkY6lFv3HQAbvXJ0Fug4RtRTezygfHi77J5T uUwn3h.ellG0ijs035YwKjUT8W1EiJifPTk5UWJjunffg8g5hneGZ2bVkjs2 yYWOeqf_x_e3giV.X36ex09kTSL8SJs75ayxnGJjErXigRnqR4OtSUIFQv0z 7Ek8NZ9tGXznRndWLo9Nqr.hHcnMMhBQ.5fERV4IMXqIpGu50FToF5dZnZfX LG7EczaapytHrb3zQPJOQqEaP3eFA4tpNNHyGTbuvUc_OHrt7wJBL8TUffha UYVAA9y61Mggpjxed4_SHO4cROGegbxvcNzayIdqvceqT6jUo8_U- Received: from [69.241.19.12] by web162002.mail.bf1.yahoo.com via HTTP; Mon, 05 Mar 2012 14:21:52 PST X-Mailer: YahooMailWebService/0.8.116.338427 References: Message-ID: <1330986112.80358.YahooMailNeo@web162002.mail.bf1.yahoo.com> Date: Mon, 5 Mar 2012 14:21:52 -0800 (PST) From: Sohel Khan To: "dispatch@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4756291-1302127974-1330986112=:80358" Subject: Re: [dispatch] dispatch Digest, Vol 36, Issue 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:21:57 -0000 --4756291-1302127974-1330986112=:80358 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thank you Dale and Paul.=0AHow about we will study the existing mechanism o= n loop prevention, recommend any changes needed on existing mechanism, and/= or work on a new solution (e.g, SPID sequence.)=0A=0A=0ARegards,=0ASohel Kh= an=0A=0A=0A________________________________=0A From: "dispatch-request@ietf= .org" =0ATo: dispatch@ietf.org =0ASent: Monday, = March 5, 2012 3:00 PM=0ASubject: dispatch Digest, Vol 36, Issue 5=0A =0AIf = you have received this digest without all the individual message=0Aattachme= nts you will need to update your digest options in your list=0Asubscription= .=A0 To do so, go to =0A=0Ahttps://www.ietf.org/mailman/listinfo/dispatch= =0A=0AClick the 'Unsubscribe or edit options' button, log in, and set "Get= =0AMIME or Plain Text Digests?" to MIME.=A0 You can set this option=0Agloba= lly for all the list digests you receive at this point.=0A=0A=0A=0ASend dis= patch mailing list submissions to=0A=A0=A0=A0 dispatch@ietf.org=0A=0ATo sub= scribe or unsubscribe via the World Wide Web, visit=0A=A0=A0=A0 https://www= .ietf.org/mailman/listinfo/dispatch=0Aor, via email, send a message with su= bject or body 'help' to=0A=A0=A0=A0 dispatch-request@ietf.org=0A=0AYou can = reach the person managing the list at=0A=A0=A0=A0 dispatch-owner@ietf.org= =0A=0AWhen replying, please edit your Subject line so it is more specific= =0Athan "Re: Contents of dispatch digest..."=0A=0A=0AToday's Topics:=0A=0A= =A0 1. Re: Proposal: ESPID Sequence Charter (Worley, Dale R (Dale))=0A=0A= =0A----------------------------------------------------------------------= =0A=0AMessage: 1=0ADate: Mon, 5 Mar 2012 13:04:47 -0500=0AFrom: "Worley, Da= le R (Dale)" =0ATo: Paul Kyzivat = , "dispatch@ietf.org"=0A=A0=A0=A0 =0ASubject: Re: [dispa= tch] Proposal: ESPID Sequence Charter=0AMessage-ID:=0A=A0=A0=A0 =0A=A0=A0=A0 = =0AContent-Type: text/plain; charset=3D"us-ascii"=0A=0A> From: Paul Kyzivat= [pkyzivat@alum.mit.edu]=0A> =0A> I disagree with the concept being propose= d here.=0A> =0A> I'm still waiting for an explanation for why the existing = mechanisms for=0A> loop detection aren't sufficient to solve the problem he= re. But even if=0A> there is some inadequacy, then it should be solved in g= eneral, not just=0A> for loops through multiple service providers. There is= really nothing=0A> special about loops through SPs.=0A=0AI'm with Paul her= e.=0A=0AThe real problem is that the SIP loop-prevention mechanisms often= =0Adon't work when network elements:=0A(1) hide the path the call has trave= rsed=0A(2) are B2BUAs=0A=0AOne consequence of this is that in many cases a = call can loop between=0Atwo service providers and not be detected.=A0 But t= here are many=0Asomewhat more complex situations that also loop.=0A=0AThe p= roposed charter assumes that the desired anti-looping mechanism=0Awould be = some form of list of the service providers that the call has=0Atraversed.= =0A=0ABut many of the more complex scenarious would *not* be detected by a= =0A"list of traversed service providers" mechanism (unless it was so=0Aaggr= essive that it flagged similar, non-looping calls).=A0 Here is one:=0A=0AUs= ers A and C are served by service provider P.=0AUsers B and D are served by= service provider Q.=0A=0AUser B has forwarded his phone to user C.=0AUser = C has forwarded his phone to user D.=0A=0AUser A calls user B.=A0 The route= of the call is:=0A=0AA->P->Q->B->Q->P->C->P->Q->D=0A=0AAt D, the call has = traversed P three times and has traversed Q three=0Atimes.=A0 It has been r= outed based on three different phone numbers.=0A=0AIf user D's phone rings,= this call is valid and should succeed.=A0 If=0Auser D has forwarded his ph= one to user A, the call is looped and=0Ashould fail.=0A=0ANo doubt the prob= lem needs to be solved.=A0 But we need to start by=0Astuding it, and determ= ining a mechanism that works in all the cases=0Athat our customers will sho= rtly be exercising.=A0 The current charter=0Aspecifies a mechanism, and tha= t mechanism will not work.=0A=0ADale=0A=0A=0A------------------------------= =0A=0A_______________________________________________=0Adispatch mailing li= st=0Adispatch@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/dispatch=0A= =0A=0AEnd of dispatch Digest, Vol 36, Issue 5=0A***************************= ************ --4756291-1302127974-1330986112=:80358 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you = Dale and Paul.
How about we will study the existing mechan= ism on loop prevention, recommend any changes needed on existing mechanism,= and/or work on a new solution (e.g, SPID sequence.)


Regards,
Sohel Khan
From: "dispatch-request= @ietf.org" <dispatch-request@ietf.org>
To: dispatch@ietf.org
Sent: Monday, March 5, 2012 3:00 PM
Subject: dispatch Digest, Vol 36, = Issue 5

=0AIf you have received this digest without = all the individual message
attachments you will need to update your dige= st options in your list
subscription.  To do so, go to

ht= tps://www.ietf.org/mailman/listinfo/dispatch

Click the 'Unsubscr= ibe or edit options' button, log in, and set "Get
MIME or Plain Text Dig= ests?" to MIME.  You can set this option
globally for all the list = digests you receive at this point.



Send dispatch mailing lis= t submissions to
    dispatch@ietf.org

To subsc= ribe or unsubscribe via the World Wide Web, visit
    h= ttps://www.ietf.org/mailman/listinfo/dispatch
or, via email, send a = message with subject or body 'help' to
    dispatch-request@ietf.org
<= br>You can reach the person managing the list at
    dispatch-owner@ietf.org

When replying, please edit your S= ubject line so it is more specific
than "Re: Contents of dispatch digest= ..."


Today's Topics:

  1. Re: Proposal: ESPID Seque= nce Charter (Worley, Dale R (Dale))


----------------------------= ------------------------------------------

Message: 1
Date: Mon, = 5 Mar 2012 13:04:47 -0500
From: "Worley, Dale R (Dale)" <dworley@ava= ya.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>= , "dis= patch@ietf.org"
    <dispatch@ietf.org>
S= ubject: Re: [dispatch] Proposal: ESPID Sequence Charter
Message-ID:
&= nbsp;   <CD5674C3CD99574EBA743= 2465FC13C1B22726A092E@DC-US1MBEX4.global.avaya.com>
  &= nbsp;
Content-Type: text/plain; charset=3D"us-ascii"

> From: = Paul Kyzivat [pkyzivat@alum.mit.edu]
>
> I disagree= with the concept being proposed here.
>
> I'm still waiting f= or an explanation for why the existing mechanisms for
> loop detectio= n aren't sufficient to solve the problem here. But even if
> there is some in= adequacy, then it should be solved in general, not just
> for loops t= hrough multiple service providers. There is really nothing
> special = about loops through SPs.

I'm with Paul here.

The real problem= is that the SIP loop-prevention mechanisms often
don't work when networ= k elements:
(1) hide the path the call has traversed
(2) are B2BUAs
One consequence of this is that in many cases a call can loop between=
two service providers and not be detected.  But there are many
= somewhat more complex situations that also loop.

The proposed charte= r assumes that the desired anti-looping mechanism
would be some form of = list of the service providers that the call has
traversed.

But ma= ny of the more complex scenarious would *not* be detected by a
"list of = traversed service providers" mechanism (unless it was so
aggressive that it flagged similar, non-looping calls).  Here i= s one:

Users A and C are served by service provider P.
Users B an= d D are served by service provider Q.

User B has forwarded his phone= to user C.
User C has forwarded his phone to user D.

User A call= s user B.  The route of the call is:

A->P->Q->B->Q-= >P->C->P->Q->D

At D, the call has traversed P three t= imes and has traversed Q three
times.  It has been routed based on = three different phone numbers.

If user D's phone rings, this call is= valid and should succeed.  If
user D has forwarded his phone to us= er A, the call is looped and
should fail.

No doubt the problem ne= eds to be solved.  But we need to start by
studing it, and determin= ing a mechanism that works in all the cases
that our customers will shor= tly be exercising.  The current charter
specifies a mechanism, and that mechanism will not work.

Dale


------= ------------------------

___________________________________________= ____
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch


End of dispatch Digest, Vol 3= 6, Issue 5
***************************************


--4756291-1302127974-1330986112=:80358-- From pkyzivat@alum.mit.edu Mon Mar 5 14:51:00 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6507E21F8766 for ; Mon, 5 Mar 2012 14:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApSU7r3x0BBI for ; Mon, 5 Mar 2012 14:50:59 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7F521F876C for ; Mon, 5 Mar 2012 14:50:59 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id hxpv1i00127AodY55yqzAr; Mon, 05 Mar 2012 22:50:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id hyqz1i00x07duvL3fyqzXz; Mon, 05 Mar 2012 22:50:59 +0000 Message-ID: <4F554351.5090802@alum.mit.edu> Date: Mon, 05 Mar 2012 17:50:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <55A5A9A87506CB4BA580BF9D531957DA239D6332@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA239D6332@STNTEXCH01.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:51:00 -0000 Jon, This sounds like an excellent way to move the discussion in a productive way. Thanks, Paul On 3/5/12 4:51 PM, Peterson, Jon wrote: > > I have a proposal to bounce off the group. Basically, this is a re-examination of some of the problems we've previously considered in the telephony-specific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through discussions in the past couple years, it's become clear that we would need to significantly extend ENUM to get it to handle all of the sorts of sources, subjects, and attributes that people want to factor into queries about telephone number routing and administration. Most of these discussions have gotten wrapped around the axle on questions of the underlying syntax and semantics of the DNS, which were a good match for the original vision of a public, user-driven ENUM, but don't seem to be such a good match for the uses people actually want to make of these protocols, in federated, service-provider-driven environments like those envisioned in SPEERMINT and provisioned in DRINKS. While the discussion may have died down a bit, the requirements that motivated th > e discussion definitely aren't going away. > > Rather than continue to debate the applicability of the DNS and the probity of various extensions to it, we might make more progress if we work towards agreement on the semantics of queries for telephone-related data independently of any underlying protocols. In other words, focus on what kinds of questions about telephone numbers we want to be able to ask, and what kinds of information needs to go into the answers, and incorporate all this into an abstract data model. So for example, we know that we want to be able to express the source of a request in a query. What do we mean by source? I can think of a bunch of different kinds of source: the logical originator of the query (the administrative entity asking), the logical identity of any intermediary or aggregator forwarding the query, or even the point at the network from which the call originates (the originating trunk group, SBC or what have you). All three of those concepts of source seem important when it comes to ans we > ring questions about telephone numbers, so a data model would treat those as separate elements which can vary independently - then we can then try to figure out what's mandatory or optional, etc. We follow this same method for all the elements of queries and responses. Figure out what the attributes are of telephone numbers that we care about, sort them into buckets of routing data and administrative data, and so on. > > Once we have an agreement on the data model, then people can map the model to whatever underlying protocol they'd like - or just build it into a web API, or what have you. Those proposals could advance as separate documents. Having that flexibility would make it a lot easier to figure out what we really want the questions and answers to be, rather than thinking about what they realistically can be within the constraints of some existing underlying protocol. > > That's the idea. I'm not going to present a proposed charter for work or anything like that in Paris, but I am interested in hearing if people think this is a promising approach, and if so, perhaps we'd put a charter on the agenda for Vancouver. I have however submitted a -00 draft for this time which gives a high-level proposal for a data model and at least enumerates what some of the elements might be that would be populated in queries and responses. This is a pretty broad sketch, but it should convey the basic idea. You can check it out here: > https://exchcas.va.neustar.com/owa/thoughts about the direction or the specifics of the data model are welcome. Thanks! > > Jon Peterson > NeuStar, Inc. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@alum.mit.edu Mon Mar 5 14:54:17 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5790F21F8780 for ; Mon, 5 Mar 2012 14:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMmB3hADw-fM for ; Mon, 5 Mar 2012 14:54:16 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 63EE921F8725 for ; Mon, 5 Mar 2012 14:54:16 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta05.westchester.pa.mail.comcast.net with comcast id hwMT1i0021YDfWL55yuHws; Mon, 05 Mar 2012 22:54:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id hyuG1i00x07duvL3gyuGRU; Mon, 05 Mar 2012 22:54:16 +0000 Message-ID: <4F554416.3020201@alum.mit.edu> Date: Mon, 05 Mar 2012 17:54:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <1330986112.80358.YahooMailNeo@web162002.mail.bf1.yahoo.com> In-Reply-To: <1330986112.80358.YahooMailNeo@web162002.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] dispatch Digest, Vol 36, Issue 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:54:17 -0000 On 3/5/12 5:21 PM, Sohel Khan wrote: > Thank you Dale and Paul. > How about we will study the existing mechanism on loop prevention, > recommend any changes needed on existing mechanism, and/or work on a new > solution (e.g, SPID sequence.) Sounds good. If you didn't already know, Hadriel previously submitted something on making loop detection work better through SBCs. Thanks, Paul > Regards, > Sohel Khan > ------------------------------------------------------------------------ > *From:* "dispatch-request@ietf.org" > *To:* dispatch@ietf.org > *Sent:* Monday, March 5, 2012 3:00 PM > *Subject:* dispatch Digest, Vol 36, Issue 5 > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/dispatch > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send dispatch mailing list submissions to > dispatch@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/dispatch > or, via email, send a message with subject or body 'help' to > dispatch-request@ietf.org > > You can reach the person managing the list at > dispatch-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dispatch digest..." > > > Today's Topics: > > 1. Re: Proposal: ESPID Sequence Charter (Worley, Dale R (Dale)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 5 Mar 2012 13:04:47 -0500 > From: "Worley, Dale R (Dale)" > > To: Paul Kyzivat >, > "dispatch@ietf.org " > > > Subject: Re: [dispatch] Proposal: ESPID Sequence Charter > Message-ID: > > > > Content-Type: text/plain; charset="us-ascii" > > > From: Paul Kyzivat [pkyzivat@alum.mit.edu ] > > > > I disagree with the concept being proposed here. > > > > I'm still waiting for an explanation for why the existing mechanisms for > > loop detection aren't sufficient to solve the problem here. But even if > > there is some inadequacy, then it should be solved in general, not just > > for loops through multiple service providers. There is really nothing > > special about loops through SPs. > > I'm with Paul here. > > The real problem is that the SIP loop-prevention mechanisms often > don't work when network elements: > (1) hide the path the call has traversed > (2) are B2BUAs > > One consequence of this is that in many cases a call can loop between > two service providers and not be detected. But there are many > somewhat more complex situations that also loop. > > The proposed charter assumes that the desired anti-looping mechanism > would be some form of list of the service providers that the call has > traversed. > > But many of the more complex scenarious would *not* be detected by a > "list of traversed service providers" mechanism (unless it was so > aggressive that it flagged similar, non-looping calls). Here is one: > > Users A and C are served by service provider P. > Users B and D are served by service provider Q. > > User B has forwarded his phone to user C. > User C has forwarded his phone to user D. > > User A calls user B. The route of the call is: > > A->P->Q->B->Q->P->C->P->Q->D > > At D, the call has traversed P three times and has traversed Q three > times. It has been routed based on three different phone numbers. > > If user D's phone rings, this call is valid and should succeed. If > user D has forwarded his phone to user A, the call is looped and > should fail. > > No doubt the problem needs to be solved. But we need to start by > studing it, and determining a mechanism that works in all the cases > that our customers will shortly be exercising. The current charter > specifies a mechanism, and that mechanism will not work. > > Dale > > > ------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > End of dispatch Digest, Vol 36, Issue 5 > *************************************** > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From glavers@cisco.com Mon Mar 5 14:11:59 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AC721F87BF for ; Mon, 5 Mar 2012 14:11:59 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEdofaE37QpY for ; Mon, 5 Mar 2012 14:11:59 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA7421F87BC for ; Mon, 5 Mar 2012 14:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=glavers@cisco.com; l=370; q=dns/txt; s=iport; t=1330985519; x=1332195119; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=BWLizlgFnHo0wTVMqhya49MF97SNI1y512Fd5vkGMKQ=; b=nJHZh7ZwlCqkrRXsK4ilmyMK1mk3/QpA5akvBRBLd/QLYIG8FpyloAVX t45sThfXmJ41QxxwK1cIQTHk+ChdCsrkwSx7NJgsQMY37yjkOHbh2NlwT s/XY1P+HiZv7rGf/uKvZ895ctJr/oFRrfyv8uTvR391XP/9pe6xt6W4ja o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAB05VU+rRDoG/2dsb2JhbABDhTSuOXqBB4F/AQQSARANBEUSASICBgYYAgIDAVYBBBsah2QBC5lNAYxlkg2BL4t+ggwzYwSIUJ0AgwQ X-IronPort-AV: E=Sophos;i="4.73,536,1325462400"; d="scan'208";a="34663555" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 05 Mar 2012 22:11:58 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q25MBwSa006045; Mon, 5 Mar 2012 22:11:58 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 14:11:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 5 Mar 2012 14:11:56 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz7CV1x2e1m2Jd5QsqIDVqUw6Sf9QAE4KPA From: "Glen Lavers (glavers)" To: X-OriginalArrivalTime: 05 Mar 2012 22:11:57.0890 (UTC) FILETIME=[FB31C220:01CCFB1C] X-Mailman-Approved-At: Mon, 05 Mar 2012 15:32:37 -0800 Subject: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:11:59 -0000 Rm9sa3MsDQpJIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IHRvIGRlZmluZSBhbiAnaW1tZXJz aXZlJyBtZWRpYSBmZWF0dXJlIHRhZy4gVGhlIGRyYWZ0IGlzIHBvc3RlZCBhdDogaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGF2ZXJzLWRpc3BhdGNoLWltbWVyc2l2ZS1jYXBhYmls aXR5IA0KDQpUaGUgYXV0aG9ycyB3b3VsZCBhcHByZWNpYXRlIGZlZWRiYWNrICBhbmQgb3IgZGV0 YWlsZWQgY29tbWVudHMuIA0KDQpNYW55IHRoYW5rcywNCkdsZW4NCg== From dworley@avaya.com Tue Mar 6 09:03:42 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D560121F84E6 for ; Tue, 6 Mar 2012 09:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stTxoO2xEJ-w for ; Tue, 6 Mar 2012 09:03:42 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8C021F84D9 for ; Tue, 6 Mar 2012 09:03:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQHAN9CVk+HCzI1/2dsb2JhbABDoxuEMI0ggQeBfQEBAQECARIoRAsCAQgNCCEQMhMSAQEEARIIEweHYAWdOJwmiTuGQGMEiFKScoUbhHaDAQ X-IronPort-AV: E=Sophos;i="4.73,540,1325480400"; d="scan'208";a="236154418" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 06 Mar 2012 12:02:53 -0500 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Mar 2012 11:47:48 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 6 Mar 2012 12:02:52 -0500 From: "Worley, Dale R (Dale)" To: Sohel Khan , "dispatch@ietf.org" Date: Tue, 6 Mar 2012 12:02:52 -0500 Thread-Topic: [dispatch] dispatch Digest, Vol 36, Issue 5 Thread-Index: Acz7HnvWweYnY/SMTPiWGZ9Q+5nhmwAmzoOq Message-ID: References: , <1330986112.80358.YahooMailNeo@web162002.mail.bf1.yahoo.com> In-Reply-To: <1330986112.80358.YahooMailNeo@web162002.mail.bf1.yahoo.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] dispatch Digest, Vol 36, Issue 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:03:42 -0000 > From: Sohel Khan [sohel_khan777@yahoo.com] >=20 > How about we will study the existing mechanism on loop prevention, > recommend any changes needed on existing mechanism, and/or work on a > new solution (e.g, SPID sequence.) That sounds like a good way to frame the work. I would recommend phrasing that explains the problem area more completely. *We* all know the difficulties we are attempting to solve, but it would be better to document it. E.g., Current SIP loop-detection mechanisms do not work effectively in large-scale service provider networks as they are now deployed. For example, the use of B2BUAs and topology-hiding techniques often defeat loop-detection. The purpose of the WG is to study how the existing mechanisms for loop detection work in current large-scale service provider networks, and to recommend changes (to the networks and/or the mechanisms) to provide practical and effective loop detection in those networks. Dale From richard@shockey.us Tue Mar 6 09:08:20 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846EA21F8763 for ; Tue, 6 Mar 2012 09:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxrVKjDPynW9 for ; Tue, 6 Mar 2012 09:08:19 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 6A19021F87A9 for ; Tue, 6 Mar 2012 09:08:18 -0800 (PST) Received: (qmail 1362 invoked by uid 0); 6 Mar 2012 17:08:16 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 6 Mar 2012 17:08:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=+zqwqo8ry+DSJf/Tbmvar9zQWvXBG713nqpP0vHmgzM=; b=BWdZvaNLWALyQZ3sCRbdBJqBvP+/ODTMX3vWqRJk0T64Woik6p4ViEBGzRivRxLdo8J/zmv5YOvHbYRjMDI+BG+lWI3YzkMFAQMuCBoXcnxPOh/q4NAI4sq0PpuC8pvd; Received: from host249-111.cablelabs.com ([192.160.73.249] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S4xrz-0005z6-3e; Tue, 06 Mar 2012 10:08:15 -0700 From: "Richard Shockey" To: "'Peterson, Jon'" , References: <55A5A9A87506CB4BA580BF9D531957DA23914ED0@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA23914ED0@STNTEXCH01.cis.neustar.com> Date: Tue, 6 Mar 2012 12:08:13 -0500 Message-ID: <01e501ccfbbb$b8af8af0$2a0ea0d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHM+xQ7UaE2MYlCb0+6Ly0bNplLX5ZcQduAgAE4D9A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 192.160.73.249 authed with richard@shockey.us} Cc: 'IETF ENUM list' Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:08:20 -0000 I think this a perfectly reasonable proposal. I'd like to see it move forward. It would be useful not to get into any Layer 10 issues of what people have used 6116 for. The simple fact is that its there, it scales, its fully deployed in private instantiations in major carrier networks and is baked into multiple NNI profiles. That said we know two things. 6116 has limitations due to its use of underlying DNS technology. Jon is right that the problem of determinate response based on source of the query in DNS has forced us to look at some duct tape and wire solutions that may be sub optimal. Though source-URI does work. Speaking of Layer 9, the other issue is phone numbers are not going away and any transition from POTS to FOO is going to have to deal with multiple types of data associated with those identifiers. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Monday, March 05, 2012 5:05 PM To: 'dispatch@ietf.org' Subject: Re: [dispatch] New Proposal for Telephone-Related Queries Oops, sorry, my mailer did not like the URL I submitted. The correct URL for the draft is: https://datatracker.ietf.org/doc/draft-peterson-terq/ Jon Peterson Neustar, Inc. -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time To: dispatch@ietf.org Subject: [dispatch] New Proposal for Telephone-Related Queries I have a proposal to bounce off the group. Basically, this is a re-examination of some of the problems we've previously considered in the telephony-specific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through discussions in the past couple years, it's become clear that we would need to significantly extend ENUM to get it to handle all of the sorts of sources, subjects, and attributes that people want to factor into queries about telephone number routing and administration. Most of these discussions have gotten wrapped around the axle on questions of the underlying syntax and semantics of the DNS, which were a good match for the original vision of a public, user-driven ENUM, but don't seem to be such a good match for the uses people actually want to make of these protocols, in federated, service-provider-driven environments like those envisioned in SPEERMINT and provisioned in DRINKS. While the discussion may have died down a bit, the requirements that motivated th e discussion definitely aren't going away. Rather than continue to debate the applicability of the DNS and the probity of various extensions to it, we might make more progress if we work towards agreement on the semantics of queries for telephone-related data independently of any underlying protocols. In other words, focus on what kinds of questions about telephone numbers we want to be able to ask, and what kinds of information needs to go into the answers, and incorporate all this into an abstract data model. So for example, we know that we want to be able to express the source of a request in a query. What do we mean by source? I can think of a bunch of different kinds of source: the logical originator of the query (the administrative entity asking), the logical identity of any intermediary or aggregator forwarding the query, or even the point at the network from which the call originates (the originating trunk group, SBC or what have you). All three of those concepts of source seem important when it comes to answe ring questions about telephone numbers, so a data model would treat those as separate elements which can vary independently - then we can then try to figure out what's mandatory or optional, etc. We follow this same method for all the elements of queries and responses. Figure out what the attributes are of telephone numbers that we care about, sort them into buckets of routing data and administrative data, and so on. Once we have an agreement on the data model, then people can map the model to whatever underlying protocol they'd like - or just build it into a web API, or what have you. Those proposals could advance as separate documents. Having that flexibility would make it a lot easier to figure out what we really want the questions and answers to be, rather than thinking about what they realistically can be within the constraints of some existing underlying protocol. That's the idea. I'm not going to present a proposed charter for work or anything like that in Paris, but I am interested in hearing if people think this is a promising approach, and if so, perhaps we'd put a charter on the agenda for Vancouver. I have however submitted a -00 draft for this time which gives a high-level proposal for a data model and at least enumerates what some of the elements might be that would be populated in queries and responses. This is a pretty broad sketch, but it should convey the basic idea. You can check it out here: https://exchcas.va.neustar.com/owa/thoughts about the direction or the specifics of the data model are welcome. Thanks! Jon Peterson NeuStar, Inc. _______________________________________________ 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 paulej@packetizer.com Tue Mar 6 11:31:48 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5620A21F8514 for ; Tue, 6 Mar 2012 11:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fb2CLTzfvf7o for ; Tue, 6 Mar 2012 11:31:46 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5246221F84F9 for ; Tue, 6 Mar 2012 11:31:36 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q26JVW9U016164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Mar 2012 14:31:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331062293; bh=+vui3kyzOLQkPS7Xf3Qwk4uWF+8OP7GZ1/HG+juat7A=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=JGcPmR7WIZWLh2aH6t6Tzf2hO7itfrtIGbD5sv7lXxMZD8jTkL/h4UOpxICCyI2bU sMsiCVOdjD/pVF5VI0N3xnMi7otrBZg8PD1Fg0rGnctTJypl3m4JvcSUt9+VKRGLnc 0ixqcBiy2ZT6trKWTOyBRWlpN/zZUCVGyLIuJC5o= From: "Paul E. Jones" To: "'Gonzalo Camarillo'" , "'DISPATCH'" References: <4F4F5C19.9070607@ericsson.com> In-Reply-To: <4F4F5C19.9070607@ericsson.com> Date: Tue, 6 Mar 2012 14:31:38 -0500 Message-ID: <030e01ccfbcf$c07b7460$41725d20$@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: AQF17Kt9fhTk7OLSTyTCet4r/WjUfJcLxeiA Content-Language: en-us Subject: Re: [dispatch] Charter process for the INSIPID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 19:31:48 -0000 Gonzalo, I would suggest adding the following text to the end of the second paragraph of the charter: "Consideration must be given to the fact that the entities involved in a communication session might change as a result of service interaction in the network, such as call transfers, joins, etc." This is text we introduced in a later version of the charter. Paul > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Thursday, March 01, 2012 6:23 AM > To: DISPATCH > Subject: [dispatch] Charter process for the INSIPID WG > > Folks, > > Robert and I have been working on a charter proposal for the INSIPID WG. > This is the proposal that we have sent for review to the IESG and IAB: > > http://www.ietf.org/iesg/evaluation/sessionid-charter.txt > > We believe this proposal represents the consensus of the group. Note that > we have left out some comments that failed to get rough consensus on this > list. > > From now on, I will be taking care of the chartering process for this WG. > Today, I will discuss the charter proposal with the IESG and, if > everything goes OK, we will be sending it for external review shortly. > If you have further comments on the charter proposal, please send them as > part of its external review, which will be announced on the IETF > announcement list as usual. > > Also, I am going to be requesting the creation of the insipid mailing > list. > > Cheers, > > Gonzalo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Tue Mar 6 12:52:41 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE4E21E8053 for ; Tue, 6 Mar 2012 12:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH+zmr8nBN7S for ; Tue, 6 Mar 2012 12:52:41 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 42BCD21E8024 for ; Tue, 6 Mar 2012 12:52:41 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta13.westchester.pa.mail.comcast.net with comcast id iLkB1i0041ZXKqc5DLshLu; Tue, 06 Mar 2012 20:52:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id iLsh1i00U07duvL3hLshRP; Tue, 06 Mar 2012 20:52:41 +0000 Message-ID: <4F567918.5080009@alum.mit.edu> Date: Tue, 06 Mar 2012 15:52:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <4F4F5C19.9070607@ericsson.com> <030e01ccfbcf$c07b7460$41725d20$@packetizer.com> In-Reply-To: <030e01ccfbcf$c07b7460$41725d20$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Charter process for the INSIPID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 20:52:42 -0000 On 3/6/12 2:31 PM, Paul E. Jones wrote: > Gonzalo, > > I would suggest adding the following text to the end of the second paragraph > of the charter: > "Consideration must be given to the fact that the entities involved in a > communication session might change as a result of service interaction in the > network, such as call transfers, joins, etc." > > This is text we introduced in a later version of the charter. These words don't mention any constraints that should be imposed wile considering this. So the outcome might or might not specify that such changes do or don't preserve the session id. Is that what you are looking for? Thanks, Paul > Paul > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Gonzalo Camarillo >> Sent: Thursday, March 01, 2012 6:23 AM >> To: DISPATCH >> Subject: [dispatch] Charter process for the INSIPID WG >> >> Folks, >> >> Robert and I have been working on a charter proposal for the INSIPID WG. >> This is the proposal that we have sent for review to the IESG and IAB: >> >> http://www.ietf.org/iesg/evaluation/sessionid-charter.txt >> >> We believe this proposal represents the consensus of the group. Note that >> we have left out some comments that failed to get rough consensus on this >> list. >> >> From now on, I will be taking care of the chartering process for this WG. >> Today, I will discuss the charter proposal with the IESG and, if >> everything goes OK, we will be sending it for external review shortly. >> If you have further comments on the charter proposal, please send them as >> part of its external review, which will be announced on the IETF >> announcement list as usual. >> >> Also, I am going to be requesting the creation of the insipid mailing >> list. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> 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 sohel_khan777@yahoo.com Tue Mar 6 13:49:30 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D2E21E80D8 for ; Tue, 6 Mar 2012 13:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w05zQE7Q8Pry for ; Tue, 6 Mar 2012 13:49:29 -0800 (PST) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) by ietfa.amsl.com (Postfix) with SMTP id CDEFC21E80CA for ; Tue, 6 Mar 2012 13:49:28 -0800 (PST) Received: from [98.139.212.148] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 06 Mar 2012 21:49:25 -0000 Received: from [98.139.215.249] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 06 Mar 2012 21:49:25 -0000 Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 06 Mar 2012 21:49:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 883189.17829.bm@omp1062.mail.bf1.yahoo.com Received: (qmail 44407 invoked by uid 60001); 6 Mar 2012 21:49:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331070565; bh=yHAla6f79yWljACu1H3yGVZ+jv/7SKlvrnEVnpgU7q0=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=oeD00o2p6DynZdtAyAepP7l1SgT9mL89beSxloCZm2Ojkqup5PZKk3pPQD1sSD8X69+e8gdXOLmGmYWPFZmmZ+l6AN319iaONMUUF+4WnUfUjDDK6361VoNmSw6Goc5eXbcOBYg+4iXy0NMa/qn+nUCG1FXM46FFNoSohcyW2qQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=i53QbHh/LlrPFPCHfTqdxTWjEqWQDwNnbwqq+YTcubAtslqpO7ism//n9/Rutyp0lUH0CcbTAjFxUJyb2/Wq+HBQuojQMTJga1NUqv2+iS/B/QLy93sK8Yr2VWYNBh+VIPUcJ2fWYPnDq3qgFBKU13bstXswePJg9DnUm9vzQjM=; X-YMail-OSG: .WI1aagVM1kY_qjvcQyFgYfRFJAoAy3GK1YSF8g4CtPOe_3 c4EmnSsJ9Ta5etEtNKcC.hWRWi_dKrpCrBTs1V5q66gX.LLMjBVCnxo8jhhA c.ioSJJkKnQsc8CXvblPtGE_ZyNLx_z_kXifpR2CPyaZO1MvZuSPoapEAqp9 gjCxRCOHBh.0ZPuETnXuNS6TLAqhjy0P_AADGd58o9RPBDcEw15z5eXHdhmx cxekBZ6ixnmm1Yd1zne7oDy3FHtC_Bs4oljhODEe2ig.HHIGCEI64Bsv2.yu K7yEKg5l1WR7LnKUTcrl8kwssLLtQbnOiNuD1Ize1VkoH6IKC7bL8OEes2kY gKEi9xwxV3U9M4qU.1XABa9vVIUIyKh6KcqpRTy_rQzV2VsKK2OB1elenz_N m1KgFvaVmiV9vT.mbVaKiEcSjMvK2nu3jdLZKEaaFMeW5.KWY0r9okc_MoLq ttSUkTAW8ztWps5wys_sqxcyr9pI41Tk- Received: from [68.87.42.110] by web162005.mail.bf1.yahoo.com via HTTP; Tue, 06 Mar 2012 13:49:25 PST X-Mailer: YahooMailWebService/0.8.116.338427 Message-ID: <1331070565.44062.YahooMailNeo@web162005.mail.bf1.yahoo.com> Date: Tue, 6 Mar 2012 13:49:25 -0800 (PST) From: Sohel Khan To: "dispatch@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1328350513-1147388840-1331070565=:44062" Subject: [dispatch] Charter Proposal for Inter-Service Provider SIP Loop Detection and Mitigation WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 21:49:30 -0000 ---1328350513-1147388840-1331070565=:44062 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Based on the feedback received, I have updated the charter proposal for the= =C2=A0 Inter-Service-Provider SIP Loop Detection and Mitigation WG.=0APleas= e let us know whether we would like further changes in the charter.=0A=C2= =A0Inter-Service-ProviderSIP loop is a growing phenomenon. =C2=A0For exampl= e, SIP request messages traverse various providers and loop back to previou= s providers due to the parity of the routing vectors. In another example, S= IP messages traverse multiple service providers in a loop because of the or= igination-destination session forwarding to each other. SIP loops are often= amplified causing operational disruption in the Inter-Service-Providers=E2= =80=99 networks.=0A=C2=A0=0AIn the absence of B2BUA in session paths or a p= resence of a standard SIP compliant B2BUA that does not remove/reset SIP pa= rameters, many of the current SIP headers can aid in detecting multi-provid= er loop although there are some limitations. In particular, Current SIP loo= p-detection mechanisms do not work effectively in large-sale Inter-service = provider networks as they are now deployed.=C2=A0 For B2BUAs and topology-h= iding techniques often defeat loop-detection.=0A=C2=A0=0ASome large-service= providers would like to hide internal topology; however, would like to kno= w about loops around multiple service providers. Operation engineers from t= hese service providers point out the limitation of current SIP headers to m= itigate Inter-Service-Providers=E2=80=99 loop, while hiding the internal to= pology. For example, Max-Forwards can be used to detect too many hops by de= crementing values to zero; however, an optimum default value for Max-Forwar= ds is hard to determine since the number of nodes in the session path is ti= me/path variant depending on the origination-destination route vector among= SIP providers. SIP History-Info is another header that also aid in detecti= ng loop among multiple SIP providers. SIP History-Info depicts node informa= tion in the session path. The parameter in the=C2=A0History-Info is not oft= en the fixed size; thus, it is difficult to extract providers' names.=C2=A0= A SIP request may traverse a set of nodes in a service provider=E2=80=99s network, may loop around the world, and may enter the p= revious SIP providers=E2=80=99 networks in a different set of nodes; thus, = the new nodes may not know that the call had traversed=C2=A0the same SIP pr= oviders' networks in the past. In addition, SIP providers do not like to di= sclose internal node information.=0A=C2=A0=0AThe purpose of the WG is to st= udy how the existing mechanisms for loop detection work in current large-sc= ale service provider networks, and to recommend changes (to the networks an= d/or the mechanisms) to provide practical and effective loop detection in I= nter-Service-Provider networks. The recommended method should be such that = it detects Inter-Service-Provider loops while maintaining privacy and prese= rving SIP flexibility such as call forwarding.=0A=C2=A0=0A=C2=A0=0A=0ARegar= ds,=0ASohel Khan=C2=A0 ---1328350513-1147388840-1331070565=:44062 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Based on the feedback received, I have up= dated the charter proposal for the  Inter-Service-Provider SIP Loop De= tection and Mitigation WG.
Please let us know w= hether we would like further changes in the c= harter.
 
<= SPAN style=3D"RIGHT: auto">
<= U>Inter-Service-Provider SIP loop is a growing phe= nomenon.  For example, SIP request messages traverse various providers= and loop back to previous providers due to the parity of the routing vecto= rs. In another example, SIP messages traverse multiple service providers in= a loop because of the origination-destination session forwarding to each o= ther. SIP loops are often amplified causing operational disruption in the I= nter-Service-Providers=E2=80=99 networks.
 
In the absence of B2BUA in se= ssion paths or a presence of a standard SIP compliant B2BUA that does not r= emove/reset SIP parameters, many of the current SIP headers can aid in dete= cting multi-provider loop although there are some limitations. In particula= r, Current SIP loop-detection mechanisms do not work effectively in large-s= ale Inter-service provider networks as they are now deployed.  For B2BUAs and topology-hiding techniques= often defeat loop-detection.
 
Some large-service providers = would like to hide internal topology; however, would like to know about loo= ps around multiple service providers. Operation engineers from these servic= e providers point out the limitation of current SIP headers to mitigate Int= er-Service-Providers=E2=80=99 loop, while hiding the internal topology. For= example, Max-Forwards can be used to detect too many hops by decrementing = values to zero; however, an optimum default value for Max-Forwards is hard = to determine since the number of nodes in the session path is time/path var= iant depending on the origination-destination route vector among SIP provid= ers. SIP History-Info is another header that also aid in detecting loop amo= ng multiple SIP providers. SIP History-Info depicts node information in the s= ession path. The parameter in the History-Info is not often the fixed = size; thus, it is difficult to extract providers' names. A SIP request= may traverse a set of nodes in a service provider=E2=80=99s network, may l= oop around the world, and may enter the previous SIP providers=E2=80=99 net= works in a different set of nodes; thus, the new nodes may not know that th= e call had traversed the same SIP providers' networks in the past. In = addition, SIP providers do not like to disclose internal node information.<= o:p>
 
The purpose of the WG is to study how the existing mechani= sms for loop detection work in current large-scale service provider network= s, and to recommend changes (to the networks and/or the mechanisms) to prov= ide practical and effective loop detection in Inter-Service-Provider= networks. The recommended method should be such that it detects Inter-Serv= ice-Provider loops while maintaining privacy and preserving SIP flexibility= such as call forwarding.
 
 
 
 
Regards,
Sohel Khan
---1328350513-1147388840-1331070565=:44062-- From sohel_khan777@yahoo.com Tue Mar 6 14:05:33 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E0221E80D8 for ; Tue, 6 Mar 2012 14:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=0.957, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFYoMnRY+Zgh for ; Tue, 6 Mar 2012 14:05:32 -0800 (PST) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) by ietfa.amsl.com (Postfix) with SMTP id 4026C21E8032 for ; Tue, 6 Mar 2012 14:05:32 -0800 (PST) Received: from [98.139.215.141] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 06 Mar 2012 22:05:26 -0000 Received: from [98.139.212.248] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 06 Mar 2012 22:05:26 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 06 Mar 2012 22:05:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 23079.58380.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 49413 invoked by uid 60001); 6 Mar 2012 22:05:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331071525; bh=ntEIO8fvIJKhQcIR6Ie1bdBiePns+s57M4kWubYt1u0=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=2tRjGZtraX7rWEuIGjeI6XHjShFsKZBuSr8D8EaAGDlafu1JDIDGoiwWu/CwTlGR2o+He27fLxLKYtAn1YekYXKworPeB5DLyjnPV1hw5DT7Msa+B2qVpbx+jMCz8uWgRUeNx847/dJC43HKtC77fF6PH10K2xFCu34lWcnyhgE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=1qERQTOwRBdlSL/6LWJhpECSa7udIvWGJidOALeBcfzRCAsgUAqE7Hx8rnmh+9PkYqcxjal8uUetjoP8rbbCJIDPv+i02O+Q0BaDAJkFm0uhgl3LLFchzRVA89g00X4hR12unMFMZ8YWYCISFp5igfFJbSywWu1cjGVvUcNpkqA=; X-YMail-OSG: 1yyVhqQVM1kS0OOm3cy5ktfipbmcI.2ycgdiF15H4VochBi oB05Q5Uow_eGdMI_b36p_Mn3z7QmDePDL1STMZhhlopecq2i8t_1zXx5aRjX RImLu83UHYY3oRItMSnNsJ8yc0YA7LId931QtsitjKnPW_AggszIl1GewCTX O9171HoieMxo8lAbhsDscNXYsyWt1BJv1kh33559x1wu6ylPrPTbTw7RzoRZ xLjldzzFL29u3B4V876eM2NhRI03pvAbr4O54ja7IU2M3_TR1hdRRRXP4hi8 J5xVv1ZtrjyGT1IbzNL5QbJc6q4WOC8oUtQQueE1NqkCZSVSFs4QrxSJGGZT mih59HkP8nK9VR6USRDhWQ8NFOftogXvXll_r.tob.dJwFJWX7zJph3cei9b M.8piBaKiUGWroJQmOcT8F.p2tzp1p.X0QSXcdJmkOzIrC0ov4LdlY9Letdt fzyOvig9mivod2XKkE4u7WQUq5f5C0yiwlZqnw9pqGbFbwm3CDu06C6jxcwR wkFqd.3_3k_g31LXZNsM9sHlUyt48o4Lbi1dEG7Jo44q4FEC1_DknViRW Received: from [68.87.42.110] by web162003.mail.bf1.yahoo.com via HTTP; Tue, 06 Mar 2012 14:05:25 PST X-Mailer: YahooMailWebService/0.8.116.338427 Message-ID: <1331071525.36010.YahooMailNeo@web162003.mail.bf1.yahoo.com> Date: Tue, 6 Mar 2012 14:05:25 -0800 (PST) From: Sohel Khan To: "dispatch@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1705842018-1896050448-1331071525=:36010" Subject: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:05:33 -0000 --1705842018-1896050448-1331071525=:36010 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Jon, it is a very good initiative. I support the creation of a WG.= =0ANevertheless, in my opinion, we will need a fresh start on=A0developing = the real-time communication routing vector data model that includes emergin= g applications routing needs. It should not be just a TN issue. =A0A TN,=A0= a user name, or some other public identities can be an input vector to reso= lve a destination route vector for the real-time communication that account= s for the emerging technologies. I humbly request that we have a fresh star= t instead of trying to make something backward compatible that=A0limits the= innovation.=0A=A0=0ASohel Khan=0A=A0=0A-----Original Message-----=0AFrom: = =A0=A0=A0 Peterson, Jon [mailto:jon.peterson@neustar.biz]=0ASent:=A0=A0=A0 = Monday, March 05, 2012 04:51 PM Eastern Standard Time=0ATo:=A0=A0=A0 dispat= ch@ietf.org=0ASubject:=A0=A0=A0 [dispatch] New Proposal for Telephone-Relat= ed Queries=0A=0A=0AI have a proposal to bounce off the group. Basically, th= is is a=0Are-examination of some of the problems we've previously considere= d in the=0Atelephony-specific cluster of work surrounding ENUM, DRINKS and = SPEERMINT.=0AThrough discussions in the past couple years, it's become clea= r that we=0Awould need to significantly extend ENUM to get it to handle all= of the sorts=0Aof sources, subjects, and attributes that people want to fa= ctor into queries=0Aabout telephone number routing and administration. Most= of these discussions=0Ahave gotten wrapped around the axle on questions of= the underlying syntax=0Aand semantics of the DNS, which were a good match = for the original vision of=0Aa public, user-driven ENUM, but don't seem to = be such a good match for the=0Auses people actually want to make of these p= rotocols, in federated,=0Aservice-provider-driven environments like those e= nvisioned in SPEERMINT and=0Aprovisioned in DRINKS. While the discussion ma= y have died down a bit, the=0Arequirements that motivated th=0Ae discussion= definitely aren't going away.=0A=0ARather than continue to debate the appl= icability of the DNS and the probity=0Aof various extensions to it, we migh= t make more progress if we work towards=0Aagreement on the semantics of que= ries for telephone-related data=0Aindependently of any underlying protocols= . In other words, focus on what=0Akinds of questions about telephone number= s we want to be able to ask, and=0Awhat kinds of information needs to go in= to the answers, and incorporate all=0Athis into an abstract data model. So = for example, we know that we want to be=0Aable to express the source of a r= equest in a query. What do we mean by=0Asource? I can think of a bunch of d= ifferent kinds of source: the logical=0Aoriginator of the query (the admini= strative entity asking), the logical=0Aidentity of any intermediary or aggr= egator forwarding the query, or even the=0Apoint at the network from which = the call originates (the originating trunk=0Agroup, SBC or what have you). = All three of those concepts of source seem=0Aimportant when it comes to ans= we=0Aring questions about telephone numbers, so a data model would treat th= ose=0Aas separate elements which can vary independently - then we can then = try to=0Afigure out what's mandatory or optional, etc. We follow this same = method for=0Aall the elements of queries and responses. Figure out what the= attributes=0Aare of telephone numbers that we care about, sort them into b= uckets of=0Arouting data and administrative data, and so on.=0A=0AOnce we h= ave an agreement on the data model, then people can map the model=0Ato what= ever underlying protocol they'd like - or just build it into a web=0AAPI, o= r what have you. Those proposals could advance as separate documents.=0AHav= ing that flexibility would make it a lot easier to figure out what we=0Area= lly want the questions and answers to be, rather than thinking about what= =0Athey realistically can be within the constraints of some existing underl= ying=0Aprotocol.=0A=0AThat's the idea. I'm not going to present a proposed = charter for work or=0Aanything like that in Paris, but I am interested in h= earing if people think=0Athis is a promising approach, and if so, perhaps w= e'd put a charter on the=0Aagenda for Vancouver. I have however submitted a= -00 draft for this time=0Awhich gives a high-level proposal for a data mod= el and at least enumerates=0Awhat some of the elements might be that would = be populated in queries and=0Aresponses. This is a pretty broad sketch, but= it should convey the basic=0Aidea. You can check it out here:=0Ahttps://ex= chcas.va.neustar.com/owa/thoughts about the direction or the=0Aspecifics of= the data model are welcome. Thanks!=0A=0AJon Peterson=0ANeuStar, Inc=0A=0A= Regards,=0ASohel Khan --1705842018-1896050448-1331071525=:36010 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Jon, it is a very good initiative.= I support the creation of a WG.
Nevertheless, in my opinion, we will need a fresh start on de= veloping the real-time communication routing vector data model that include= s emerging applications routing needs. It should not be just a TN issue.  A TN, a user name, or some othe= r public identities can be an input vector to resolve a destination route v= ector for the real-time communication that accounts for the emerging techno= logies. I humbly request that we have a fresh start instead of trying to ma= ke something backward compatible that limits the innovation.
 
Sohel Khan
 
-----Original Messag= e-----
From:     Peterson, Jon [mailto:jon.p= eterson@neustar.biz]
Sent:    Monday, March 05, 2012 = 04:51 PM Eastern Standard Time
To:    dispatch@ietf.org
Subject:    [dispatch] New Proposal for Telephone-Relat= ed Queries


I have a proposal to bounce off the group. Basically,= this is a
re-examination of some of the problems we've previously consi= dered in the
telephony-specific cluster of work surrounding ENUM, DRINKS= and SPEERMINT.
Through discussions in the past couple years, it's becom= e clear that we
would need to significantly extend ENUM to get it to han= dle all of the sorts
of sources, subjects, and attributes that people wa= nt to factor into queries
about telephone number routing and administration. = Most of these discussions
have gotten wrapped around the axle on questio= ns of the underlying syntax
and semantics of the DNS, which were a good = match for the original vision of
a public, user-driven ENUM, but don't s= eem to be such a good match for the
uses people actually want to make of= these protocols, in federated,
service-provider-driven environments lik= e those envisioned in SPEERMINT and
provisioned in DRINKS. While the dis= cussion may have died down a bit, the
requirements that motivated th
= e discussion definitely aren't going away.

Rather than continue to d= ebate the applicability of the DNS and the probity
of various extensions= to it, we might make more progress if we work towards
agreement on the = semantics of queries for telephone-related data
independently of any und= erlying protocols. In other words, focus on what
kinds of questions about telephone numbers we want to be able to ask, and
what k= inds of information needs to go into the answers, and incorporate all
th= is into an abstract data model. So for example, we know that we want to be<= BR>able to express the source of a request in a query. What do we mean bysource? I can think of a bunch of different kinds of source: the logical<= BR>originator of the query (the administrative entity asking), the logical<= BR>identity of any intermediary or aggregator forwarding the query, or even= the
point at the network from which the call originates (the originatin= g trunk
group, SBC or what have you). All three of those concepts of sou= rce seem
important when it comes to answe
ring questions about teleph= one numbers, so a data model would treat those
as separate elements whic= h can vary independently - then we can then try to
figure out what's man= datory or optional, etc. We follow this same method for
all the elements of queries and responses. Figure out what the attributes
are o= f telephone numbers that we care about, sort them into buckets of
routin= g data and administrative data, and so on.

Once we have an agreement= on the data model, then people can map the model
to whatever underlying= protocol they'd like - or just build it into a web
API, or what have yo= u. Those proposals could advance as separate documents.
Having that flex= ibility would make it a lot easier to figure out what we
really want the= questions and answers to be, rather than thinking about what
they reali= stically can be within the constraints of some existing underlying
proto= col.

That's the idea. I'm not going to present a proposed charter fo= r work or
anything like that in Paris, but I am interested in hearing if= people think
this is a promising approach, and if so, perhaps we'd put = a charter on the
agenda for Vancouver. I have however submitted a -00 draft for this time
which gives a high-level proposal for a data mo= del and at least enumerates
what some of the elements might be that woul= d be populated in queries and
responses. This is a pretty broad sketch, = but it should convey the basic
idea. You can check it out here:
https://= exchcas.va.neustar.com/owa/thoughts about the direction or the
speci= fics of the data model are welcome. Thanks!

Jon Peterson
NeuStar, Inc
 
Regards,
Sohel Khan
--1705842018-1896050448-1331071525=:36010-- From pkyzivat@alum.mit.edu Tue Mar 6 14:22:03 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763D421E80A9 for ; Tue, 6 Mar 2012 14:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgqviBQHj+H6 for ; Tue, 6 Mar 2012 14:22:02 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB7D21E8013 for ; Tue, 6 Mar 2012 14:22:02 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta06.westchester.pa.mail.comcast.net with comcast id iNHg1i0030bG4ec56NN1Yi; Tue, 06 Mar 2012 22:22:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta03.westchester.pa.mail.comcast.net with comcast id iNMz1i02107duvL3PNMzxn; Tue, 06 Mar 2012 22:22:00 +0000 Message-ID: <4F568E06.2080408@alum.mit.edu> Date: Tue, 06 Mar 2012 17:21:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <1331070565.44062.YahooMailNeo@web162005.mail.bf1.yahoo.com> In-Reply-To: <1331070565.44062.YahooMailNeo@web162005.mail.bf1.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] Charter Proposal for Inter-Service Provider SIP Loop Detection and Mitigation WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:22:03 -0000 On 3/6/12 4:49 PM, Sohel Khan wrote: > Based on the feedback received, I have updated the charter proposal for > the Inter-Service-Provider SIP Loop Detection and Mitigation WG. > Please let us know whether we would like further changesin the charter. > _Inter-Service-Provider_SIP loop is a growing phenomenon. While I believe what you say above, I would hate to see the effort restricted to that scope. I suspect this occurs whenever messages cross trust boundaries. For instance, a singe SP with sip trunks to multiple enterprises could see the same sort of looping. > For example, > SIP request messages traverse various providers and loop back to > previous providers due to the parity of the routing vectors. In another I have no clue what "parity of routing vectors" means, and what that might have to do with looping. > example, SIP messages traverse multiple service providers in a loop > because of the origination-destination session forwarding to each other. > SIP loops are often amplified causing operational disruption in the > Inter-Service-Providers’ networks. > In the absence of B2BUA in session paths or a presence of a standard SIP > compliant B2BUA that does not remove/reset SIP parameters, many of the > current SIP headers can aid in detecting multi-provider loop although > there are some limitations. In particular, Current SIP loop-detection > mechanisms do not work effectively in large-sale Inter-service provider > networks as they are now deployed.For B2BUAs and topology-hiding > techniques often defeat loop-detection. Perhaps the major problem is topology hiding. And maybe all that's necessary to solve the problem is to do it more carefully. > Some large-service providers would like to hide internal topology; > however, would like to know about loops around multiple service > providers. Operation engineers from these service providers point out > the limitation of current SIP headers to mitigate > Inter-Service-Providers’ loop, while hiding the internal topology. For > example, Max-Forwards can be used to detect too many hops by > decrementing values to zero; however, an optimum default value for > Max-Forwards is hard to determine since the number of nodes in the > session path is time/path variant depending on the > origination-destination route vector among SIP providers. SIP > History-Info is another header that also aid in detecting loop among > multiple SIP providers. SIP History-Info depicts node information in the > session path. The parameter in the History-Info is not often the fixed > size; thus, it is difficult to extract providers' names. A SIP request I don't believe that lack of a fixed size identifier is the problem with this approach. For one thing, from what I have heard, a given SP will only be looking for itself. And as long as it knows the size of its own identifier you have the same advantage. (If its an advantage.) > may traverse a set of nodes in a service provider’s network, may loop > around the world, and may enter the previous SIP providers’ networks in > a different set of nodes; thus, the new nodes may not know that the call > had traversed the same SIP providers' networks in the past. In addition, As Dale has pointed out, traversing a particular SP's network multiple times *is not* sufficient evidence that there is a loop. And its not clear if topology hiding will preserve enough added data to tell those that are from those that aren't. > SIP providers do not like to disclose internal node information. > The purpose of the WG is to study how the existing mechanisms for loop > detection work in current large-scale service provider networks, and to > recommend changes (to the networks and/or the mechanisms) to provide > practical and effective loop detection in _Inter-Service-Provider_ > networks. Perhaps instead of "service provider networks" this should say "networks where topology hiding is used", or "networks that span SBCs". > The recommended method should be such that it detects > Inter-Service-Provider loops Just omit "Inter-Service-Provider" in the above. > while maintaining privacy and preserving > SIP flexibility such as call forwarding. Thanks, Paul > Regards, > Sohel Khan > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jon.peterson@neustar.biz Tue Mar 6 14:26:32 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDEC21E80EB for ; Tue, 6 Mar 2012 14:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.122 X-Spam-Level: X-Spam-Status: No, score=-106.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F39aHxA88hM for ; Tue, 6 Mar 2012 14:26:31 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8556721E8013 for ; Tue, 6 Mar 2012 14:26:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1331072810; x=1646425635; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=hEAoN8EWCiLY1EjKkne04 /dQlsVRjLtFdTraDL+mQew=; b=qj3QgmGEW/1MF9pB/I1FnHL2i6q+W5FAkQMFb XpjdWvImsglRUTO1E+/z3lewPO7Cr/JcXAYaWWCTxUk2vl+Bg== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.4002364; Tue, 06 Mar 2012 17:26:49 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 6 Mar 2012 17:26:27 -0500 From: "Peterson, Jon" To: Sohel Khan , "dispatch@ietf.org" Date: Tue, 6 Mar 2012 17:22:45 -0500 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: Acz75UhXejJb7c9BS3Sdawu1OPBFJwAAl9B5 Message-ID: <55A5A9A87506CB4BA580BF9D531957DA239D633D@STNTEXCH01.cis.neustar.com> References: <1331071525.36010.YahooMailNeo@web162003.mail.bf1.yahoo.com> In-Reply-To: <1331071525.36010.YahooMailNeo@web162003.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 8geuZ724Z5VDpSy+pV1h5Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:26:33 -0000 Hi Sohel, Thanks for your comment. If you take a look in the TeRQ draft, you'll see that the data model define= s a Subject of queries, but doesn't restrict it to telephone numbers. In fa= ct, there is at least one other identifier that we know we want to be able = to resolve as a telephone-related query today, and that's a SPID - in any S= PEERMINT-like architecture with a LUF/LRF, distinction, you may effectively= make two route passes, and on the second, operate on a SPID instead of a T= N. There are probably whole classes of similar identifiers for networks or = federations that might make sense in some deployments. The basic idea of the draft is to leave these categories pretty open-ended,= however, so that if we do have other sorts of identifiers we want to resol= ve that are related to telephone calls and routing, we can add them in futu= re specifications through an extensibility mechanism. So definitely we won'= t be trying to limit innovation in this space. Jon Peterson NeuStar, Inc. ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of So= hel Khan [sohel_khan777@yahoo.com] Sent: Tuesday, March 06, 2012 2:05 PM To: dispatch@ietf.org Subject: [dispatch] New Proposal for Telephone-Related Queries Thanks Jon, it is a very good initiative. I support the creation of a WG. Nevertheless, in my opinion, we will need a fresh start on developing the r= eal-time communication routing vector data model that includes emerging app= lications routing needs. It should not be just a TN issue. A TN, a user na= me, or some other public identities can be an input vector to resolve a des= tination route vector for the real-time communication that accounts for the= emerging technologies. I humbly request that we have a fresh start instead= of trying to make something backward compatible that limits the innovation= . Sohel Khan -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time To: dispatch@ietf.org Subject: [dispatch] New Proposal for Telephone-Related Queries I have a proposal to bounce off the group. Basically, this is a re-examination of some of the problems we've previously considered in the telephony-specific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through discussions in the past couple years, it's become clear that we would need to significantly extend ENUM to get it to handle all of the sort= s of sources, subjects, and attributes that people want to factor into querie= s about telephone number routing and administration. Most of these discussion= s have gotten wrapped around the axle on questions of the underlying syntax and semantics of the DNS, which were a good match for the original vision o= f a public, user-driven ENUM, but don't seem to be such a good match for the uses people actually want to make of these protocols, in federated, service-provider-driven environments like those envisioned in SPEERMINT and provisioned in DRINKS. While the discussion may have died down a bit, the requirements that motivated th e discussion definitely aren't going away. Rather than continue to debate the applicability of the DNS and the probity of various extensions to it, we might make more progress if we work towards agreement on the semantics of queries for telephone-related data independently of any underlying protocols. In other words, focus on what kinds of questions about telephone numbers we want to be able to ask, and what kinds of information needs to go into the answers, and incorporate all this into an abstract data model. So for example, we know that we want to b= e able to express the source of a request in a query. What do we mean by source? I can think of a bunch of different kinds of source: the logical originator of the query (the administrative entity asking), the logical identity of any intermediary or aggregator forwarding the query, or even th= e point at the network from which the call originates (the originating trunk group, SBC or what have you). All three of those concepts of source seem important when it comes to answe ring questions about telephone numbers, so a data model would treat those as separate elements which can vary independently - then we can then try to figure out what's mandatory or optional, etc. We follow this same method fo= r all the elements of queries and responses. Figure out what the attributes are of telephone numbers that we care about, sort them into buckets of routing data and administrative data, and so on. Once we have an agreement on the data model, then people can map the model to whatever underlying protocol they'd like - or just build it into a web API, or what have you. Those proposals could advance as separate documents. Having that flexibility would make it a lot easier to figure out what we really want the questions and answers to be, rather than thinking about wha= t they realistically can be within the constraints of some existing underlyin= g protocol. That's the idea. I'm not going to present a proposed charter for work or anything like that in Paris, but I am interested in hearing if people think this is a promising approach, and if so, perhaps we'd put a charter on the agenda for Vancouver. I have however submitted a -00 draft for this time which gives a high-level proposal for a data model and at least enumerates what some of the elements might be that would be populated in queries and responses. This is a pretty broad sketch, but it should convey the basic idea. You can check it out here: https://exchcas.va.neustar.com/owa/thoughts about the direction or the specifics of the data model are welcome. Thanks! Jon Peterson NeuStar, Inc Regards, Sohel Khan From jmpolk@cisco.com Tue Mar 6 15:22:04 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CABB21E8026; Tue, 6 Mar 2012 15:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.668 X-Spam-Level: X-Spam-Status: No, score=-109.668 tagged_above=-999 required=5 tests=[AWL=0.931, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8o970q5wS8O; Tue, 6 Mar 2012 15:22:03 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC6521E800F; Tue, 6 Mar 2012 15:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2731; q=dns/txt; s=iport; t=1331076123; x=1332285723; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=Tdi4ZRJHcsao0wQEkcaJU3kjxcrFAGtQgzNv7EJrIsI=; b=nG1O3m7s8e4BoJ1ur5Awk5MCtzSwtiLlxEzctI0TihfVwPQTIEzkBVWM rTp8L6n0fAOfb6ATO3D5c+LWPSY/c0oXJqTtxbJoqB7cFVsLvtOjjlK3H r+RpJLY7AZR1CsFR+DWGqBDGA64F+++XFwmHeMB7heFvriTb4jHn0ALeH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOibVk+rRDoJ/2dsb2JhbABDDrUBgQeBfQEBAQQBAQEPASUCNBcEBwQOAwQBAQEeCQcZDh8JCAYBCQkJGYdkDKBaAZcxkHAEiFKdA4IsVg X-IronPort-AV: E=Sophos;i="4.73,542,1325462400"; d="scan'208";a="32275633" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 06 Mar 2012 23:22:03 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q26NM2BT020676; Tue, 6 Mar 2012 23:22:02 GMT Message-Id: <201203062322.q26NM2BT020676@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 06 Mar 2012 17:22:01 -0600 To: Paul Kyzivat , dispatch@ietf.org, insipid@ietf.org From: "James M. Polk" In-Reply-To: <4F567918.5080009@alum.mit.edu> References: <4F4F5C19.9070607@ericsson.com> <030e01ccfbcf$c07b7460$41725d20$@packetizer.com> <4F567918.5080009@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dispatch] Charter process for the INSIPID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 23:22:04 -0000 At 02:52 PM 3/6/2012, Paul Kyzivat wrote: >On 3/6/12 2:31 PM, Paul E. Jones wrote: >>Gonzalo, >> >>I would suggest adding the following text to the end of the second paragraph >>of the charter: >>"Consideration must be given to the fact that the entities involved in a >>communication session might change as a result of service interaction in the >>network, such as call transfers, joins, etc." >> >>This is text we introduced in a later version of the charter. > >These words don't mention any constraints that should be imposed >wile considering this. So the outcome might or might not specify >that such changes do or don't preserve the session id. > >Is that what you are looking for? > > Thanks, > Paul May I suggest that folks interested in this subject take their discussions over to the NEW INSIPID list at insipid@ietf.org after they register into that list. This will clear up DISPATCH from hearing about this, while focusing Session-ID talk to the IPSIPID list, which is more appropriate IMO. James >>Paul >> >>>-----Original Message----- >>>From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>Behalf Of Gonzalo Camarillo >>>Sent: Thursday, March 01, 2012 6:23 AM >>>To: DISPATCH >>>Subject: [dispatch] Charter process for the INSIPID WG >>> >>>Folks, >>> >>>Robert and I have been working on a charter proposal for the INSIPID WG. >>>This is the proposal that we have sent for review to the IESG and IAB: >>> >>>http://www.ietf.org/iesg/evaluation/sessionid-charter.txt >>> >>>We believe this proposal represents the consensus of the group. Note that >>>we have left out some comments that failed to get rough consensus on this >>>list. >>> >>> From now on, I will be taking care of the chartering process for this WG. >>>Today, I will discuss the charter proposal with the IESG and, if >>>everything goes OK, we will be sending it for external review shortly. >>>If you have further comments on the charter proposal, please send them as >>>part of its external review, which will be announced on the IETF >>>announcement list as usual. >>> >>>Also, I am going to be requesting the creation of the insipid mailing >>>list. >>> >>>Cheers, >>> >>>Gonzalo >>> >>>_______________________________________________ >>>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 Tue Mar 6 16:31:33 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E46621F8691; Tue, 6 Mar 2012 16:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.747 X-Spam-Level: X-Spam-Status: No, score=-102.747 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pimwtVGkap4Q; Tue, 6 Mar 2012 16:31:32 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38B8821F8684; Tue, 6 Mar 2012 16:31:29 -0800 (PST) Received: by vbbez10 with SMTP id ez10so5726609vbb.31 for ; Tue, 06 Mar 2012 16:31:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ej1pS68htU5MpIOX6b1GcBn+wLMQ1dbSnNAGonANmbs=; b=Bc1vyFH8hEaULGFl+41MVMUw/F8olGAX42j+jJRnO6DiIArtSjws1TOmE/fxpK/RK/ y8aG/oJd/uDcX6JDcNMB5D5gR8crf2QQTDsoYVJaWjKCek40k8PMcpHp6gjZjivWMkks HCb9gQ1aKjSnfyY6eVoCouRm1azocki9Zdp5em7ofWEKdBwXYEuMV1MRIZYQsh8lBSeU sedyrxTT52wGFFiKKO63p2rONNv7W/A8GDF1BV6UsniOCkhSEHH0tIaQcnXuSHzZi7eC 5S1d/l2QKezj13KueHFknj/maBtMvLHCe0EL6+QAfaRAE81de/VjW+2zw1FI/XHCo6gD eaVg== MIME-Version: 1.0 Received: by 10.52.28.200 with SMTP id d8mr75653vdh.38.1331080288780; Tue, 06 Mar 2012 16:31:28 -0800 (PST) Received: by 10.52.111.136 with HTTP; Tue, 6 Mar 2012 16:31:28 -0800 (PST) In-Reply-To: <201203062322.q26NM2BT020676@mtv-core-4.cisco.com> References: <4F4F5C19.9070607@ericsson.com> <030e01ccfbcf$c07b7460$41725d20$@packetizer.com> <4F567918.5080009@alum.mit.edu> <201203062322.q26NM2BT020676@mtv-core-4.cisco.com> Date: Tue, 6 Mar 2012 18:31:28 -0600 Message-ID: From: Mary Barnes To: "James M. Polk" Content-Type: multipart/alternative; boundary=20cf3079bc9ec7c3a604ba9c47a8 Cc: dispatch@ietf.org, insipid@ietf.org Subject: Re: [dispatch] Charter process for the INSIPID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 00:31:33 -0000 --20cf3079bc9ec7c3a604ba9c47a8 Content-Type: text/plain; charset=ISO-8859-1 Personally, I think we should keep charter discussions on DISPATCH for now. I agree that discussing solution details should happen on the INSIPID list. Thanks, Mary On Tue, Mar 6, 2012 at 5:22 PM, James M. Polk wrote: > At 02:52 PM 3/6/2012, Paul Kyzivat wrote: > >> On 3/6/12 2:31 PM, Paul E. Jones wrote: >> >>> Gonzalo, >>> >>> I would suggest adding the following text to the end of the second >>> paragraph >>> of the charter: >>> "Consideration must be given to the fact that the entities involved in a >>> communication session might change as a result of service interaction in >>> the >>> network, such as call transfers, joins, etc." >>> >>> This is text we introduced in a later version of the charter. >>> >> >> These words don't mention any constraints that should be imposed wile >> considering this. So the outcome might or might not specify that such >> changes do or don't preserve the session id. >> >> Is that what you are looking for? >> >> Thanks, >> Paul >> > > May I suggest that folks interested in this subject take their discussions > over to the NEW INSIPID list at insipid@ietf.org after they register into > that list. > > This will clear up DISPATCH from hearing about this, while focusing > Session-ID talk to the IPSIPID list, which is more appropriate IMO. > > James > > > > Paul >>> >>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.**org] >>>> On >>>> Behalf Of Gonzalo Camarillo >>>> Sent: Thursday, March 01, 2012 6:23 AM >>>> To: DISPATCH >>>> Subject: [dispatch] Charter process for the INSIPID WG >>>> >>>> Folks, >>>> >>>> Robert and I have been working on a charter proposal for the INSIPID WG. >>>> This is the proposal that we have sent for review to the IESG and IAB: >>>> >>>> http://www.ietf.org/iesg/**evaluation/sessionid-charter.**txt >>>> >>>> We believe this proposal represents the consensus of the group. Note >>>> that >>>> we have left out some comments that failed to get rough consensus on >>>> this >>>> list. >>>> >>>> From now on, I will be taking care of the chartering process for this >>>> WG. >>>> Today, I will discuss the charter proposal with the IESG and, if >>>> everything goes OK, we will be sending it for external review shortly. >>>> If you have further comments on the charter proposal, please send them >>>> as >>>> part of its external review, which will be announced on the IETF >>>> announcement list as usual. >>>> >>>> Also, I am going to be requesting the creation of the insipid mailing >>>> list. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> ______________________________**_________________ >>>> 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 > --20cf3079bc9ec7c3a604ba9c47a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Personally, I think we should keep charter discussions on DISPATCH for now.= =A0I agree that discussing solution details should happen on the INSIPID l= ist.

Thanks,
Mary=A0

On Tue, Mar 6, 2012 at 5:22 PM, James M. Polk <jmpolk@cisco.com> wrote:
At 02:52 PM 3/6/2012, Paul Kyzivat wrote:
On 3/6/12 2:31 PM, Paul E. Jones wrote:
Gonzalo,

I would suggest adding the following text to the end of the second paragrap= h
of the charter:
"Consideration must be given to the fact that the entities involved in= a
communication session might change as a result of service interaction in th= e
network, such as call transfers, joins, etc."

This is text we introduced in a later version of the charter.

These words don't mention any constraints that should be imposed wile c= onsidering this. So the outcome might or might not specify that such change= s do or don't preserve the session id.

Is that what you are looking for?

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

May I suggest that folks interested in this subject take their discussions = over to the NEW INSIPID list at insipid@ietf.org after they register into that list.

This will clear up DISPATCH from hearing about this, while focusing Session= -ID talk to the IPSIPID list, which is more appropriate IMO.

James



Paul

-----Original Message-----
From: dispat= ch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Gonzalo Camarillo
Sent: Thursday, March 01, 2012 6:23 AM
To: DISPATCH
Subject: [dispatch] Charter process for the INSIPID WG

Folks,

Robert and I have been working on a charter proposal for the INSIPID WG. This is the proposal that we have sent for review to the IESG and IAB:

http://www.ietf.org/iesg/evaluation/sessionid-charter.<= u>txt

We believe this proposal represents the consensus of the group. Note that we have left out some comments that failed to get rough consensus on this list.

=A0From now on, I will be taking care of the chartering process for this WG= .
Today, I will discuss the charter proposal with the IESG and, if
everything goes OK, we will be sending it for external review shortly.
If you have further comments on the charter proposal, please send them as part of its external review, which will be announced on the IETF
announcement list as usual.

Also, I am going to be requesting the creation of the insipid mailing
list.

Cheers,

Gonzalo

_______________________________________________
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

--20cf3079bc9ec7c3a604ba9c47a8-- From mary.ietf.barnes@gmail.com Tue Mar 6 16:34:38 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D3221F8698; Tue, 6 Mar 2012 16:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.734 X-Spam-Level: X-Spam-Status: No, score=-102.734 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0wTp2wOSE0K; Tue, 6 Mar 2012 16:34:37 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36C4F21F8692; Tue, 6 Mar 2012 16:34:37 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so5758117vcb.31 for ; Tue, 06 Mar 2012 16:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hfEUu8OOI2x3+PHwnAlJevMZz1/QVKw/J1DsrlcjXTs=; b=hlktm1LWwI92eG1fUpNbXJw7AwBg9yhVLxdzE5pRv8gKQYQzTlqAcVyOOgzNuqAtsn F6nR+w0Nu1K4L6bsCb/JcOhfFLCJ35pLtzeilK5X0bYGfZZqhAqUUSwjbw3gAYEyJ6rE iDz88yF9Gci7Bf/59CJJo29QXwZDXIkigx+/XsOLapkiWn84Gys7Im6vXTlBOarGNAw6 nl+x4GgX8XeakmHpMAWX8DpUHEteIqqZIHXBxCo7YJAKkvK50OLbH0jxmS+Ncyy3LiSU 9kcIZ81oc3miVLLY1fU/pclxHmvzWUNSaVsQ/NgyTc9ko2MP+cArLOwM0YFkkW4RB2Ff V1BQ== MIME-Version: 1.0 Received: by 10.52.88.103 with SMTP id bf7mr30675vdb.72.1331080476549; Tue, 06 Mar 2012 16:34:36 -0800 (PST) Received: by 10.52.111.136 with HTTP; Tue, 6 Mar 2012 16:34:36 -0800 (PST) In-Reply-To: <201203062322.q26NM2BT020676@mtv-core-4.cisco.com> References: <4F4F5C19.9070607@ericsson.com> <030e01ccfbcf$c07b7460$41725d20$@packetizer.com> <4F567918.5080009@alum.mit.edu> <201203062322.q26NM2BT020676@mtv-core-4.cisco.com> Date: Tue, 6 Mar 2012 18:34:36 -0600 Message-ID: From: Mary Barnes To: "James M. Polk" Content-Type: multipart/alternative; boundary=20cf307f3c04f8e35b04ba9c5248 Cc: rai-ads@tools.ietf.org, dispatch@ietf.org, insipid@ietf.org Subject: Re: [dispatch] Charter process for the INSIPID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 00:34:38 -0000 --20cf307f3c04f8e35b04ba9c5248 Content-Type: text/plain; charset=ISO-8859-1 Also, did anyone ever send an email to DISPATCH announcing the new mailing list? I can't find anything in the archives nor was anything posted on the RAI area mailing list. Mary. On Tue, Mar 6, 2012 at 5:22 PM, James M. Polk wrote: > At 02:52 PM 3/6/2012, Paul Kyzivat wrote: > >> On 3/6/12 2:31 PM, Paul E. Jones wrote: >> >>> Gonzalo, >>> >>> I would suggest adding the following text to the end of the second >>> paragraph >>> of the charter: >>> "Consideration must be given to the fact that the entities involved in a >>> communication session might change as a result of service interaction in >>> the >>> network, such as call transfers, joins, etc." >>> >>> This is text we introduced in a later version of the charter. >>> >> >> These words don't mention any constraints that should be imposed wile >> considering this. So the outcome might or might not specify that such >> changes do or don't preserve the session id. >> >> Is that what you are looking for? >> >> Thanks, >> Paul >> > > May I suggest that folks interested in this subject take their discussions > over to the NEW INSIPID list at insipid@ietf.org after they register into > that list. > > This will clear up DISPATCH from hearing about this, while focusing > Session-ID talk to the IPSIPID list, which is more appropriate IMO. > > James > > > > Paul >>> >>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.**org] >>>> On >>>> Behalf Of Gonzalo Camarillo >>>> Sent: Thursday, March 01, 2012 6:23 AM >>>> To: DISPATCH >>>> Subject: [dispatch] Charter process for the INSIPID WG >>>> >>>> Folks, >>>> >>>> Robert and I have been working on a charter proposal for the INSIPID WG. >>>> This is the proposal that we have sent for review to the IESG and IAB: >>>> >>>> http://www.ietf.org/iesg/**evaluation/sessionid-charter.**txt >>>> >>>> We believe this proposal represents the consensus of the group. Note >>>> that >>>> we have left out some comments that failed to get rough consensus on >>>> this >>>> list. >>>> >>>> From now on, I will be taking care of the chartering process for this >>>> WG. >>>> Today, I will discuss the charter proposal with the IESG and, if >>>> everything goes OK, we will be sending it for external review shortly. >>>> If you have further comments on the charter proposal, please send them >>>> as >>>> part of its external review, which will be announced on the IETF >>>> announcement list as usual. >>>> >>>> Also, I am going to be requesting the creation of the insipid mailing >>>> list. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> ______________________________**_________________ >>>> 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 > --20cf307f3c04f8e35b04ba9c5248 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Also, did anyone ever send an email to DISPATCH announcing the new mailing = list? =A0I can't find anything in the archives nor was anything posted = on the RAI area mailing list.=A0

Mary.

On Tue, Mar 6, 2012 at 5:22 PM, James M. Polk <jmpolk@cisco.com> wrote:
At 02:52 PM 3/6/2012, Paul Kyzivat wrote:
On 3/6/12 2:31 PM, Paul E. Jones wrote:
Gonzalo,

I would suggest adding the following text to the end of the second paragrap= h
of the charter:
"Consideration must be given to the fact that the entities involved in= a
communication session might change as a result of service interaction in th= e
network, such as call transfers, joins, etc."

This is text we introduced in a later version of the charter.

These words don't mention any constraints that should be imposed wile c= onsidering this. So the outcome might or might not specify that such change= s do or don't preserve the session id.

Is that what you are looking for?

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

May I suggest that folks interested in this subject take their discussions = over to the NEW INSIPID list at insipid@ietf.org after they register into that list.

This will clear up DISPATCH from hearing about this, while focusing Session= -ID talk to the IPSIPID list, which is more appropriate IMO.

James



Paul

-----Original Message-----
From: dispat= ch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Gonzalo Camarillo
Sent: Thursday, March 01, 2012 6:23 AM
To: DISPATCH
Subject: [dispatch] Charter process for the INSIPID WG

Folks,

Robert and I have been working on a charter proposal for the INSIPID WG. This is the proposal that we have sent for review to the IESG and IAB:

http://www.ietf.org/iesg/evaluation/sessionid-charter.<= u>txt

We believe this proposal represents the consensus of the group. Note that we have left out some comments that failed to get rough consensus on this list.

=A0From now on, I will be taking care of the chartering process for this WG= .
Today, I will discuss the charter proposal with the IESG and, if
everything goes OK, we will be sending it for external review shortly.
If you have further comments on the charter proposal, please send them as part of its external review, which will be announced on the IETF
announcement list as usual.

Also, I am going to be requesting the creation of the insipid mailing
list.

Cheers,

Gonzalo

_______________________________________________
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

--20cf307f3c04f8e35b04ba9c5248-- From mary.ietf.barnes@gmail.com Tue Mar 6 16:41:12 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022AB21F8705 for ; Tue, 6 Mar 2012 16:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dKKvQJh64c7 for ; Tue, 6 Mar 2012 16:41:11 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7212521F8704 for ; Tue, 6 Mar 2012 16:41:11 -0800 (PST) Received: by vbbez10 with SMTP id ez10so5732757vbb.31 for ; Tue, 06 Mar 2012 16:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fZbZlcoceX2LvTbSpghZbD5WHshWFfBY5qGEJmUmuDk=; b=ilb6wY1errW5TFO6oJYUPJKMGGQlQYfG4OA1Z0yLR4pUCqmPQaVs+xJce4n4eU/2jG Zm5V5xgztw0dhdHU5sTU1hgo+xr0Kqht0VkN7aLqivpGgMY4G3gRatrcTCJGuAZmhMn5 3/Hd0ZHSYy2lk2CpK2iGj9zqaqWyfQ8+DygrfcqqFapvaBfOfYzJrTVU8oMyaCY02lCy zyrku2fqiAzI6nnqQWdcoOtVug7kUdxENidatFklJINzWDQERBk19EJv0AH8vMYViT6K XF/DakZjUKWQJ8O7jDwMyuGDyqkGMDn/BtEkmn3k5vfAjmwqwWpDrYQEK5Mw5EpRO9YE IiGg== MIME-Version: 1.0 Received: by 10.52.70.165 with SMTP id n5mr87030vdu.55.1331080870719; Tue, 06 Mar 2012 16:41:10 -0800 (PST) Received: by 10.52.111.136 with HTTP; Tue, 6 Mar 2012 16:41:10 -0800 (PST) Date: Tue, 6 Mar 2012 18:41:10 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=bcaec5015e5377718004ba9c6ac2 Subject: [dispatch] NEW mailing list for proposed INSIPID working group X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 00:41:12 -0000 --bcaec5015e5377718004ba9c6ac2 Content-Type: text/plain; charset=ISO-8859-1 Here's a link to subscribe to the new mailing list: https://www1.ietf.org/mailman/listinfo/insipid As I said in a previous email, please keep charter discussions on DISPATCH as not everyone will want to be involved in the detailed solution discussions but might care about the charter in general. Thanks, Mary. --bcaec5015e5377718004ba9c6ac2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here's a link to subscribe to the new mailing list:

As I said in a previous email,= please keep charter discussions on DISPATCH as not everyone will want to b= e involved in the detailed solution discussions but might care about the ch= arter in general.

Thanks,
Mary.
--bcaec5015e5377718004ba9c6ac2-- From sohel_khan777@yahoo.com Tue Mar 6 18:08:07 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E46221E8046 for ; Tue, 6 Mar 2012 18:08:07 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjLAd46MqQYo for ; Tue, 6 Mar 2012 18:08:06 -0800 (PST) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) by ietfa.amsl.com (Postfix) with SMTP id 0284021E8043 for ; Tue, 6 Mar 2012 18:08:05 -0800 (PST) Received: from [98.139.212.148] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2012 02:08:00 -0000 Received: from [98.139.212.238] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2012 02:08:00 -0000 Received: from [127.0.0.1] by omp1047.mail.bf1.yahoo.com with NNFMP; 07 Mar 2012 02:08:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 516069.87922.bm@omp1047.mail.bf1.yahoo.com Received: (qmail 61057 invoked by uid 60001); 7 Mar 2012 02:08:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331086080; bh=wMQxkHhBKPXUxW/4g6Atap4znjvSVx+ZzdAytwwg9UU=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=h1maTOGcldcPGMqTfP+PmDNOEDCPYPPJeSAblAA9PFWGVvm4l7zQVlXT6vnSoyD3TCEpLJihKv+lHgjZpdYWEw7Nepw0bqOYautu3lxqFfNuSVDUR6G2uJcTIaOKjy7cDnL4tz2By2RJQ0p4pzaQgf1ESb/4E6ZnLUBRIbEBtc0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=5pg7E8TZzwro35bcrwpdvSDkSww2AkN9GJV7aZu6LgsXkZa2bERLrvtNvnp0fr/+4Dj6yX01WWPbF3CzoNlMLQuPgC+wPMjMChj+9WnyC8h04+uFYyJTn2AVikD+AzONZfBtbwjtPNk9CNUOLzVrfsyaYvWmYqBsjEv35u12NdI=; X-YMail-OSG: fJlXwO8VM1n76eRajYuoN6FTi2rqYAqL.WWI3FoUewlWbLo byUluWevsbo7YXpmBuW_.0lOTQH7S2q2aSO2EA_2i_2aNAdEga7yFkLFhR6U sjnbh9ih8fdG4ZWDeyAr9LxmlCOedh_2DZuuAKbcjkjhODlvA4mcEGWvMAFG vTSBuYDDJ17QZGa2ZMR5v_d3GCMg8Fl.6cyNPuXk3YsVqWea3E7JzpSYNtZM PIDOUD9VWZYXJRSjxPvjOM4TtqECUSNmcaT.BbMdSI_yzbouWurQmRV6kWje GlQcIimk4hOkHoq_07pgrPLky8fxcAKbRZ1VyPUyhhdgkdqkDTSMG_bwWRVB 976Ln2CWkShtVB3V3Tw74yUY0uzo5FYpPy2MDFUgSr3lpnjjIDdPZIpBeFpH Y508k3INm33O8IZmsnbrC0mF4Iopogh.tK46Zv_OVQOAPJdfl6BDSFRJF8Xy BDfk6qSephXE86Nsk6HuWoxLbbKnwIr5mHOHqg2G.yywwdyeMmOdYzmM_gBw F1Qr2qwzOTxXCbvs5i6jtCM.9szDe4kaB5rJh3x04L9qoloSVkrxok7fbQBV LjDS1F.0TozsAZmuRDpM0hXs- Received: from [71.224.138.238] by web162003.mail.bf1.yahoo.com via HTTP; Tue, 06 Mar 2012 18:08:00 PST X-Mailer: YahooMailWebService/0.8.116.338427 References: <1331071525.36010.YahooMailNeo@web162003.mail.bf1.yahoo.com> <55A5A9A87506CB4BA580BF9D531957DA239D633D@STNTEXCH01.cis.neustar.com> Message-ID: <1331086080.49394.YahooMailNeo@web162003.mail.bf1.yahoo.com> Date: Tue, 6 Mar 2012 18:08:00 -0800 (PST) From: Sohel Khan To: "Peterson, Jon" , "dispatch@ietf.org" In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA239D633D@STNTEXCH01.cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1705842018-1820889896-1331086080=:49394" Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 02:08:07 -0000 --1705842018-1820889896-1331086080=:49394 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jon,=0A=0AThank you for the nice draft.=0AIt will be nice to have a sing= le query an array of identifiers to resolve the destination and service arr= ay instead of current enum method of only one single identifier input. =A0I= will explain more in details in Pairs.=0A=A0=0ARegards,=0ASohel Khan=0A=0A= =0A________________________________=0A From: "Peterson, Jon" =0ATo: Sohel Khan ; "dispatch@ietf.org= " =0ASent: Tuesday, March 6, 2012 5:22 PM=0ASubject: RE= : [dispatch] New Proposal for Telephone-Related Queries=0A =0A=0AHi Sohel,= =0A=0AThanks for your comment.=0A=0AIf you take a look in the TeRQ draft, y= ou'll see that the data model defines a Subject of queries, but doesn't res= trict it to telephone numbers. In fact, there is at least one other identif= ier that we know we want to be able to resolve as a telephone-related query= today, and that's a SPID - in any SPEERMINT-like architecture with a LUF/L= RF, distinction, you may effectively make two route passes, and on the seco= nd, operate on a SPID instead of a TN. There are probably whole classes of = similar identifiers for networks or federations that might make sense in so= me deployments.=0A=0AThe basic idea of the draft is to leave these categori= es pretty open-ended, however, so that if we do have other sorts of identif= iers we want to resolve that are related to telephone calls and routing, we= can add them in future specifications through an extensibility mechanism. = So definitely we won't be trying to limit innovation in this space.=0A=0AJo= n Peterson=0ANeuStar, Inc.=0A________________________________________=0AFro= m: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Sohel= Khan [sohel_khan777@yahoo.com]=0ASent: Tuesday, March 06, 2012 2:05 PM=0AT= o: dispatch@ietf.org=0ASubject: [dispatch]=A0 New Proposal for Telephone-Re= lated Queries=0A=0AThanks Jon, it is a very good initiative. I support the = creation of a WG.=0ANevertheless, in my opinion, we will need a fresh start= on developing the real-time communication routing vector data model that i= ncludes emerging applications routing needs. It should not be just a TN iss= ue.=A0 A TN, a user name, or some other public identities can be an input v= ector to resolve a destination route vector for the real-time communication= that accounts for the emerging technologies. I humbly request that we have= a fresh start instead of trying to make something backward compatible that= limits the innovation.=0A=0ASohel Khan=0A=0A-----Original Message-----=0AF= rom:=A0 =A0 Peterson, Jon [mailto:jon.peterson@neustar.biz]=0ASent:=A0 =A0 Monday, March 05, 2012 04:51 PM Eastern S= tandard Time=0ATo:=A0 =A0 dispatch@ietf.org=0ASub= ject:=A0 =A0 [dispatch] New Proposal for Telephone-Related Queries=0A=0A=0A= I have a proposal to bounce off the group. Basically, this is a=0Are-examin= ation of some of the problems we've previously considered in the=0Atelephon= y-specific cluster of work surrounding ENUM, DRINKS and SPEERMINT.=0AThroug= h discussions in the past couple years, it's become clear that we=0Awould n= eed to significantly extend ENUM to get it to handle all of the sorts=0Aof = sources, subjects, and attributes that people want to factor into queries= =0Aabout telephone number routing and administration. Most of these discuss= ions=0Ahave gotten wrapped around the axle on questions of the underlying s= yntax=0Aand semantics of the DNS, which were a good match for the original = vision of=0Aa public, user-driven ENUM, but don't seem to be such a good ma= tch for the=0Auses people actually want to make of these protocols, in fede= rated,=0Aservice-provider-driven environments like those envisioned in SPEE= RMINT and=0Aprovisioned in DRINKS. While the discussion may have died down = a bit, the=0Arequirements that motivated th=0Ae discussion definitely aren'= t going away.=0A=0ARather than continue to debate the applicability of the = DNS and the probity=0Aof various extensions to it, we might make more progr= ess if we work towards=0Aagreement on the semantics of queries for telephon= e-related data=0Aindependently of any underlying protocols. In other words,= focus on what=0Akinds of questions about telephone numbers we want to be a= ble to ask, and=0Awhat kinds of information needs to go into the answers, a= nd incorporate all=0Athis into an abstract data model. So for example, we k= now that we want to be=0Aable to express the source of a request in a query= . What do we mean by=0Asource? I can think of a bunch of different kinds of= source: the logical=0Aoriginator of the query (the administrative entity a= sking), the logical=0Aidentity of any intermediary or aggregator forwarding= the query, or even the=0Apoint at the network from which the call originat= es (the originating trunk=0Agroup, SBC or what have you). All three of thos= e concepts of source seem=0Aimportant when it comes to answe=0Aring questio= ns about telephone numbers, so a data model would treat those=0Aas separate= elements which can vary independently - then we can then try to=0Afigure o= ut what's mandatory or optional, etc. We follow this same method for=0Aall = the elements of queries and responses. Figure out what the attributes=0Aare= of telephone numbers that we care about, sort them into buckets of=0Arouti= ng data and administrative data, and so on.=0A=0AOnce we have an agreement = on the data model, then people can map the model=0Ato whatever underlying p= rotocol they'd like - or just build it into a web=0AAPI, or what have you. = Those proposals could advance as separate documents.=0AHaving that flexibil= ity would make it a lot easier to figure out what we=0Areally want the ques= tions and answers to be, rather than thinking about what=0Athey realistical= ly can be within the constraints of some existing underlying=0Aprotocol.=0A= =0AThat's the idea. I'm not going to present a proposed charter for work or= =0Aanything like that in Paris, but I am interested in hearing if people th= ink=0Athis is a promising approach, and if so, perhaps we'd put a charter o= n the=0Aagenda for Vancouver. I have however submitted a -00 draft for this= time=0Awhich gives a high-level proposal for a data model and at least enu= merates=0Awhat some of the elements might be that would be populated in que= ries and=0Aresponses. This is a pretty broad sketch, but it should convey t= he basic=0Aidea. You can check it out here:=0Ahttps://exchcas.va.neustar.co= m/owa/thoughts about the direction or the=0Aspecifics of the data model are= welcome. Thanks!=0A=0AJon Peterson=0ANeuStar, Inc=0A=0ARegards,=0ASohel Kh= an --1705842018-1820889896-1331086080=:49394 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jon,

Thank you for the nice draft.
It will be nice to= have a single query an array of identifiers to resolve the destination and= service array instead of current enum method of only one single identifier= input.  I will explain more in details in Pairs.
 
Regards,
Sohel Khan
=
From: "Peterson, Jon" <jon.pete= rson@neustar.biz>
To: Sohel Khan <sohel_khan777@yahoo.com>; "dispatch@ietf.org" <dispatch@ietf.org>
Sent:= Tuesday, March 6, 2012 5:22 PM
Subject: RE: [dispatch] New Proposal for Telephone-Re= lated Queries

=0A
Hi Sohel,

Thanks for you= r comment.

If you take a look in the TeRQ draft, you'll see that the= data model defines a Subject of queries, but doesn't restrict it to teleph= one numbers. In fact, there is at least one other identifier that we know w= e want to be able to resolve as a telephone-related query today, and that's= a SPID - in any SPEERMINT-like architecture with a LUF/LRF, distinction, y= ou may effectively make two route passes, and on the second, operate on a S= PID instead of a TN. There are probably whole classes of similar identifier= s for networks or federations that might make sense in some deployments.
The basic idea of the draft is to leave these categories pretty open-e= nded, however, so that if we do have other sorts of identifiers we want to = resolve that are related to telephone calls and routing, we can add them in= future specifications through an extensibility mechanism. So definitely we= won't be trying to limit innovation in this space.

Jon Peterson
NeuStar, Inc.
________= ________________________________
From: dispatch-bounces@i= etf.org [dispatch-bounces@ietf.org] On Behalf Of Soh= el Khan [sohel_khan777@yahoo.com]
Sent: Tuesday, March 06= , 2012 2:05 PM
To: dispatch@ietf.org
Subject: [dispatch]  New= Proposal for Telephone-Related Queries

Thanks Jon, it is a very goo= d initiative. I support the creation of a WG.
Nevertheless, in my opinio= n, we will need a fresh start on developing the real-time communication rou= ting vector data model that includes emerging applications routing needs. I= t should not be just a TN issue.  A TN, a user name, or some other public iden= tities can be an input vector to resolve a destination route vector for the= real-time communication that accounts for the emerging technologies. I hum= bly request that we have a fresh start instead of trying to make something = backward compatible that limits the innovation.

Sohel Khan

--= ---Original Message-----
From:    Peterson, Jon [mailto:jon.peterson@neustar.biz<mailto:jon.peterson@ne= ustar.biz>]
Sent:    Monday, March 05, 2012 04:51 PM Ea= stern Standard Time
To:    dispatch@ietf.org<mailto:dispatch@ietf.org>
Subject:&nb= sp;   [dispatch] New Proposal for Telephone-Related Queries

I have a proposal to bounce off the group. Basically, this is a
re-exam= ination of some of the problems we've previously considered in the
telep= hony-specific cluster of work surrounding ENUM, DRINKS and SPEERMINT.
Th= rough discussions in the past couple years, it's become clear that we
wo= uld need to significantly extend ENUM to get it to handle all of the sorts<= br>of sources, subjects, and attributes that people want to factor into que= ries
about telephone number routing and administration. Most of these di= scussions
have gotten wrapped around the axle on questions of the underl= ying syntax
and semantics of the DNS, which were a good match for the or= iginal vision of
a public, user-driven ENUM, but don't seem to be such a= good match for the
uses people actually want to make of these protocols, in federated,
service-provider-driven environments like thos= e envisioned in SPEERMINT and
provisioned in DRINKS. While the discussio= n may have died down a bit, the
requirements that motivated th
e disc= ussion definitely aren't going away.

Rather than continue to debate = the applicability of the DNS and the probity
of various extensions to it= , we might make more progress if we work towards
agreement on the semant= ics of queries for telephone-related data
independently of any underlyin= g protocols. In other words, focus on what
kinds of questions about tele= phone numbers we want to be able to ask, and
what kinds of information n= eeds to go into the answers, and incorporate all
this into an abstract d= ata model. So for example, we know that we want to be
able to express th= e source of a request in a query. What do we mean by
source? I can think= of a bunch of different kinds of source: the logical
originator of the query (the administrative entity asking), the logical
identity o= f any intermediary or aggregator forwarding the query, or even the
point= at the network from which the call originates (the originating trunk
gr= oup, SBC or what have you). All three of those concepts of source seem
i= mportant when it comes to answe
ring questions about telephone numbers, = so a data model would treat those
as separate elements which can vary in= dependently - then we can then try to
figure out what's mandatory or opt= ional, etc. We follow this same method for
all the elements of queries a= nd responses. Figure out what the attributes
are of telephone numbers th= at we care about, sort them into buckets of
routing data and administrat= ive data, and so on.

Once we have an agreement on the data model, th= en people can map the model
to whatever underlying protocol they'd like = - or just build it into a web
API, or what have you. Those proposals could advance as separate documents.
Having that flexibility = would make it a lot easier to figure out what we
really want the questio= ns and answers to be, rather than thinking about what
they realistically= can be within the constraints of some existing underlying
protocol.
=
That's the idea. I'm not going to present a proposed charter for work o= r
anything like that in Paris, but I am interested in hearing if people = think
this is a promising approach, and if so, perhaps we'd put a charte= r on the
agenda for Vancouver. I have however submitted a -00 draft for = this time
which gives a high-level proposal for a data model and at leas= t enumerates
what some of the elements might be that would be populated = in queries and
responses. This is a pretty broad sketch, but it should c= onvey the basic
idea. You can check it out here:
https://exchcas.va.neustar.com/owa/thoughts about th= e direction or the
specifics of the data model are welcome. Thanks!
<= br>Jon Peterson
NeuStar, Inc

Regards,
Sohel Khan


<= /div>
--1705842018-1820889896-1331086080=:49394-- From pkyzivat@alum.mit.edu Tue Mar 6 18:12:14 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC32D21E8037 for ; Tue, 6 Mar 2012 18:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaWwG5wlMi3B for ; Tue, 6 Mar 2012 18:12:14 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id EB4DF21E8019 for ; Tue, 6 Mar 2012 18:12:13 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by QMTA11.westchester.pa.mail.comcast.net with comcast id iGvt1i00527AodY5BSCEHE; Wed, 07 Mar 2012 02:12:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id iSCE1i00k07duvL3fSCESm; Wed, 07 Mar 2012 02:12:14 +0000 Message-ID: <4F56C3FC.6070901@alum.mit.edu> Date: Tue, 06 Mar 2012 21:12:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "dispatch@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 02:12:14 -0000 Glen, I have a few issues with this, as written: - My major one is that I don't find good criteria for deciding if something should be described as immersive or not. Lacking that, its going to be hard to get any kind of useful interoperability out of this. What section 6 says is: Summary of the media feature indicated by this tag: This feature tag indicates that the device provides an immersive audio and/or video communication experience. Values appropriate for use with this feature tag: Boolean. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a Telepresence system. Examples of typical use: Routing a call to a multimedia communication system that can provide an immersive communication experience. Ideally if a UA has identified itself to me as immersive, then there ought to be something special about its behavior that I can count on. The one tangible part of the description is "such as a Telepresence system". But it isn't very tangible because its only "such as", and "Telepresence system" itself isn't very well defined. This would be much more tangible if it was tied to some specification, such as those in progress in the CLUE wg. There is also the specification of immersive in draft-ietf-mmusic-traffic-class-for-sdp-00. I presume there might be some relationship to it as well. - My second (minor) point is that when using this tag in Contact headers you need to write it as '+sip.immersive'. Thanks, Paul On 3/5/12 4:36 PM, Glen Lavers (glavers) wrote: > Folks, > I have submitted a new draft to define an 'immersive' media feature tag. The draft is posted at: http://tools.ietf.org/html/draft-lavers-sipcore-immersive-capability > > The authors would appreciate feedback and or detailed comments. > > Many thanks, > Glen > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dschwartz@xconnect.net Tue Mar 6 19:13:50 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF1E21E8051 for ; Tue, 6 Mar 2012 19:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34n2h6h9tBoa for ; Tue, 6 Mar 2012 19:13:49 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 87C3221E8043 for ; Tue, 6 Mar 2012 19:13:45 -0800 (PST) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Wed, 7 Mar 2012 05:13:44 +0200 From: David Schwartz To: "Peterson, Jon" Date: Wed, 7 Mar 2012 05:13:41 +0200 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: Acz8EE2LBybNLBEQQjyK3EALy21FPQ== Message-ID: References: <55A5A9A87506CB4BA580BF9D531957DA23914ED0@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA23914ED0@STNTEXCH01.cis.neustar.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] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 03:13:50 -0000 Hi Jon Imho, it is critical to come up with a set of use cases prior to defining a= data model. Data models come to answer a need and while we all know there = is a need for this, I think it will be easier to discuss in the context of = a high level use case doc. With that said, here are a few quick comments (m= ore in Paris :)) 1. The text for a Query Intermediary currently states... "This field is pro= vided in the source for those deployments in which the service makes an aut= horization decision based on the identity of the intermediary rather than a= query source". I can think of use cases where the intermediary is authenti= cated but the authorization is based on the source. 2. Query Source has as one of its types a domain name - not sure I understa= nd this use case (I like the TN and URI) 3. You split Attributes into "administrative" and "routing". I think this w= ill require lots of discussion in Paris (and again - use cases would be hel= pful here) as I see different types of attribute classes. The "administrati= ve" ones are more "flag" like (not name-value) and kind of define the "appl= ication" or "service". These guys are the part of the query that tell the s= ervice what kind of resolution is required. For example, CNAM would indicat= e that I am not looking for a RouteGroup in DRINKS terminology - but rather= "ownership" or even "assignment rights" at the level of the TN or identifi= er, while "ROUTE" could indicate a typical routing resolution. While I agre= e that these serve to limit or filter the resolution set - I still think th= at they are in a separate class. These may have to be registered in an IANA= type registry, but again, this is to be discussed. In addition, the Routi= ng attributes are also just a subclass of a more generic type of attributes= that can included other types of non routing based attributes. Again, Use = cases are your friend and as we are rethinking this problem in 2012 and not= when ENUM was created we need to be much more generic. I will save example= s of this for Paris, but I am sure we can all come up with non routing base= d lookups that we may want to associate with the subject. 4. Following up on the last comment in your examples of attributes, I would= differentiate between flag type attributes (e.g. "CarrierOfRecord") and na= me=3Dvalue type attributes (e.g. service=3Dvoip or service=3Dsms) 5. I would consider a "supported" type indication in the response to inform= the querying party which attributes are allowed 6. I would think of adding a mechanism to limit number of responses a query= ing party wishes to get so that if the resolution set is large, the queryin= g party can define how many responses he/she is interested in getting 7. TBD in Paris - but do we want to provide state (e.g. "cookie") for query= so that service can provide different information in a followup query by s= ame party (use-case) Overall, I think this is a fantastic idea and long overdue. We have been "p= atching" existing protocols for so long that the code has become quite cumb= ersome at this point. I will support this effort. Thanks, :D If a Query Intermediary is used=20 On Mar 6, 2012, at 12:04 AM, Peterson, Jon wrote: >=20 > Oops, sorry, my mailer did not like the URL I submitted. The correct URL = for the draft is: >=20 > https://datatracker.ietf.org/doc/draft-peterson-terq/ >=20 > Jon Peterson > Neustar, Inc. >=20 >=20 >=20 > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time > To: dispatch@ietf.org > Subject: [dispatch] New Proposal for Telephone-Related Queries >=20 >=20 > I have a proposal to bounce off the group. Basically, this is a re-examin= ation of some of the problems we've previously considered in the telephony-= specific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through di= scussions in the past couple years, it's become clear that we would need to= significantly extend ENUM to get it to handle all of the sorts of sources,= subjects, and attributes that people want to factor into queries about tel= ephone number routing and administration. Most of these discussions have go= tten wrapped around the axle on questions of the underlying syntax and sema= ntics of the DNS, which were a good match for the original vision of a publ= ic, user-driven ENUM, but don't seem to be such a good match for the uses p= eople actually want to make of these protocols, in federated, service-provi= der-driven environments like those envisioned in SPEERMINT and provisioned = in DRINKS. While the discussion may have died down a bit, the requirements = that motivated th > e discussion definitely aren't going away. >=20 > Rather than continue to debate the applicability of the DNS and the probi= ty of various extensions to it, we might make more progress if we work towa= rds agreement on the semantics of queries for telephone-related data indepe= ndently of any underlying protocols. In other words, focus on what kinds of= questions about telephone numbers we want to be able to ask, and what kind= s of information needs to go into the answers, and incorporate all this int= o an abstract data model. So for example, we know that we want to be able t= o express the source of a request in a query. What do we mean by source? I = can think of a bunch of different kinds of source: the logical originator o= f the query (the administrative entity asking), the logical identity of any= intermediary or aggregator forwarding the query, or even the point at the = network from which the call originates (the originating trunk group, SBC or= what have you). All three of those concepts of source seem important when = it comes to answe > ring questions about telephone numbers, so a data model would treat those= as separate elements which can vary independently - then we can then try t= o figure out what's mandatory or optional, etc. We follow this same method = for all the elements of queries and responses. Figure out what the attribut= es are of telephone numbers that we care about, sort them into buckets of r= outing data and administrative data, and so on. >=20 > Once we have an agreement on the data model, then people can map the mode= l to whatever underlying protocol they'd like - or just build it into a web= API, or what have you. Those proposals could advance as separate documents= . Having that flexibility would make it a lot easier to figure out what we = really want the questions and answers to be, rather than thinking about wha= t they realistically can be within the constraints of some existing underly= ing protocol. >=20 > That's the idea. I'm not going to present a proposed charter for work or = anything like that in Paris, but I am interested in hearing if people think= this is a promising approach, and if so, perhaps we'd put a charter on the= agenda for Vancouver. I have however submitted a -00 draft for this time w= hich gives a high-level proposal for a data model and at least enumerates w= hat some of the elements might be that would be populated in queries and re= sponses. This is a pretty broad sketch, but it should convey the basic idea= . You can check it out here: > https://exchcas.va.neustar.com/owa/thoughts about the direction or the sp= ecifics of the data model are welcome. Thanks! >=20 > Jon Peterson > NeuStar, Inc. > _______________________________________________ > 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 jon.peterson@neustar.biz Tue Mar 6 19:59:26 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F57221E8048 for ; Tue, 6 Mar 2012 19:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.882 X-Spam-Level: X-Spam-Status: No, score=-105.882 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A8jrCCP7ip3 for ; Tue, 6 Mar 2012 19:59:25 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 18AF121E8013 for ; Tue, 6 Mar 2012 19:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1331092794; x=1646452712; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=/fVlCZ+6/uFCS4EitVLfa yKi7ZvQkh6/x9fh2IpoGLM=; b=ss3ssohi6pE4HyE2V4wxgufcspnZgmz3s0ufh iITwFPUcbYOjEJpi0jOv4z2C1b9RiY0g7iwLs9x2P1xNdZjdQ== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.5366973; Tue, 06 Mar 2012 22:59:53 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 6 Mar 2012 22:59:22 -0500 From: "Peterson, Jon" To: David Schwartz Date: Tue, 6 Mar 2012 22:59:21 -0500 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: Acz8EE2LBybNLBEQQjyK3EALy21FPQAAxDQu Message-ID: <55A5A9A87506CB4BA580BF9D531957DA239D6340@STNTEXCH01.cis.neustar.com> References: <55A5A9A87506CB4BA580BF9D531957DA23914ED0@STNTEXCH01.cis.neustar.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: QOOqkChPRNZri94e/Tz61w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 03:59:26 -0000 Hi David, Thanks for giving this a detailed read and noodling it over, and glad you s= upport the effort! At this stage of the dispatch process, really the question for the group wi= ll be whether or not there's sufficient interest in the direction and so on= to justify chartering, and even that discussion isn't going to be resolved= in Paris given this started up pretty late in this cycle. Definitely I am = as eager as you to delve into some of the technical details, but bear in mi= nd that my -00 is really intended more to illustrate the potential space ra= ther than to solve the problem at the outset. Use cases as you say will be = crucial to nailing this down when we get to that stage. Still, a couple qui= ck notes on some of your comments below... 1. I'm sure there are cases where the Server wants to know both who origina= ted the query and who intermediated, and might make authorization decisions= based on both or either, definitely. The idea is to supply as much of that= intelligence as we can. 2. att.com? comcast.net? Things like that. The logical identity of the admi= nistrative domain that is sending the request seems like something that jus= t a domain name can represent, in some cases. Wouldn't want to rule it out. 3. I'm not sure the two categories I proposed here are the end-all-be-all, = sure. Ultimately, given how generic the framework is, I can imagine even de= fining different profiles with packages of relevant attributes for differen= t use cases. That's a ways down the pike though. Ultimately I do envision t= hat attributes and virtually all other parts of the data model will be exte= nsible in IANA registries. 4. This is a pretty low-level question about syntax, really, but I suppose = I wouldn't rule out attributes that have no values in responses, sure. I do= n't think (to your previous point) that necessarily all "administrative" at= tributes lack values. 5. There will definitely need to be some kind of capability negotiation mec= hanism - again, I suspect it might be something closer to profiles at the e= nd of the day, but we'll see. 6. The chunking characteristics of certain underlying protocol have been a = problem here in the past, yes. In the general framework as I've laid it out= anyway, this question would be deferred to the underlying protocols to sol= ve. A lightweight binary mechanisms would do this differently than a web se= rvice. 7. That too might end up being something deferred to the encoding protocol.= Some protocols will have persistent sockets and others just datagrams. The= re will in the data model need to be enough transaction identification to c= orrelate requests and responses at the application layer, however, and it m= ight be the case that we need something closer to a session than just a tra= nsaction to capture the semantics here. That is indeed exactly the sort of = discussion we'd be having if we chartered this work. Thanks again, Jon Peterson NeuStar, Inc. ________________________________________ From: David Schwartz [dschwartz@xconnect.net] Sent: Tuesday, March 06, 2012 7:13 PM To: Peterson, Jon Cc: dispatch@ietf.org Subject: Re: [dispatch] New Proposal for Telephone-Related Queries Hi Jon Imho, it is critical to come up with a set of use cases prior to defining a= data model. Data models come to answer a need and while we all know there = is a need for this, I think it will be easier to discuss in the context of = a high level use case doc. With that said, here are a few quick comments (m= ore in Paris :)) 1. The text for a Query Intermediary currently states... "This field is pro= vided in the source for those deployments in which the service makes an aut= horization decision based on the identity of the intermediary rather than a= query source". I can think of use cases where the intermediary is authenti= cated but the authorization is based on the source. 2. Query Source has as one of its types a domain name - not sure I understa= nd this use case (I like the TN and URI) 3. You split Attributes into "administrative" and "routing". I think this w= ill require lots of discussion in Paris (and again - use cases would be hel= pful here) as I see different types of attribute classes. The "administrati= ve" ones are more "flag" like (not name-value) and kind of define the "appl= ication" or "service". These guys are the part of the query that tell the s= ervice what kind of resolution is required. For example, CNAM would indicat= e that I am not looking for a RouteGroup in DRINKS terminology - but rather= "ownership" or even "assignment rights" at the level of the TN or identifi= er, while "ROUTE" could indicate a typical routing resolution. While I agre= e that these serve to limit or filter the resolution set - I still think th= at they are in a separate class. These may have to be registered in an IANA= type registry, but again, this is to be discussed. In addition, the Routi= ng attributes are also just a subclass of a more generic type of attributes= that can included other types of non routing based attributes. Again, Use = cases are your friend and as we are rethinking this problem in 2012 and not= when ENUM was created we need to be much more generic. I will save example= s of this for Paris, but I am sure we can all come up with non routing base= d lookups that we may want to associate with the subject. 4. Following up on the last comment in your examples of attributes, I would= differentiate between flag type attributes (e.g. "CarrierOfRecord") and na= me=3Dvalue type attributes (e.g. service=3Dvoip or service=3Dsms) 5. I would consider a "supported" type indication in the response to inform= the querying party which attributes are allowed 6. I would think of adding a mechanism to limit number of responses a query= ing party wishes to get so that if the resolution set is large, the queryin= g party can define how many responses he/she is interested in getting 7. TBD in Paris - but do we want to provide state (e.g. "cookie") for query= so that service can provide different information in a followup query by s= ame party (use-case) Overall, I think this is a fantastic idea and long overdue. We have been "p= atching" existing protocols for so long that the code has become quite cumb= ersome at this point. I will support this effort. Thanks, :D If a Query Intermediary is used On Mar 6, 2012, at 12:04 AM, Peterson, Jon wrote: > > Oops, sorry, my mailer did not like the URL I submitted. The correct URL = for the draft is: > > https://datatracker.ietf.org/doc/draft-peterson-terq/ > > Jon Peterson > Neustar, Inc. > > > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time > To: dispatch@ietf.org > Subject: [dispatch] New Proposal for Telephone-Related Queries > > > I have a proposal to bounce off the group. Basically, this is a re-examin= ation of some of the problems we've previously considered in the telephony-= specific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through di= scussions in the past couple years, it's become clear that we would need to= significantly extend ENUM to get it to handle all of the sorts of sources,= subjects, and attributes that people want to factor into queries about tel= ephone number routing and administration. Most of these discussions have go= tten wrapped around the axle on questions of the underlying syntax and sema= ntics of the DNS, which were a good match for the original vision of a publ= ic, user-driven ENUM, but don't seem to be such a good match for the uses p= eople actually want to make of these protocols, in federated, service-provi= der-driven environments like those envisioned in SPEERMINT and provisioned = in DRINKS. While the discussion may have died down a bit, the requirements = that motivated th > e discussion definitely aren't going away. > > Rather than continue to debate the applicability of the DNS and the probi= ty of various extensions to it, we might make more progress if we work towa= rds agreement on the semantics of queries for telephone-related data indepe= ndently of any underlying protocols. In other words, focus on what kinds of= questions about telephone numbers we want to be able to ask, and what kind= s of information needs to go into the answers, and incorporate all this int= o an abstract data model. So for example, we know that we want to be able t= o express the source of a request in a query. What do we mean by source? I = can think of a bunch of different kinds of source: the logical originator o= f the query (the administrative entity asking), the logical identity of any= intermediary or aggregator forwarding the query, or even the point at the = network from which the call originates (the originating trunk group, SBC or= what have you). All three of those concepts of source seem important when = it comes to answe > ring questions about telephone numbers, so a data model would treat those= as separate elements which can vary independently - then we can then try t= o figure out what's mandatory or optional, etc. We follow this same method = for all the elements of queries and responses. Figure out what the attribut= es are of telephone numbers that we care about, sort them into buckets of r= outing data and administrative data, and so on. > > Once we have an agreement on the data model, then people can map the mode= l to whatever underlying protocol they'd like - or just build it into a web= API, or what have you. Those proposals could advance as separate documents= . Having that flexibility would make it a lot easier to figure out what we = really want the questions and answers to be, rather than thinking about wha= t they realistically can be within the constraints of some existing underly= ing protocol. > > That's the idea. I'm not going to present a proposed charter for work or = anything like that in Paris, but I am interested in hearing if people think= this is a promising approach, and if so, perhaps we'd put a charter on the= agenda for Vancouver. I have however submitted a -00 draft for this time w= hich gives a high-level proposal for a data model and at least enumerates w= hat some of the elements might be that would be populated in queries and re= sponses. This is a pretty broad sketch, but it should convey the basic idea= . You can check it out here: > https://exchcas.va.neustar.com/owa/thoughts about the direction or the sp= ecifics of the data model are welcome. Thanks! > > Jon Peterson > NeuStar, Inc. > _______________________________________________ > 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 paulej@packetizer.com Tue Mar 6 20:22:04 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8149C21E8052 for ; Tue, 6 Mar 2012 20:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib5qcxCr6+sm for ; Tue, 6 Mar 2012 20:22:03 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 78BDE21E8047 for ; Tue, 6 Mar 2012 20:22:03 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q274M08D029355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Mar 2012 23:22:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331094121; bh=eQuTTEP2a5i6tt9AbmJItPiN79DWAyStVaAxgzLvudA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=m9MP1nZ6LDALSGY768jMTrxDZ1+XqxUggMRPVzp1bMbMj+s5WbpzEXS87gjuJY7RT V7VwMjCj688q18RQ05BkJmo3AxHCrv9I0d6o0QgdJ1asPp5CKJ0PZvd2pSK0I93IUL N5RK7SO1yqWBpEm4GXmzoMNij+Sn1v1tBJz9v1io= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <4F4F5C19.9070607@ericsson.com> <030e01ccfbcf$c07b7460$41725d20$@packetizer.com> <4F567918.5080009@alum.mit.edu> In-Reply-To: <4F567918.5080009@alum.mit.edu> Date: Tue, 6 Mar 2012 23:22:06 -0500 Message-ID: <03b801ccfc19$dbb9f180$932dd480$@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: AQF17Kt9fhTk7OLSTyTCet4r/WjUfALHn26LAc8weq6W56LGQA== Content-Language: en-us Subject: Re: [dispatch] Charter process for the INSIPID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 04:22:04 -0000 Paul, > > I would suggest adding the following text to the end of the second > > paragraph of the charter: > > "Consideration must be given to the fact that the entities involved in > > a communication session might change as a result of service > > interaction in the network, such as call transfers, joins, etc." > > > > This is text we introduced in a later version of the charter. > > These words don't mention any constraints that should be imposed wile > considering this. So the outcome might or might not specify that such > changes do or don't preserve the session id. > > Is that what you are looking for? This is text just to serve as a reminder that we cannot ignore service interactions. Now, what we decide to do as a result of service interactions is still to be determined. However, every single time I've seen a "call ID" proposed before, it seemed the proposal did not fully take such mid-call service interactions into account or failed to do so properly. So, I just don't want that to be ignored. Paul From stephen.botzko@gmail.com Wed Mar 7 04:44:20 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FA921F87BC for ; Wed, 7 Mar 2012 04:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtnBQFoW5XnF for ; Wed, 7 Mar 2012 04:44:19 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEC621F87B7 for ; Wed, 7 Mar 2012 04:44:19 -0800 (PST) Received: by obbta4 with SMTP id ta4so5741578obb.31 for ; Wed, 07 Mar 2012 04:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SQpz85RW8TdJ2ZyZFi9AAskyZ8TnHsfoZJgcmfgaBas=; b=nBvXOnWTSqRxUdO2o1OhsBOqzfCFy+IzKR9cOhcGE1WcDW6eoEk6PNg5isX+vhfH69 s4Jo0hqk7Wz8Hxrs06Vw7sabAG5bcBhL38YdzjS+0GjtA82JKmFHNb2OH98mPylzX6Oj QDJH4+X0bwZCp0syUJs4msH1T0MowpIk5PU2ALrUxzEOr+KQSpCTDXLYhSa31n70jRO/ nHpAhN9OL4F7AI/3Pi/gbrT3CJO2ipPCV3BjAAk1t0Bs8+h6S5UTXPJvEiNruyfozBDp BDAKY3BMywxJlqReeZgTW1XGIqlZIXki4zq2ZrUYxMd/T4k+SHpyBFRcBZR0amQHEukU G9Zg== MIME-Version: 1.0 Received: by 10.182.216.101 with SMTP id op5mr709363obc.54.1331124259224; Wed, 07 Mar 2012 04:44:19 -0800 (PST) Received: by 10.182.74.164 with HTTP; Wed, 7 Mar 2012 04:44:19 -0800 (PST) In-Reply-To: <4F56C3FC.6070901@alum.mit.edu> References: <4F56C3FC.6070901@alum.mit.edu> Date: Wed, 7 Mar 2012 07:44:19 -0500 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d0447864b9f7a8304baa6843e Cc: "dispatch@ietf.org" Subject: Re: [dispatch] [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 12:44:20 -0000 --f46d0447864b9f7a8304baa6843e Content-Type: text/plain; charset=ISO-8859-1 >>> My major one is that I don't find good criteria for deciding if something should be described as immersive or not. Lacking that, its going to be hard to get any kind of useful interoperability out of this. ... Ideally if a UA has identified itself to me as immersive, then there ought to be something special about its behavior that I can count on. >>> I agree. Two systems that describe themselves as immersive might not be interoperable at all, so today this preferential call routing might not be such a good idea. It would be better to re-evaluate this idea later on, and see if the CLUE work eliminates the need for it. (Or maybe Glen should take this to CLUE for consideration???) Regards, Stephen Botzko On Tue, Mar 6, 2012 at 9:12 PM, Paul Kyzivat wrote: > Glen, > > I have a few issues with this, as written: > > - My major one is that I don't find good criteria for deciding if > something should be described as immersive or not. Lacking that, its going > to be hard to get any kind of useful interoperability out of this. > What section 6 says is: > > Summary of the media feature indicated by this tag: This feature tag > indicates that the device provides an immersive audio and/or video > communication experience. > > Values appropriate for use with this feature tag: Boolean. > > The feature tag is intended primarily for use in the following > applications, protocols, services, or negotiation mechanisms: This > feature tag is most useful in a communications application for > describing the capabilities of a device, such as a Telepresence > system. > > Examples of typical use: Routing a call to a multimedia > communication system that can provide an immersive communication > experience. > > Ideally if a UA has identified itself to me as immersive, then there ought > to be something special about its behavior that I can count on. > > The one tangible part of the description is "such as a Telepresence > system". But it isn't very tangible because its only "such as", and > "Telepresence system" itself isn't very well defined. > > This would be much more tangible if it was tied to some specification, > such as those in progress in the CLUE wg. There is also the specification > of immersive in draft-ietf-mmusic-traffic-**class-for-sdp-00. I presume > there might be some relationship to it as well. > > - My second (minor) point is that when using this tag in Contact headers > you need to write it as '+sip.immersive'. > > Thanks, > Paul > > > > > > On 3/5/12 4:36 PM, Glen Lavers (glavers) wrote: > >> Folks, >> I have submitted a new draft to define an 'immersive' media feature tag. >> The draft is posted at: http://tools.ietf.org/html/** >> draft-lavers-sipcore-**immersive-capability >> >> >> The authors would appreciate feedback and or detailed comments. >> >> Many thanks, >> Glen >> ______________________________**_________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/**listinfo/sipcore >> >> > ______________________________**_________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/**listinfo/dispatch > --f46d0447864b9f7a8304baa6843e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
My major one is that I don't find good criteria for dec= iding if=20 something should be described as immersive or not. Lacking that, its=20 going to be hard to get any kind of useful interoperability out of this....
Ideally if a UA has identified itself to me as immersive, then ther= e=20 ought to be something special about its behavior that I can count on.
&g= t;>>
I agree. Two systems that describe themselves as immersive mi= ght not be interoperable at all, so today this preferential call routing mi= ght not be such a good idea.

It would be better to re-evaluate this idea later on, and see if the CL= UE work eliminates the need for it.=A0 (Or maybe Glen should take this to C= LUE for consideration???)

Regards,
Stephen Botzko

On Tue, Mar 6, 2012 at 9:12 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrot= e:
Glen,

I have a few issues with this, as written:

- My major one is that I don't find good criteria for deciding if somet= hing should be described as immersive or not. Lacking that, its going to be= hard to get any kind of useful interoperability out of this.
What section 6 says is:

=A0 Summary of the media feature indicated by this tag: =A0This feature ta= g
=A0 =A0 =A0indicates that the device provides an immersive audio and/or vi= deo
=A0 =A0 =A0communication experience.

=A0 Values appropriate for use with this feature tag: =A0Boolean.

=A0 The feature tag is intended primarily for use in the following
=A0 applications, protocols, services, or negotiation mechanisms: =A0 This=
=A0 =A0 =A0feature tag is most useful in a communications application for<= br> =A0 =A0 =A0describing the capabilities of a device, such as a Telepresence=
=A0 =A0 =A0system.

=A0 Examples of typical use: =A0Routing a call to a multimedia
=A0 =A0 =A0communication system that can provide an immersive communicatio= n
=A0 =A0 =A0experience.

Ideally if a UA has identified itself to me as immersive, then there ought = to be something special about its behavior that I can count on.

The one tangible part of the description is "such as a Telepresence sy= stem". But it isn't very tangible because its only "such as&q= uot;, and "Telepresence system" itself isn't very well define= d.

This would be much more tangible if it was tied to some specification, such= as those in progress in the CLUE wg. There is also the specification of im= mersive in draft-ietf-mmusic-traffic-class-for-sdp-00. I presume the= re might be some relationship to it as well.

- My second (minor) point is that when using this tag in Contact headers yo= u need to write it as '+sip.immersive'.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul





On 3/5/12 4:36 PM, Glen Lavers (glavers) wrote:
Folks,
I have submitted a new draft to define an 'immersive' media feature= tag. The draft is posted at: http://tools.ietf.org= /html/draft-lavers-sipcore-immersive-capability


The authors would appreciate feedback =A0and or detailed comments.

Many thanks,
Glen
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


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

--f46d0447864b9f7a8304baa6843e-- From paulej@packetizer.com Wed Mar 7 05:09:51 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4792521F84DE for ; Wed, 7 Mar 2012 05:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGWwBjxDpBDy for ; Wed, 7 Mar 2012 05:09:47 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B685B21F87BD for ; Wed, 7 Mar 2012 05:09:42 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q27D9ds6009134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Mar 2012 08:09:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331125780; bh=+FImUqsDc5kWXUyApqAkuR2s+kQa4doYS135w9HmSBc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=JiyCDZYdeWrbMDsC2vwWC+ine7EYjZxPd3CgVSfS/L22Jawz8hN4IWHNsJFW+eoWm e6ZszKke5X6BvOLuCkxTm5jXulp8hEAxZ4ESG2QfEEGuMbgvcTxF5vm9cuDM9qtQz6 D4slIvhMwDHahZ5DRDSytKlbBlUg5JmMPNCg4ulM= From: "Paul E. Jones" To: "'Stephen Botzko'" , "'Paul Kyzivat'" References: <4F56C3FC.6070901@alum.mit.edu> In-Reply-To: Date: Wed, 7 Mar 2012 08:09:46 -0500 Message-ID: <002d01ccfc63$92613df0$b723b9d0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CCFC39.A98DA6F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHenJm8OFlCRln1wB9t6DGLFBXyWgIbkfZIAaOgBcuWHZMVsA== Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 13:09:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002E_01CCFC39.A98DA6F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stephen, The 'immersive' tag is not intended to carry interoperability considerations with it. It is just an indicator that the system provides, what it believes is, an immersive experience. If two systems cannot communicate properly, this tag is not going to make any difference one way or the other. This proposed tag is like the existing 'video' or 'audio' tags. Those alone do not suggest one will achieve any kind of interoperability. Now, what this tag does provide is the ability for the calling device to indicate a preference. This tag can be used following the caller preferences RFC to help entities in the network route calls to devices that advertise as having this feature. It might help to avoid directing a video call to a desktop phone or it might help the intermediaries in routing calls over physical links that can provide a better level of service than the routine audio or video call. Paul From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, March 07, 2012 7:44 AM To: Paul Kyzivat Cc: dispatch@ietf.org Subject: Re: [dispatch] [sipcore] draft-lavers-sipcore-immersive-capability-00.txt >>> My major one is that I don't find good criteria for deciding if something should be described as immersive or not. Lacking that, its going to be hard to get any kind of useful interoperability out of this. ... Ideally if a UA has identified itself to me as immersive, then there ought to be something special about its behavior that I can count on. >>> I agree. Two systems that describe themselves as immersive might not be interoperable at all, so today this preferential call routing might not be such a good idea. It would be better to re-evaluate this idea later on, and see if the CLUE work eliminates the need for it. (Or maybe Glen should take this to CLUE for consideration???) Regards, Stephen Botzko On Tue, Mar 6, 2012 at 9:12 PM, Paul Kyzivat wrote: Glen, I have a few issues with this, as written: - My major one is that I don't find good criteria for deciding if something should be described as immersive or not. Lacking that, its going to be hard to get any kind of useful interoperability out of this. What section 6 says is: Summary of the media feature indicated by this tag: This feature tag indicates that the device provides an immersive audio and/or video communication experience. Values appropriate for use with this feature tag: Boolean. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a Telepresence system. Examples of typical use: Routing a call to a multimedia communication system that can provide an immersive communication experience. Ideally if a UA has identified itself to me as immersive, then there ought to be something special about its behavior that I can count on. The one tangible part of the description is "such as a Telepresence system". But it isn't very tangible because its only "such as", and "Telepresence system" itself isn't very well defined. This would be much more tangible if it was tied to some specification, such as those in progress in the CLUE wg. There is also the specification of immersive in draft-ietf-mmusic-traffic-class-for-sdp-00. I presume there might be some relationship to it as well. - My second (minor) point is that when using this tag in Contact headers you need to write it as '+sip.immersive'. Thanks, Paul On 3/5/12 4:36 PM, Glen Lavers (glavers) wrote: Folks, I have submitted a new draft to define an 'immersive' media feature tag. The draft is posted at: http://tools.ietf.org/html/draft-lavers-sipcore-immersive-capability The authors would appreciate feedback and or detailed comments. Many thanks, Glen _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_002E_01CCFC39.A98DA6F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephen,

 

The ‘immersive’ tag is not intended to carry = interoperability considerations with it.  It is just an indicator = that the system provides, what it believes is, an immersive = experience.  If two systems cannot communicate properly, this tag = is not going to make any difference one way or the other.  This = proposed tag is like the existing ‘video’ or = ‘audio’ tags.  Those alone do not suggest one will = achieve any kind of interoperability.

 

Now, what this tag does provide is the ability for the calling device = to indicate a preference.  This tag can be used following the = caller preferences RFC to help entities in the network route calls to = devices that advertise as having this feature.  It might help to = avoid directing a video call to a desktop phone or it might help the = intermediaries in routing calls over physical links that can provide a = better level of service than the routine audio or video = call.

 

Paul

 

From:= = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Stephen Botzko
Sent: Wednesday, March 07, 2012 = 7:44 AM
To: Paul Kyzivat
Cc: = dispatch@ietf.org
Subject: Re: [dispatch] [sipcore] = draft-lavers-sipcore-immersive-capability-00.txt

 

>>>
My major one is that I = don't find good criteria for deciding if something should be described = as immersive or not. Lacking that, its going to be hard to get any kind = of useful interoperability out of this.
...
Ideally if a UA has = identified itself to me as immersive, then there ought to be something = special about its behavior that I can count on.
>>>
I = agree. Two systems that describe themselves as immersive might not be = interoperable at all, so today this preferential call routing might not = be such a good idea.

It would be better to re-evaluate this idea = later on, and see if the CLUE work eliminates the need for it.  (Or = maybe Glen should take this to CLUE for = consideration???)

Regards,
Stephen = Botzko

On Tue, Mar 6, 2012 at = 9:12 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

Glen,

I have a few = issues with this, as written:

- My major one is that I don't find = good criteria for deciding if something should be described as immersive = or not. Lacking that, its going to be hard to get any kind of useful = interoperability out of this.
What section 6 says is:

  = Summary of the media feature indicated by this tag:  This feature = tag
     indicates that the device provides an = immersive audio and/or video
     communication = experience.

  Values appropriate for use with this feature = tag:  Boolean.

  The feature tag is intended primarily = for use in the following
  applications, protocols, services, or = negotiation mechanisms:   This
     feature tag = is most useful in a communications application for
    =  describing the capabilities of a device, such as a = Telepresence
     system.

  Examples of = typical use:  Routing a call to a multimedia
    =  communication system that can provide an immersive = communication
     experience.

Ideally if a UA = has identified itself to me as immersive, then there ought to be = something special about its behavior that I can count on.

The one = tangible part of the description is "such as a Telepresence = system". But it isn't very tangible because its only "such = as", and "Telepresence system" itself isn't very well = defined.

This would be much more tangible if it was tied to some = specification, such as those in progress in the CLUE wg. There is also = the specification of immersive in = draft-ietf-mmusic-traffic-class-for-sdp-00. I presume there might be = some relationship to it as well.

- My second (minor) point is = that when using this tag in Contact headers you need to write it as = '+sip.immersive'.

       Thanks,
  =      Paul






On 3/5/12 4:36 PM, Glen Lavers = (glavers) wrote:

Folks,
I have submitted a new draft to define an = 'immersive' media feature tag. The draft is posted at: http://tools.ietf.org/html/draft-lavers-sipcore-immersi= ve-capability



The = authors would appreciate feedback  and or detailed = comments.

Many = thanks,
Glen
_______________________________________________

sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= /o:p>


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

 

------=_NextPart_000_002E_01CCFC39.A98DA6F0-- From pkyzivat@alum.mit.edu Wed Mar 7 07:53:11 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B33F21F86D0 for ; Wed, 7 Mar 2012 07:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y5GKlqO5bz5 for ; Wed, 7 Mar 2012 07:53:10 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id A2A9221F86DA for ; Wed, 7 Mar 2012 07:53:10 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta07.westchester.pa.mail.comcast.net with comcast id iftA1i0090vyq2s57ftBoQ; Wed, 07 Mar 2012 15:53:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta05.westchester.pa.mail.comcast.net with comcast id iftA1i01A07duvL3RftAsM; Wed, 07 Mar 2012 15:53:10 +0000 Message-ID: <4F578464.6030602@alum.mit.edu> Date: Wed, 07 Mar 2012 10:53:08 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <4F56C3FC.6070901@alum.mit.edu> <002d01ccfc63$92613df0$b723b9d0$@packetizer.com> In-Reply-To: <002d01ccfc63$92613df0$b723b9d0$@packetizer.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:53:11 -0000 On 3/7/12 8:09 AM, Paul E. Jones wrote: > Stephen, > > The ‘immersive’ tag is not intended to carry interoperability > considerations with it. It is just an indicator that the system > provides, what it believes is, an immersive experience. If two systems > cannot communicate properly, this tag is not going to make any > difference one way or the other. This proposed tag is like the existing > ‘video’ or ‘audio’ tags. Those alone do not suggest one will achieve any > kind of interoperability. AFAIK the existing video/audio tags mean, respectively, that m=video/m=audio lines will be supported in offers and answers. Of course there still might not be interop because there are no codecs in common, but at least there is the basis for proposing something. > Now, what this tag does provide is the ability for the calling device to > indicate a preference. This tag can be used following the caller > preferences RFC to help entities in the network route calls to devices > that advertise as having this feature. It might help to avoid directing > a video call to a desktop phone or it might help the intermediaries in > routing calls over physical links that can provide a better level of > service than the routine audio or video call. Replace the tag "immersive" with one called "xyzzy". That also provides an ability to indicate a preference. But how do I decide if I am qualified to offer it? At the moment the word "immersive" is just an advertising buzz word. We need for it to have some tangible semantics. Is there a difference between "immersive" and "telepresence"? Thanks, Paul > Paul > > *From:*dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] *On > Behalf Of *Stephen Botzko > *Sent:* Wednesday, March 07, 2012 7:44 AM > *To:* Paul Kyzivat > *Cc:* dispatch@ietf.org > *Subject:* Re: [dispatch] [sipcore] > draft-lavers-sipcore-immersive-capability-00.txt > > >>> > My major one is that I don't find good criteria for deciding if > something should be described as immersive or not. Lacking that, its > going to be hard to get any kind of useful interoperability out of this. > ... > Ideally if a UA has identified itself to me as immersive, then there > ought to be something special about its behavior that I can count on. > >>> > I agree. Two systems that describe themselves as immersive might not be > interoperable at all, so today this preferential call routing might not > be such a good idea. > > It would be better to re-evaluate this idea later on, and see if the > CLUE work eliminates the need for it. (Or maybe Glen should take this to > CLUE for consideration???) > > Regards, > Stephen Botzko > > On Tue, Mar 6, 2012 at 9:12 PM, Paul Kyzivat > wrote: > > Glen, > > I have a few issues with this, as written: > > - My major one is that I don't find good criteria for deciding if > something should be described as immersive or not. Lacking that, its > going to be hard to get any kind of useful interoperability out of this. > What section 6 says is: > > Summary of the media feature indicated by this tag: This feature tag > indicates that the device provides an immersive audio and/or video > communication experience. > > Values appropriate for use with this feature tag: Boolean. > > The feature tag is intended primarily for use in the following > applications, protocols, services, or negotiation mechanisms: This > feature tag is most useful in a communications application for > describing the capabilities of a device, such as a Telepresence > system. > > Examples of typical use: Routing a call to a multimedia > communication system that can provide an immersive communication > experience. > > Ideally if a UA has identified itself to me as immersive, then there > ought to be something special about its behavior that I can count on. > > The one tangible part of the description is "such as a Telepresence > system". But it isn't very tangible because its only "such as", and > "Telepresence system" itself isn't very well defined. > > This would be much more tangible if it was tied to some specification, > such as those in progress in the CLUE wg. There is also the > specification of immersive in > draft-ietf-mmusic-traffic-class-for-sdp-00. I presume there might be > some relationship to it as well. > > - My second (minor) point is that when using this tag in Contact headers > you need to write it as '+sip.immersive'. > > Thanks, > Paul > > > > > > > On 3/5/12 4:36 PM, Glen Lavers (glavers) wrote: > > Folks, > I have submitted a new draft to define an 'immersive' media feature > tag. The draft is posted at: > http://tools.ietf.org/html/draft-lavers-sipcore-immersive-capability > > > > The authors would appreciate feedback and or detailed comments. > > Many thanks, > Glen > _______________________________________________ > > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From adam@nostrum.com Wed Mar 7 07:55:57 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037D421F85AA for ; Wed, 7 Mar 2012 07:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJHOPGkQidHE for ; Wed, 7 Mar 2012 07:55:54 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA5821F869A for ; Wed, 7 Mar 2012 07:55:48 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q27Ftj6o051732 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Mar 2012 09:55:45 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F578501.2060109@nostrum.com> Date: Wed, 07 Mar 2012 09:55:45 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Paul E. Jones" References: <4F56C3FC.6070901@alum.mit.edu> <002d01ccfc63$92613df0$b723b9d0$@packetizer.com> In-Reply-To: <002d01ccfc63$92613df0$b723b9d0$@packetizer.com> Content-Type: multipart/alternative; boundary="------------060808020703010603080508" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org Subject: Re: [dispatch] [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:55:57 -0000 This is a multi-part message in MIME format. --------------060808020703010603080508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think the issue that people are having is that call capabilities have all been objective in nature to date. A device, by casual examination, either does or does not have an audio source and sink. It does or does not have a camera and a display. There's no opinion that enters into it. What you're proposing steps outside this model by adding an inherently subjective capability. The way "immersive" is defined in the current draft ("visual conferencing environments that duplicate, as closely as possible, an in-person experience") cannot be objectively measured. Reasonable people could disagree about whether a 32-inch display is sufficient to convey something approaching an "in-person" experience; whether 60 pixels per inch is a sufficiently high-definition display; whether G.722 is wideband enough to qualify as high-def audio; etc. Even worse: as technology advances, these definitions will drift upwards (while the older implementations will continue to tag themselves as "immersive"). Functionally, the proposed "immersive" tag is on par with the prospect of "expensive," "well-implemented," or "feature-rich" as capabilities. From a practical perspective, I agree with Stephen's comments. Wait for CLUE to get closer to finishing, and then see whether they've already solved this problem for you. If not, come back at that time with a feature tag that means something objective like "implements the protocol defined by CLUE." /a On 3/7/12 7:09 AM, Paul E. Jones wrote: > > Stephen, > > The 'immersive' tag is not intended to carry interoperability > considerations with it. It is just an indicator that the system > provides, what it believes is, an immersive experience. If two > systems cannot communicate properly, this tag is not going to make any > difference one way or the other. This proposed tag is like the > existing 'video' or 'audio' tags. Those alone do not suggest one will > achieve any kind of interoperability. > > Now, what this tag does provide is the ability for the calling device > to indicate a preference. This tag can be used following the caller > preferences RFC to help entities in the network route calls to devices > that advertise as having this feature. It might help to avoid > directing a video call to a desktop phone or it might help the > intermediaries in routing calls over physical links that can provide a > better level of service than the routine audio or video call. > > Paul > > *From:*dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > *On Behalf Of *Stephen Botzko > *Sent:* Wednesday, March 07, 2012 7:44 AM > *To:* Paul Kyzivat > *Cc:* dispatch@ietf.org > *Subject:* Re: [dispatch] [sipcore] > draft-lavers-sipcore-immersive-capability-00.txt > > >>> > My major one is that I don't find good criteria for deciding if > something should be described as immersive or not. Lacking that, its > going to be hard to get any kind of useful interoperability out of this. > ... > Ideally if a UA has identified itself to me as immersive, then there > ought to be something special about its behavior that I can count on. > >>> > I agree. Two systems that describe themselves as immersive might not > be interoperable at all, so today this preferential call routing might > not be such a good idea. > > It would be better to re-evaluate this idea later on, and see if the > CLUE work eliminates the need for it. (Or maybe Glen should take this > to CLUE for consideration???) > > Regards, > Stephen Botzko > > On Tue, Mar 6, 2012 at 9:12 PM, Paul Kyzivat > wrote: > > Glen, > > I have a few issues with this, as written: > > - My major one is that I don't find good criteria for deciding if > something should be described as immersive or not. Lacking that, its > going to be hard to get any kind of useful interoperability out of this. > What section 6 says is: > > Summary of the media feature indicated by this tag: This feature tag > indicates that the device provides an immersive audio and/or video > communication experience. > > Values appropriate for use with this feature tag: Boolean. > > The feature tag is intended primarily for use in the following > applications, protocols, services, or negotiation mechanisms: This > feature tag is most useful in a communications application for > describing the capabilities of a device, such as a Telepresence > system. > > Examples of typical use: Routing a call to a multimedia > communication system that can provide an immersive communication > experience. > > Ideally if a UA has identified itself to me as immersive, then there > ought to be something special about its behavior that I can count on. > > The one tangible part of the description is "such as a Telepresence > system". But it isn't very tangible because its only "such as", and > "Telepresence system" itself isn't very well defined. > > This would be much more tangible if it was tied to some specification, > such as those in progress in the CLUE wg. There is also the > specification of immersive in > draft-ietf-mmusic-traffic-class-for-sdp-00. I presume there might be > some relationship to it as well. > > - My second (minor) point is that when using this tag in Contact > headers you need to write it as '+sip.immersive'. > > Thanks, > Paul > > > > > > > On 3/5/12 4:36 PM, Glen Lavers (glavers) wrote: > > Folks, > I have submitted a new draft to define an 'immersive' media > feature tag. The draft is posted at: > http://tools.ietf.org/html/draft-lavers-sipcore-immersive-capability > > > > The authors would appreciate feedback and or detailed comments. > > Many thanks, > Glen > _______________________________________________ > > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > 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 --------------060808020703010603080508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think the issue that people are having is that call capabilities have all been objective in nature to date. A device, by casual examination, either does or does not have an audio source and sink. It does or does not have a camera and a display. There's no opinion that enters into it.

What you're proposing steps outside this model by adding an inherently subjective capability.

The way "immersive" is defined in the current draft ("visual conferencing environments that duplicate, as closely as possible, an in-person experience") cannot be objectively measured. Reasonable people could disagree about whether a 32-inch display is sufficient to convey something approaching an "in-person" experience; whether 60 pixels per inch is a sufficiently high-definition display; whether G.722 is wideband enough to qualify as high-def audio; etc. Even worse: as technology advances, these definitions will drift upwards (while the older implementations will continue to tag themselves as "immersive").

Functionally, the proposed "immersive" tag is on par with the prospect of "expensive," "well-implemented," or "feature-rich" as capabilities.

From a practical perspective, I agree with Stephen's comments. Wait for CLUE to get closer to finishing, and then see whether they've already solved this problem for you. If not, come back at that time with a feature tag that means something objective like "implements the protocol defined by CLUE."

/a



On 3/7/12 7:09 AM, Paul E. Jones wrote:

Stephen,

 

The ‘immersive’ tag is not intended to carry interoperability considerations with it.  It is just an indicator that the system provides, what it believes is, an immersive experience.  If two systems cannot communicate properly, this tag is not going to make any difference one way or the other.  This proposed tag is like the existing ‘video’ or ‘audio’ tags.  Those alone do not suggest one will achieve any kind of interoperability.

 

Now, what this tag does provide is the ability for the calling device to indicate a preference.  This tag can be used following the caller preferences RFC to help entities in the network route calls to devices that advertise as having this feature.  It might help to avoid directing a video call to a desktop phone or it might help the intermediaries in routing calls over physical links that can provide a better level of service than the routine audio or video call.

 

Paul

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Stephen Botzko
Sent: Wednesday, March 07, 2012 7:44 AM
To: Paul Kyzivat
Cc: dispatch@ietf.org
Subject: Re: [dispatch] [sipcore] draft-lavers-sipcore-immersive-capability-00.txt

 

>>>
My major one is that I don't find good criteria for deciding if something should be described as immersive or not. Lacking that, its going to be hard to get any kind of useful interoperability out of this.
...
Ideally if a UA has identified itself to me as immersive, then there ought to be something special about its behavior that I can count on.
>>>
I agree. Two systems that describe themselves as immersive might not be interoperable at all, so today this preferential call routing might not be such a good idea.

It would be better to re-evaluate this idea later on, and see if the CLUE work eliminates the need for it.  (Or maybe Glen should take this to CLUE for consideration???)

Regards,
Stephen Botzko

On Tue, Mar 6, 2012 at 9:12 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Glen,

I have a few issues with this, as written:

- My major one is that I don't find good criteria for deciding if something should be described as immersive or not. Lacking that, its going to be hard to get any kind of useful interoperability out of this.
What section 6 says is:

  Summary of the media feature indicated by this tag:  This feature tag
     indicates that the device provides an immersive audio and/or video
     communication experience.

  Values appropriate for use with this feature tag:  Boolean.

  The feature tag is intended primarily for use in the following
  applications, protocols, services, or negotiation mechanisms:   This
     feature tag is most useful in a communications application for
     describing the capabilities of a device, such as a Telepresence
     system.

  Examples of typical use:  Routing a call to a multimedia
     communication system that can provide an immersive communication
     experience.

Ideally if a UA has identified itself to me as immersive, then there ought to be something special about its behavior that I can count on.

The one tangible part of the description is "such as a Telepresence system". But it isn't very tangible because its only "such as", and "Telepresence system" itself isn't very well defined.

This would be much more tangible if it was tied to some specification, such as those in progress in the CLUE wg. There is also the specification of immersive in draft-ietf-mmusic-traffic-class-for-sdp-00. I presume there might be some relationship to it as well.

- My second (minor) point is that when using this tag in Contact headers you need to write it as '+sip.immersive'.

       Thanks,
       Paul






On 3/5/12 4:36 PM, Glen Lavers (glavers) wrote:

Folks,
I have submitted a new draft to define an 'immersive' media feature tag. The draft is posted at: http://tools.ietf.org/html/draft-lavers-sipcore-immersive-capability



The authors would appreciate feedback  and or detailed comments.

Many thanks,
Glen
_______________________________________________

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


_______________________________________________
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

--------------060808020703010603080508-- From fluffy@iii.ca Wed Mar 7 08:05:39 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9EA21F84C4 for ; Wed, 7 Mar 2012 08:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.783 X-Spam-Level: X-Spam-Status: No, score=-2.783 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXqyc65kDiIP for ; Wed, 7 Mar 2012 08:05:38 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8B89C21F84B9 for ; Wed, 7 Mar 2012 08:05:38 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B6CDD22E25B; Wed, 7 Mar 2012 11:05:31 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F4F5C19.9070607@ericsson.com> Date: Wed, 7 Mar 2012 09:05:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F4F5C19.9070607@ericsson.com> To: DISPATCH X-Mailer: Apple Mail (2.1084) Subject: Re: [dispatch] Charter process for the INSIPID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:05:39 -0000 I believe the charter in the proposed link represents the rough = consensus from the hum we took in the meeting and the associated mailing = list discussion.=20 I do not believe there was consensus in DISPATCH to expand the scope to = service interaction issues beyond the semantics to/from/call-id = semantics. In the meeting, specific questions were asked around this = topic such as interaction with conferences bridges and what people = hummed on was not the expanded scope. Cullen On Mar 1, 2012, at 4:23 AM, Gonzalo Camarillo wrote: > Folks, >=20 > Robert and I have been working on a charter proposal for the INSIPID = WG. > This is the proposal that we have sent for review to the IESG and IAB: >=20 > http://www.ietf.org/iesg/evaluation/sessionid-charter.txt >=20 > We believe this proposal represents the consensus of the group. Note > that we have left out some comments that failed to get rough consensus > on this list. >=20 > =46rom now on, I will be taking care of the chartering process for = this > WG. Today, I will discuss the charter proposal with the IESG and, if > everything goes OK, we will be sending it for external review shortly. > If you have further comments on the charter proposal, please send them > as part of its external review, which will be announced on the IETF > announcement list as usual. >=20 > Also, I am going to be requesting the creation of the insipid mailing = list. >=20 > Cheers, >=20 > Gonzalo >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@iii.ca Wed Mar 7 08:09:10 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAC121F84C4 for ; Wed, 7 Mar 2012 08:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.779 X-Spam-Level: X-Spam-Status: No, score=-2.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qIj4aP0YyMJ for ; Wed, 7 Mar 2012 08:09:10 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E407221F84CD for ; Wed, 7 Mar 2012 08:09:09 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E45F222E1EB; Wed, 7 Mar 2012 11:09:07 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <01d501ccf3d4$75e6ad50$61b407f0$@us> Date: Wed, 7 Mar 2012 09:09:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com>, <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4EC361B8-792C-4B7C-9DEE-CE552FD15EB4@acmepacket.com> <38726EDA2109264987B45E29E758C4D6087083@MISOUT7MSGUSR9N.ITServices.sbc.com> <01d501ccf3d4$75e6ad50$61b407f0$@us> To: Richard Shockey X-Mailer: Apple Mail (2.1084) Cc: dispatch@ietf.org Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:09:10 -0000 On Feb 25, 2012, at 8:45 AM, Richard Shockey wrote: > And we want a WHOIS. That is essential.=20 Can you say more about the required properties you need here. = Specifically aorund how much the information in the WHOIS is validated? From fluffy@iii.ca Wed Mar 7 08:10:04 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3749D21F850C for ; Wed, 7 Mar 2012 08:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoojPTcQHdCc for ; Wed, 7 Mar 2012 08:10:03 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id AF35321F8501 for ; Wed, 7 Mar 2012 08:10:03 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D01D522E25B; Wed, 7 Mar 2012 11:10:01 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 7 Mar 2012 09:10:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1C392088-1150-4567-BF37-776396A0497A@iii.ca> References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4F459082.2040402@alum.mit.edu> <01d601ccf3d5$37710880$a6531980$@us> <4F4987A7.5080804@alum.mit.edu> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:10:04 -0000 On Feb 28, 2012, at 11:17 AM, Hadriel Kaplan wrote: > I don't think it's so much that there'll be a law about what exact SIP = headers must be used/included per se - it's more that they'll pass a law = saying each service provider (ie, IXC/ILEC/etc.) must indicate the call = request transited it, and pass on those indications it received from = upstream. Can you say more about what such a law is trying to accomplish as a way = of helping drive requirements. I can't imagine someone passing a law to = try and deal with loop detection so clearly it is more than that. From fluffy@iii.ca Wed Mar 7 08:18:11 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED9021F8596 for ; Wed, 7 Mar 2012 08:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.773 X-Spam-Level: X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnQoeS8KwMCR for ; Wed, 7 Mar 2012 08:18:10 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 87B1521F8595 for ; Wed, 7 Mar 2012 08:18:10 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C84C222E259; Wed, 7 Mar 2012 11:18:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 7 Mar 2012 09:18:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76CCB49A-FEE9-47F6-968E-C6AB54799816@iii.ca> References: <1330640892.23608.YahooMailNeo@web162003.mail.bf1.yahoo.com>, <4F513AC8.6050906@alum.mit.edu> To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1084) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposal: ESPID Sequence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:18:11 -0000 So just throwing out straw man here ... if you took the current VIA = based looping mechanism and also included an encrypted version of the = via in a separate header, 1) could you convinces the SBC not to remove = the encrypted version 2) would this work to correctly detect loops yet = not break spirals such as Dales example? On Mar 5, 2012, at 11:04 AM, Worley, Dale R (Dale) wrote: >> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >>=20 >> I disagree with the concept being proposed here. >>=20 >> I'm still waiting for an explanation for why the existing mechanisms = for >> loop detection aren't sufficient to solve the problem here. But even = if >> there is some inadequacy, then it should be solved in general, not = just >> for loops through multiple service providers. There is really nothing >> special about loops through SPs. >=20 > I'm with Paul here. >=20 > The real problem is that the SIP loop-prevention mechanisms often > don't work when network elements: > (1) hide the path the call has traversed > (2) are B2BUAs >=20 > One consequence of this is that in many cases a call can loop between > two service providers and not be detected. But there are many > somewhat more complex situations that also loop. >=20 > The proposed charter assumes that the desired anti-looping mechanism > would be some form of list of the service providers that the call has > traversed. >=20 > But many of the more complex scenarious would *not* be detected by a > "list of traversed service providers" mechanism (unless it was so > aggressive that it flagged similar, non-looping calls). Here is one: >=20 > Users A and C are served by service provider P. > Users B and D are served by service provider Q. >=20 > User B has forwarded his phone to user C. > User C has forwarded his phone to user D. >=20 > User A calls user B. The route of the call is: >=20 > A->P->Q->B->Q->P->C->P->Q->D >=20 > At D, the call has traversed P three times and has traversed Q three > times. It has been routed based on three different phone numbers. >=20 > If user D's phone rings, this call is valid and should succeed. If > user D has forwarded his phone to user A, the call is looped and > should fail. >=20 > No doubt the problem needs to be solved. But we need to start by > studing it, and determining a mechanism that works in all the cases > that our customers will shortly be exercising. The current charter > specifies a mechanism, and that mechanism will not work. >=20 > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@iii.ca Wed Mar 7 08:22:09 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BC721F8609 for ; Wed, 7 Mar 2012 08:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lmg262LCNLBq for ; Wed, 7 Mar 2012 08:22:08 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4310221F8602 for ; Wed, 7 Mar 2012 08:22:08 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 07E3922E1EB; Wed, 7 Mar 2012 11:22:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 7 Mar 2012 09:22:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> References: To: Glen Lavers (glavers) X-Mailer: Apple Mail (2.1084) Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:22:09 -0000 This draft does not actually define enough information to decide if a = given video phone should consider itself "immersive" or not.=20 I don't understand the use cases for this.=20 On Mar 5, 2012, at 3:11 PM, Glen Lavers (glavers) wrote: > Folks, > I have submitted a new draft to define an 'immersive' media feature = tag. The draft is posted at: = http://tools.ietf.org/html/draft-lavers-dispatch-immersive-capability=20 >=20 > The authors would appreciate feedback and or detailed comments.=20 >=20 > Many thanks, > Glen > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Wed Mar 7 08:28:48 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4E621F864D for ; Wed, 7 Mar 2012 08:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FscSufIxRwsc for ; Wed, 7 Mar 2012 08:28:47 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5C75821F864C for ; Wed, 7 Mar 2012 08:28:47 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q27GSij7013347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Mar 2012 11:28:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331137725; bh=4V63HAP9Ymmv8gnMO71TqUos9CEWeeJuhDViX1pKN08=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=k0yCQ3AT2PThCpmB9icLUhN3YjRSw7xzlik71gDqD1pwJFXtXToK3IYrY2GyNGkKR iuRTJbvt+8R3TxKIwGe8aSZNFWqxTX82NlA8nIHzQOKoZma8OWL0FYUWSfBxbgxyj1 1ZyBMBhue6pL8cbBdvMr7VJGnEyOwyHHbNk1sfGc= From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <4F56C3FC.6070901@alum.mit.edu> <002d01ccfc63$92613df0$b723b9d0$@packetizer.com> <4F578464.6030602@alum.mit.edu> In-Reply-To: <4F578464.6030602@alum.mit.edu> Date: Wed, 7 Mar 2012 11:28:51 -0500 Message-ID: <006d01ccfc7f$62321fc0$26965f40$@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: AQHenJm8OFlCRln1wB9t6DGLFBXyWgIbkfZIAaOgBcsB8gFj8wGjeBUClgEYpRA= Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:28:48 -0000 Paul, > > The 'immersive' tag is not intended to carry interoperability > > considerations with it. It is just an indicator that the system > > provides, what it believes is, an immersive experience. If two systems > > cannot communicate properly, this tag is not going to make any > > difference one way or the other. This proposed tag is like the > > existing 'video' or 'audio' tags. Those alone do not suggest one will > > achieve any kind of interoperability. > > AFAIK the existing video/audio tags mean, respectively, that > m=video/m=audio lines will be supported in offers and answers. Of course > there still might not be interop because there are no codecs in common, > but at least there is the basis for proposing something. The 'video' and 'audio' tags would suggest that, but 'mobility' (another tag specified in 3840) does not mean there is a mobility m= line. As an author of that document, you know quite well that tags do not equate to m= lines. > > Now, what this tag does provide is the ability for the calling device > > to indicate a preference. This tag can be used following the caller > > preferences RFC to help entities in the network route calls to devices > > that advertise as having this feature. It might help to avoid > > directing a video call to a desktop phone or it might help the > > intermediaries in routing calls over physical links that can provide a > > better level of service than the routine audio or video call. > > Replace the tag "immersive" with one called "xyzzy". That also provides an > ability to indicate a preference. But how do I decide if I am qualified to > offer it? Because you, the network administrator, or manufacturer configured the device to do that. How sets the mobile tag, duplex tag, description tag, etc? > At the moment the word "immersive" is just an advertising buzz word. We > need for it to have some tangible semantics. It is a buzzword, but not so vague. We could define the term in the draft. We could borrow part of the definition of "Telepresence", which is fitting: "An interactive audio-visual communications experience between remote locations, where the users enjoy a strong sense of realism and presence between all participants." > Is there a difference between "immersive" and "telepresence"? Yes. "Immersive" does not necessarily mean "telepresence". I think the above definition goes a bit further than what everyone might consider as "immersive"; i.e., a telepresence system is immersive, but not all immersive systems are necessarily telepresence systems. For example, my son plays videogames online wearing a wireless headset. In a dark room, nice screen, and the headset, he has an immersive experience. I'd call that system immersive, but it's not telepresence. Telepresence is defined more broadly: "An interactive audio-visual communications experience between remote locations, where the users enjoy a strong sense of realism and presence between all participants by optimizing a variety of attributes such as audio and video quality, eye contact, body language, spatial audio, coordinated environments and natural image size." An immersive experience does not necessarily include spatial audio or include video. An audio-only system can be immersive. Net is that I would have all Telepresence systems advertise as "immersive", but I might also have non-telepresence systems advertise that, too. This is intended for caller preferences, it's not intended to signal a different flavor of SIP, different endpoint behavior, etc. Its aim is to connect two endpoints taking user preferences into consideration. Paul From adam@nostrum.com Wed Mar 7 08:37:18 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8857E21F86BB for ; Wed, 7 Mar 2012 08:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ0atpHXP6q0 for ; Wed, 7 Mar 2012 08:37:18 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A79FB21F86B9 for ; Wed, 7 Mar 2012 08:37:16 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q27GbDHK058206 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Mar 2012 10:37:15 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F578EB9.9050001@nostrum.com> Date: Wed, 07 Mar 2012 10:37:13 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Dawes, Peter, VF-Group" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020402030004000305030309" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: fluffy@cisco.com, mary.barnes@polycom.com, dispatch@ietf.org Subject: Re: [dispatch] Media Plane Security draft-dawes-dispatch-mediasec-parameter-05 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:37:18 -0000 This is a multi-part message in MIME format. --------------020402030004000305030309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/1/12 5:56 AM, Dawes, Peter, VF-Group wrote: > > One way to provide security on the media plane of a session set up > using SIP is using DTLS-SRTP but this solution was not chosen by the > 3GPP security group for the reasons in clause 1.1.2.2 of > draft-dawes-dispatch-mediasec-parameter-05 > Which I'll quote below for the purposes of discussion: > Some networks are required by regulation to provide lawful intercept, > and no method compatible with DTLS-SRTP is available when a UA is > outside its own network (i.e., roaming). Followed by a quote from RFC2804: > The IETF has decided not to consider requirements for wiretapping as > part of the process for creating and maintaining IETF standards. And I'll leave it at that. /a --------------020402030004000305030309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/1/12 5:56 AM, Dawes, Peter, VF-Group wrote:

One way to provide security on the media plane of a session set up using SIP is using DTLS-SRTP but this solution was not chosen by the 3GPP security group for the reasons in clause 1.1.2.2 of draft-dawes-dispatch-mediasec-parameter-05


Which I'll quote below for the purposes of discussion:

   Some networks are required by regulation to provide lawful intercept,
   and no method compatible with DTLS-SRTP is available when a UA is
   outside its own network (i.e., roaming).

Followed by a quote from RFC2804:

   The IETF has decided not to consider requirements for wiretapping as
   part of the process for creating and maintaining IETF standards.

And I'll leave it at that.

/a
--------------020402030004000305030309-- From pkyzivat@alum.mit.edu Wed Mar 7 10:12:52 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A8B21E80B1 for ; Wed, 7 Mar 2012 10:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueiGbvjsCy4M for ; Wed, 7 Mar 2012 10:12:51 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6D821E8081 for ; Wed, 7 Mar 2012 10:12:51 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id icuQ1i0041c6gX853iCrtE; Wed, 07 Mar 2012 18:12:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id iiCr1i00907duvL3jiCrSG; Wed, 07 Mar 2012 18:12:51 +0000 Message-ID: <4F57A521.5050705@alum.mit.edu> Date: Wed, 07 Mar 2012 13:12:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <4F56C3FC.6070901@alum.mit.edu> <002d01ccfc63$92613df0$b723b9d0$@packetizer.com> <4F578464.6030602@alum.mit.edu> <006d01ccfc7f$62321fc0$26965f40$@packetizer.com> In-Reply-To: <006d01ccfc7f$62321fc0$26965f40$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 18:12:52 -0000 On 3/7/12 11:28 AM, Paul E. Jones wrote: > Paul, > >>> The 'immersive' tag is not intended to carry interoperability >>> considerations with it. It is just an indicator that the system >>> provides, what it believes is, an immersive experience. If two systems >>> cannot communicate properly, this tag is not going to make any >>> difference one way or the other. This proposed tag is like the >>> existing 'video' or 'audio' tags. Those alone do not suggest one will >>> achieve any kind of interoperability. >> >> AFAIK the existing video/audio tags mean, respectively, that >> m=video/m=audio lines will be supported in offers and answers. Of course >> there still might not be interop because there are no codecs in common, >> but at least there is the basis for proposing something. > > The 'video' and 'audio' tags would suggest that, but 'mobility' (another tag > specified in 3840) does not mean there is a mobility m= line. As an author > of that document, you know quite well that tags do not equate to m= lines. And if I was doing it again I would tighten it up. No reason to repeat past mistakes. >>> Now, what this tag does provide is the ability for the calling device >>> to indicate a preference. This tag can be used following the caller >>> preferences RFC to help entities in the network route calls to devices >>> that advertise as having this feature. It might help to avoid >>> directing a video call to a desktop phone or it might help the >>> intermediaries in routing calls over physical links that can provide a >>> better level of service than the routine audio or video call. >> >> Replace the tag "immersive" with one called "xyzzy". That also provides an >> ability to indicate a preference. But how do I decide if I am qualified to >> offer it? > > Because you, the network administrator, or manufacturer configured the > device to do that. How sets the mobile tag, duplex tag, description tag, > etc? So you are suggesting that this will only work right if the same administrator controls those setting the tags and those consuming the tags? >> At the moment the word "immersive" is just an advertising buzz word. We >> need for it to have some tangible semantics. > > It is a buzzword, but not so vague. We could define the term in the draft. > We could borrow part of the definition of "Telepresence", which is fitting: > > "An interactive audio-visual communications experience between remote > locations, where the users enjoy a strong sense of realism and presence > between all participants." The better you define it the better off we are. It would be helpful to have some use cases for this. That would guide the sort of definition that is needed. >> Is there a difference between "immersive" and "telepresence"? > > Yes. "Immersive" does not necessarily mean "telepresence". I think the > above definition goes a bit further than what everyone might consider as > "immersive"; i.e., a telepresence system is immersive, but not all immersive > systems are necessarily telepresence systems. For example, my son plays > videogames online wearing a wireless headset. In a dark room, nice screen, > and the headset, he has an immersive experience. I'd call that system > immersive, but it's not telepresence. > Telepresence is defined more broadly: > > "An interactive audio-visual communications experience between remote > locations, where the users enjoy a strong sense of realism and presence > between all participants by optimizing a variety of attributes such as audio > and video quality, eye contact, body language, spatial audio, coordinated > environments and natural image size." > > An immersive experience does not necessarily include spatial audio or > include video. An audio-only system can be immersive. > > Net is that I would have all Telepresence systems advertise as "immersive", > but I might also have non-telepresence systems advertise that, too. This is > intended for caller preferences, it's not intended to signal a different > flavor of SIP, different endpoint behavior, etc. Its aim is to connect two > endpoints taking user preferences into consideration. So then, once we have some telepresence systems declaring themselves immersive, and we have some gaming systems also calling themselves immersive, what can we do that we couldn't do without that tagging? Thanks, Paul From glavers@cisco.com Wed Mar 7 10:40:36 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A846721E80B6 for ; Wed, 7 Mar 2012 10:40:36 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DS1V+NaEw0q for ; Wed, 7 Mar 2012 10:40:35 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BCB9021E8017 for ; Wed, 7 Mar 2012 10:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=glavers@cisco.com; l=3017; q=dns/txt; s=iport; t=1331145635; x=1332355235; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ullGLyLdAUsNsi6xfUieIXOI3LItx6B5ktkjfVmOj+s=; b=EwLJL1Ppj2Sn8X/MA7RWdOe8KtTwtlIASw+CRdq3OswEdn2aAiGozz+f hrzUM5lxbqPeHQA8b8HdOGJCCw4fuzaukJE7u6cNC9d5AmWWc72yMtG9E zR9nsFYL35WShuU/YRJ/aNU6X5SEhksCaSSdx5WoAYfGCF3DfSg7O0tCs w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABarV0+rRDoJ/2dsb2JhbABCtSuBB4IKAQEFEgEdCi4GCwwEAgEIDgMEAQEBCgMDFwEGAUUJCAEBBBsRCYdlAQugBwGXL4olhWdjBIhSnQaDBIE0 X-IronPort-AV: E=Sophos;i="4.73,547,1325462400"; d="scan'208";a="34882355" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 07 Mar 2012 18:30:58 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q27IUwsw007501; Wed, 7 Mar 2012 18:30:58 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 10:30:58 -0800 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, 7 Mar 2012 10:30:58 -0800 Message-ID: In-Reply-To: <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz8fnYVPZA7PINoTJup2lZzobozigAAEAKw References: <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> From: "Glen Lavers (glavers)" To: "Cullen Jennings" X-OriginalArrivalTime: 07 Mar 2012 18:30:58.0137 (UTC) FILETIME=[70978490:01CCFC90] Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 18:40:36 -0000 Cullen, Adam, et al., Sorry I hadn't confirmed my subscription to dispatch :-/ so I'm only now getting the emails. I did find them in the archive though and really mean to respond to the 2 major points that are being brought up.=20 1) The definition of immersive and it's subjectivity/objectivity 2) Use cases=20 The more criteria exposed the more restrictive it becomes. It wasn't the intention of the draft to make the definition of immersive restrictive. Some implementers might consider immersive to be a simple in-person interaction of an audio and video experience. Other implementers might require an environment that is replicated on each side of video communication such that lighting, microphones etc... make the individuals in the conference feel like they are in the same room.=20 We opted for a less restrictive definition. The idea here is to provide a line, not a fine one, but a notion nonetheless that immersive is a duplication of an in-person or life-like experience. Above and beyond that there is no limit, no specific requirement to be met. It is subjective. Audio/Video quality is subjective. But this isn't just about media quality it's about business and policy distinctions.=20 =20 The use cases are for business and policy distinctions. There are valid policy decisions that implementers would like to make to differentiate a video experience from an immersive experience such that an immersive experience is a video experience but not the other way around. This is a user preference which is of course subjective. But just because it's subjective does not mean that it's invalid.=20 As an enterprise I may want my endpoints to be classified as "immersive" (this draft) and "video" (RFC 3840) in order to classify an endpoints support of "video" vs "immersive" video (in-person experience) from other endpoints and call flows and manage them for policy decisions. One use case that we noted was for call routing. Another was for admission control.=20 Cheers, glen > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@iii.ca] > Sent: Wednesday, March 07, 2012 8:22 AM > To: Glen Lavers (glavers) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt >=20 >=20 > This draft does not actually define enough information to decide if a given > video phone should consider itself "immersive" or not. >=20 > I don't understand the use cases for this. >=20 > On Mar 5, 2012, at 3:11 PM, Glen Lavers (glavers) wrote: >=20 > > Folks, > > I have submitted a new draft to define an 'immersive' media feature tag. The > draft is posted at: http://tools.ietf.org/html/draft-lavers-dispatch-immersive- > capability > > > > The authors would appreciate feedback and or detailed comments. > > > > Many thanks, > > Glen > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Wed Mar 7 11:53:34 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7049011E8097 for ; Wed, 7 Mar 2012 11:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVGPa8RR6Dgb for ; Wed, 7 Mar 2012 11:53:34 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0073B11E8072 for ; Wed, 7 Mar 2012 11:53:33 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q27JrU6D089037 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Mar 2012 13:53:31 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F57BCBA.3020206@nostrum.com> Date: Wed, 07 Mar 2012 13:53:30 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Glen Lavers (glavers)" References: <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org, Cullen Jennings Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 19:53:34 -0000 On 3/7/12 12:30 PM, Glen Lavers (glavers) wrote: > The use cases are for business and policy distinctions. There are valid > policy decisions that implementers would like to make to differentiate a > video experience from an immersive experience such that an immersive > experience is a video experience but not the other way around. You're positing that network operators will be willing to make business and policy decisions based on the nearly arbitrary, subjective opinions of implementors? I think that's a bit naïve. /a From glavers@cisco.com Wed Mar 7 12:27:22 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC43311E8094 for ; Wed, 7 Mar 2012 12:27:22 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXaZxWVbnzUT for ; Wed, 7 Mar 2012 12:27:22 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3D65411E8085 for ; Wed, 7 Mar 2012 12:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=glavers@cisco.com; l=1987; q=dns/txt; s=iport; t=1331152042; x=1332361642; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=8BbQX39sh8RYnK0Js51FpDtQIFNzjUtXTZNX4EYG5KQ=; b=USFaDdYa/vol/D/ZsJHvyvokZnLDtLy6zqaYy62eMw8/GkrI9ZH0sTt1 St5GO2T+vLHq6eXM+InVbxwb4GsbRuxsGQn+Jwfx4Zn6NbbRsKMuyMeB+ 5pU+C0veYX6DBRXTb6ZVMouL5PYbCAQ23ovD1uLs6cYKMRz1n5TuXDLb5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKPDV0+rRDoJ/2dsb2JhbABEtSWBB4IKAQEBBBIBHUkMBAIBCBEEAQEBCgYXAQYBRQkIAQEEEwgah2UBml4BnwuQDGMEiB8znQaDBA X-IronPort-AV: E=Sophos;i="4.73,547,1325462400"; d="scan'208";a="34903245" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 07 Mar 2012 20:27:22 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q27KRLCV008437; Wed, 7 Mar 2012 20:27:21 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 12:27:21 -0800 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: Wed, 7 Mar 2012 12:27:22 -0800 Message-ID: In-Reply-To: <4F57BCBA.3020206@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz8nAFHSEaV3+2cR2mUq6VJORgEKQAALfaA References: <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <4F57BCBA.3020206@nostrum.com> From: "Glen Lavers (glavers)" To: "Adam Roach" X-OriginalArrivalTime: 07 Mar 2012 20:27:21.0952 (UTC) FILETIME=[B3451E00:01CCFCA0] Cc: dispatch@ietf.org, Cullen Jennings Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 20:27:23 -0000 Sorry I'm using implementer in 2 contexts. What I mean by implementer is = network operator, or someone deploying products or systems that use this = feature tag. A vendor would add it to their product and provide ways to = enable/disable/filter depending on product and usage. =09 If I'm an implementer who has purchased 2 different vendor products that = allow for the immersive feature tag. As an implementer I can decide to = use the tag or not based on what I know of the products and what I want = as a policy decision. If I choose to use it I would know the = capabilities of the 2 vendor products and decide for myself if they fit = the criteria for this differentiation that I as an implementer/network = operator am after. If they do then I can leverage that to make policy = decisions, in my network, in call control, wherever or I turn them off = or filter them based on the products themselves.=20 A vendor adding this media feature tag to their product would hopefully = leave it to the implementer to decide when and how to use it for policy. = =20 Does that better clarify my statements? -glen > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Wednesday, March 07, 2012 11:54 AM > To: Glen Lavers (glavers) > Cc: Cullen Jennings; dispatch@ietf.org > Subject: Re: [dispatch] = draft-lavers-sipcore-immersive-capability-00.txt >=20 > On 3/7/12 12:30 PM, Glen Lavers (glavers) wrote: > > The use cases are for business and policy distinctions. There are > > valid policy decisions that implementers would like to make to > > differentiate a video experience from an immersive experience such > > that an immersive experience is a video experience but not the other = way > around. >=20 > You're positing that network operators will be willing to make = business and > policy decisions based on the nearly arbitrary, subjective opinions of > implementors? I think that's a bit na=EFve. >=20 > /a From pkyzivat@alum.mit.edu Wed Mar 7 13:07:03 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6190111E809A for ; Wed, 7 Mar 2012 13:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OerjfSmRrwX5 for ; Wed, 7 Mar 2012 13:07:02 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id EE47011E8086 for ; Wed, 7 Mar 2012 13:07:01 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta06.westchester.pa.mail.comcast.net with comcast id ikBk1i00B1swQuc56l72hj; Wed, 07 Mar 2012 21:07:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id il721i00W07duvL3bl72y3; Wed, 07 Mar 2012 21:07:02 +0000 Message-ID: <4F57CDF3.2030700@alum.mit.edu> Date: Wed, 07 Mar 2012 16:06:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <4F57BCBA.3020206@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 21:07:03 -0000 Glen, I'm still not understanding your use cases. Is your intent to *register* endpoints with the feature tag, and then use callerprefs so that calls prefer (or require) callees that have registered the tag? Or is your intent to pass the tag (on a Contact header) during call establishment and use the value to decide whether to accept the call, or condition behavior after the call is established? Either way, it isn't going to work right if everybody doesn't have some level of common understanding of what this means. If I'm sitting in a telepresence room and calling you, I will be wanting to reach a telepresence system, and probably won't be satisfied if I reach your game machine. (And what if you have both?) Also, AFAIK virtually nothing currently supports callerprefs (Accept-Contact/Reject-Contact), except 3gpp. But I'll be pleased to hear I am wrong about that. And even if some do, Accept-Contact won't be very useful unless you have multiple systems with different capabilities registered to the same AOR. (Reject-Contact might be useful to cause calls to fail unless you reach a device with the desired capabilities.) Can you spell out the use case(s) you have in mind for this in significantly more detail? (Describe the capabilities and desires of the caller, the characteristics and behaviors of the potential callees, and the expected outcome in both positive and negative cases.) Also, how the UAs come to know what capabilities to register and to prefer - are those compiled into the code by the code developer, or are they configured in by the deployer? Thanks, Paul On 3/7/12 3:27 PM, Glen Lavers (glavers) wrote: > Sorry I'm using implementer in 2 contexts. What I mean by implementer is network operator, or someone deploying products or systems that use this feature tag. A vendor would add it to their product and provide ways to enable/disable/filter depending on product and usage. > > If I'm an implementer who has purchased 2 different vendor products that allow for the immersive feature tag. As an implementer I can decide to use the tag or not based on what I know of the products and what I want as a policy decision. If I choose to use it I would know the capabilities of the 2 vendor products and decide for myself if they fit the criteria for this differentiation that I as an implementer/network operator am after. If they do then I can leverage that to make policy decisions, in my network, in call control, wherever or I turn them off or filter them based on the products themselves. > > A vendor adding this media feature tag to their product would hopefully leave it to the implementer to decide when and how to use it for policy. > > Does that better clarify my statements? > -glen > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Wednesday, March 07, 2012 11:54 AM >> To: Glen Lavers (glavers) >> Cc: Cullen Jennings; dispatch@ietf.org >> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt >> >> On 3/7/12 12:30 PM, Glen Lavers (glavers) wrote: >>> The use cases are for business and policy distinctions. There are >>> valid policy decisions that implementers would like to make to >>> differentiate a video experience from an immersive experience such >>> that an immersive experience is a video experience but not the other way >> around. >> >> You're positing that network operators will be willing to make business and >> policy decisions based on the nearly arbitrary, subjective opinions of >> implementors? I think that's a bit naïve. >> >> /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From Peter.Dawes@vodafone.com Thu Mar 8 08:49:57 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729BA21F84E0 for ; Thu, 8 Mar 2012 08:49:57 -0800 (PST) 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.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiBLvwa8Je7e for ; Thu, 8 Mar 2012 08:49:56 -0800 (PST) Received: from mailout06.vodafone.com (mailout06.vodafone.com [195.232.224.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4F96521F84DF for ; Thu, 8 Mar 2012 08:49:56 -0800 (PST) Received: from mailint06 (localhost [127.0.0.1]) by mailout06 (Postfix) with ESMTP id 6F7F484F04 for ; Thu, 8 Mar 2012 17:49:54 +0100 (CET) Received: from avoexs04.internal.vodafone.com (avoexs04.dc-ratingen.de [145.230.4.198]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint06 (Postfix) with ESMTPS id 61604847C6; Thu, 8 Mar 2012 17:49:54 +0100 (CET) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs04.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 17:49:28 +0100 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_01CCFD4B.6CD59211" Date: Thu, 8 Mar 2012 17:49:55 +0100 Message-ID: In-Reply-To: <4F578EB9.9050001@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Media Plane Security draft-dawes-dispatch-mediasec-parameter-05 Thread-Index: Acz8gILAlKcdN4IVSdugLK3di/bMyQAurVGw References: <4F578EB9.9050001@nostrum.com> From: "Dawes, Peter, VF-Group" To: "Adam Roach" X-OriginalArrivalTime: 08 Mar 2012 16:49:28.0305 (UTC) FILETIME=[6D2EA610:01CCFD4B] Cc: fluffy@cisco.com, mary.barnes@polycom.com, dispatch@ietf.org Subject: Re: [dispatch] Media Plane Security draft-dawes-dispatch-mediasec-parameter-05 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:49:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFD4B.6CD59211 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Adam, Thanks very much for commenting on this topic. The primary purpose of the draft is to enable set up of media security from a terminal to a media security function in a "terminal to access edge" mode, so that the media is at least protected from eavesdropping in the access network e.g. a WiFi network. Although end-to-access-edge media security can make it possible to perform lawful intercept in a core network, the terminal can specify end-to-end protection as described at the end of 1.1.1. in the draft. =20 (end of 1.1.1.) End to access edge media protection described in this document is not a substitute for end-to-end media protection. A user agent requests end-to-access-edge media protection by including a "a=3D3ge2ae" SDP attribute at session setup. If this attribute is not included, then end-to-end protection is expected by the user agent and protection MUST NOT fall back to end-to-access-edge protection. =20 So this media security functionality was not motivated by lawful intercept but this was a consideration in the 3GPP discussions and design behind the draft. =20 Regards, Peter =20 From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: 07 March 2012 16:37 To: Dawes, Peter, VF-Group Cc: dispatch@ietf.org; fluffy@cisco.com; mary.barnes@polycom.com Subject: Re: [dispatch] Media Plane Security draft-dawes-dispatch-mediasec-parameter-05 =20 On 3/1/12 5:56 AM, Dawes, Peter, VF-Group wrote:=20 One way to provide security on the media plane of a session set up using SIP is using DTLS-SRTP but this solution was not chosen by the 3GPP security group for the reasons in clause 1.1.2.2 of draft-dawes-dispatch-mediasec-parameter-05 Which I'll quote below for the purposes of discussion: Some networks are required by regulation to provide lawful intercept, and no method compatible with DTLS-SRTP is available when a UA is outside its own network (i.e., roaming). Followed by a quote from RFC2804: The IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards. And I'll leave it at that. /a ------_=_NextPart_001_01CCFD4B.6CD59211 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = Adam,

Thanks very much for commenting on this topic. = The primary purpose of the draft is to enable set up of media security = from a terminal to a media security function in a "terminal to = access edge" mode, so that the media is at least protected from = eavesdropping in the access network e.g. a WiFi network. Although = end-to-access-edge media security can make it possible to perform lawful = intercept in a core network, the terminal can specify end-to-end = protection as described at the end of 1.1.1. in the = draft.

 

(end of = 1.1.1.)

End to access edge media protection described in = this document is not

   a substitute for end-to-end media = protection.  A user agent requests

   = end-to-access-edge media protection by including a = "a=3D3ge2ae" SDP

   attribute = at session setup.  If this attribute is not included, then  = end-to-end protection is expected by the user agent and = protection

   MUST NOT fall back to = end-to-access-edge protection.

 

So this media security = functionality was not motivated by lawful intercept but this was a = consideration in the 3GPP discussions and design behind the = draft.

 

Regards,

Peter

 

From: Adam Roach [mailto:adam@nostrum.com] =
Sent: 07 March 2012 16:37
To: Dawes, Peter, = VF-Group
Cc: dispatch@ietf.org; fluffy@cisco.com; = mary.barnes@polycom.com
Subject: Re: [dispatch] Media Plane = Security = draft-dawes-dispatch-mediasec-parameter-05

 

On = 3/1/12 5:56 AM, Dawes, Peter, VF-Group wrote:

One way to provide security on the media plane of a session set up = using SIP is using DTLS-SRTP but this solution was not chosen by the = 3GPP security group for the reasons in clause 1.1.2.2 of = draft-dawes-dispatch-mediasec-parameter-05


Which I'll quote below = for the purposes of = discussion:


   Some =
networks are required by regulation to provide lawful =
intercept,
   and no method compatible =
with DTLS-SRTP is available when a UA =
is
   outside its own network (i.e., =
roaming).


Followed by a quote from = RFC2804:


   The IETF has =
decided not to consider requirements for wiretapping =
as
   part of the process for creating =
and maintaining IETF standards.


And I'll leave it at = that.

/a

------_=_NextPart_001_01CCFD4B.6CD59211-- From adam@nostrum.com Thu Mar 8 10:39:23 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A4C21F86FD for ; Thu, 8 Mar 2012 10:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0pueAb+ok+w for ; Thu, 8 Mar 2012 10:39:23 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E098F21F86F4 for ; Thu, 8 Mar 2012 10:39:22 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q28IdK5o007390 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 12:39:21 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F58FCD8.3060106@nostrum.com> Date: Thu, 08 Mar 2012 12:39:20 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Dawes, Peter, VF-Group" References: <4F578EB9.9050001@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010304000601030306050206" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: fluffy@cisco.com, mary.barnes@polycom.com, dispatch@ietf.org Subject: Re: [dispatch] Media Plane Security draft-dawes-dispatch-mediasec-parameter-05 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:39:23 -0000 This is a multi-part message in MIME format. --------------010304000601030306050206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/8/12 10:49 AM, Dawes, Peter, VF-Group wrote: > > Hello Adam, > > Thanks very much for commenting on this topic. The primary purpose of > the draft is to enable set up of media security from a terminal to a > media security function in a "terminal to access edge" mode, so that > the media is at least protected from eavesdropping in the access > network e.g. a WiFi network. Although end-to-access-edge media > security can make it possible to perform lawful intercept in a core > network, the terminal can specify end-to-end protection as described > at the end of 1.1.1. in the draft. > > (end of 1.1.1.) > > End to access edge media protection described in this document is not > > a substitute for end-to-end media protection. A user agent requests > > end-to-access-edge media protection by including a "a=3ge2ae" SDP > > attribute at session setup. If this attribute is not included, > then end-to-end protection is expected by the user agent and protection > > MUST NOT fall back to end-to-access-edge protection. > > So this media security functionality was not motivated by lawful > intercept but this was a consideration in the 3GPP discussions and > design behind the draft. > > Be that as it may, by adding it to 1.1.2.2, you imply that is a constraining requirement on the solution. It cannot be. The fundamental outcome of the Raven process was that we don't constrain the IETF's protocols -- in any way -- to accommodate legal interception requirements. What I'm saying is that you need to remove the quoted paragraph from the document. You also need to be willing to accept any changes that satisfy the other requirements in the document while potentially breaking intercept capabilities. /a --------------010304000601030306050206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/8/12 10:49 AM, Dawes, Peter, VF-Group wrote:

Hello Adam,

Thanks very much for commenting on this topic. The primary purpose of the draft is to enable set up of media security from a terminal to a media security function in a "terminal to access edge" mode, so that the media is at least protected from eavesdropping in the access network e.g. a WiFi network. Although end-to-access-edge media security can make it possible to perform lawful intercept in a core network, the terminal can specify end-to-end protection as described at the end of 1.1.1. in the draft.

 

(end of 1.1.1.)

End to access edge media protection described in this document is not

   a substitute for end-to-end media protection.  A user agent requests

   end-to-access-edge media protection by including a "a=3ge2ae" SDP

   attribute at session setup.  If this attribute is not included, then  end-to-end protection is expected by the user agent and protection

   MUST NOT fall back to end-to-access-edge protection.

 

So this media security functionality was not motivated by lawful intercept but this was a consideration in the 3GPP discussions and design behind the draft.

 


Be that as it may, by adding it to 1.1.2.2, you imply that is a constraining requirement on the solution. It cannot be. The fundamental outcome of the Raven process was that we don't constrain the IETF's protocols -- in any way -- to accommodate legal interception requirements.

What I'm saying is that you need to remove the quoted paragraph from the document. You also need to be willing to accept any changes that satisfy the other requirements in the document while potentially breaking intercept capabilities.

/a
--------------010304000601030306050206-- From dworley@avaya.com Thu Mar 8 10:55:46 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E1021F8604 for ; Thu, 8 Mar 2012 10:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr+lgqoPtZO6 for ; Thu, 8 Mar 2012 10:55:45 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 784A221F85FF for ; Thu, 8 Mar 2012 10:55:45 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPL/WE+HCzI1/2dsb2JhbABDtSiBB4ILAQUSKDEBAwcTAgEIDQUkEDIXDgEBBAEaGodoni6cJ49zYwSIUpJ6ihGDAQ X-IronPort-AV: E=Sophos;i="4.73,553,1325480400"; d="scan'208";a="236622156" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Mar 2012 13:46:57 -0500 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 Mar 2012 13:31:48 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 8 Mar 2012 13:46:56 -0500 From: "Worley, Dale R (Dale)" To: "Glen Lavers (glavers)" , "dispatch@ietf.org" Date: Thu, 8 Mar 2012 13:44:08 -0500 Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz8nAFHSEaV3+2cR2mUq6VJORgEKQAALfaAAC+ujGM= Message-ID: References: <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <4F57BCBA.3020206@nostrum.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 Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:55:46 -0000 I'm no expert in this, but the following comments come to mind. (Not in priority order.) The definition of "immersive" (which seems to be synonymous with "telepresence") is not exact. That doesn't mean that the term isn't useful, but it is a warning that there may be no *technological* distinction. In regard to admission control, I expect that in both architecture and practice, networks will want to base admission distinctions on more detailed information than "immersive". But maybe I'm wrong; I think networks have explicitly excluded all "video" media as an admission policy. So perhaps a network would refuse admission to any "immersive" video but allow non-immersive video, in order to conserve bandwidth. Please, please, please do not use the word "leverage" to mean "utilize (to gain a further advantage)". That word makes it sound like contact with marketing people has damaged your brain. In regard to routing decisions, a feature tag is useful if *some* calls *prefer* the feature and also *some* calls *reject* (anti-prefer) the feature. Unless this criterion is true, the callee's local network (or the callee's behavior) can obtain all possible benefit by statically prioritizing the alternative UAs. There are two examples in the draft, but neither is an example of either stated motivation. The examples and the motivations should not be conceptually disjoint. As Paul notes, the tag would be expressed as "+sip.immersive". A motivation which seems plausible to me is that a video UA would want to know if the *other* video UA was operating in an immersive manner or not, or whether it was capable of doing so, so as to adjust its behavior. E.g., if an immersive system is communicating with an "ordinary" system, it might want to (effectively) crop its transmitted video signal from "immersive surrounding" to "viewing screen" dimensions. The previous paragraph suggests that the set of existing video conferencing systems might be bimodal, that is, they might fall into two distinct classes: small-screen systems that people look at like televisions, and large-screen systems that surround the viewers, with no systems of intermediate size. If that is actually true (and it might have become true in the market without people explicitly planning or noticing it), it should be documented, and might be a justification for labeling videoconferencing systems with a binary "immersive" attribute. I suspect that there are important aspects of this subject that the authors know (at least intuitively) but have not documented, and a revision of the draft might be very informative. In any case, it seems to me that this draft falls squarely within the remit of CLUE. Dale From richard@shockey.us Thu Mar 8 15:56:46 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F5421F86C4 for ; Thu, 8 Mar 2012 15:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.654 X-Spam-Level: X-Spam-Status: No, score=-98.654 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0veCM66H1bw for ; Thu, 8 Mar 2012 15:56:46 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 3DBC121F86C2 for ; Thu, 8 Mar 2012 15:56:46 -0800 (PST) Received: (qmail 16428 invoked by uid 0); 8 Mar 2012 23:50:06 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 8 Mar 2012 23:50:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=BdOl7uztS5JgGQ7T2oRoEzML6iNJto4ERlYNutCaue8=; b=Y0yV6WXHUlONdtkVhSv86cnPKNPv/LelIidV/XJP9SushZDAQA0pwPmyS6md4Q/BunRZzWEl/A2roPufg1AFEMQLR7K9O9iuW7bhoigl7rruMg2m0HoQjYhy5Tyt3dDK; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S5n5x-0001Kk-8e; Thu, 08 Mar 2012 16:50:05 -0700 From: "Richard Shockey" To: , , Date: Thu, 8 Mar 2012 18:50:05 -0500 Message-ID: <001201ccfd86$30d719f0$92854dd0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CCFD5C.480111F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz9hi+tXVbYOlEGQ6Svhv7wAz9bcQ== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Subject: [dispatch] SIPNOC news Dr Henning Schulzrinne will be keynote speaker X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 23:56:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01CCFD5C.480111F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit he SIP Forum Announces FCC Chief Technology Officer Henning Schulzrinne Keynote Speaker for SIPNOC US 2012 SIP Visionary Schulzrinne to address the worldwide service provider community on SIP technology and opportunities facing the IP communications industry NORTH ANDOVER, MA (March 5, 2012) - The SIP Forum announced today Federal Communications Commission (FCC) Chief Technology Officer (CTO) Henning Schulzrinne as the keynote speaker for the second annual SIP Network Operators Conference (SIPNOC), being held at the Hyatt Dulles Hotel in Herndon, VA, June 25-27, 2012. SIPNOC US 2012 will host an international audience focused on the operational and technical aspects of Session Initiation Protocol (SIP) in service provider networks and issues critical to the reliable and successful deployment and operation of SIP-based services in carrier networks. The agenda will feature special presentations, panel discussions and workshops covering key topics by network operators related to SIP-based services and infrastructure, including testing, application development, SIP trunking, FoIP, call routing and peering, troubleshooting and monitoring, emergency services and more. The event website is located at www.sipnoc.org. "I'm excited to be able to talk about the challenges and opportunities of moving to an all-IP network to this international audience of network operational and technical professionals," said Schulzrinne. "As part of my participation in SIPNOC US 2012, I hope to gain a richer perspective on the future of SIP-enabled communications among service providers." "The SIP Forum is delighted to have Henning keynote this year's SIPNOC event," said Richard Shockey, Chairman of the Board of the SIP Forum. "Henning is universally acclaimed as the Father of the SIP standard. We have come a long way since the first SIP specification was adopted in 1999, and we still have much work to do. We look forward to hearing Henning's insights on where we are headed." As CTO of the FCC, Schulzrinne guides the organization's work on technology and engineering issues, together with the FCC's Office of Engineering and Technology. He advises on matters across the agency to ensure that FCC policies are driving technological innovation, including serving as a resource to FCC Commissioners. Schulzrinne joined the FCC in 2010 as an Engineering Fellow. Schulzrinne serves as Julian Clarence Levi Professor of Mathematical Methods and Computer Science and Professor of Engineering at The Fu Foundation School of Engineering at Columbia University. Over the course of his career, he has published more than 250 journal and conference papers and more than 70 Internet Requests for Comment (RFCs) - working to shape the key protocols for enabling voice-over-IP (VoIP) and other multimedia applications, including the Session Initiation Protocol (SIP) which have become Internet Standards. His research interests include Internet multimedia systems, applied network engineering, wireless networks, security, quality of service, and performance evaluation. "Mr. Schulzrinne is one of the key architects of the SIP standard, and a leading mind in the IP communications industry. We are simply thrilled to have him take part in this year's SIPNOC event," said Marc Robins, SIP Forum President and Managing Director. SIPNOC US 2012 will build on themes first discussed at last year's inaugural event: addressing issues critical to the reliable and successful deployment and operation of SIP-based services in carrier networks and the opportunities that come with it. Among the topics expected to be on the agenda at this year's conference are SIP trunking interoperability and the SIP Forum's recently ratified SIPconnect 1.1 technical specification that provides a definitive and standardized set of guidelines for seamless, end-to-end interoperability between SIP-enabled IP-PBXs and service provider networks. Other themes to be discussed include Fax over Internet protocol (FoIP) interworking, implementing SIP with IPv6, and the sharing of best practices for the utilization of Wireshark for network diagnostics within IP network environments. Attendees at SIPNOC US 2012 will include engineers and network architects from telecommunications providers, major backbone operators, interconnect and wholesale solution providers, ISPs, cable operators, wireless network operators as well as large enterprises deploying major SIP initiatives. At last year's SIPNOC 2011, informational presentations were made by a number of professionals from organizations such as Comcast Cable, Cox Communications, Sprint Nextel, CableLabs and the Internet Engineering Task Force (IETF). Dr. Douglas C. Sicker, Chief Technologist at the Federal Communications Commission, provided the keynote speech. For more information about SIPNOC US 2012, please visit www.sipnoc.org or send an email to sipnocinfo@sipforum.org. REGISTER TODAY- $100 Discount for Limited Time Registration for SIPNOC US 2012 is now open, and for a limited time attendees can take advantage of a special $100 discount off the regular registration rate by entering code "sipnocus12100" on the initial registration page. Click here to register or visit http://www.regonline.com/sipnocus2012. ABOUT THE SIP FORUM The SIP Forum is an IP communications industry association that engages in numerous activities that promote and advance SIP-based technology, such as the development of industry recommendations, the SIPit interoperability and testing events, special interoperability workshops, educational seminars, and general promotion of SIP in the industry. One of the Forum's notable technical activities is the development of the SIPconnect Technical Recommendation -- a standards-based recommendation that provides detailed guidelines for direct IP peering and interoperability between IP PBXs and VoIP service provider networks. The SIPconnect Compliant Certification Program is an associated program through which eligible companies can gain SIPconnect validation and the right to license the use of the SIP Forum's 'SIPconnect Compliant' certification mark -- the official brand of the leading standard for SIP Trunking products and services. Other important Forum initiatives include work in Fax-over-IP interoperability, User Agent Configuration, video interoperability, and SIP and IPv6. For more information, please visit: http://www.sipforum.org. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_0013_01CCFD5C.480111F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

he SIP = Forum Announces FCC Chief Technology Officer

Henning Schulzrinne Keynote Speaker for SIPNOC US = 2012

 

SIP Visionary Schulzrinne to address the worldwide = service provider community on SIP technology and opportunities facing = the IP communications industry

 

NORTH = ANDOVER, MA (March 5, 2012) - The SIP Forum announced today Federal = Communications Commission (FCC) Chief Technology Officer (CTO) Henning = Schulzrinne as the keynote speaker for the second annual SIP Network = Operators Conference (SIPNOC), being held at the Hyatt Dulles Hotel in = Herndon, VA, June 25-27, 2012.

 

SIPNOC US = 2012 will host an international audience focused on the operational and = technical aspects of Session Initiation Protocol (SIP) in service = provider networks and issues critical to the reliable and successful = deployment and operation of SIP-based services in carrier networks. The = agenda will feature special presentations, panel discussions and = workshops covering key topics by network operators related to SIP-based = services and infrastructure, including testing, application development, = SIP trunking, FoIP, call routing and peering, troubleshooting and = monitoring, emergency services and more. The event website is located at = www.sipnoc.org.

“I’m = excited to be able to talk about the challenges and opportunities of = moving to an all-IP network to this international audience of network = operational and technical professionals,” said Schulzrinne. = “As part of my participation in SIPNOC US 2012, I hope to gain a = richer perspective on the future of SIP-enabled communications among = service providers.”

 

“The = SIP Forum is delighted to have Henning keynote this year’s SIPNOC = event,” said Richard Shockey, Chairman of the Board of the SIP = Forum. “Henning is universally acclaimed as the Father of the SIP = standard. We have come a long way since the first SIP specification was = adopted in 1999, and we still have much work to do. We look forward to = hearing Henning’s insights on where we are headed.” =

 

As CTO of the FCC, Schulzrinne guides the = organization’s work on technology and engineering issues, together = with the FCC’s Office of Engineering and Technology. He advises on = matters across the agency to ensure that FCC policies are driving = technological innovation, including serving as a resource to FCC = Commissioners.  Schulzrinne joined the FCC in 2010 as an = Engineering Fellow.

 

Schulzrinne = serves as Julian Clarence Levi Professor of Mathematical Methods and = Computer Science and Professor of Engineering at The Fu Foundation = School of Engineering at Columbia University.  Over the course of = his career, he has published more than 250 journal and conference papers = and more than 70 Internet Requests for Comment (RFCs) – working to = shape the key protocols for enabling voice-over-IP (VoIP) and other = multimedia applications, including the Session Initiation Protocol (SIP) = which have become Internet Standards.  His research interests = include Internet multimedia systems, applied network engineering, = wireless networks, security, quality of service, and performance = evaluation.

 

“Mr. Schulzrinne is one of the key architects of = the SIP standard, and a leading mind in the IP communications = industry.  We are simply thrilled to have him take part in this = year’s SIPNOC event,” said Marc Robins, SIP Forum President = and Managing Director.

 

SIPNOC US = 2012 will build on themes first discussed at last year’s inaugural = event: addressing issues critical to the reliable and successful = deployment and operation of SIP-based services in carrier networks and = the opportunities that come with it. Among the topics expected to be on = the agenda at this year’s conference are SIP trunking = interoperability and the SIP Forum’s recently ratified SIPconnect = 1.1 technical specification that provides a definitive and standardized = set of guidelines for seamless, end-to-end interoperability between = SIP-enabled IP-PBXs and service provider networks. Other themes to be = discussed include Fax over Internet protocol (FoIP) interworking, = implementing SIP with IPv6, and the sharing of best practices for the = utilization of Wireshark for network diagnostics within IP network = environments.

 

Attendees at = SIPNOC US 2012 will include engineers and network architects from = telecommunications providers, major backbone operators, interconnect and = wholesale solution providers, ISPs, cable operators, wireless network = operators as well as large enterprises deploying major SIP initiatives. = At last year’s SIPNOC 2011, informational presentations were made = by a number of professionals from organizations such as Comcast Cable, = Cox Communications, Sprint Nextel, CableLabs and the Internet = Engineering Task Force (IETF). Dr. Douglas C. Sicker, Chief Technologist = at the Federal Communications Commission, provided the keynote speech. =

 

For more information about SIPNOC US 2012, please = visit www.sipnoc.org or send an email to sipnocinfo@sipforum.org. =

 

 

REGISTER = TODAY–  $100 Discount for Limited Time

Registration for SIPNOC US 2012 is now open, and for a = limited time attendees can take advantage of a special $100 discount off = the regular registration rate by entering code = “sipnocus12100” on the initial registration page.  = Click here to register or visit = http://www.regonline.com/sipnocus2012.

 

ABOUT THE = SIP FORUM

The SIP Forum is an IP = communications industry association that engages in numerous activities = that promote and advance SIP-based technology, such as the development = of industry recommendations, the SIPit interoperability and testing = events, special interoperability workshops, educational seminars, and = general promotion of SIP in the industry.  One of the Forum's = notable technical activities is the development of the SIPconnect = Technical Recommendation -- a standards-based recommendation that = provides detailed guidelines for direct IP peering and interoperability = between IP PBXs and VoIP service provider networks. The SIPconnect = Compliant Certification Program is an associated program through which = eligible companies can gain SIPconnect validation and the right to = license the use of the SIP Forum's 'SIPconnect Compliant' certification = mark -- the official brand of the leading standard for SIP Trunking = products and services. Other important Forum initiatives include work in = Fax-over-IP interoperability, User Agent Configuration, video = interoperability, and SIP and IPv6. For more information, please visit: = http://www.sipforum.org.

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype= -linkedin-facebook: rshockey101
http//www.sipforum.org

 

------=_NextPart_000_0013_01CCFD5C.480111F0-- From glavers@cisco.com Fri Mar 9 09:17:54 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADE421F86EE for ; Fri, 9 Mar 2012 09:17:53 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2S-A+AGSH2tt for ; Fri, 9 Mar 2012 09:17:50 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id D270421F8718 for ; Fri, 9 Mar 2012 09:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=glavers@cisco.com; l=10428; q=dns/txt; s=iport; t=1331313470; x=1332523070; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=JPseGCyRC9rWMt+nO1Wdenf2TGg+vZ+3YUb6YwWWNAM=; b=jgJWQYrsNmhVJp0XNc400IF+YDinh5PfvzRLaQy8vDUPJOrlQ6zzcZWJ YuunIH4KoM7526tw5CSMT7A56gXWHNdPL73iTrI4gNK5q5v287Vr9lwtH fV43UShmrIDcENyMnO6EbMzsaUbfxIGMsOo3j3hkixXaKnzDLM3nQqdIG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACw6Wk+rRDoG/2dsb2JhbABCDrUxgQeCCgEBAQMBAQEBDwEpATEQBwYBCA4DBAEBAScuHwkIAQEEARIbB4djBAELoAMBlxkEiiiGMgSIIDOMdpAcgixYgTQBFw X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208";a="32601288" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 09 Mar 2012 17:17:50 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q29HHncF024650; Fri, 9 Mar 2012 17:17:50 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 09:17:49 -0800 Received: from 10.19.88.26 ([10.19.88.26]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Mar 2012 17:17:49 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 09 Mar 2012 09:17:46 -0800 From: Glen Lavers To: Paul Kyzivat , "dispatch@ietf.org" Message-ID: Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz+GIuAluAkJFst6ECB5pHojiBr2Q== In-Reply-To: <4F57CDF3.2030700@alum.mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Mar 2012 17:17:49.0963 (UTC) FILETIME=[8DDCCDB0:01CCFE18] Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:17:54 -0000 Hi Paul, Comments inline On 3/7/12 1:06 PM, "Paul Kyzivat" wrote: > Glen, >=20 > I'm still not understanding your use cases. >=20 > Is your intent to *register* endpoints with the feature tag, and then > use callerprefs so that calls prefer (or require) callees that have > registered the tag? >=20 > Or is your intent to pass the tag (on a Contact header) during call > establishment and use the value to decide whether to accept the call, or > condition behavior after the call is established? My example below was to pass the tag in a contact header during call establishment and use the value for a B2BUA or SBC to determine how to use it. In the draft we provided a few examples that might be useful but I coul= d imagine others. What I do see is for the ability for enterprise call management systems that interoperate like B2BUA's or SBCs to use this heade= r to drive routing decisions or effectuate admission control prior to SDP offer (the 2 examples in the draft) >=20 > Either way, it isn't going to work right if everybody doesn't have some > level of common understanding of what this means. If I'm sitting in a > telepresence room and calling you, I will be wanting to reach a > telepresence system, and probably won't be satisfied if I reach your > game machine. (And what if you have both?) Do you know of any systems that route calls for both gaming and telepresenc= e like endpoints? In any case I see this feature tag as more applicable to vendors of telepresence like systems. If the gaming systems wanted to leverage it then I guess they could. I guess you could imagine having a gaming system that could do both telepresence conferencing AND immersive gaming but if they did then I would see using another feature tag as a further qualifier, perhaps sip.application. I agree that a common understanding of what immersive means is critical. I don't think however that it needs to be restrictive or extremely specific. It's clear that many on this list are confused by our attempt at a broad definition of telepresence like immersive video. We can try and articulate this in terms of more specific adjectives however as many have mentioned there will most always be a level of subjectivity unless we add clear technical delineations which I'm extremely apprehensive about doing. What i= s critical is that the network operator managing these systems is able to control what uses the tag. Video is clearly a very broad tag that is both useful and fits all types of video. What we want here is a delineation of video and we would like that delineation to be managed by the network operator and really used at their discretion. Where they are able to decide where the line between video and immersive video lies in the solution that they manage. >=20 > Also, AFAIK virtually nothing currently supports callerprefs > (Accept-Contact/Reject-Contact), except 3gpp. But I'll be pleased to > hear I am wrong about that. >=20 > And even if some do, Accept-Contact won't be very useful unless you have > multiple systems with different capabilities registered to the same AOR. > (Reject-Contact might be useful to cause calls to fail unless you reach > a device with the desired capabilities.) >=20 > Can you spell out the use case(s) you have in mind for this in > significantly more detail? (Describe the capabilities and desires of the > caller, the characteristics and behaviors of the potential callees, and > the expected outcome in both positive and negative cases.) Also, how the > UAs come to know what capabilities to register and to prefer - are those > compiled into the code by the code developer, or are they configured in > by the deployer? I see endpoint vendors coding it into their endpoints and allowing it to be enabled/disabled. I also see call management systems using it between one another.=20 =20 An example of admission control: 2 telepresence like vendor systems that manage Enterprise calls for both video systems and telepresence like systems. Prior to ringing an endpoint it is often difficult to determine th= e type of call that is being established. Therefore sending an invite with a contact header that stipulates video for example is useful, especially in cases where delayed offer is used. This allows the receiving system to make some decisions. In this example the decision is for admission control. Call management systems tend to set an upper limit on how much bandwidth any given call from one endpoint to another can use. So knowing that the call i= s video prior to getting an offer is useful to validate that the bandwidth is allocated for a potential video call prior to ringing the device. The same is true for fixed telepresence-like systems which tend to use higher bandwidth limits than generic desktop video. So if an endpoint or a call management system can use this contact header with immersive it allows the receiving system to know that the intent of the call is telepresence like and can associate the correct bandwidth limits and deductions from the appropriate bandwidth allocations. As I mentioned it could be useful for any of those 2 systems to know at invite what type of call they are receiving. That the intent of the call is for an immersive telepresence like experience if available by the called party. The calling system could send the invite with a contact header showing not only immersive but other features as well like audio, video as the possibilities of the type of call that's possible: Contact: ;immersive;video;audio The receiving system could make any number of assumptions using that information. If it's doing admission control it could instantiate the invit= e at ring as an immersive call deducting from an allocation of bandwidth reserved for immersive style systems. If that fails it could then try video or audio-only. If only an immersive tag was available then maybe it would only try the immersive bandwidth allocation and if that failed it would simply fail the call. If the called system has bandwidth for the call the i= t in-turn signals the call on to the terminating endpoint or UA. I'll say here that I think that it's very important that the network operator control the manner in which the tag is used. Therefore it should b= e controllable by the network operator. Meaning they should be able to enable or disable the use of the header on a specific endpoint or determine how it's used in calls from call management system to system. I can also see a use case in a similar scenario for SBCs where the SBC can use the information to determine directionality. If a user "owns" a number of devices that have varying levels of capabilities. Let's say that Bob own= s a telepresence like system fixed in a room. He also has 2 other devices. A desktop phone with standard video and a mobile device to receive audio only calls. If the way to reach any of these devices is the same, meaning that Bob's number or URI is exactly the same it could be useful for a network operator to be able to use things like this media feature tag and the base tags in order to direct the call to specific devices. So when a call comes from another telepresence like system to Bob only Bob's telepresence endpoint rings for example. If a call comes with a video and audio tag for example the call could be routed to all devices. The network operator could leverage the tag to achieve the requirements of the use cases. I can imagine other use cases where the called system could also use the indication to validate the call against a scheduling system specifically fo= r immersive calls.=20 I find that these tags can be useful in a number of scenarios for interoperation between call management system simply by allowing the use of the tags.=20 =20 >=20 > Thanks, > Paul >=20 > On 3/7/12 3:27 PM, Glen Lavers (glavers) wrote: >> Sorry I'm using implementer in 2 contexts. What I mean by implementer is >> network operator, or someone deploying products or systems that use this >> feature tag. A vendor would add it to their product and provide ways to >> enable/disable/filter depending on product and usage. >>=20 >> If I'm an implementer who has purchased 2 different vendor products that >> allow for the immersive feature tag. As an implementer I can decide to u= se >> the tag or not based on what I know of the products and what I want as a >> policy decision. If I choose to use it I would know the capabilities of = the 2 >> vendor products and decide for myself if they fit the criteria for this >> differentiation that I as an implementer/network operator am after. If t= hey >> do then I can leverage that to make policy decisions, in my network, in = call >> control, wherever or I turn them off or filter them based on the product= s >> themselves. >>=20 >> A vendor adding this media feature tag to their product would hopefully = leave >> it to the implementer to decide when and how to use it for policy. >>=20 >> Does that better clarify my statements? >> -glen >>=20 >>> -----Original Message----- >>> From: Adam Roach [mailto:adam@nostrum.com] >>> Sent: Wednesday, March 07, 2012 11:54 AM >>> To: Glen Lavers (glavers) >>> Cc: Cullen Jennings; dispatch@ietf.org >>> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.tx= t >>>=20 >>> On 3/7/12 12:30 PM, Glen Lavers (glavers) wrote: >>>> The use cases are for business and policy distinctions. There are >>>> valid policy decisions that implementers would like to make to >>>> differentiate a video experience from an immersive experience such >>>> that an immersive experience is a video experience but not the other w= ay >>> around. >>>=20 >>> You're positing that network operators will be willing to make business= and >>> policy decisions based on the nearly arbitrary, subjective opinions of >>> implementors? I think that's a bit na=EFve. >>>=20 >>> /a >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mphmmr@gmail.com Fri Mar 9 09:44:43 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D79421F8661 for ; Fri, 9 Mar 2012 09:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYKkNZodcNME for ; Fri, 9 Mar 2012 09:44:41 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED69721F8621 for ; Fri, 9 Mar 2012 09:44:40 -0800 (PST) Received: by lagj5 with SMTP id j5so2248575lag.31 for ; Fri, 09 Mar 2012 09:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WaD4m49RlLQKkyL100Fens+aHDK6jJLFYArxkP51S4M=; b=GtqTC/K/oR+Rq1p9LAtXIJjeW1YJHj4uBqzaK+xIc84bx/qKFzXbimjNOJDHJmZrvi AqZ71TIYj4U5Ub/Vx3ub/mGR9uuAxkTEvb4+dtI2FvvYf+7RaedV4s3GRu5flyY8Tt7U L5bOL4CqmC43Kz1yTbitEI/Cp5AwaSIf3yspi2EgIbsmjKEkxF3plDG0o74PORscC6Od 53iBN9NSdwdp5XaGz1ybRkv5O7kvigJEZaVga4qhXi43IgqrbKnjtEUnzY73C2/x6oJC D7qd81l31EhqG74GPTgou3/xZBjT+X0qIHpApoRhCkSK0S5MThfewaby7tmfk5AbYATu Q7Sg== MIME-Version: 1.0 Received: by 10.152.134.2 with SMTP id pg2mr2356995lab.3.1331315079897; Fri, 09 Mar 2012 09:44:39 -0800 (PST) Received: by 10.112.9.166 with HTTP; Fri, 9 Mar 2012 09:44:39 -0800 (PST) In-Reply-To: References: <4F57CDF3.2030700@alum.mit.edu> Date: Fri, 9 Mar 2012 12:44:39 -0500 Message-ID: From: Michael Hammer To: Glen Lavers Content-Type: multipart/alternative; boundary=f46d042ef7a96be30404bad2f219 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:44:43 -0000 --f46d042ef7a96be30404bad2f219 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Glen, The intent seems to be to indicate that the flow will be massive, whether it is immersive or not. Could you not also have something, say a brain-machine interface that is remote, but not video, that could also use a lot of BW? An potentially still immersive. If this all boils down to BW, then why not just ask for a BW indicator that lets SP's to make policy decisions accordingly. You could then take this indicator and make it a vector with a value. Mike On Fri, Mar 9, 2012 at 12:17 PM, Glen Lavers wrote: > Hi Paul, > Comments inline > > > On 3/7/12 1:06 PM, "Paul Kyzivat" wrote: > > > Glen, > > > > I'm still not understanding your use cases. > > > > Is your intent to *register* endpoints with the feature tag, and then > > use callerprefs so that calls prefer (or require) callees that have > > registered the tag? > > > > Or is your intent to pass the tag (on a Contact header) during call > > establishment and use the value to decide whether to accept the call, o= r > > condition behavior after the call is established? > My example below was to pass the tag in a contact header during call > establishment and use the value for a B2BUA or SBC to determine how to us= e > it. In the draft we provided a few examples that might be useful but I > could > imagine others. What I do see is for the ability for enterprise call > management systems that interoperate like B2BUA's or SBCs to use this > header > to drive routing decisions or effectuate admission control prior to SDP > offer (the 2 examples in the draft) > > > > > Either way, it isn't going to work right if everybody doesn't have some > > level of common understanding of what this means. If I'm sitting in a > > telepresence room and calling you, I will be wanting to reach a > > telepresence system, and probably won't be satisfied if I reach your > > game machine. (And what if you have both?) > Do you know of any systems that route calls for both gaming and > telepresence > like endpoints? In any case I see this feature tag as more applicable to > vendors of telepresence like systems. If the gaming systems wanted to > leverage it then I guess they could. I guess you could imagine having a > gaming system that could do both telepresence conferencing AND immersive > gaming but if they did then I would see using another feature tag as a > further qualifier, perhaps sip.application. > > I agree that a common understanding of what immersive means is critical. = I > don't think however that it needs to be restrictive or extremely specific= . > It's clear that many on this list are confused by our attempt at a broad > definition of telepresence like immersive video. We can try and articulat= e > this in terms of more specific adjectives however as many have mentioned > there will most always be a level of subjectivity unless we add clear > technical delineations which I'm extremely apprehensive about doing. What > is > critical is that the network operator managing these systems is able to > control what uses the tag. > > Video is clearly a very broad tag that is both useful and fits all types = of > video. What we want here is a delineation of video and we would like that > delineation to be managed by the network operator and really used at thei= r > discretion. Where they are able to decide where the line between video an= d > immersive video lies in the solution that they manage. > > > > > Also, AFAIK virtually nothing currently supports callerprefs > > (Accept-Contact/Reject-Contact), except 3gpp. But I'll be pleased to > > hear I am wrong about that. > > > > And even if some do, Accept-Contact won't be very useful unless you hav= e > > multiple systems with different capabilities registered to the same AOR= . > > (Reject-Contact might be useful to cause calls to fail unless you reach > > a device with the desired capabilities.) > > > > Can you spell out the use case(s) you have in mind for this in > > significantly more detail? (Describe the capabilities and desires of th= e > > caller, the characteristics and behaviors of the potential callees, and > > the expected outcome in both positive and negative cases.) Also, how th= e > > UAs come to know what capabilities to register and to prefer - are thos= e > > compiled into the code by the code developer, or are they configured in > > by the deployer? > I see endpoint vendors coding it into their endpoints and allowing it to = be > enabled/disabled. I also see call management systems using it between one > another. > > An example of admission control: 2 telepresence like vendor systems that > manage Enterprise calls for both video systems and telepresence like > systems. Prior to ringing an endpoint it is often difficult to determine > the > type of call that is being established. Therefore sending an invite with = a > contact header that stipulates video for example is useful, especially in > cases where delayed offer is used. This allows the receiving system to ma= ke > some decisions. In this example the decision is for admission control. Ca= ll > management systems tend to set an upper limit on how much bandwidth any > given call from one endpoint to another can use. So knowing that the call > is > video prior to getting an offer is useful to validate that the bandwidth = is > allocated for a potential video call prior to ringing the device. The sam= e > is true for fixed telepresence-like systems which tend to use higher > bandwidth limits than generic desktop video. So if an endpoint or a call > management system can use this contact header with immersive it allows th= e > receiving system to know that the intent of the call is telepresence like > and can associate the correct bandwidth limits and deductions from the > appropriate bandwidth allocations. > > As I mentioned it could be useful for any of those 2 systems to know at > invite what type of call they are receiving. That the intent of the call = is > for an immersive telepresence like experience if available by the called > party. The calling system could send the invite with a contact header > showing not only immersive but other features as well like audio, video a= s > the possibilities of the type of call that's possible: Contact: > ;immersive;video;audio > The receiving system could make any number of assumptions using that > information. If it's doing admission control it could instantiate the > invite > at ring as an immersive call deducting from an allocation of bandwidth > reserved for immersive style systems. If that fails it could then try vid= eo > or audio-only. If only an immersive tag was available then maybe it would > only try the immersive bandwidth allocation and if that failed it would > simply fail the call. If the called system has bandwidth for the call the > it > in-turn signals the call on to the terminating endpoint or UA. > > I'll say here that I think that it's very important that the network > operator control the manner in which the tag is used. Therefore it should > be > controllable by the network operator. Meaning they should be able to enab= le > or disable the use of the header on a specific endpoint or determine how > it's used in calls from call management system to system. > > I can also see a use case in a similar scenario for SBCs where the SBC ca= n > use the information to determine directionality. If a user "owns" a numbe= r > of devices that have varying levels of capabilities. Let's say that Bob > owns > a telepresence like system fixed in a room. He also has 2 other devices. = A > desktop phone with standard video and a mobile device to receive audio on= ly > calls. If the way to reach any of these devices is the same, meaning that > Bob's number or URI is exactly the same it could be useful for a network > operator to be able to use things like this media feature tag and the bas= e > tags in order to direct the call to specific devices. So when a call come= s > from another telepresence like system to Bob only Bob's telepresence > endpoint rings for example. If a call comes with a video and audio tag fo= r > example the call could be routed to all devices. The network operator cou= ld > leverage the tag to achieve the requirements of the use cases. > > I can imagine other use cases where the called system could also use the > indication to validate the call against a scheduling system specifically > for > immersive calls. > > I find that these tags can be useful in a number of scenarios for > interoperation between call management system simply by allowing the use = of > the tags. > > > > > > Thanks, > > Paul > > > > On 3/7/12 3:27 PM, Glen Lavers (glavers) wrote: > >> Sorry I'm using implementer in 2 contexts. What I mean by implementer = is > >> network operator, or someone deploying products or systems that use th= is > >> feature tag. A vendor would add it to their product and provide ways t= o > >> enable/disable/filter depending on product and usage. > >> > >> If I'm an implementer who has purchased 2 different vendor products th= at > >> allow for the immersive feature tag. As an implementer I can decide to > use > >> the tag or not based on what I know of the products and what I want as= a > >> policy decision. If I choose to use it I would know the capabilities o= f > the 2 > >> vendor products and decide for myself if they fit the criteria for thi= s > >> differentiation that I as an implementer/network operator am after. If > they > >> do then I can leverage that to make policy decisions, in my network, i= n > call > >> control, wherever or I turn them off or filter them based on the > products > >> themselves. > >> > >> A vendor adding this media feature tag to their product would hopefull= y > leave > >> it to the implementer to decide when and how to use it for policy. > >> > >> Does that better clarify my statements? > >> -glen > >> > >>> -----Original Message----- > >>> From: Adam Roach [mailto:adam@nostrum.com] > >>> Sent: Wednesday, March 07, 2012 11:54 AM > >>> To: Glen Lavers (glavers) > >>> Cc: Cullen Jennings; dispatch@ietf.org > >>> Subject: Re: [dispatch] > draft-lavers-sipcore-immersive-capability-00.txt > >>> > >>> On 3/7/12 12:30 PM, Glen Lavers (glavers) wrote: > >>>> The use cases are for business and policy distinctions. There are > >>>> valid policy decisions that implementers would like to make to > >>>> differentiate a video experience from an immersive experience such > >>>> that an immersive experience is a video experience but not the other > way > >>> around. > >>> > >>> You're positing that network operators will be willing to make > business and > >>> policy decisions based on the nearly arbitrary, subjective opinions o= f > >>> implementors? I think that's a bit na=EFve. > >>> > >>> /a > >> _______________________________________________ > >> 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 > --f46d042ef7a96be30404bad2f219 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Glen,

The intent seems to be to indicate that the flow w= ill be massive, whether it is immersive or not.

Co= uld you not also have something, say a brain-machine interface that is remo= te, but not video,
that could also use a lot of BW? =A0An potentially still immersive.

If this all boils down to BW, then why not just ask = for a BW indicator that lets SP's to make policy decisions accordingly.=
You could then take this indicator and make it a vector with a value.<= /div>

Mike



On Fri, Mar 9, 2012 at 12:17 PM, Glen Lavers <glavers@cisco.com> wrote:
Hi Paul,
Comments inline


On 3/7/12 1:06 PM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:

> Glen,
>
> I'm still not understanding your use cases.
>
> Is your intent to *register* endpoints with the feature tag, and then<= br> > use callerprefs so that calls prefer (or require) callees that have > registered the tag?
>
> Or is your intent to pass the tag (on a Contact header) during call > establishment and use the value to decide whether to accept the call, = or
> condition behavior after the call is established?
My example below was to pass the tag in a contact header during call
establishment and use the value for a B2BUA or SBC to determine how to use<= br> it. In the draft we provided a few examples that might be useful but I coul= d
imagine others. What I do see is for the ability for enterprise call
management systems that interoperate like B2BUA's or SBCs to use this h= eader
to drive routing decisions or effectuate admission control prior to SDP
offer (the 2 examples in the draft)

>
> Either way, it isn't going to work right if everybody doesn't = have some
> level of common understanding of what this means. If I'm sitting i= n a
> telepresence room and calling you, I will be wanting to reach a
> telepresence system, and probably won't be satisfied if I reach yo= ur
> game machine. (And what if you have both?)
Do you know of any systems that route calls for both gaming and telepresenc= e
like endpoints? In any case I see this feature tag as more applicable to vendors of telepresence like systems. If the gaming systems wanted to
leverage it then I guess they could. I guess you could imagine having a
gaming system that could do both telepresence conferencing AND immersive gaming but if they did then I would see using another feature tag as a
further qualifier, perhaps sip.application.

I agree that a common understanding of what immersive means is critical. I<= br> don't think however that it needs to be restrictive or extremely specif= ic.
It's clear that many on this list are confused by our attempt at a broa= d
definition of telepresence like immersive video. We can try and articulate<= br> this in terms of more specific adjectives however as many have mentioned there will most always be a level of subjectivity unless we add clear
technical delineations which I'm extremely apprehensive about doing. Wh= at is
critical is that the network operator managing these systems is able to
control what uses the tag.

Video is clearly a very broad tag that is both useful and fits all types of=
video. What we want here is a delineation of video and we would like that delineation to be managed by the network operator and really used at their<= br> discretion. Where they are able to decide where the line between video and<= br> immersive video lies in the solution that they manage.

>
> Also, AFAIK virtually nothing currently supports callerprefs
> (Accept-Contact/Reject-Contact), except 3gpp. But I'll be pleased = to
> hear I am wrong about that.
>
> And even if some do, Accept-Contact won't be very useful unless yo= u have
> multiple systems with different capabilities registered to the same AO= R.
> (Reject-Contact might be useful to cause calls to fail unless you reac= h
> a device with the desired capabilities.)
>
> Can you spell out the use case(s) you have in mind for this in
> significantly more detail? (Describe the capabilities and desires of t= he
> caller, the characteristics and behaviors of the potential callees, an= d
> the expected outcome in both positive and negative cases.) Also, how t= he
> UAs come to know what capabilities to register and to prefer - are tho= se
> compiled into the code by the code developer, or are they configured i= n
> by the deployer?
I see endpoint vendors coding it into their endpoints and allowing it to be=
enabled/disabled. I also see call management systems using it between one another.

An example of admission control: 2 telepresence like vendor systems that manage Enterprise calls for both video systems and telepresence like
systems. Prior to ringing an endpoint it is often difficult to determine th= e
type of call that is being established. Therefore sending an invite with a<= br> contact header that stipulates video for example is useful, especially in cases where delayed offer is used. This allows the receiving system to make=
some decisions. In this example the decision is for admission control. Call=
management systems tend to set an upper limit on how much bandwidth any
given call from one endpoint to another can use. So knowing that the call i= s
video prior to getting an offer is useful to validate that the bandwidth is=
allocated for a potential video call prior to ringing the device. The same<= br> is true for fixed telepresence-like systems which tend to use higher
bandwidth limits than generic desktop video. So if an endpoint or a call management system can use this contact header with immersive it allows the<= br> receiving system to know that the intent of the call is telepresence like and can associate the correct bandwidth limits and deductions from the
appropriate bandwidth allocations.

As I mentioned it could be useful for any of those 2 systems to know at
invite what type of call they are receiving. That the intent of the call is=
for an immersive telepresence like experience if available by the called party. The calling system could send the invite with a contact header
showing not only immersive but other features as well like audio, video as<= br> the possibilities of the type of call that's possible: Contact:
<sip:bob@example.com;transp= ort=3Dtcp>;immersive;video;audio
The receiving system could make any number of assumptions using that
information. If it's doing admission control it could instantiate the i= nvite
at ring as an immersive call deducting from an allocation of bandwidth
reserved for immersive style systems. If that fails it could then try video=
or audio-only. If only an immersive tag was available then maybe it would only try the immersive bandwidth allocation and if that failed it would
simply fail the call. If the called system has bandwidth for the call the i= t
in-turn signals the call on to the terminating endpoint or UA.

I'll say here that I think that it's very important that the networ= k
operator control the manner in which the tag is used. Therefore it should b= e
controllable by the network operator. Meaning they should be able to enable=
or disable the use of the header on a specific endpoint or determine how it's used in calls from call management system to system.

I can also see a use case in a similar scenario for SBCs where the SBC can<= br> use the information to determine directionality. If a user "owns"= a number
of devices that have varying levels of capabilities. Let's say that Bob= owns
a telepresence like system fixed in a room. He also has 2 other devices. A<= br> desktop phone with standard video and a mobile device to receive audio only=
calls. If the way to reach any of these devices is the same, meaning that Bob's number or URI is exactly the same it could be useful for a networ= k
operator to be able to use things like this media feature tag and the base<= br> tags in order to direct the call to specific devices. So when a call comes<= br> from another telepresence like system to Bob only Bob's telepresence endpoint rings for example. If a call comes with a video and audio tag for<= br> example the call could be routed to all devices. The network operator could=
leverage the tag to achieve the requirements of the use cases.

I can imagine other use cases where the called system could also use the indication to validate the call against a scheduling system specifically fo= r
immersive calls.

I find that these tags can be useful in a number of scenarios for
interoperation between call management system simply by allowing the use of=
the tags.


>
> Thanks,
> Paul
>
> On 3/7/12 3:27 PM, Glen Lavers (glavers) wrote:
>> Sorry I'm using implementer in 2 contexts. What I mean by impl= ementer is
>> network operator, or someone deploying products or systems that us= e this
>> feature tag. A vendor would add it to their product and provide wa= ys to
>> enable/disable/filter depending on product and usage.
>>
>> If I'm an implementer who has purchased 2 different vendor pro= ducts that
>> allow for the immersive feature tag. As an implementer I can decid= e to use
>> the tag or not based on what I know of the products and what I wan= t as a
>> policy decision. If I choose to use it I would know the capabiliti= es of the 2
>> vendor products and decide for myself if they fit the criteria for= this
>> differentiation that I as an implementer/network operator am after= . If they
>> do then I can leverage that to make policy decisions, in my networ= k, in call
>> control, wherever or I turn them off or filter them based on the p= roducts
>> themselves.
>>
>> A vendor adding this media feature tag to their product would hope= fully leave
>> it to the implementer to decide when and how to use it for policy.=
>>
>> Does that better clarify my statements?
>> -glen
>>
>>> -----Original Message-----
>>> From: Adam Roach [mailto:a= dam@nostrum.com]
>>> Sent: Wednesday, March 07, 2012 11:54 AM
>>> To: Glen Lavers (glavers)
>>> Cc: Cullen Jennings; disp= atch@ietf.org
>>> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capabil= ity-00.txt
>>>
>>> On 3/7/12 12:30 PM, Glen Lavers (glavers) wrote:
>>>> The use cases are for business and policy distinctions. Th= ere are
>>>> valid policy decisions that implementers would like to mak= e to
>>>> differentiate a video experience from an immersive experie= nce such
>>>> that an immersive experience is a video experience but not= the other way
>>> around.
>>>
>>> You're positing that network operators will be willing to = make business and
>>> policy decisions based on the nearly arbitrary, subjective opi= nions of
>>> implementors? I think that's a bit na=EFve.
>>>
>>> /a
>> _______________________________________________
>> 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

--f46d042ef7a96be30404bad2f219-- From glavers@cisco.com Fri Mar 9 10:32:10 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16D21E804B for ; Fri, 9 Mar 2012 10:32:10 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fenIr6mPg+1r for ; Fri, 9 Mar 2012 10:32:09 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 74B7221F8712 for ; Fri, 9 Mar 2012 10:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=glavers@cisco.com; l=11184; q=dns/txt; s=iport; t=1331317929; x=1332527529; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=F/uUD93s3inSuyurdcjoZk1xDptslgsVOxOSRAU5s4Q=; b=aNEVEz5fhQNlZa82WS1UFNjT8HCyT9REXIcTC98YF1hZvkEyCW7+W3hG L7CsZQ1EPMWxjX1k65xGPt20DzWAk59ExWyWSQNApVgTsi55iadazAOmu 9t+KsspZFTO6pAJ0M0ovJMeExsPwvgGy14LLVgNGGKUXb+kmhU5EQiCZM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL5LWk+rRDoH/2dsb2JhbABCDrUygQeCCgEBAQMBAQEBDwEpATEQBwYBCA4DBAEBAScuHwkIAQEEARIbB4djBAELn3gBlxcEiiiGUASIIDOMdpAcgixYgTQBFw X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208";a="35276361" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 09 Mar 2012 18:32:09 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q29IW7Zn028005; Fri, 9 Mar 2012 18:32:08 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 10:32:07 -0800 Received: from 10.19.88.26 ([10.19.88.26]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) via Exchange Front-End Server email.cisco.com ([128.107.191.32]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Mar 2012 18:32:07 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 09 Mar 2012 10:32:04 -0800 From: Glen Lavers To: Paul Kyzivat , "dispatch@ietf.org" Message-ID: Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz+GIuAluAkJFst6ECB5pHojiBr2QACmEs4 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Mar 2012 18:32:07.0885 (UTC) FILETIME=[EEFDB7D0:01CCFE22] Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 18:32:10 -0000 Paul, As one of the authors of 3840 do you know of implementations that make use of 3840? And how they are using it? It would be good to know anecdotally your intended use cases and how it was actually used. -glen On 3/9/12 9:17 AM, "Glen Lavers" wrote: > Hi Paul, > Comments inline >=20 >=20 > On 3/7/12 1:06 PM, "Paul Kyzivat" wrote: >=20 >> Glen, >>=20 >> I'm still not understanding your use cases. >>=20 >> Is your intent to *register* endpoints with the feature tag, and then >> use callerprefs so that calls prefer (or require) callees that have >> registered the tag? >>=20 >> Or is your intent to pass the tag (on a Contact header) during call >> establishment and use the value to decide whether to accept the call, or >> condition behavior after the call is established? > My example below was to pass the tag in a contact header during call > establishment and use the value for a B2BUA or SBC to determine how to us= e it. > In the draft we provided a few examples that might be useful but I could > imagine others. What I do see is for the ability for enterprise call > management systems that interoperate like B2BUA's or SBCs to use this hea= der > to drive routing decisions or effectuate admission control prior to SDP o= ffer > (the 2 examples in the draft) >=20 >>=20 >> Either way, it isn't going to work right if everybody doesn't have some >> level of common understanding of what this means. If I'm sitting in a >> telepresence room and calling you, I will be wanting to reach a >> telepresence system, and probably won't be satisfied if I reach your >> game machine. (And what if you have both?) > Do you know of any systems that route calls for both gaming and teleprese= nce > like endpoints? In any case I see this feature tag as more applicable to > vendors of telepresence like systems. If the gaming systems wanted to lev= erage > it then I guess they could. I guess you could imagine having a gaming sys= tem > that could do both telepresence conferencing AND immersive gaming but if = they > did then I would see using another feature tag as a further qualifier, pe= rhaps > sip.application.=20 >=20 > I agree that a common understanding of what immersive means is critical. = I > don't think however that it needs to be restrictive or extremely specific= . > It's clear that many on this list are confused by our attempt at a broad > definition of telepresence like immersive video. We can try and articulat= e > this in terms of more specific adjectives however as many have mentioned = there > will most always be a level of subjectivity unless we add clear technical > delineations which I'm extremely apprehensive about doing. What is critic= al is > that the network operator managing these systems is able to control what = uses > the tag.=20 >=20 > Video is clearly a very broad tag that is both useful and fits all types = of > video. What we want here is a delineation of video and we would like that > delineation to be managed by the network operator and really used at thei= r > discretion. Where they are able to decide where the line between video an= d > immersive video lies in the solution that they manage. >=20 >>=20 >> Also, AFAIK virtually nothing currently supports callerprefs >> (Accept-Contact/Reject-Contact), except 3gpp. But I'll be pleased to >> hear I am wrong about that. >>=20 >> And even if some do, Accept-Contact won't be very useful unless you have >> multiple systems with different capabilities registered to the same AOR. >> (Reject-Contact might be useful to cause calls to fail unless you reach >> a device with the desired capabilities.) >>=20 >> Can you spell out the use case(s) you have in mind for this in >> significantly more detail? (Describe the capabilities and desires of the >> caller, the characteristics and behaviors of the potential callees, and >> the expected outcome in both positive and negative cases.) Also, how the >> UAs come to know what capabilities to register and to prefer - are those >> compiled into the code by the code developer, or are they configured in >> by the deployer? > I see endpoint vendors coding it into their endpoints and allowing it to = be > enabled/disabled. I also see call management systems using it between one > another.=20 > =20 > An example of admission control: 2 telepresence like vendor systems that > manage Enterprise calls for both video systems and telepresence like syst= ems. > Prior to ringing an endpoint it is often difficult to determine the type = of > call that is being established. Therefore sending an invite with a contac= t > header that stipulates video for example is useful, especially in cases w= here > delayed offer is used. This allows the receiving system to make some > decisions. In this example the decision is for admission control. Call > management systems tend to set an upper limit on how much bandwidth any g= iven > call from one endpoint to another can use. So knowing that the call is vi= deo > prior to getting an offer is useful to validate that the bandwidth is > allocated for a potential video call prior to ringing the device. The sam= e is > true for fixed telepresence-like systems which tend to use higher bandwid= th > limits than generic desktop video. So if an endpoint or a call management > system can use this contact header with immersive it allows the receiving > system to know that the intent of the call is telepresence like and can > associate the correct bandwidth limits and deductions from the appropriat= e > bandwidth allocations. >=20 > As I mentioned it could be useful for any of those 2 systems to know at i= nvite > what type of call they are receiving. That the intent of the call is for = an > immersive telepresence like experience if available by the called party. = The > calling system could send the invite with a contact header showing not on= ly > immersive but other features as well like audio, video as the possibiliti= es of > the type of call that's possible: Contact: > ;immersive;video;audio > The receiving system could make any number of assumptions using that > information. If it's doing admission control it could instantiate the inv= ite > at ring as an immersive call deducting from an allocation of bandwidth > reserved for immersive style systems. If that fails it could then try vid= eo or > audio-only. If only an immersive tag was available then maybe it would on= ly > try the immersive bandwidth allocation and if that failed it would simply= fail > the call. If the called system has bandwidth for the call the it in-turn > signals the call on to the terminating endpoint or UA. >=20 > I'll say here that I think that it's very important that the network oper= ator > control the manner in which the tag is used. Therefore it should be > controllable by the network operator. Meaning they should be able to enab= le or > disable the use of the header on a specific endpoint or determine how it'= s > used in calls from call management system to system. >=20 > I can also see a use case in a similar scenario for SBCs where the SBC ca= n use > the information to determine directionality. If a user "owns" a number of > devices that have varying levels of capabilities. Let's say that Bob owns= a > telepresence like system fixed in a room. He also has 2 other devices. A > desktop phone with standard video and a mobile device to receive audio on= ly > calls. If the way to reach any of these devices is the same, meaning that > Bob's number or URI is exactly the same it could be useful for a network > operator to be able to use things like this media feature tag and the bas= e > tags in order to direct the call to specific devices. So when a call come= s > from another telepresence like system to Bob only Bob's telepresence endp= oint > rings for example. If a call comes with a video and audio tag for example= the > call could be routed to all devices. The network operator could leverage = the > tag to achieve the requirements of the use cases. >=20 > I can imagine other use cases where the called system could also use the > indication to validate the call against a scheduling system specifically = for > immersive calls.=20 >=20 > I find that these tags can be useful in a number of scenarios for > interoperation between call management system simply by allowing the use = of > the tags.=20 > =20 >=20 >>=20 >> Thanks, >> Paul >>=20 >> On 3/7/12 3:27 PM, Glen Lavers (glavers) wrote: >>> Sorry I'm using implementer in 2 contexts. What I mean by implementer i= s >>> network operator, or someone deploying products or systems that use thi= s >>> feature tag. A vendor would add it to their product and provide ways to >>> enable/disable/filter depending on product and usage. >>>=20 >>> If I'm an implementer who has purchased 2 different vendor products tha= t >>> allow for the immersive feature tag. As an implementer I can decide to = use >>> the tag or not based on what I know of the products and what I want as = a >>> policy decision. If I choose to use it I would know the capabilities of= the >>> 2=20 >>> vendor products and decide for myself if they fit the criteria for this >>> differentiation that I as an implementer/network operator am after. If = they >>> do then I can leverage that to make policy decisions, in my network, in= call >>> control, wherever or I turn them off or filter them based on the produc= ts >>> themselves. >>>=20 >>> A vendor adding this media feature tag to their product would hopefully >>> leave=20 >>> it to the implementer to decide when and how to use it for policy. >>>=20 >>> Does that better clarify my statements? >>> -glen >>>=20 >>>> -----Original Message----- >>>> From: Adam Roach [mailto:adam@nostrum.com] >>>> Sent: Wednesday, March 07, 2012 11:54 AM >>>> To: Glen Lavers (glavers) >>>> Cc: Cullen Jennings; dispatch@ietf.org >>>> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.t= xt >>>>=20 >>>> On 3/7/12 12:30 PM, Glen Lavers (glavers) wrote: >>>>> The use cases are for business and policy distinctions. There are >>>>> valid policy decisions that implementers would like to make to >>>>> differentiate a video experience from an immersive experience such >>>>> that an immersive experience is a video experience but not the other = way >>>> around. >>>>=20 >>>> You're positing that network operators will be willing to make busines= s and >>>> policy decisions based on the nearly arbitrary, subjective opinions of >>>> implementors? I think that's a bit na=EFve. >>>>=20 >>>> /a >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From glavers@cisco.com Fri Mar 9 11:17:32 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB0121E808D for ; Fri, 9 Mar 2012 11:17:32 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEz9Et+daelm for ; Fri, 9 Mar 2012 11:17:31 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E4B9421E807B for ; Fri, 9 Mar 2012 11:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=glavers@cisco.com; l=6155; q=dns/txt; s=iport; t=1331320646; x=1332530246; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=Lonec/2Shd2f4qAA6IaVgtoQ0/Q4zwFEi57tTSYk8Jw=; b=m/SrFMatc5zrzBK89aKYxCRpslr15wn081OwnBtJGXd4lU1/rOtpb9zP YJ4q0IhdG/gs1+IKsSlQ0rqI+Hshkigob2E2KFGpdPznNqN2aWG6nI0b1 2i0JZjaCMlRixQvMtc5R4KeuAsHW0yZImiooXNacPHWUIF4vhXM1CC6d/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABlWWk+rRDoI/2dsb2JhbABDtTKBB4IKAQEBAwESAScCAS4BAwcIDQEIEn0OAQEEARIZCYdjBAGcEgGed5B4BIhTjHaQHIME X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208";a="35415111" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 09 Mar 2012 19:17:25 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q29JHPrR005243; Fri, 9 Mar 2012 19:17:25 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 11:17:25 -0800 Received: from 10.19.88.26 ([10.19.88.26]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) via Exchange Front-End Server email.cisco.com ([128.107.191.87]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Mar 2012 19:17:25 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 09 Mar 2012 11:17:23 -0800 From: Glen Lavers To: "Worley, Dale R (Dale)" , "dispatch@ietf.org" Message-ID: Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz8nAFHSEaV3+2cR2mUq6VJORgEKQAALfaAAC+ujGMAM3OBkQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Mar 2012 19:17:25.0479 (UTC) FILETIME=[42CDA770:01CCFE29] Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 19:17:32 -0000 Hi Dale, inline On 3/8/12 10:44 AM, "Worley, Dale R (Dale)" wrote: > I'm no expert in this, but the following comments come to mind. (Not > in priority order.) > > The definition of "immersive" (which seems to be synonymous with > "telepresence") is not exact. That doesn't mean that the term isn't > useful, but it is a warning that there may be no *technological* > distinction. This is why I do not think that this is much of a problem, specifically if it's the network operator who should have control of when and how to use the tag. > > In regard to admission control, I expect that in both architecture and > practice, networks will want to base admission distinctions on more > detailed information than "immersive". But maybe I'm wrong; I think > networks have explicitly excluded all "video" media as an admission > policy. So perhaps a network would refuse admission to any > "immersive" video but allow non-immersive video, in order to conserve > bandwidth. I think what would be more useful is simply an indication of call type that allows the network administrator to associate the call to a BW pool dedicated for these call types. Today most implementations have 2 pools audio and video. For a video call most implementations deduct both audio and video and mark them the same (QoS). For audio only the call is deducted out of an audio pool and marked differently from video. As video requirements are raised networks are more and more challenged to admit and provide preferential treatment of types of video becomes more important. Allow immersive calls up to W and other video up to X. Direct immersive calls to Y system and other video to Z system for example. > > Please, please, please do not use the word "leverage" to mean "utilize > (to gain a further advantage)". That word makes it sound like contact > with marketing people has damaged your brain. It's a good word that's been overused for sure. I guess "use to control" would be better ;-) > > In regard to routing decisions, a feature tag is useful if *some* > calls *prefer* the feature and also *some* calls *reject* > (anti-prefer) the feature. Unless this criterion is true, the > callee's local network (or the callee's behavior) can obtain all > possible benefit by statically prioritizing the alternative UAs. Well to be more exacting it's not the calls that "prefer" but the network operator that creates a policy of treatment based on user or admin requirements. Immersive, video and audio just become variables that the operator has at their disposal to make policy decisions. After all configuration of a system is policy. Without those attributes there's no other way to make those policy decisions unless you have SDP and even then it's not clear. Dial-plan is one way but if you are doing URI or number dialing a single number or URI can be associated to a number of endpoints of varying capabilities. > > There are two examples in the draft, but neither is an example of > either stated motivation. The examples and the motivations should not > be conceptually disjoint. > > As Paul notes, the tag would be expressed as "+sip.immersive". Thanks, we'll change it. > > A motivation which seems plausible to me is that a video UA would want > to know if the *other* video UA was operating in an immersive manner > or not, or whether it was capable of doing so, so as to adjust its > behavior. E.g., if an immersive system is communicating with an > "ordinary" system, it might want to (effectively) crop its transmitted > video signal from "immersive surrounding" to "viewing screen" > dimensions. I agree that could be useful. Today telepresence for example does this with TIP (telepresence interoperability protocol). TIP however is established endpoint to endpoint and not through the call management system and also is established after the call has been answered so pre-ring there is really no other informative manner to know that the call is telepresence. I'm using telepresence as an example because it was brought up in the beginning but this could be any telepresence like system that attempts to recreate an in-person like audio and video experience. Are there other mechanisms that exist on an invite that declare such capability that are standards based? I don't know of any. > > The previous paragraph suggests that the set of existing video > conferencing systems might be bimodal, that is, they might fall into > two distinct classes: small-screen systems that people look at like > televisions, and large-screen systems that surround the viewers, with > no systems of intermediate size. If that is actually true (and it > might have become true in the market without people explicitly > planning or noticing it), it should be documented, and might be a > justification for labeling videoconferencing systems with a binary > "immersive" attribute. I tend to agree with your statement about these bi-modal systems. This is what I'm seeing in the Enterprise as many move to varying sizes of video resolution up to something that will support viewing a person in life-size. Management of these systems tend to be differentiated at that point, "tend" being the key word and my perception of things. I see a lot of enterprises standardizing on video bit rate for example where you'd see desktop video at X rate and room-based systems at y rate. And that might be it for a lot of Enterprises. Some have a dizzying array of endpoints with varying capabilities but again attempts are made at managing and standardizing the bit rate across a range of endpoints. Telepresence like systems have their requirements and tend to set apart and are also in minority when it comes to systems deployed. > > I suspect that there are important aspects of this subject that the > authors know (at least intuitively) but have not documented, and a > revision of the draft might be very informative. > > In any case, it seems to me that this draft falls squarely within the > remit of CLUE. > > Dale From glavers@cisco.com Fri Mar 9 11:22:42 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D20721E8088 for ; Fri, 9 Mar 2012 11:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.835 X-Spam-Level: X-Spam-Status: No, score=-9.835 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulDQjNp7JBJD for ; Fri, 9 Mar 2012 11:22:34 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D35F221E8080 for ; Fri, 9 Mar 2012 11:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=glavers@cisco.com; l=28292; q=dns/txt; s=iport; t=1331320955; x=1332530555; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=EVC4hkeDAp69VdqR/h3Bh60O3tNsRP+NddUewwnkDiw=; b=S8yp7ybExDMerMTdU3F1F3kABvgm5CpJiRX4NmUqyjsWKLVlAHRJO/SD 9mrpdHyQP8PX/JGnEZabXRo5FVNjowIi2w+0p/pId7NvfEHEDZu9MukoS 4eQsjuMtaVh2srCVkOJEuIAxXSgYogIVc3sYGwVowESXrxY4ASvqW9u9Z Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAClYWk+rRDoG/2dsb2JhbABCglKxeXSBB4IKAQEBAwEBAQEPAQcjMQsFBwYBCA4DBAEBAScoBh8JCAEBBA4FGweHYwQBC597AZcMBIk8bIZQBIggM4x2iySEeIMEgTMBAQUS X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208,217";a="32820908" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 09 Mar 2012 19:22:34 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q29JMX4E012711; Fri, 9 Mar 2012 19:22:33 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 11:22:33 -0800 Received: from 10.19.88.26 ([10.19.88.26]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Mar 2012 19:22:33 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 09 Mar 2012 11:22:30 -0800 From: Glen Lavers To: Michael Hammer Message-ID: Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz+KfhPNUKLByOfV0WFJzX0541lsg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3414136951_16952590" X-OriginalArrivalTime: 09 Mar 2012 19:22:33.0760 (UTC) FILETIME=[FA8D9A00:01CCFE29] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 19:22:42 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3414136951_16952590 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable BW is just one use case. As I mentioned scheduling and call routing could b= e others. BW indicator alone is not a good differentiator. A desktop device with a good camera could effectively have the same BW requirements for vide= o as a telepresence like system. A differentiator could be something like QoS marking and BW pool (CAC). So a BW indicator alone doesn=B9t bring this differentiation. Also what is useful are also all of the other attributes like audio, video, application. So why go an recreate another mechanism for all other attributes when it makes enough sense (to me anyway) to simply extend 3840 with this feature tag? Although I think other uses could be made for a BW indicator. At least for systems that =B3know=B2 what their max yet do not send early offer on invite. -glen On 3/9/12 9:44 AM, "Michael Hammer" wrote: > Glen, >=20 > The intent seems to be to indicate that the flow will be massive, whether= it > is immersive or not. >=20 > Could you not also have something, say a brain-machine interface that is > remote, but not video, > that could also use a lot of BW? =A0An potentially still immersive. >=20 > If this all boils down to BW, then why not just ask for a BW indicator th= at > lets SP's to make policy decisions accordingly. > You could then take this indicator and make it a vector with a value. >=20 > Mike >=20 >=20 >=20 > On Fri, Mar 9, 2012 at 12:17 PM, Glen Lavers wrote: >> Hi Paul, >> Comments inline >>=20 >>=20 >> On 3/7/12 1:06 PM, "Paul Kyzivat" wrote: >>=20 >>> > Glen, >>> > >>> > I'm still not understanding your use cases. >>> > >>> > Is your intent to *register* endpoints with the feature tag, and then >>> > use callerprefs so that calls prefer (or require) callees that have >>> > registered the tag? >>> > >>> > Or is your intent to pass the tag (on a Contact header) during call >>> > establishment and use the value to decide whether to accept the call,= or >>> > condition behavior after the call is established? >> My example below was to pass the tag in a contact header during call >> establishment and use the value for a B2BUA or SBC to determine how to u= se >> it. In the draft we provided a few examples that might be useful but I c= ould >> imagine others. What I do see is for the ability for enterprise call >> management systems that interoperate like B2BUA's or SBCs to use this he= ader >> to drive routing decisions or effectuate admission control prior to SDP >> offer (the 2 examples in the draft) >>=20 >>> > >>> > Either way, it isn't going to work right if everybody doesn't have so= me >>> > level of common understanding of what this means. If I'm sitting in a >>> > telepresence room and calling you, I will be wanting to reach a >>> > telepresence system, and probably won't be satisfied if I reach your >>> > game machine. (And what if you have both?) >> Do you know of any systems that route calls for both gaming and telepres= ence >> like endpoints? In any case I see this feature tag as more applicable to >> vendors of telepresence like systems. If the gaming systems wanted to >> leverage it then I guess they could. I guess you could imagine having a >> gaming system that could do both telepresence conferencing AND immersive >> gaming but if they did then I would see using another feature tag as a >> further qualifier, perhaps sip.application. >>=20 >> I agree that a common understanding of what immersive means is critical.= I >> don't think however that it needs to be restrictive or extremely specifi= c. >> It's clear that many on this list are confused by our attempt at a broad >> definition of telepresence like immersive video. We can try and articula= te >> this in terms of more specific adjectives however as many have mentioned >> there will most always be a level of subjectivity unless we add clear >> technical delineations which I'm extremely apprehensive about doing. Wha= t is >> critical is that the network operator managing these systems is able to >> control what uses the tag. >>=20 >> Video is clearly a very broad tag that is both useful and fits all types= of >> video. What we want here is a delineation of video and we would like tha= t >> delineation to be managed by the network operator and really used at the= ir >> discretion. Where they are able to decide where the line between video a= nd >> immersive video lies in the solution that they manage. >>=20 >>> > >>> > Also, AFAIK virtually nothing currently supports callerprefs >>> > (Accept-Contact/Reject-Contact), except 3gpp. But I'll be pleased to >>> > hear I am wrong about that. >>> > >>> > And even if some do, Accept-Contact won't be very useful unless you h= ave >>> > multiple systems with different capabilities registered to the same A= OR. >>> > (Reject-Contact might be useful to cause calls to fail unless you rea= ch >>> > a device with the desired capabilities.) >>> > >>> > Can you spell out the use case(s) you have in mind for this in >>> > significantly more detail? (Describe the capabilities and desires of = the >>> > caller, the characteristics and behaviors of the potential callees, a= nd >>> > the expected outcome in both positive and negative cases.) Also, how = the >>> > UAs come to know what capabilities to register and to prefer - are th= ose >>> > compiled into the code by the code developer, or are they configured = in >>> > by the deployer? >> I see endpoint vendors coding it into their endpoints and allowing it to= be >> enabled/disabled. I also see call management systems using it between on= e >> another. >>=20 >> An example of admission control: 2 telepresence like vendor systems that >> manage Enterprise calls for both video systems and telepresence like >> systems. Prior to ringing an endpoint it is often difficult to determine= the >> type of call that is being established. Therefore sending an invite with= a >> contact header that stipulates video for example is useful, especially i= n >> cases where delayed offer is used. This allows the receiving system to m= ake >> some decisions. In this example the decision is for admission control. C= all >> management systems tend to set an upper limit on how much bandwidth any >> given call from one endpoint to another can use. So knowing that the cal= l is >> video prior to getting an offer is useful to validate that the bandwidth= is >> allocated for a potential video call prior to ringing the device. The sa= me >> is true for fixed telepresence-like systems which tend to use higher >> bandwidth limits than generic desktop video. So if an endpoint or a call >> management system can use this contact header with immersive it allows t= he >> receiving system to know that the intent of the call is telepresence lik= e >> and can associate the correct bandwidth limits and deductions from the >> appropriate bandwidth allocations. >>=20 >> As I mentioned it could be useful for any of those 2 systems to know at >> invite what type of call they are receiving. That the intent of the call= is >> for an immersive telepresence like experience if available by the called >> party. The calling system could send the invite with a contact header >> showing not only immersive but other features as well like audio, video = as >> the possibilities of the type of call that's possible: Contact: >> >> ;transport=3Dtcp>;immersive;video;audio >> The receiving system could make any number of assumptions using that >> information. If it's doing admission control it could instantiate the in= vite >> at ring as an immersive call deducting from an allocation of bandwidth >> reserved for immersive style systems. If that fails it could then try vi= deo >> or audio-only. If only an immersive tag was available then maybe it woul= d >> only try the immersive bandwidth allocation and if that failed it would >> simply fail the call. If the called system has bandwidth for the call th= e it >> in-turn signals the call on to the terminating endpoint or UA. >>=20 >> I'll say here that I think that it's very important that the network >> operator control the manner in which the tag is used. Therefore it shoul= d be >> controllable by the network operator. Meaning they should be able to ena= ble >> or disable the use of the header on a specific endpoint or determine how >> it's used in calls from call management system to system. >>=20 >> I can also see a use case in a similar scenario for SBCs where the SBC c= an >> use the information to determine directionality. If a user "owns" a numb= er >> of devices that have varying levels of capabilities. Let's say that Bob = owns >> a telepresence like system fixed in a room. He also has 2 other devices.= A >> desktop phone with standard video and a mobile device to receive audio o= nly >> calls. If the way to reach any of these devices is the same, meaning tha= t >> Bob's number or URI is exactly the same it could be useful for a network >> operator to be able to use things like this media feature tag and the ba= se >> tags in order to direct the call to specific devices. So when a call com= es >> from another telepresence like system to Bob only Bob's telepresence >> endpoint rings for example. If a call comes with a video and audio tag f= or >> example the call could be routed to all devices. The network operator co= uld >> leverage the tag to achieve the requirements of the use cases. >>=20 >> I can imagine other use cases where the called system could also use the >> indication to validate the call against a scheduling system specifically= for >> immersive calls. >>=20 >> I find that these tags can be useful in a number of scenarios for >> interoperation between call management system simply by allowing the use= of >> the tags. >>=20 >>=20 >>> > >>> > Thanks, >>> > Paul >>> > >>> > On 3/7/12 3:27 PM, Glen Lavers (glavers) wrote: >>>> >> Sorry I'm using implementer in 2 contexts. What I mean by implement= er is >>>> >> network operator, or someone deploying products or systems that use= this >>>> >> feature tag. A vendor would add it to their product and provide way= s to >>>> >> enable/disable/filter depending on product and usage. >>>> >> >>>> >> If I'm an implementer who has purchased 2 different vendor products= that >>>> >> allow for the immersive feature tag. As an implementer I can decide= to >>>> use >>>> >> the tag or not based on what I know of the products and what I want= as a >>>> >> policy decision. If I choose to use it I would know the capabilitie= s of >>>> the 2 >>>> >> vendor products and decide for myself if they fit the criteria for = this >>>> >> differentiation that I as an implementer/network operator am after.= If >>>> they >>>> >> do then I can leverage that to make policy decisions, in my network= , in >>>> call >>>> >> control, wherever or I turn them off or filter them based on the >>>> products >>>> >> themselves. >>>> >> >>>> >> A vendor adding this media feature tag to their product would hopef= ully >>>> leave >>>> >> it to the implementer to decide when and how to use it for policy. >>>> >> >>>> >> Does that better clarify my statements? >>>> >> -glen >>>> >> >>>>> >>> -----Original Message----- >>>>> >>> From: Adam Roach [mailto:adam@nostrum.com] >>>>> >>> Sent: Wednesday, March 07, 2012 11:54 AM >>>>> >>> To: Glen Lavers (glavers) >>>>> >>> Cc: Cullen Jennings; dispatch@ietf.org >>>>> >>> Subject: Re: [dispatch] >>>>> draft-lavers-sipcore-immersive-capability-00.txt >>>>> >>> >>>>> >>> On 3/7/12 12:30 PM, Glen Lavers (glavers) wrote: >>>>>> >>>> The use cases are for business and policy distinctions. There a= re >>>>>> >>>> valid policy decisions that implementers would like to make to >>>>>> >>>> differentiate a video experience from an immersive experience s= uch >>>>>> >>>> that an immersive experience is a video experience but not the = other way >>>>> >>> around. >>>>> >>> >>>>> >>> You're positing that network operators will be willing to make >>>>> business and >>>>> >>> policy decisions based on the nearly arbitrary, subjective opinio= ns of >>>>> >>> implementors? I think that's a bit na=EFve. >>>>> >>> >>>>> >>> /a >>>> >> _______________________________________________ >>>> >> 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 >=20 --B_3414136951_16952590 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>BW is just one use case. As I mentioned scheduling and call routing could = be others. BW indicator alone is not a good differentiator. A desktop device= with a good camera could effectively have the same BW requirements for vide= o as a telepresence like system. A differentiator could be something like Qo= S marking and BW pool (CAC). So a BW indicator alone doesn’t bring thi= s differentiation. Also what is useful are also all of the other attributes = like audio, video, application. So why go an recreate another mechanism for = all other attributes when it makes enough sense (to me anyway) to simply ext= end 3840 with this feature tag?      <BR> <BR> Although I think other uses could be made for a BW indicator. At least for = systems that “know” what their max yet do not send early offer o= n invite. <BR> -glen<BR> <BR> <BR> On 3/9/12 9:44 AM, "Michael Hammer" <<a href=3D"mphmmr@gmail.com= ">mphmmr@gmail.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>Glen,<BR> <BR> The intent seems to be to indicate that the flow will be massive, whether i= t is immersive or not.<BR> <BR> Could you not also have something, say a brain-machine interface that is re= mote, but not video,<BR> that could also use a lot of BW? =A0An potentially still immersive.<BR> <BR> If this all boils down to BW, then why not just ask for a BW indicator that= lets SP's to make policy decisions accordingly.<BR> You could then take this indicator and make it a vector with a value.<BR> <BR> Mike<BR> <BR> <BR> <BR> On Fri, Mar 9, 2012 at 12:17 PM, Glen Lavers <<a href=3D"glavers@cisco.com= ">glavers@cisco.com</a>> wrote:<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>Hi Paul,<BR> Comments inline<BR> <BR> <BR> On 3/7/12 1:06 PM, "Paul Kyzivat" <<a href=3D"pkyzivat@alum.mit.= edu">pkyzivat@alum.mit.edu</a>> wrote:<BR> <BR> > Glen,<BR> ><BR> > I'm still not understanding your use cases.<BR> ><BR> > Is your intent to *register* endpoints with the feature tag, and then<= BR> > use callerprefs so that calls prefer (or require) callees that have<BR= > > registered the tag?<BR> ><BR> > Or is your intent to pass the tag (on a Contact header) during call<BR= > > establishment and use the value to decide whether to accept the call, = or<BR> > condition behavior after the call is established?<BR> My example below was to pass the tag in a contact header during call<BR> establishment and use the value for a B2BUA or SBC to determine how to use<= BR> it. In the draft we provided a few examples that might be useful but I coul= d<BR> imagine others. What I do see is for the ability for enterprise call<BR> management systems that interoperate like B2BUA's or SBCs to use this heade= r<BR> to drive routing decisions or effectuate admission control prior to SDP<BR> offer (the 2 examples in the draft)<BR> <BR> ><BR> > Either way, it isn't going to work right if everybody doesn't have som= e<BR> > level of common understanding of what this means. If I'm sitting in a<= BR> > telepresence room and calling you, I will be wanting to reach a<BR> > telepresence system, and probably won't be satisfied if I reach your<B= R> > game machine. (And what if you have both?)<BR> Do you know of any systems that route calls for both gaming and telepresenc= e<BR> like endpoints? In any case I see this feature tag as more applicable to<BR= > vendors of telepresence like systems. If the gaming systems wanted to<BR> leverage it then I guess they could. I guess you could imagine having a<BR> gaming system that could do both telepresence conferencing AND immersive<BR= > gaming but if they did then I would see using another feature tag as a<BR> further qualifier, perhaps sip.application.<BR> <BR> I agree that a common understanding of what immersive means is critical. I<= BR> don't think however that it needs to be restrictive or extremely specific.<= BR> It's clear that many on this list are confused by our attempt at a broad<BR= > definition of telepresence like immersive video. We can try and articulate<= BR> this in terms of more specific adjectives however as many have mentioned<BR= > there will most always be a level of subjectivity unless we add clear<BR> technical delineations which I'm extremely apprehensive about doing. What i= s<BR> critical is that the network operator managing these systems is able to<BR> control what uses the tag.<BR> <BR> Video is clearly a very broad tag that is both useful and fits all types of= <BR> video. What we want here is a delineation of video and we would like that<B= R> delineation to be managed by the network operator and really used at their<= BR> discretion. Where they are able to decide where the line between video and<= BR> immersive video lies in the solution that they manage.<BR> <BR> ><BR> > Also, AFAIK virtually nothing currently supports callerprefs<BR> > (Accept-Contact/Reject-Contact), except 3gpp. But I'll be pleased to<B= R> > hear I am wrong about that.<BR> ><BR> > And even if some do, Accept-Contact won't be very useful unless you ha= ve<BR> > multiple systems with different capabilities registered to the same AO= R.<BR> > (Reject-Contact might be useful to cause calls to fail unless you reac= h<BR> > a device with the desired capabilities.)<BR> ><BR> > Can you spell out the use case(s) you have in mind for this in<BR> > significantly more detail? (Describe the capabilities and desires of t= he<BR> > caller, the characteristics and behaviors of the potential callees, an= d<BR> > the expected outcome in both positive and negative cases.) Also, how t= he<BR> > UAs come to know what capabilities to register and to prefer - are tho= se<BR> > compiled into the code by the code developer, or are they configured i= n<BR> > by the deployer?<BR> I see endpoint vendors coding it into their endpoints and allowing it to be= <BR> enabled/disabled. I also see call management systems using it between one<B= R> another.<BR> <BR> An example of admission control: 2 telepresence like vendor systems that<BR= > manage Enterprise calls for both video systems and telepresence like<BR> systems. Prior to ringing an endpoint it is often difficult to determine th= e<BR> type of call that is being established. Therefore sending an invite with a<= BR> contact header that stipulates video for example is useful, especially in<B= R> cases where delayed offer is used. This allows the receiving system to make= <BR> some decisions. In this example the decision is for admission control. Call= <BR> management systems tend to set an upper limit on how much bandwidth any<BR> given call from one endpoint to another can use. So knowing that the call i= s<BR> video prior to getting an offer is useful to validate that the bandwidth is= <BR> allocated for a potential video call prior to ringing the device. The same<= BR> is true for fixed telepresence-like systems which tend to use higher<BR> bandwidth limits than generic desktop video. So if an endpoint or a call<BR= > management system can use this contact header with immersive it allows the<= BR> receiving system to know that the intent of the call is telepresence like<B= R> and can associate the correct bandwidth limits and deductions from the<BR> appropriate bandwidth allocations.<BR> <BR> As I mentioned it could be useful for any of those 2 systems to know at<BR> invite what type of call they are receiving. That the intent of the call is= <BR> for an immersive telepresence like experience if available by the called<BR= > party. The calling system could send the invite with a contact header<BR> showing not only immersive but other features as well like audio, video as<= BR> the possibilities of the type of call that's possible: Contact:<BR> <sip:<a href=3D"bob@example.com">bob@example.com</a> <<a href=3D"mailto:s= ip%3Abob@example.com">mailto:sip%3Abob@example.com</a>> ;transport=3Dtcp>= ;;immersive;video;audio<BR> The receiving system could make any number of assumptions using that<BR> information. If it's doing admission control it could instantiate the invit= e<BR> at ring as an immersive call deducting from an allocation of bandwidth<BR> reserved for immersive style systems. If that fails it could then try video= <BR> or audio-only. If only an immersive tag was available then maybe it would<B= R> only try the immersive bandwidth allocation and if that failed it would<BR> simply fail the call. If the called system has bandwidth for the call the i= t<BR> in-turn signals the call on to the terminating endpoint or UA.<BR> <BR> I'll say here that I think that it's very important that the network<BR> operator control the manner in which the tag is used. Therefore it should b= e<BR> controllable by the network operator. Meaning they should be able to enable= <BR> or disable the use of the header on a specific endpoint or determine how<BR= > it's used in calls from call management system to system.<BR> <BR> I can also see a use case in a similar scenario for SBCs where the SBC can<= BR> use the information to determine directionality. If a user "owns"= a number<BR> of devices that have varying levels of capabilities. Let's say that Bob own= s<BR> a telepresence like system fixed in a room. He also has 2 other devices. A<= BR> desktop phone with standard video and a mobile device to receive audio only= <BR> calls. If the way to reach any of these devices is the same, meaning that<B= R> Bob's number or URI is exactly the same it could be useful for a network<BR= > operator to be able to use things like this media feature tag and the base<= BR> tags in order to direct the call to specific devices. So when a call comes<= BR> from another telepresence like system to Bob only Bob's telepresence<BR> endpoint rings for example. If a call comes with a video and audio tag for<= BR> example the call could be routed to all devices. The network operator could= <BR> leverage the tag to achieve the requirements of the use cases.<BR> <BR> I can imagine other use cases where the called system could also use the<BR= > indication to validate the call against a scheduling system specifically fo= r<BR> immersive calls.<BR> <BR> I find that these tags can be useful in a number of scenarios for<BR> interoperation between call management system simply by allowing the use of= <BR> the tags.<BR> <BR> <BR> ><BR> > Thanks,<BR> > Paul<BR> ><BR> > On 3/7/12 3:27 PM, Glen Lavers (glavers) wrote:<BR> >> Sorry I'm using implementer in 2 contexts. What I mean by implemen= ter is<BR> >> network operator, or someone deploying products or systems that us= e this<BR> >> feature tag. A vendor would add it to their product and provide wa= ys to<BR> >> enable/disable/filter depending on product and usage.<BR> >><BR> >> If I'm an implementer who has purchased 2 different vendor product= s that<BR> >> allow for the immersive feature tag. As an implementer I can decid= e to use<BR> >> the tag or not based on what I know of the products and what I wan= t as a<BR> >> policy decision. If I choose to use it I would know the capabiliti= es of the 2<BR> >> vendor products and decide for myself if they fit the criteria for= this<BR> >> differentiation that I as an implementer/network operator am after= . If they<BR> >> do then I can leverage that to make policy decisions, in my networ= k, in call<BR> >> control, wherever or I turn them off or filter them based on the p= roducts<BR> >> themselves.<BR> >><BR> >> A vendor adding this media feature tag to their product would hope= fully leave<BR> >> it to the implementer to decide when and how to use it for policy.= <BR> >><BR> >> Does that better clarify my statements?<BR> >> -glen<BR> >><BR> >>> -----Original Message-----<BR> >>> From: Adam Roach [<a href=3D"mailto:adam@nostrum.com">mailto:ada= m@nostrum.com</a>]<BR> >>> Sent: Wednesday, March 07, 2012 11:54 AM<BR> >>> To: Glen Lavers (glavers)<BR> >>> Cc: Cullen Jennings; <a href=3D"dispatch@ietf.org">dispatch@ietf= .org</a><BR> >>> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capabil= ity-00.txt<BR> >>><BR> >>> On 3/7/12 12:30 PM, Glen Lavers (glavers) wrote:<BR> >>>> The use cases are for business and policy distinctions. Th= ere are<BR> >>>> valid policy decisions that implementers would like to mak= e to<BR> >>>> differentiate a video experience from an immersive experie= nce such<BR> >>>> that an immersive experience is a video experience but not= the other way<BR> >>> around.<BR> >>><BR> >>> You're positing that network operators will be willing to make= business and<BR> >>> policy decisions based on the nearly arbitrary, subjective opi= nions of<BR> >>> implementors? I think that's a bit naïve.<BR> >>><BR> >>> /a<BR> >> _______________________________________________<BR> >> dispatch mailing list<BR> >> <a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR> >> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://w= ww.ietf.org/mailman/listinfo/dispatch</a><BR> >><BR> ><BR> > _______________________________________________<BR> > dispatch mailing list<BR> > <a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR> > <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.i= etf.org/mailman/listinfo/dispatch</a><BR> <BR> _______________________________________________<BR> dispatch mailing list<BR> <a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.o= rg/mailman/listinfo/dispatch</a><BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN STYLE=3D'font-size:11pt'><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3414136951_16952590-- From pkyzivat@alum.mit.edu Fri Mar 9 12:47:28 2012 Return-Path: <pkyzivat@alum.mit.edu> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1215721E8044 for <dispatch@ietfa.amsl.com>; Fri, 9 Mar 2012 12:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jFfVBf77LxT for <dispatch@ietfa.amsl.com>; Fri, 9 Mar 2012 12:47:27 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id C2DAB21E80B0 for <dispatch@ietf.org>; Fri, 9 Mar 2012 12:47:26 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta15.westchester.pa.mail.comcast.net with comcast id jYBW1i0051wpRvQ5FYnTpF; Fri, 09 Mar 2012 20:47:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id jYnS1i00Q07duvL3eYnSJR; Fri, 09 Mar 2012 20:47:27 +0000 Message-ID: <4F5A6C5D.3030606@alum.mit.edu> Date: Fri, 09 Mar 2012 15:47:25 -0500 From: Paul Kyzivat <pkyzivat@alum.mit.edu> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Glen Lavers <glavers@cisco.com> References: <CB7F8CA4.1DB88%glavers@cisco.com> In-Reply-To: <CB7F8CA4.1DB88%glavers@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Mar 2012 20:47:28 -0000 On 3/9/12 1:32 PM, Glen Lavers wrote: > Paul, > As one of the authors of 3840 do you know of implementations that make use > of 3840? And how they are using it? It would be good to know anecdotally > your intended use cases and how it was actually used. I don't have any actual facts on this, only rumors and impressions. I don't think I have heard of any implementations of 3841 (the callerprefs part), though *maybe* IMS does. (If so it came in after the last time I looked at the IMS specs, which was several years ago.) People do seem to use 3840 in token ways, such as the infocus indicator, and IMS has some proprietary tokens that they use. But I would be more than pleased if people who know of actual uses piped up here and told us about them. Thanks, Paul > -glen > > > On 3/9/12 9:17 AM, "Glen Lavers"<glavers@cisco.com> wrote: > >> Hi Paul, >> Comments inline >> >> >> On 3/7/12 1:06 PM, "Paul Kyzivat"<pkyzivat@alum.mit.edu> wrote: >> >>> Glen, >>> >>> I'm still not understanding your use cases. >>> >>> Is your intent to *register* endpoints with the feature tag, and then >>> use callerprefs so that calls prefer (or require) callees that have >>> registered the tag? >>> >>> Or is your intent to pass the tag (on a Contact header) during call >>> establishment and use the value to decide whether to accept the call, or >>> condition behavior after the call is established? >> My example below was to pass the tag in a contact header during call >> establishment and use the value for a B2BUA or SBC to determine how to use it. >> In the draft we provided a few examples that might be useful but I could >> imagine others. What I do see is for the ability for enterprise call >> management systems that interoperate like B2BUA's or SBCs to use this header >> to drive routing decisions or effectuate admission control prior to SDP offer >> (the 2 examples in the draft) >> >>> >>> Either way, it isn't going to work right if everybody doesn't have some >>> level of common understanding of what this means. If I'm sitting in a >>> telepresence room and calling you, I will be wanting to reach a >>> telepresence system, and probably won't be satisfied if I reach your >>> game machine. (And what if you have both?) >> Do you know of any systems that route calls for both gaming and telepresence >> like endpoints? In any case I see this feature tag as more applicable to >> vendors of telepresence like systems. If the gaming systems wanted to leverage >> it then I guess they could. I guess you could imagine having a gaming system >> that could do both telepresence conferencing AND immersive gaming but if they >> did then I would see using another feature tag as a further qualifier, perhaps >> sip.application. >> >> I agree that a common understanding of what immersive means is critical. I >> don't think however that it needs to be restrictive or extremely specific. >> It's clear that many on this list are confused by our attempt at a broad >> definition of telepresence like immersive video. We can try and articulate >> this in terms of more specific adjectives however as many have mentioned there >> will most always be a level of subjectivity unless we add clear technical >> delineations which I'm extremely apprehensive about doing. What is critical is >> that the network operator managing these systems is able to control what uses >> the tag. >> >> Video is clearly a very broad tag that is both useful and fits all types of >> video. What we want here is a delineation of video and we would like that >> delineation to be managed by the network operator and really used at their >> discretion. Where they are able to decide where the line between video and >> immersive video lies in the solution that they manage. >> >>> >>> Also, AFAIK virtually nothing currently supports callerprefs >>> (Accept-Contact/Reject-Contact), except 3gpp. But I'll be pleased to >>> hear I am wrong about that. >>> >>> And even if some do, Accept-Contact won't be very useful unless you have >>> multiple systems with different capabilities registered to the same AOR. >>> (Reject-Contact might be useful to cause calls to fail unless you reach >>> a device with the desired capabilities.) >>> >>> Can you spell out the use case(s) you have in mind for this in >>> significantly more detail? (Describe the capabilities and desires of the >>> caller, the characteristics and behaviors of the potential callees, and >>> the expected outcome in both positive and negative cases.) Also, how the >>> UAs come to know what capabilities to register and to prefer - are those >>> compiled into the code by the code developer, or are they configured in >>> by the deployer? >> I see endpoint vendors coding it into their endpoints and allowing it to be >> enabled/disabled. I also see call management systems using it between one >> another. >> >> An example of admission control: 2 telepresence like vendor systems that >> manage Enterprise calls for both video systems and telepresence like systems. >> Prior to ringing an endpoint it is often difficult to determine the type of >> call that is being established. Therefore sending an invite with a contact >> header that stipulates video for example is useful, especially in cases where >> delayed offer is used. This allows the receiving system to make some >> decisions. In this example the decision is for admission control. Call >> management systems tend to set an upper limit on how much bandwidth any given >> call from one endpoint to another can use. So knowing that the call is video >> prior to getting an offer is useful to validate that the bandwidth is >> allocated for a potential video call prior to ringing the device. The same is >> true for fixed telepresence-like systems which tend to use higher bandwidth >> limits than generic desktop video. So if an endpoint or a call management >> system can use this contact header with immersive it allows the receiving >> system to know that the intent of the call is telepresence like and can >> associate the correct bandwidth limits and deductions from the appropriate >> bandwidth allocations. >> >> As I mentioned it could be useful for any of those 2 systems to know at invite >> what type of call they are receiving. That the intent of the call is for an >> immersive telepresence like experience if available by the called party. The >> calling system could send the invite with a contact header showing not only >> immersive but other features as well like audio, video as the possibilities of >> the type of call that's possible: Contact: >> <sip:bob@example.com;transport=tcp>;immersive;video;audio >> The receiving system could make any number of assumptions using that >> information. If it's doing admission control it could instantiate the invite >> at ring as an immersive call deducting from an allocation of bandwidth >> reserved for immersive style systems. If that fails it could then try video or >> audio-only. If only an immersive tag was available then maybe it would only >> try the immersive bandwidth allocation and if that failed it would simply fail >> the call. If the called system has bandwidth for the call the it in-turn >> signals the call on to the terminating endpoint or UA. >> >> I'll say here that I think that it's very important that the network operator >> control the manner in which the tag is used. Therefore it should be >> controllable by the network operator. Meaning they should be able to enable or >> disable the use of the header on a specific endpoint or determine how it's >> used in calls from call management system to system. >> >> I can also see a use case in a similar scenario for SBCs where the SBC can use >> the information to determine directionality. If a user "owns" a number of >> devices that have varying levels of capabilities. Let's say that Bob owns a >> telepresence like system fixed in a room. He also has 2 other devices. A >> desktop phone with standard video and a mobile device to receive audio only >> calls. If the way to reach any of these devices is the same, meaning that >> Bob's number or URI is exactly the same it could be useful for a network >> operator to be able to use things like this media feature tag and the base >> tags in order to direct the call to specific devices. So when a call comes >> from another telepresence like system to Bob only Bob's telepresence endpoint >> rings for example. If a call comes with a video and audio tag for example the >> call could be routed to all devices. The network operator could leverage the >> tag to achieve the requirements of the use cases. >> >> I can imagine other use cases where the called system could also use the >> indication to validate the call against a scheduling system specifically for >> immersive calls. >> >> I find that these tags can be useful in a number of scenarios for >> interoperation between call management system simply by allowing the use of >> the tags. >> >> >>> >>> Thanks, >>> Paul >>> >>> On 3/7/12 3:27 PM, Glen Lavers (glavers) wrote: >>>> Sorry I'm using implementer in 2 contexts. What I mean by implementer is >>>> network operator, or someone deploying products or systems that use this >>>> feature tag. A vendor would add it to their product and provide ways to >>>> enable/disable/filter depending on product and usage. >>>> >>>> If I'm an implementer who has purchased 2 different vendor products that >>>> allow for the immersive feature tag. As an implementer I can decide to use >>>> the tag or not based on what I know of the products and what I want as a >>>> policy decision. If I choose to use it I would know the capabilities of the >>>> 2 >>>> vendor products and decide for myself if they fit the criteria for this >>>> differentiation that I as an implementer/network operator am after. If they >>>> do then I can leverage that to make policy decisions, in my network, in call >>>> control, wherever or I turn them off or filter them based on the products >>>> themselves. >>>> >>>> A vendor adding this media feature tag to their product would hopefully >>>> leave >>>> it to the implementer to decide when and how to use it for policy. >>>> >>>> Does that better clarify my statements? >>>> -glen >>>> >>>>> -----Original Message----- >>>>> From: Adam Roach [mailto:adam@nostrum.com] >>>>> Sent: Wednesday, March 07, 2012 11:54 AM >>>>> To: Glen Lavers (glavers) >>>>> Cc: Cullen Jennings; dispatch@ietf.org >>>>> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt >>>>> >>>>> On 3/7/12 12:30 PM, Glen Lavers (glavers) wrote: >>>>>> The use cases are for business and policy distinctions. There are >>>>>> valid policy decisions that implementers would like to make to >>>>>> differentiate a video experience from an immersive experience such >>>>>> that an immersive experience is a video experience but not the other way >>>>> around. >>>>> >>>>> You're positing that network operators will be willing to make business and >>>>> policy decisions based on the nearly arbitrary, subjective opinions of >>>>> implementors? I think that's a bit naïve. >>>>> >>>>> /a >>>> _______________________________________________ >>>> 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 dworley@avaya.com Fri Mar 9 13:10:40 2012 Return-Path: <dworley@avaya.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4900021E803F for <dispatch@ietfa.amsl.com>; Fri, 9 Mar 2012 13:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.415 X-Spam-Level: X-Spam-Status: No, score=-103.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPo4nqD6ta5v for <dispatch@ietfa.amsl.com>; Fri, 9 Mar 2012 13:10:39 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5216A21E8038 for <dispatch@ietf.org>; Fri, 9 Mar 2012 13:10:39 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAK5wWk/GmAcF/2dsb2JhbAA3DLUygQeCCwEBBBILHS0SEAIBCA0BKBAyJQEBBA4NGodonwicBIoaAYV6YwSIU5J+ihSDAQ X-IronPort-AV: E=Sophos;i="4.73,559,1325480400"; d="scan'208";a="296161545" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Mar 2012 16:10:37 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Mar 2012 16:02:58 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 9 Mar 2012 16:10:36 -0500 From: "Worley, Dale R (Dale)" <dworley@avaya.com> To: Cullen Jennings <fluffy@iii.ca> Date: Fri, 9 Mar 2012 16:10:23 -0500 Thread-Topic: [dispatch] Proposal: ESPID Sequence Charter Thread-Index: Acz8feSzuGZDTtDmRlaIWagyk7kQGwBuyWgV Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A094B@DC-US1MBEX4.global.avaya.com> References: <1330640892.23608.YahooMailNeo@web162003.mail.bf1.yahoo.com>, <4F513AC8.6050906@alum.mit.edu> <CD5674C3CD99574EBA7432465FC13C1B22726A092E@DC-US1MBEX4.global.avaya.com>, <76CCB49A-FEE9-47F6-968E-C6AB54799816@iii.ca> In-Reply-To: <76CCB49A-FEE9-47F6-968E-C6AB54799816@iii.ca> 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> Subject: Re: [dispatch] Proposal: ESPID Sequence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Mar 2012 21:10:40 -0000 \Here's one approach to loop detection in environments that involve topology-hiding: It exploits the fact that most of the time, a request will proceed through a carrier's network with the request-URI remaining constant (the destination E.164 number of the message). Each carrier chooses a secret key which all of its proxies/B2BUAs know. Each proxy/B2BUA that handles a request perforce calculates a loop detection value according to the method of RFC 5393 section 4.2.1: This second part MUST vary with any field used by the location service logic in determining where to retarget or forward this request. This is necessary to distinguish looped requests from spirals by allowing the proxy to recognize if none of the values affecting the processing of the request have changed. Hence, the second part MUST depend at least on the received Request-URI and any Route header field values used when processing the received request. Implementers need to take care to include all fields used by the location service logic in that particular implementation. The proxy/B2BUA "encrypts" the loop detection value with the secret key to create an "encrypted loop detection value", which it compares to the list of values in the "ESPID" header. There are several cases: The request has arrived from outside the carrier: The new ELDV is the same as another ELDV in ESSID: The request has been in this carrier before, with the same destination, and so is looping. Otherwise: Add this ELDV to ESSID. Forward the request. The request has arrived from another proxy/B2BUA within the same carrier: The new ELDV is the same as the last ELDV in ESSID: The request has been proceeding through the carrier. Forward the request. (Of course, the proxy/B2BUA has to perform RFC 5393 loop detection to detect any loop since the ingress to the carrier.) The new ELDV is the same as an ELDV in ESSID that is not the last: The request is looping. Otherwise: Add this ELDV to ESSID. Forward the request. The "encryption" process can be as simple as hashing the key with the loop detection value, because there is no need to decrypt these values. The way we have constructed ESSID, it can be much shorter than the typical stack of Vias, because we can restrict the ELDVs to, say, 11 base64 characters, and ESSID will generally have one ELDV per carrier transit plus one for each redirection. E.g., the example I gave would have only 6 ELDV values (72 characters), but probably transits 20 proxies/B2BUAs. A carrier can change its key from time to time (perhaps to prevent any statistical attack), perhaps by hashing a master key with the date. As long as the change interval exceeds the lifetime of any request in transit, the ony penalty is that near a changeover time, some looping requests may proceed for twice as many hops as normal before being detected. The tricky part is that each "carrier network" must have the property that a request will never correctly exit the network and re-enter it without the request-URI having been changed. In many cases, this isn't true of a carrier: E.g., in the US, one carrier can handle the last-mile of a call at the origination end, the trunk part of the call is handled by a second carrier, but the last-mile at the destination is handled by the first carrier. In those cases, the carrier needs to divide its network into several sub-networks; each sub-network has its own ELDV key for its proxies/B2BUAs. Dale From dworley@avaya.com Fri Mar 9 13:44:20 2012 Return-Path: <dworley@avaya.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E468C21F85B6 for <dispatch@ietfa.amsl.com>; Fri, 9 Mar 2012 13:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.42 X-Spam-Level: X-Spam-Status: No, score=-103.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1tsomHZfEnX for <dispatch@ietfa.amsl.com>; Fri, 9 Mar 2012 13:44:20 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id EE2BF21F85AF for <dispatch@ietf.org>; Fri, 9 Mar 2012 13:44:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA95Wk/GmAcF/2dsb2JhbAA4Cg61MoEHggoBAQEBAgESKC0XCwIBCA0BKBAyJQEBBAEaEweHYwULonCUHoojhXJjBIhTkn6KFIIsVQ X-IronPort-AV: E=Sophos;i="4.73,560,1325480400"; d="scan'208";a="335781639" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Mar 2012 16:44:19 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Mar 2012 16:36:39 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 9 Mar 2012 16:44:18 -0500 From: "Worley, Dale R (Dale)" <dworley@avaya.com> To: Glen Lavers <glavers@cisco.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "dispatch@ietf.org" <dispatch@ietf.org> Date: Fri, 9 Mar 2012 16:44:18 -0500 Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz+GIuAluAkJFst6ECB5pHojiBr2QAIpzad Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A094C@DC-US1MBEX4.global.avaya.com> References: <4F57CDF3.2030700@alum.mit.edu>, <CB7F7B3A.1DB6B%glavers@cisco.com> In-Reply-To: <CB7F7B3A.1DB6B%glavers@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] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Mar 2012 21:44:21 -0000 > Video is clearly a very broad tag that is both useful and fits all types = of > video. What we want here is a delineation of video and we would like that > delineation to be managed by the network operator and really used at thei= r > discretion. Where they are able to decide where the line between video an= d > immersive video lies in the solution that they manage. > I'll say here that I think that it's very important that the network > operator control the manner in which the tag is used. Therefore it should= be > controllable by the network operator. Meaning they should be able to enab= le > or disable the use of the header on a specific endpoint or determine how > it's used in calls from call management system to system. This discussion seems to assume two things which we have long fought agains= t: 1) The carrier controls the user's devices. 2) The carrier knows the detailed intention of the user's communication. These points are deeply important. The IETF protocols are distinguished from the ITU protocols because they deny these things, and thus reduce the carriers' ability to exercise price discrimination (http://en.wikipedia.org/wiki/Price_discrimination). The resulting price advantage of the IETF protocols is what caused them to triumph over the ITU protocols in the market. Related considerations are discussed in Jonathan Rosenberg's RFC 5897, "Identification of Communications Services in the Session Initiation Protocol (SIP)", which is really "Why SIP should not attempt to identify the 'type of service' being requested in an INVITE." Once you exclude these things, what the UA can usefully tell the carrier is the bandwidth (and other QoS) that it needs, or the various "steps" of QoS that it can usefully fall back to. As Michael Hammer notes, the category of "high bandwidth" doesn't necessarily correlate well with "immersive video system", and IIRC you mentioned that some desktop video systems demand as much bandwidth as an immersive system. Looking at what CLUE is addressing, it seems to me that they are addressing systems with a range of bandwidth demands that is large enough that a binary "immersive" attribute will not be sufficient. That is, they will almost necessarily solve the problem of effectively signaling the bandwidth needs of a dialog. Why not leverage their solution? Dale From pkyzivat@alum.mit.edu Fri Mar 9 13:52:33 2012 Return-Path: <pkyzivat@alum.mit.edu> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEAE21F85B6 for <dispatch@ietfa.amsl.com>; Fri, 9 Mar 2012 13:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qqrN4APOiuE for <dispatch@ietfa.amsl.com>; Fri, 9 Mar 2012 13:52:32 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 09F6F21F8596 for <dispatch@ietf.org>; Fri, 9 Mar 2012 13:52:31 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id jY9C1i0071swQuc55ZsYZ8; Fri, 09 Mar 2012 21:52:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id jZsY1i00D07duvL3bZsYGd; Fri, 09 Mar 2012 21:52:32 +0000 Message-ID: <4F5A7B9D.3050006@alum.mit.edu> Date: Fri, 09 Mar 2012 16:52:29 -0500 From: Paul Kyzivat <pkyzivat@alum.mit.edu> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <CB7F9743.1DB92%glavers@cisco.com> In-Reply-To: <CB7F9743.1DB92%glavers@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Mar 2012 21:52:33 -0000 On 3/9/12 2:17 PM, Glen Lavers wrote: > Hi Dale, > inline > > > On 3/8/12 10:44 AM, "Worley, Dale R (Dale)"<dworley@avaya.com> wrote: > >> I'm no expert in this, but the following comments come to mind. (Not >> in priority order.) >> >> The definition of "immersive" (which seems to be synonymous with >> "telepresence") is not exact. That doesn't mean that the term isn't >> useful, but it is a warning that there may be no *technological* >> distinction. > This is why I do not think that this is much of a problem, specifically if > it's the network operator who should have control of when and how to use the > tag. This is something that deserves a discussion of its own, in a more general way. Is it your thought that all use of feature tags is to be controlled by the network operator? There are multiple aspects to that question: - what tags a UA *indicates*, in registrations and dialogs. Is this driven by the native code of the UA, or by operator config? - whether a UA *takes action* based on the presence of a particular tag. Is this driven by the native code of the UA, or by operator config? - whether a middle box on the signaling path takes action based on the presence of a particular tag. Is this driven by the native code of the UA, or by operator config? - are the answers to the above consistent for all tags, or is use of some tags driven by operator config and others by native code? I don't think there can be hard and fast answers to the above, because of the wide range of implementations and uses. But some understanding of expectations in common cases would be very helpful. My understanding of the intent of 3840 and 3841 was that individual devices would indicate their capabilities in a generic way. (For devices with variable capabilities this might depend on what capabilities have been enabled on the device. But this would typically be by, or on behalf of, the end user of the device.) Action by middle boxs was envisioned to be controlled by following the callerprefs inserted by the UAC, with limitations possibly imposed by middle box policies. How the UAC decided what callerprefs to include was AFAIK not discussed. I certainly didn't imagine end users writing callerpref expressions - I envisioned that these would be constructed to support various calling features offered in the UI of the UAC. So, as I envision it, a device that has only plain voice phone capabilities would know intrinsically that it should indicate voice and not video. A device with video capabilities would intrinsically indicate voice and video, unless video had explicitly been disabled by the end user, or possibly the operator. Presumably a telepresence system would indicate voice and video and immersive (or telepresence or whatever it ends up being called). Again I suppose some of those could be disabled by policy, but to me that would be a weird policy to impose on such a device. >> In regard to admission control, I expect that in both architecture and >> practice, networks will want to base admission distinctions on more >> detailed information than "immersive". But maybe I'm wrong; I think >> networks have explicitly excluded all "video" media as an admission >> policy. So perhaps a network would refuse admission to any >> "immersive" video but allow non-immersive video, in order to conserve >> bandwidth. > I think what would be more useful is simply an indication of call type that > allows the network administrator to associate the call to a BW pool > dedicated for these call types. Today most implementations have 2 pools > audio and video. For a video call most implementations deduct both audio and > video and mark them the same (QoS). For audio only the call is deducted out > of an audio pool and marked differently from video. As video requirements > are raised networks are more and more challenged to admit and provide > preferential treatment of types of video becomes more important. Allow > immersive calls up to W and other video up to X. Direct immersive calls to Y > system and other video to Z system for example. Here you seem to be aligned with the intent of draft-ietf-mmusic-traffic-class-for-sdp. But it is a more explicit way to get at this. I think it would be useful for you to huddle with the authors of that draft and see if you can reconcile and align the goals and terminology of the two drafts. >> Please, please, please do not use the word "leverage" to mean "utilize >> (to gain a further advantage)". That word makes it sound like contact >> with marketing people has damaged your brain. > It's a good word that's been overused for sure. I guess "use to control" > would be better ;-) > >> >> In regard to routing decisions, a feature tag is useful if *some* >> calls *prefer* the feature and also *some* calls *reject* >> (anti-prefer) the feature. Unless this criterion is true, the >> callee's local network (or the callee's behavior) can obtain all >> possible benefit by statically prioritizing the alternative UAs. > Well to be more exacting it's not the calls that "prefer" but the network > operator that creates a policy of treatment based on user or admin > requirements. Note that 3840 and 3841 are about callee *capabilities* and caller *preferences*. So the intent was really to support the preferences of callers. And, like option tags, feature tags represent *capabilities*, regardless of whether they are used or not. So for instance, a UAC could indicate it has audio and video capability, but without specifying any preference for video. And the UAS could in response indicate that it has only audio capability and all would be well. Or the UAS could indicate video *capability*, but the call could still be set up with only audio. Using the capabilities of the caller to make an admission decision, such as to deny the call because there insufficient resources for a video call, goes contrary to the intent of 3840/3841. If you wanted to do something here, it might be more justified if the UAC had included callerprefs *requiring* video support. Better I think to just let the call be established without giving it sufficient resources for video, and let the call be established without video, or with very low BW video. > Immersive, video and audio just become variables that the > operator has at their disposal to make policy decisions. After all > configuration of a system is policy. Without those attributes there's no > other way to make those policy decisions unless you have SDP and even then > it's not clear. The SDP provides a lot more to go on. But IMO its dicy to make admission control decisions based on what you guess the resource requirements of the call will be. For instance that just doesn't work if the requirements change over the course of the call. For instance, CLUE is trying to arrange things so a CLUE UA can interoperate with a "regular" (e.g. voice, optionally video) UA. So the initial call may not require more than ordinary resources. And depending on what the UAS is, it may never. If the UAS turns out to be another CLUE UA, then a lot of resources may be used. If I've gone to a telepresence room to call you, I probably do prefer to get the resources for a telepresence call. But if those aren't available, I would probably prefer to reach you via a plain audio/video call, or even a plain audio call, than to not reach you at all. So doing admission control based on your expectation that I must have resources for telepresence doesn't seem desirable. > Dial-plan is one way but if you are doing URI or number > dialing a single number or URI can be associated to a number of endpoints of > varying capabilities. > >> >> There are two examples in the draft, but neither is an example of >> either stated motivation. The examples and the motivations should not >> be conceptually disjoint. >> >> As Paul notes, the tag would be expressed as "+sip.immersive". > Thanks, we'll change it. > >> >> A motivation which seems plausible to me is that a video UA would want >> to know if the *other* video UA was operating in an immersive manner >> or not, or whether it was capable of doing so, so as to adjust its >> behavior. E.g., if an immersive system is communicating with an >> "ordinary" system, it might want to (effectively) crop its transmitted >> video signal from "immersive surrounding" to "viewing screen" >> dimensions. > I agree that could be useful. Today telepresence for example does this with > TIP (telepresence interoperability protocol). TIP however is established > endpoint to endpoint and not through the call management system and also is > established after the call has been answered so pre-ring there is really no > other informative manner to know that the call is telepresence. I'm using > telepresence as an example because it was brought up in the beginning but > this could be any telepresence like system that attempts to recreate an > in-person like audio and video experience. Are there other mechanisms that > exist on an invite that declare such capability that are standards based? I > don't know of any. >> The previous paragraph suggests that the set of existing video >> conferencing systems might be bimodal, that is, they might fall into >> two distinct classes: small-screen systems that people look at like >> televisions, and large-screen systems that surround the viewers, with >> no systems of intermediate size. If that is actually true (and it >> might have become true in the market without people explicitly >> planning or noticing it), it should be documented, and might be a >> justification for labeling videoconferencing systems with a binary >> "immersive" attribute. > I tend to agree with your statement about these bi-modal systems. This is > what I'm seeing in the Enterprise as many move to varying sizes of video > resolution up to something that will support viewing a person in life-size. > Management of these systems tend to be differentiated at that point, "tend" > being the key word and my perception of things. I see a lot of enterprises > standardizing on video bit rate for example where you'd see desktop video at > X rate and room-based systems at y rate. And that might be it for a lot of > Enterprises. Some have a dizzying array of endpoints with varying > capabilities but again attempts are made at managing and standardizing the > bit rate across a range of endpoints. Telepresence like systems have their > requirements and tend to set apart and are also in minority when it comes to > systems deployed. From working in CLUE its quite apparent that the BW required for a telepresence call won't be a constant, and may vary vastly from one call to another. To some extent it may be predictable by the geometry of the room - based on the number of cameras and screens. But it also may depend on the complexity of the call - what is going on at the other end. So I don't think just putting all telepresence systems into a single pool will be helpful. Since I am not in Cisco any longer I can't look up what org you come from. But if you aren't part of the telepresence group, then it would probably be helpful for you to get together with them to sort out what makes sense in the context of what will be coming with CLUE. >> I suspect that there are important aspects of this subject that the >> authors know (at least intuitively) but have not documented, and a >> revision of the draft might be very informative. >> >> In any case, it seems to me that this draft falls squarely within the >> remit of CLUE. Speaking as one of the chairs of CLUE, I agree that it seems like the right place to address something like this, though it might not fit within the current charter. I'd also want to see this brought forward as a set of use cases and requirements rather than as a proposed mechanism. But I also think that if this were to come to CLUE the likely outcome would be to postpone it until the existing work on CLUE is more advanced. Also note that one of the Dispatch chairs (Mary) is also the other chair of CLUE, so we should hopefully be able to settle this quickly. Thanks, Paul From jmpolk@cisco.com Fri Mar 9 17:00:52 2012 Return-Path: <jmpolk@cisco.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2274321E8019 for <dispatch@ietfa.amsl.com>; Fri, 9 Mar 2012 17:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.728 X-Spam-Level: X-Spam-Status: No, score=-109.728 tagged_above=-999 required=5 tests=[AWL=0.871, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BET9+DujekKa for <dispatch@ietfa.amsl.com>; Fri, 9 Mar 2012 17:00:49 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9215921E8018 for <dispatch@ietf.org>; Fri, 9 Mar 2012 17:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3550; q=dns/txt; s=iport; t=1331341249; x=1332550849; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=HjlPJlrpWGGEWR1KQYnmdMhqOMo6ceZOjmK2ztP21X0=; b=bfCNjPdagbsnRCklhs3xsi570p76xnVD+oNCaM2d7VF3FdEzvKkZ7Zub 3taJZ7+aZkA9pBPOzTyxxTc5MsRWWgZpkiQZZ5ix+yLxpJlshuYwHf3j4 8kiL1T0FCWNI5R9ssP2kIhWy2hJTEpkTVKckPe8zEA+5DHzMJsRivO10T 0=; X-IronPort-AV: E=Sophos;i="4.73,561,1325462400"; d="scan'208";a="32865382" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 10 Mar 2012 01:00:49 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2A10m9E028451; Sat, 10 Mar 2012 01:00:48 GMT Message-Id: <201203100100.q2A10m9E028451@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 09 Mar 2012 19:00:47 -0600 To: "Worley, Dale R (Dale)" <dworley@avaya.com>, Glen Lavers <glavers@cisco.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "dispatch@ietf.org" <dispatch@ietf.org> From: "James M. Polk" <jmpolk@cisco.com> In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A094C@DC-US1MBEX4.glo bal.avaya.com> References: <4F57CDF3.2030700@alum.mit.edu> <CB7F7B3A.1DB6B%glavers@cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A094C@DC-US1MBEX4.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 10 Mar 2012 01:00:52 -0000 At 03:44 PM 3/9/2012, Worley, Dale R (Dale) wrote: > > Video is clearly a very broad tag that is both useful and fits all types of > > video. What we want here is a delineation of video and we would like that > > delineation to be managed by the network operator and really used at their > > discretion. Where they are able to decide where the line between video and > > immersive video lies in the solution that they manage. > > > I'll say here that I think that it's very important that the network > > operator control the manner in which the tag is used. Therefore > it should be > > controllable by the network operator. Meaning they should be able to enable > > or disable the use of the header on a specific endpoint or determine how > > it's used in calls from call management system to system. > >This discussion seems to assume two things which we have long fought against: > >1) The carrier controls the user's devices. > >2) The carrier knows the detailed intention of the user's >communication. > >These points are deeply important. The IETF protocols are >distinguished from the ITU protocols because they deny these things, >and thus reduce the carriers' ability to exercise price discrimination >(http://en.wikipedia.org/wiki/Price_discrimination). The resulting >price advantage of the IETF protocols is what caused them to triumph >over the ITU protocols in the market. > >Related considerations are discussed in Jonathan Rosenberg's RFC 5897, >"Identification of Communications Services in the Session Initiation >Protocol (SIP)", which is really "Why SIP should not attempt to >identify the 'type of service' being requested in an INVITE." > >Once you exclude these things, what the UA can usefully tell the >carrier is the bandwidth (and other QoS) that it needs, or the various >"steps" of QoS that it can usefully fall back to. As Michael Hammer >notes, the category of "high bandwidth" doesn't necessarily correlate >well with "immersive video system", and IIRC you mentioned that some >desktop video systems demand as much bandwidth as an immersive system. > >Looking at what CLUE is addressing, it seems to me that they are >addressing systems with a range of bandwidth demands that is large >enough that a binary "immersive" attribute will not be sufficient. >That is, they will almost necessarily solve the problem of effectively >signaling the bandwidth needs of a dialog. Why not leverage their >solution? color me confused a bit, but this is not a new capability, it is just a clarification on an existing capability. Caller Prefs already defines the 'audio' and 'video' feature tags, and this draft separates 'video' into 'video' and 'immersive'. If the carrier were the one to do this, I might agree with you, but the UA is the device that installs this feature tag on the Contact header, so, to edit your two bullets from above: 1b) The carrier controls the user's devices, but does *not* necessarily need to know about this feature tag. 2b) The carrier does not need to know the detailed intention of the user's communication since the carrier does not insert this feature tag (unless this is a completely SP operated and managed network in which the SP provides all call signaling services (i.e., the SIP servers). Of course, this is my opinion, and I could be wrong. James >Dale >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Sat Mar 10 20:00:31 2012 Return-Path: <dean.willis@softarmor.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBF021F85FD for <dispatch@ietfa.amsl.com>; Sat, 10 Mar 2012 20:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.916 X-Spam-Level: X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPY-PGvutDpn for <dispatch@ietfa.amsl.com>; Sat, 10 Mar 2012 20:00:30 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9D1D21F85FB for <dispatch@ietf.org>; Sat, 10 Mar 2012 20:00:30 -0800 (PST) Received: by dakl33 with SMTP id l33so3684564dak.31 for <dispatch@ietf.org>; Sat, 10 Mar 2012 20:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sVvEuUVUaG41PXdbsBAp45d7/hEMF2wxLjL6jp3umC4=; b=Ewe1BbMO0aTkVJXHmMcIXND+Ac+CDh9I1Ia7kywq6vOD5ZCLafFLBI1Kd0p1oA78m/ AwMTh/ynsx7WyM1840FR/FTKJ09Orw/CFY8qKg5XH4pyiuM1EPiCdtnf7LP7912a24gY r8liWbBZDN6+dCr5Q7KGj0TzKrzDtQJfR1Xqw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=sVvEuUVUaG41PXdbsBAp45d7/hEMF2wxLjL6jp3umC4=; b=cnrWTj8j3WK11ihA9oclzO/Zk3zfwDuIZBfomPzBQ0vyAd6NzX8To7k/TM8/upFfQX Jf8oHR8PbkuFnUWGELZo4XfJLf4IHGZAyeAf2OSvIdUUbT81p89Nb2r0ZNg0NV/h7YcN gnx0tSLDeoyciIuvxdTmliU50ObF0SSy+jrntiynq5d65csWop8uMUIyLg1TUPVhODHG SPtWvEgfNjkO3ZW4vYYADEZWUzLpuOXejvpv7xznzTU55HKwzrm5e9C7tZE9ufR6GudX hCeb4t5VKVpCtD/6cuPHh5IpTEcXDJpNs15tajeb5eguTcInmv82PCU++saiARLdukTo gA7w== MIME-Version: 1.0 Received: by 10.68.129.74 with SMTP id nu10mr7233847pbb.157.1331438430553; Sat, 10 Mar 2012 20:00:30 -0800 (PST) Received: by 10.68.9.104 with HTTP; Sat, 10 Mar 2012 20:00:30 -0800 (PST) In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA239D6332@STNTEXCH01.cis.neustar.com> References: <55A5A9A87506CB4BA580BF9D531957DA239D6332@STNTEXCH01.cis.neustar.com> Date: Sat, 10 Mar 2012 22:00:30 -0600 Message-ID: <CAOHm=4t7WJ7fgy+CC1NNoecJDF0QqLH+C9bh2ZA_E3Z=Y2QPvw@mail.gmail.com> From: Dean Willis <dean.willis@softarmor.com> To: "Peterson, Jon" <jon.peterson@neustar.biz> Content-Type: multipart/alternative; boundary=e89a8f234f31b1870604baefaa10 X-Gm-Message-State: ALoCoQnSKb2aSyegKxXJ025tgA+kvHDnkO6aiJB+joH76O0Kuw5DvIRNh7607U1FTNsVHQ3oNf/O Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 11 Mar 2012 04:00:31 -0000 --e89a8f234f31b1870604baefaa10 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 5, 2012 at 3:51 PM, Peterson, Jon <jon.peterson@neustar.biz>wrote: > > Rather than continue to debate the applicability of the DNS and the > probity of various extensions to it, we might make more progress if we work > towards agreement on the semantics of queries for telephone-related data > independently of any underlying protocols. > Finally! The doc is a good start. -- Dean --e89a8f234f31b1870604baefaa10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Mon, Mar 5, 2012 at 3:51 PM, Peterson= , Jon <span dir=3D"ltr"><<a href=3D"mailto:jon.peterson@neustar.biz">jon= .peterson@neustar.biz</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"> <br> Rather than continue to debate the applicability of the DNS and the probity= of various extensions to it, we might make more progress if we work toward= s agreement on the semantics of queries for telephone-related data independ= ently of any underlying protocols.<span class=3D"HOEnZb"><font color=3D"#88= 8888"><br> </font></span></blockquote></div><div><br></div><div>Finally!</div><div><br= ></div><div>The doc is a good start.</div><div>--</div><div>Dean</div><div>= <br></div> --e89a8f234f31b1870604baefaa10-- From Peter.Dawes@vodafone.com Mon Mar 12 04:32:09 2012 Return-Path: <Peter.Dawes@vodafone.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC85621F86F1 for <dispatch@ietfa.amsl.com>; Mon, 12 Mar 2012 04:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtxoWKLxSzre for <dispatch@ietfa.amsl.com>; Mon, 12 Mar 2012 04:32:09 -0700 (PDT) Received: from mailout06.vodafone.com (mailout06.vodafone.com [195.232.224.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0C80021F86D6 for <dispatch@ietf.org>; Mon, 12 Mar 2012 04:32:09 -0700 (PDT) Received: from mailint06 (localhost [127.0.0.1]) by mailout06 (Postfix) with ESMTP id 29F3384D1F for <dispatch@ietf.org>; Mon, 12 Mar 2012 12:32:07 +0100 (CET) Received: from avoexs02.internal.vodafone.com (unknown [145.230.4.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint06 (Postfix) with ESMTPS id 1C418846AC; Mon, 12 Mar 2012 12:32:07 +0100 (CET) Received: from avoexf10.internal.vodafone.com ([145.230.6.94]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 12:31:40 +0100 Received: from VOEXC01W.internal.vodafone.com (145.230.101.21) by avoexf10.internal.vodafone.com (145.230.6.94) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 12 Mar 2012 12:32:06 +0100 Received: from VOEXM25W.internal.vodafone.com ([169.254.1.6]) by VOEXC01W.internal.vodafone.com ([145.230.101.21]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 12:31:40 +0100 From: "Dawes, Peter, VF-Group" <Peter.Dawes@vodafone.com> To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, DISPATCH <dispatch@ietf.org> Thread-Topic: [dispatch] Charter process for the INSIPID WG Thread-Index: Acz3nagK1UjCs5I5Q1yNoraMXkfq1AIoPh3w Date: Mon, 12 Mar 2012 11:31:39 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99D39A@VOEXM25W.internal.vodafone.com> References: <4F4F5C19.9070607@ericsson.com> In-Reply-To: <4F4F5C19.9070607@ericsson.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [145.230.12.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2012 11:31:40.0951 (UTC) FILETIME=[B1CE5270:01CD0043] Subject: Re: [dispatch] Charter process for the INSIPID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 12 Mar 2012 11:32:10 -0000 Hello Gonzalo, All, I think the following paragraph of the INSIPID charter at http://www.ietf.o= rg/iesg/evaluation/sessionid-charter.txt should be revised: "This group will focus on a document that will specify an SIP identifier that have the same aim as the From-tag, To-tag and Call-ID conjunction, but is less likely to be mangled by intermediaries." This paragraph limits the charter to a single document, even though more th= an one draft already exists related to identifying sessions, and by mention= ing the "From-tag" points to a solution that includes information from both= ends of a session before INSIPID has started discussion. Therefore, I woul= d like to propose the following re-wording: "This group will focus on specifying a SIP identifier that has similar uniqueness and end-to-end properties as a dialo= g identifier (made up of the From-tag, To-tag and Call-ID conjunction), but is less likely to be mangled by intermediaries. Related identifiers and parameters to satisfy requirements = for use cases like troubleshooting, billing, session tracking, session recording, media and signalling correlation, and so forth will also be specified." Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Gonzalo Camarillo Sent: 01 March 2012 11:23 To: DISPATCH Subject: [dispatch] Charter process for the INSIPID WG Folks, Robert and I have been working on a charter proposal for the INSIPID WG. This is the proposal that we have sent for review to the IESG and IAB: http://www.ietf.org/iesg/evaluation/sessionid-charter.txt We believe this proposal represents the consensus of the group. Note that w= e have left out some comments that failed to get rough consensus on this li= st. >From now on, I will be taking care of the chartering process for this WG. T= oday, I will discuss the charter proposal with the IESG and, if everything = goes OK, we will be sending it for external review shortly. If you have further comments on the charter proposal, please send them as p= art of its external review, which will be announced on the IETF announcemen= t list as usual. Also, I am going to be requesting the creation of the insipid mailing list. Cheers, Gonzalo _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Mon Mar 12 09:09:26 2012 Return-Path: <pkyzivat@alum.mit.edu> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E57321F87F7 for <dispatch@ietfa.amsl.com>; Mon, 12 Mar 2012 09:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NywAnEBENd3w for <dispatch@ietfa.amsl.com>; Mon, 12 Mar 2012 09:09:25 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9F07521F87DC for <dispatch@ietf.org>; Mon, 12 Mar 2012 09:09:05 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta01.westchester.pa.mail.comcast.net with comcast id ke8D1i0061c6gX851g955B; Mon, 12 Mar 2012 16:09:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id kg951i00w07duvL3jg951B; Mon, 12 Mar 2012 16:09:05 +0000 Message-ID: <4F5E1FA0.2080102@alum.mit.edu> Date: Mon, 12 Mar 2012 12:09:04 -0400 From: Paul Kyzivat <pkyzivat@alum.mit.edu> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Glen Lavers <glavers@cisco.com> References: <CB7F7B3A.1DB6B%glavers@cisco.com> In-Reply-To: <CB7F7B3A.1DB6B%glavers@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 12 Mar 2012 16:09:26 -0000 On 3/9/12 12:17 PM, Glen Lavers wrote: > Hi Paul, > Comments inline > > > On 3/7/12 1:06 PM, "Paul Kyzivat"<pkyzivat@alum.mit.edu> wrote: > >> Glen, >> >> I'm still not understanding your use cases. >> >> Is your intent to *register* endpoints with the feature tag, and then >> use callerprefs so that calls prefer (or require) callees that have >> registered the tag? >> >> Or is your intent to pass the tag (on a Contact header) during call >> establishment and use the value to decide whether to accept the call, or >> condition behavior after the call is established? > My example below was to pass the tag in a contact header during call > establishment and use the value for a B2BUA or SBC to determine how to use > it. In the draft we provided a few examples that might be useful but I could > imagine others. What I do see is for the ability for enterprise call > management systems that interoperate like B2BUA's or SBCs to use this header > to drive routing decisions or effectuate admission control prior to SDP > offer (the 2 examples in the draft) I see two examples - registration and session establishment. But neither of them give any insight into the purpose of doing this. And I see two things mentioned in motivation - admission control and selective routing. But both of them are very vague. Regarding admission control - why would you want to want to base admission control on such a vague indication, rather than basing it on something that more explicitly indicates the resources required, such as the SDP? Regarding selective routing decisions - it would be helpful to have some realistic and tangible examples where the selective routing would actually be helpful. Presumably this would be where there are multiple registrations for an AOR and one is more suitable than another, and where that trumps the recipient's prioritization of the alternatives. We have had callerprefs for 10 years or so, and I have yet to hear of a single case where it is being used that way. >> Either way, it isn't going to work right if everybody doesn't have some >> level of common understanding of what this means. If I'm sitting in a >> telepresence room and calling you, I will be wanting to reach a >> telepresence system, and probably won't be satisfied if I reach your >> game machine. (And what if you have both?) > Do you know of any systems that route calls for both gaming and telepresence > like endpoints? No. I also don't know any systems that have telepresence endpoints and something less capable registered to the same AOR. I only mention gaming systems because those were brought up when I asked if immersive is the same as telepresence. The same argument applies if its just differing telepresence implementations that can't interoperate. I would be more convinced if the proposal was for a feature tag indicating CLUE support. (But that is a bit premature.) > In any case I see this feature tag as more applicable to > vendors of telepresence like systems. If the gaming systems wanted to > leverage it then I guess they could. I guess you could imagine having a > gaming system that could do both telepresence conferencing AND immersive > gaming but if they did then I would see using another feature tag as a > further qualifier, perhaps sip.application. I can see focusing on telepresence, and including game systems if that is one of the things they can do. > I agree that a common understanding of what immersive means is critical. I > don't think however that it needs to be restrictive or extremely specific. > It's clear that many on this list are confused by our attempt at a broad > definition of telepresence like immersive video. We can try and articulate > this in terms of more specific adjectives however as many have mentioned > there will most always be a level of subjectivity unless we add clear > technical delineations which I'm extremely apprehensive about doing. What is > critical is that the network operator managing these systems is able to > control what uses the tag. IMO the first step is to focus on what you want to accomplish with this, and nail down the definitions that are required to accomplish that. Telepresence itself isn't all that well defined. A good part of what CLUE is doing is arguing out what the essential characteristics are that different telepresence systems share. If you are interested in something less specific than that, then I think you have the burden to spell it out such that different people can look at a system and agree on whether it is immersive or not. And you have to show that knowing that is helpful in making behavioral decisions. What I would not like to see is agreement on just a *name* with fuzzy semantics, such that its only useful in a closed garden where a side agreement narrows the meaning. (E.g. Cisco systems assign meaning related to its own implementations, and things work only as long as all the systems using the tag adhere to that meaning.) > Video is clearly a very broad tag that is both useful and fits all types of > video. AFAIK it remains to be shown whether the sip.video feature tag is actually useful. I welcome some examples of how it is being used. > What we want here is a delineation of video and we would like that > delineation to be managed by the network operator and really used at their > discretion. Where they are able to decide where the line between video and > immersive video lies in the solution that they manage. >> Also, AFAIK virtually nothing currently supports callerprefs >> (Accept-Contact/Reject-Contact), except 3gpp. But I'll be pleased to >> hear I am wrong about that. >> >> And even if some do, Accept-Contact won't be very useful unless you have >> multiple systems with different capabilities registered to the same AOR. >> (Reject-Contact might be useful to cause calls to fail unless you reach >> a device with the desired capabilities.) >> >> Can you spell out the use case(s) you have in mind for this in >> significantly more detail? (Describe the capabilities and desires of the >> caller, the characteristics and behaviors of the potential callees, and >> the expected outcome in both positive and negative cases.) Also, how the >> UAs come to know what capabilities to register and to prefer - are those >> compiled into the code by the code developer, or are they configured in >> by the deployer? > I see endpoint vendors coding it into their endpoints and allowing it to be > enabled/disabled. I also see call management systems using it between one > another. Do you see this configurability as something special for immersive, or do you imagine that all the capabilities the endpoint has can likewise be configured? Also, do you see this as a matter of configuring the device to have the functionality (e.g. telepresence functionality) and then the reporting of the corresponding capability feature tag is implicitly enabled? Or are you thinking that the enabling of the feature tag is independent of the enabling of the actual functionality? Again, I'm concerned about interoperability. Its important that each endpoint vendor can make the decision whether it is "immersive", and that those decisions are consistent across vendors. If that is so, then it shouldn't be necessary to enable advertising of the feature tag independently of enabling the functionality. > An example of admission control: 2 telepresence like vendor systems that > manage Enterprise calls for both video systems and telepresence like > systems. Prior to ringing an endpoint it is often difficult to determine the > type of call that is being established. Therefore sending an invite with a > contact header that stipulates video for example is useful, especially in > cases where delayed offer is used. This allows the receiving system to make > some decisions. In this example the decision is for admission control. Call > management systems tend to set an upper limit on how much bandwidth any > given call from one endpoint to another can use. So knowing that the call is > video prior to getting an offer is useful to validate that the bandwidth is > allocated for a potential video call prior to ringing the device. The same > is true for fixed telepresence-like systems which tend to use higher > bandwidth limits than generic desktop video. So if an endpoint or a call > management system can use this contact header with immersive it allows the > receiving system to know that the intent of the call is telepresence like > and can associate the correct bandwidth limits and deductions from the > appropriate bandwidth allocations. I already discussed this some above. IMO it could be counterproductive to do admission control based on the *capabilities* of the calling device. (I think I mentioned this in some other reply.) It might make more sense to base such a decision on stated callerprefs. But even then, what sort of decision would you want to make if the caller *prefers* but doesn't *require* video? ISTM that you should reject a call for lack of available video bandwidth if the caller *requires* video. In common usage I would expect that most callers with video capability might *prefer* but not *require* video. OTOH, I can see how a telepresence system might often want to *require* telepresence capability and bandwidth as precondition for establishing the call. BUT, I think the admission control could better be handled by other mechanisms, such as RSVP and preconditions during the O/A. And arguing for this to work around limitations of an offerless INVITE seems silly. I am a proponent of offerless INVITES, in cases where they make sense. But the point of them is that you are delegating to the callee the decision about what sort of call this will be. If you have specific requirements about the media in the call, then you should be making the initial offer. > As I mentioned it could be useful for any of those 2 systems to know at > invite what type of call they are receiving. That the intent of the call is > for an immersive telepresence like experience if available by the called > party. The calling system could send the invite with a contact header > showing not only immersive but other features as well like audio, video as > the possibilities of the type of call that's possible: Contact: > <sip:bob@example.com;transport=tcp>;immersive;video;audio > The receiving system could make any number of assumptions using that > information. If it's doing admission control it could instantiate the invite > at ring as an immersive call deducting from an allocation of bandwidth > reserved for immersive style systems. If that fails it could then try video > or audio-only. If only an immersive tag was available then maybe it would > only try the immersive bandwidth allocation and if that failed it would > simply fail the call. If the called system has bandwidth for the call the it > in-turn signals the call on to the terminating endpoint or UA. > > I'll say here that I think that it's very important that the network > operator control the manner in which the tag is used. Therefore it should be > controllable by the network operator. Meaning they should be able to enable > or disable the use of the header on a specific endpoint or determine how > it's used in calls from call management system to system. > > I can also see a use case in a similar scenario for SBCs where the SBC can > use the information to determine directionality. If a user "owns" a number > of devices that have varying levels of capabilities. Let's say that Bob owns > a telepresence like system fixed in a room. He also has 2 other devices. A > desktop phone with standard video and a mobile device to receive audio only > calls. If the way to reach any of these devices is the same, meaning that > Bob's number or URI is exactly the same it could be useful for a network > operator to be able to use things like this media feature tag and the base > tags in order to direct the call to specific devices. So when a call comes > from another telepresence like system to Bob only Bob's telepresence > endpoint rings for example. That won't work very well if Bob is out of the office and only his mobile device is accessible to him. Even when calling from your telepresence room it will probably be better for the call to ring and connect to his phone, so you can talk with him - if only to decide when to reschedule. This would all be quite straightforward (with a suitably smart home proxy) if the call included not just caller capabilities, but also callerprefs. Then the evaluation of the callerprefs could result in prioritizing the endpoints, and serial forking, first to his telepresence room, then his video phone, and finally to his mobile. Thanks, Paul > If a call comes with a video and audio tag for > example the call could be routed to all devices. The network operator could > leverage the tag to achieve the requirements of the use cases. > > I can imagine other use cases where the called system could also use the > indication to validate the call against a scheduling system specifically for > immersive calls. > > I find that these tags can be useful in a number of scenarios for > interoperation between call management system simply by allowing the use of > the tags. > > >> >> Thanks, >> Paul >> >> On 3/7/12 3:27 PM, Glen Lavers (glavers) wrote: >>> Sorry I'm using implementer in 2 contexts. What I mean by implementer is >>> network operator, or someone deploying products or systems that use this >>> feature tag. A vendor would add it to their product and provide ways to >>> enable/disable/filter depending on product and usage. >>> >>> If I'm an implementer who has purchased 2 different vendor products that >>> allow for the immersive feature tag. As an implementer I can decide to use >>> the tag or not based on what I know of the products and what I want as a >>> policy decision. If I choose to use it I would know the capabilities of the 2 >>> vendor products and decide for myself if they fit the criteria for this >>> differentiation that I as an implementer/network operator am after. If they >>> do then I can leverage that to make policy decisions, in my network, in call >>> control, wherever or I turn them off or filter them based on the products >>> themselves. >>> >>> A vendor adding this media feature tag to their product would hopefully leave >>> it to the implementer to decide when and how to use it for policy. >>> >>> Does that better clarify my statements? >>> -glen >>> >>>> -----Original Message----- >>>> From: Adam Roach [mailto:adam@nostrum.com] >>>> Sent: Wednesday, March 07, 2012 11:54 AM >>>> To: Glen Lavers (glavers) >>>> Cc: Cullen Jennings; dispatch@ietf.org >>>> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt >>>> >>>> On 3/7/12 12:30 PM, Glen Lavers (glavers) wrote: >>>>> The use cases are for business and policy distinctions. There are >>>>> valid policy decisions that implementers would like to make to >>>>> differentiate a video experience from an immersive experience such >>>>> that an immersive experience is a video experience but not the other way >>>> around. >>>> >>>> You're positing that network operators will be willing to make business and >>>> policy decisions based on the nearly arbitrary, subjective opinions of >>>> implementors? I think that's a bit naïve. >>>> >>>> /a >>> _______________________________________________ >>> 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 dworley@avaya.com Mon Mar 12 09:14:47 2012 Return-Path: <dworley@avaya.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FAE21F875A for <dispatch@ietfa.amsl.com>; Mon, 12 Mar 2012 09:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.424 X-Spam-Level: X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTVdOwVT5q5n for <dispatch@ietfa.amsl.com>; Mon, 12 Mar 2012 09:14:47 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8406E21F8760 for <dispatch@ietf.org>; Mon, 12 Mar 2012 09:14:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGogXk+HCzI1/2dsb2JhbABDDrVJgQeCCQEBAQECARIoLRcLAgEIDQghEDIlAQEEARIIGodjBaAim3WQHmMEm1eKGIIsUw X-IronPort-AV: E=Sophos;i="4.73,571,1325480400"; d="scan'208";a="296542159" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Mar 2012 12:14:45 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Mar 2012 11:59:27 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Mon, 12 Mar 2012 12:14:38 -0400 From: "Worley, Dale R (Dale)" <dworley@avaya.com> To: "James M. Polk" <jmpolk@cisco.com>, Glen Lavers <glavers@cisco.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "dispatch@ietf.org" <dispatch@ietf.org> Date: Mon, 12 Mar 2012 12:14:37 -0400 Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz+WT4fu5lG7I1kRqOdWDYfA1asyACER5qI Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0952@DC-US1MBEX4.global.avaya.com> References: <4F57CDF3.2030700@alum.mit.edu> <CB7F7B3A.1DB6B%glavers@cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A094C@DC-US1MBEX4.global.avaya.com>, <201203100100.q2A10m9E028451@mtv-core-4.cisco.com> In-Reply-To: <201203100100.q2A10m9E028451@mtv-core-4.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] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 12 Mar 2012 16:14:47 -0000 > From: James M. Polk [jmpolk@cisco.com] >=20 > If the carrier were the one to do this, I might agree with you, but > the UA is the device that installs this feature tag on the Contact > header, so, to edit your two bullets from above: I quoted from earlier messages the following sentences: > > > What we want here is a delineation of video and we would like that > > > delineation to be managed by the network operator and really used at = their > > > discretion. > > > I'll say here that I think that it's very important that the network > > > operator control the manner in which the tag is used. So, independently of the *technical* content of the proposal, its author seems to envision that its use is intended to be managed by a network operator. (Though the "network operator" is probably intended to include both service providers and enterprise networks.) Though the phrase "network operator" does not appear in the draft itself; it may be that the proposal does not depend so much on network operators. Dale From dworley@avaya.com Mon Mar 12 09:37:25 2012 Return-Path: <dworley@avaya.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649C411E80AE for <dispatch@ietfa.amsl.com>; Mon, 12 Mar 2012 09:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.129 X-Spam-Level: X-Spam-Status: No, score=-103.129 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf+0UjCTG5VI for <dispatch@ietfa.amsl.com>; Mon, 12 Mar 2012 09:37:24 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8151811E80AC for <dispatch@ietf.org>; Mon, 12 Mar 2012 09:37:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAL4kXk/GmAcF/2dsb2JhbAA5CrVXgQeCCQEBAQEDEig4FwIBCA0IIRAyJQEBBBMIGodooCybd4osBYVtYwSbV4oYgn+BOQ X-IronPort-AV: E=Sophos;i="4.73,571,1325480400"; d="scan'208";a="296546629" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Mar 2012 12:37:21 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Mar 2012 12:29:13 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 12 Mar 2012 12:37:01 -0400 From: "Worley, Dale R (Dale)" <dworley@avaya.com> To: "dispatch@ietf.org" <dispatch@ietf.org> Date: Mon, 12 Mar 2012 12:37:00 -0400 Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz+WT4fu5lG7I1kRqOdWDYfA1asyACEf9sQ Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0953@DC-US1MBEX4.global.avaya.com> References: <4F57CDF3.2030700@alum.mit.edu> <CB7F7B3A.1DB6B%glavers@cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A094C@DC-US1MBEX4.global.avaya.com>, <201203100100.q2A10m9E028451@mtv-core-4.cisco.com> In-Reply-To: <201203100100.q2A10m9E028451@mtv-core-4.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] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 12 Mar 2012 16:37:25 -0000 If the purpose of the proposal is to allow UAs to identify themselves (or rather, their sessions) as to their bandwidth/QoS needs, and the identification is to pigeonhole the devices into a small number of "device classes" (which is probably quite common in network deployments), why don't we define a string-valued "device class" media feature tag? This has a number of advantages over the current proposal (which is to add an additional classification, "immersive" to the current set, "audio" and "video"): The classification system can be expanded or subdivided without limit, without further standards action, to accommodate future needs. We do not have to specificy what is "immersive" and what is not. Since the classification is done by the network operator for its own benefit, the network operator can define classes and assign devices to them as it sees fit. Since the "device class" is expected to be defined and set by the network operator, and only consumed by the network operator, there is no need to standardize its vaules. I see that there is already a "class" media feature tag, so let me propose "devclass": Devclass Media feature tag name: sip.devclass Summary of the media feature indicated by this tag: This feature tag indicates the type of device that the UA is. The value is expected to be provisioned into the UA by the network that it is attached to. (The means of provisioning is outside the scope of this document.) Values appropriate for use with this feature tag: Token with an equality relationship. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is used by the network to which the UA is attached to classify the sessions created by the UA for admission control, bandwidth allocation, and QoS support. Examples of typical use: Differentiating between devices that regularly provide audio, low-resolution video, and high-resolution (immersive) video. Typical uses would be: REGISTER sip:example.com SIP/2.0 From: sip:user@example.com;tag=3Dasd98 To: sip:user@example.com Call-ID: hh89as0d-asd88jkk@host.example.com CSeq: 9987 REGISTER Max-Forwards: 70 Via: SIP/2.0/UDP host.example.com;branch=3Dz9hG4bKnashds8 Contact: <sip:user@host.example.com>;audio;video >> ;+sip.devclass=3D"<immersive>" ;methods=3D"INVITE,BYE,OPTIONS,ACK,CANCEL" Content-Length: 0 INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=3Dz9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=3D1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> >> ;+sip.devclass=3D"<immersive>" Content-Type: application/sdp Content-Length: 142 (Assuming I've got the syntax of media feature tags correct.) Dale From paulej@packetizer.com Mon Mar 12 18:05:26 2012 Return-Path: <paulej@packetizer.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4BA21F8A43 for <dispatch@ietfa.amsl.com>; Mon, 12 Mar 2012 18:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWCEGEzHtfPC for <dispatch@ietfa.amsl.com>; Mon, 12 Mar 2012 18:05:24 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AF88E21F8A41 for <dispatch@ietf.org>; Mon, 12 Mar 2012 18:05:24 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2D15LAi014530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Mar 2012 21:05:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331600722; bh=R5YKeZusYAHDYan5w3jWrH5cXj/1Top8txqHi+ecClc=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=bxHTyS92rt0PvV/kl1vMTCONb6T8hKYOSs+qnkLjryAZqu8SZLE+Cn3CHjS1eok4C FTSIx+OmAxojWsRlm8znNOwhtTJxUTndP+GaiVfwUh5Kj+/GwTewe+0pJcNIglyL8p BTkuAK/3xZrxNQ6VnEd2iMFMYRF93Nv9ecDfN2ZU= From: "Paul E. Jones" <paulej@packetizer.com> To: "'Worley, Dale R \(Dale\)'" <dworley@avaya.com>, "'Glen Lavers \(glavers\)'" <glavers@cisco.com>, <dispatch@ietf.org> References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com>, <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> Date: Mon, 12 Mar 2012 21:05:25 -0400 Message-ID: <035501cd00b5$5fcddd20$1f699760$@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: AQIGlAq4PGrll3yWVQrHLtOjxHlL0QGM5LtOApsegtMCwxqCqQIVAynKArlo1yaVlmkTYA== Content-Language: en-us Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 01:05:26 -0000 Dale, Thanks for the thorough review (as usual) :) > The definition of "immersive" (which seems to be synonymous with > "telepresence") is not exact. That doesn't mean that the term isn't > useful, but it is a warning that there may be no *technological* > distinction. I personally view "immersive" as an adjective one can apply to Telepresence, but not all immersive systems are telepresence systems. For example, my son has an immersive video gaming experience each time puts his headset on his head. While the definition of "immersive" can be debated, I think it is important to differentiate immersive from Telepresence. A voice call could certainly be immersive. Our intent was to allow this tag to be used as a user preference in conjunction with audio and video tags to help route calls or select devices. > In regard to admission control, I expect that in both architecture and > practice, networks will want to base admission distinctions on more > detailed information than "immersive". But maybe I'm wrong; I think > networks have explicitly excluded all "video" media as an admission > policy. So perhaps a network would refuse admission to any "immersive" > video but allow non-immersive video, in order to conserve bandwidth. Admission control was viewed as just one possible usage. Quite likely, if it were used for admission control, the tag would be policed somewhere. Assuming the tag is policed on both ends and both ends seek an immersive experience, this will have an influence on the admission control decisions. This draft certainly does not intend to suggest every input that will go into admission control logic, but this is just one potentially useful code point. > Please, please, please do not use the word "leverage" to mean "utilize (to > gain a further advantage)". That word makes it sound like contact with > marketing people has damaged your brain. :-) I cannot argue with you on that point. > In regard to routing decisions, a feature tag is useful if *some* calls > *prefer* the feature and also *some* calls *reject* > (anti-prefer) the feature. Unless this criterion is true, the callee's > local network (or the callee's behavior) can obtain all possible benefit > by statically prioritizing the alternative UAs. Since it's a caller preferences tag, all things are possible. A UA could require tag, reject on the tag, etc. > There are two examples in the draft, but neither is an example of either > stated motivation. The examples and the motivations should not be > conceptually disjoint. The REGISTER example wasn't intended to provide an example of motivation of the tag directly, but it shows how might be used in signaling to facilitate device selection. Once the device is registered with this feature tag, then call routing logic can utilize this information in device selection. The INVITE example just shows its use, but I agree it does not help to support the stated motivations. The intent was just to show its usage. I would have been happy without the examples, but others felt like the examples were useful to show where this is signaled; that's about all the examples are for. > As Paul notes, the tag would be expressed as "+sip.immersive". That was a point that was not entirely clear to me. I wish I had seen Paul K's message, but I seem to lose some of his :-( Syntactically, the "immersive" tag is allowed per RFC 3261 syntax. Per RFC 3640, it seemed to suggest +sip was needed, but it was not clear how one can define new "base" tags that do not require +sip. So, there is no possibility for introducing new base tags -- ever? > A motivation which seems plausible to me is that a video UA would want to > know if the *other* video UA was operating in an immersive manner or not, > or whether it was capable of doing so, so as to adjust its behavior. > E.g., if an immersive system is communicating with an "ordinary" system, > it might want to (effectively) crop its transmitted video signal from > "immersive surrounding" to "viewing screen" > dimensions. That's certainly possible, yes. > The previous paragraph suggests that the set of existing video > conferencing systems might be bimodal, that is, they might fall into two > distinct classes: small-screen systems that people look at like > televisions, and large-screen systems that surround the viewers, with no > systems of intermediate size. If that is actually true (and it might have > become true in the market without people explicitly planning or noticing > it), it should be documented, and might be a justification for labeling > videoconferencing systems with a binary "immersive" attribute. I definitely think we will have such systems. One does not want to limit a system that can provide a rich experience from communicating with a desktop video phone or an iPad. Any communication is better than no communication. In such cases, I can certainly see that a system might adjust behavior. The main idea we had in mind (or I did and let the others state their thoughts) was that a user might have a plurality of callable devices. I could use this tag to route calls to preferred devices. I could tell my SIP server that during the business day, I prefer to route all "immersive" calls to my single screen Telepresence system on my desk. In the evenings, I might have those routed to my softphone. Of course, the caller can also indicate preferences: it may not want to allow the call to go to a softphone. All of these things are possible with the caller preferences framework. > I suspect that there are important aspects of this subject that the > authors know (at least intuitively) but have not documented, and a > revision of the draft might be very informative. Reading too much into this can be dangerous. It's certainly possible to throw out a lot of ideas for this tag, but at the end of the day it is nothing but a feature tag. In RFC 3840, no single tag is discussed at such length. As such, I didn't feel like this one should. It was stated that "immersive" is subjective and, to some extent, that's true. An "immersive" system is what one says it is. Beyond that, though, the system behavior is fairly well-defined in RFC 3840 and RFC 3841. > In any case, it seems to me that this draft falls squarely within the > remit of CLUE. I do have to disagree with you on this point. :-) If CLUE did or did not exist, it would not change the desire to an immersive tag. We're not defining multiple streams, camera positioning, or the multitude of things people are pouring into "Telepresence". None of that makes any sense of an immersive audio call. This gets back to "what is immersive"? Like RFC 3840, one can ask "what is text?" (That's another feature tag.) Is this instant messaging text? Or is this real-time text that is delivered character-at-a-time? There is also the "mobility" tag. Is that a mobile phone? Is it a laptop with Wi-Fi? A tablet? I'd like to separate the notion of "immersive" from Telepresence, because I view it as an adjective that is a part of Telepresence. Nonetheless, it is an adjective that we would like to use with or without Telepresence and in conjunction with audio and video feature tags. Paul From adam@nostrum.com Mon Mar 12 22:11:49 2012 Return-Path: <adam@nostrum.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F83821F88AF for <dispatch@ietfa.amsl.com>; Mon, 12 Mar 2012 22:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NBUgPrCdFHG for <dispatch@ietfa.amsl.com>; Mon, 12 Mar 2012 22:11:49 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CBF3621F8818 for <dispatch@ietf.org>; Mon, 12 Mar 2012 22:11:48 -0700 (PDT) Received: from [192.168.0.159] (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2D5Bi1w021745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2012 00:11:46 -0500 (CDT) (envelope-from adam@nostrum.com) References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> In-Reply-To: <035501cd00b5$5fcddd20$1f699760$@packetizer.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1A873A09-59B0-429D-AFBC-D510E6025FBC Message-Id: <3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com> X-Mailer: iPad Mail (9B176) From: Adam Roach <adam@nostrum.com> Date: Tue, 13 Mar 2012 00:12:24 -0500 To: "Paul E. Jones" <paulej@packetizer.com> Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "<dispatch@ietf.org>" <dispatch@ietf.org> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 05:11:49 -0000 --Apple-Mail-1A873A09-59B0-429D-AFBC-D510E6025FBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 12, 2012, at 20:05, "Paul E. Jones" <paulej@packetizer.com> wrote: > Syntactically, the "immersive" tag is allowed per RFC 3261 syntax. Per RFC= > 3640, it seemed to suggest +sip was needed, but it was not clear how one c= an > define new "base" tags that do not require +sip. So, there is no > possibility for introducing new base tags -- ever? You can define new parameters, sure. But they aren't capability tags without= the +sip.xxx syntax. You seem to think you want to define a capability. If t= hat turns out to be the case, you'll need the +sip prefix. Now, I personally think you have jumped to a broken, semantic-free mechanism= to satisfy implied and vaguely defined requirements, rather than taking the= more straightforward route of coming to the WG with solid, clear requiremen= ts, and soliciting input on reasonable mechanisms for meeting those requirem= ents. The discussion around syntax of capability tags is like arguing over w= hether the car you've specified should have pin stripes, rather than discuss= ing the broader issue of whether a car is actually the best tool for cooking= pancakes. Your requirements are probably valid, and it would be good to have them stat= ed in a clear and exhaustive fashion. Your proposed mechanism, however, is m= isguided. /a= --Apple-Mail-1A873A09-59B0-429D-AFBC-D510E6025FBC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head></head><body bgcolor=3D"#FFFFFF"><div>On Mar 12, 2012, at 20:05,= "Paul E. Jones" <<a href=3D"mailto:paulej@packetizer.com">paulej@packeti= zer.com</a>> wrote:<br><br></div><blockquote type=3D"cite"><span>Syntacti= cally, the "immersive" tag is allowed per RFC 3261 syntax.  Per RFC</sp= an><br><span>3640, it seemed to suggest +sip was needed, but it was not clea= r how one can</span><br><span>define new "base" tags that do not require +si= p.  So, there is no</span><br><span>possibility for introducing new bas= e tags -- ever?</span></blockquote><br><div></div><div><br></div><div>You ca= n define new parameters, sure. But they aren't capability tags without the += sip.xxx syntax. You seem to think you want to define a capability. If that t= urns out to be the case, you'll need the +sip prefix.</div><div><br></div><d= iv>Now, I personally think you have jumped to a broken, semantic-free mechan= ism to satisfy implied and vaguely defined requirements, rather than taking t= he more straightforward route of coming to the WG with solid, clear requirem= ents, and soliciting input on reasonable mechanisms for meeting those requir= ements. The discussion around syntax of capability tags is like arguing over= whether the car you've specified should have pin stripes, rather than discu= ssing the broader issue of whether a car is actually the best tool for cooki= ng pancakes.</div><div><br></div><div>Your requirements are probably valid, a= nd it would be good to have them stated in a clear <i>and exhaustive</i> fas= hion. Your proposed mechanism, however, is misguided.</div><div><br></div><d= iv>/a</div></body></html>= --Apple-Mail-1A873A09-59B0-429D-AFBC-D510E6025FBC-- From paulej@packetizer.com Tue Mar 13 00:21:41 2012 Return-Path: <paulej@packetizer.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F31B11E8076 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 00:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUIvRv4KMzCo for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 00:21:40 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 29B5D11E8073 for <dispatch@ietf.org>; Tue, 13 Mar 2012 00:21:39 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2D7LZpc021313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2012 03:21:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331623296; bh=tX6sy9Nfb4qRl4bTXbVt7Hl/9GYaAv1Uzh/tpkyZhC0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Lxsp8d1a5yEEsE85hO8ivl9M8MCnjnV4QR2HYkvCmQMBPq57/6oLBfll6N0TkIWgk nDuYPVXOFSq79KddWGU6ujBZ6A6RyeUYKY780CsU1eOyxMyLKFE/AQDcJT+xf1V3Dw g7or6Xiu3+H9KYv2Rec6r515N3+AHINFef5RMp9w= From: "Paul E. Jones" <paulej@packetizer.com> To: "'Adam Roach'" <adam@nostrum.com> References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> <3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com> In-Reply-To: <3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com> Date: Tue, 13 Mar 2012 03:21:40 -0400 Message-ID: <03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03D1_01CD00C8.68984040" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGlAq4PGrll3yWVQrHLtOjxHlL0QGM5LtOApsegtMCwxqCqQIVAynKArlo1yYCM/uG3wIxpaqWlXOnG8A= Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 07:21:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03D1_01CD00C8.68984040 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adam, =20 The intent was to register a new capability and the registration appears = with sip. prepended in the I-D. What I=E2=80=99m missing is the message = apparently sent by Paul K. regarding usage of that new tag in the = contact header. Does it require a +sip. or can we use sip.? Is sip. = stripped or not? Reading page 7, it seems to suggest that tags that are = not the =E2=80=9Cbase tags=E2=80=9D (those defined and enumerated on = page 7) sip. cannot be stripped and a + sign prepended. I may not be = reading that correctly, thus the reason for the question below. =20 The broader issue is why we propose the introduction of this feature = tag. We=E2=80=99re not trying to =E2=80=9Cjump to a broken, = semantic-free mechanism.=E2=80=9D The intent is to define a user agent = capability and, more specifically, a feature tag. The intent is to = introduce something similar to those defined in RFC 3840. Just as a = device might be mobile, or a device might do video, we wanted something = to indicate that a device has an immersive quality. Why is sip.class = defined to indicate that a device is in a business setting or personal = setting? With whatever logic was applied there, I would think = specifying that a device is classified as =E2=80=9Cimmersive=E2=80=9D or = not should apply. =20 The issue is that the IETF has defined the car (RFC 3840) into which we = wish to install a radio, but folks are suggesting that we=E2=80=99re = taking the wrong approach because the car isn=E2=80=99t actually a car, = but a horse drawn carriage without electrical power and therefore = impossible to support a radio. Or, perhaps RFC 3840 is a defective = Pinto that needs to be recalled? =20 You=E2=80=99re a smart fellow. You understand the idea behind = classifying a device as =E2=80=9Cimmersive=E2=80=9D. There=E2=80=99s no = magic to this, one does not need a voluminous document to convey the = idea, nor are we trying to invent something that is out in left field = that warrants such an elaborate document. As with all of the other very = short registrations appearing in RFC 3840, we merely propose to register = a =E2=80=9Csip.immersive=E2=80=9D tag so that we can know when a device = registers that it is an =E2=80=9Cimmersive=E2=80=9D device. When the = device calls another device, it can indicate via the Accept-Contact and = Reject-Contact headers its preferences for communicating with another = device that is classified as =E2=80=9Cimmersive=E2=80=9D. =20 The definition of immersive might be in question; a portion of the = definition for Telepresence could be used. Telepresence brings with it = much more than the immersive quality, as I mentioned before. We could = work to define =E2=80=9Cimmersive=E2=80=9D if that was the only concern, = but I don=E2=80=99t think that is the issue. =20 I=E2=80=99m certainly open to suggestions for how this should be = accomplished. If this absolutely does not fit within the RFC 3840 = framework, then I can accept the fact that I do not understand the point = of RFC 3840. =20 Paul =20 From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, March 13, 2012 1:12 AM To: Paul E. Jones Cc: Worley, Dale R (Dale); Glen Lavers (glavers); <dispatch@ietf.org> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt =20 On Mar 12, 2012, at 20:05, "Paul E. Jones" <paulej@packetizer.com> = wrote: Syntactically, the "immersive" tag is allowed per RFC 3261 syntax. Per = RFC 3640, it seemed to suggest +sip was needed, but it was not clear how one = can define new "base" tags that do not require +sip. So, there is no possibility for introducing new base tags -- ever? =20 =20 You can define new parameters, sure. But they aren't capability tags = without the +sip.xxx syntax. You seem to think you want to define a = capability. If that turns out to be the case, you'll need the +sip = prefix. =20 Now, I personally think you have jumped to a broken, semantic-free = mechanism to satisfy implied and vaguely defined requirements, rather = than taking the more straightforward route of coming to the WG with = solid, clear requirements, and soliciting input on reasonable mechanisms = for meeting those requirements. The discussion around syntax of = capability tags is like arguing over whether the car you've specified = should have pin stripes, rather than discussing the broader issue of = whether a car is actually the best tool for cooking pancakes. =20 Your requirements are probably valid, and it would be good to have them = stated in a clear and exhaustive fashion. Your proposed mechanism, = however, is misguided. =20 /a ------=_NextPart_000_03D1_01CD00C8.68984040 Content-Type: text/html; charset="UTF-8" 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=3Dutf-8"><meta = name=3DGenerator content=3D"Microsoft Word 14 (filtered = medium)"><style><!-- /* Font Definitions */ @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;} /* 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;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></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 bgcolor=3Dwhite = lang=3DEN-US link=3Dblue vlink=3Dpurple><div class=3DWordSection1><p = class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'>Adam,<o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p> </o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'>The intent was to register a new capability and the registration = appears with sip. prepended in the I-D.=C2=A0 What I=E2=80=99m missing = is the message apparently sent by Paul K. regarding usage of that new = tag in the contact header.=C2=A0 Does it require a +sip. or can we use = sip.?=C2=A0 Is sip. stripped or not?=C2=A0 Reading page 7, it seems to = suggest that tags that are not the =E2=80=9Cbase tags=E2=80=9D (those = defined and enumerated on page 7) sip. cannot be stripped <i>and</i> a + = sign prepended.=C2=A0 I may not be reading that correctly, thus the = reason for the question below.<o:p></o:p></span></p><p = class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p> </o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'>The broader issue is why we propose the introduction of this feature = tag.=C2=A0 We=E2=80=99re not trying to =E2=80=9Cjump to a broken, = semantic-free mechanism.=E2=80=9D=C2=A0 The intent is to define a user = agent capability and, more specifically, a feature tag.=C2=A0 The intent = is to introduce something similar to those defined in RFC 3840.=C2=A0 = Just as a device might be mobile, or a device might do video, we wanted = something to indicate that a device has an immersive quality.=C2=A0 Why = is sip.class defined to indicate that a device is in a business setting = or personal setting?=C2=A0 With whatever logic was applied there, I = would think specifying that a device is classified as = =E2=80=9Cimmersive=E2=80=9D or not should apply.<o:p></o:p></span></p><p = class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p> </o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'>The issue is that the IETF has defined the car (RFC 3840) into which = we wish to install a radio, but folks are suggesting that we=E2=80=99re = taking the wrong approach because the car isn=E2=80=99t actually a car, = but a horse drawn carriage without electrical power and therefore = impossible to support a radio.=C2=A0 Or, perhaps RFC 3840 is a defective = Pinto that needs to be recalled?<o:p></o:p></span></p><p = class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p> </o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'>You=E2=80=99re a smart fellow.=C2=A0 You understand the idea behind = classifying a device as =E2=80=9Cimmersive=E2=80=9D.=C2=A0 = There=E2=80=99s no magic to this, one does not need a voluminous = document to convey the idea, nor are we trying to invent something that = is out in left field that warrants such an elaborate document.=C2=A0 As = with all of the other very short registrations appearing in RFC 3840, we = merely propose to register a =E2=80=9Csip.immersive=E2=80=9D tag so that = we can know when a device registers that it is an = =E2=80=9Cimmersive=E2=80=9D device.=C2=A0 When the device calls another = device, it can indicate via the Accept-Contact and Reject-Contact = headers its preferences for communicating with another device that is = classified as =E2=80=9Cimmersive=E2=80=9D.<o:p></o:p></span></p><p = class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p> </o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'>The definition of immersive might be in question; =C2=A0a portion of = the definition for Telepresence could be used.=C2=A0 Telepresence brings = with it much more than the immersive quality, as I mentioned = before.=C2=A0 We could work to define =E2=80=9Cimmersive=E2=80=9D if = that was the only concern, but I don=E2=80=99t think that is the = issue.<o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p> </o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'>I=E2=80=99m certainly open to suggestions for how this should be = accomplished.=C2=A0 If this absolutely does not fit within the RFC 3840 = framework, then I can accept the fact that I do not understand the point = of RFC 3840.<o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p> </o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'>Paul<o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><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 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"'> = Adam Roach [mailto:adam@nostrum.com] <br><b>Sent:</b> Tuesday, March 13, = 2012 1:12 AM<br><b>To:</b> Paul E. Jones<br><b>Cc:</b> Worley, Dale R = (Dale); Glen Lavers (glavers); = <dispatch@ietf.org><br><b>Subject:</b> Re: [dispatch] = draft-lavers-sipcore-immersive-capability-00.txt<o:p></o:p></span></p></d= iv></div><p class=3DMsoNormal><o:p> </o:p></p><div><p = class=3DMsoNormal style=3D'margin-bottom:12.0pt'>On Mar 12, 2012, at = 20:05, "Paul E. Jones" <<a = href=3D"mailto:paulej@packetizer.com">paulej@packetizer.com</a>> = wrote:<o:p></o:p></p></div><blockquote = style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><p = class=3DMsoNormal>Syntactically, the "immersive" tag is = allowed per RFC 3261 syntax.  Per RFC<br>3640, it seemed to suggest = +sip was needed, but it was not clear how one can<br>define new = "base" tags that do not require +sip.  So, there is = no<br>possibility for introducing new base tags -- = ever?<o:p></o:p></p></blockquote><p = class=3DMsoNormal><o:p> </o:p></p><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>You can define new parameters, sure. But they aren't = capability tags without the +sip.xxx syntax. You seem to think you want = to define a capability. If that turns out to be the case, you'll need = the +sip prefix.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>Now, I personally think you have jumped to a broken, = semantic-free mechanism to satisfy implied and vaguely defined = requirements, rather than taking the more straightforward route of = coming to the WG with solid, clear requirements, and soliciting input on = reasonable mechanisms for meeting those requirements. The discussion = around syntax of capability tags is like arguing over whether the car = you've specified should have pin stripes, rather than discussing the = broader issue of whether a car is actually the best tool for cooking = pancakes.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>Your requirements are probably valid, and it would be = good to have them stated in a clear <i>and exhaustive</i> fashion. Your = proposed mechanism, however, is misguided.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>/a<o:p></o:p></p></div></div></div></body></html> ------=_NextPart_000_03D1_01CD00C8.68984040-- From mphmmr@gmail.com Tue Mar 13 06:11:00 2012 Return-Path: <mphmmr@gmail.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C91121F877C for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 06:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFeFeGRStKKc for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 06:10:58 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1790B21F8762 for <dispatch@ietf.org>; Tue, 13 Mar 2012 06:10:57 -0700 (PDT) Received: by lagj5 with SMTP id j5so518955lag.31 for <dispatch@ietf.org>; Tue, 13 Mar 2012 06:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vxhRIHHZE1a/nwLDUtUN7I0tafMGbpbhYXcTPA2AdjA=; b=MnTAc0LIDruL7ZG/AZM8ta6tWWipUtSCDd8KD9n3owwoDTwQAmLlaSoT5xrAz7/7Ly i5pznvxZp4KctfO0LX5zyhJfNLKWHIPcpWaiSBP6h/ulFkLTEeAw22fJmtwdFoWtM/SP KBbIncdx21yTaXfvcXLxLW/4r3gOPUVhDp6eJwgzAN/ChSrm48yfRBZGZrF4ocVVbSfL Uu83+o+JRNpJbp8vlWtudpKaTNkSaYOiqA6weHsdSpP6mMGioJPMOvaQsZEJ6GCU+hE3 009neSh40Ljl4zKhN3yw8ko1k91/+Pa+9v79x9zwb0paIqKLJTwFp1+VQTfI5eF2YCk6 5QwQ== MIME-Version: 1.0 Received: by 10.112.39.169 with SMTP id q9mr4448426lbk.47.1331644256988; Tue, 13 Mar 2012 06:10:56 -0700 (PDT) Received: by 10.112.76.196 with HTTP; Tue, 13 Mar 2012 06:10:56 -0700 (PDT) In-Reply-To: <035501cd00b5$5fcddd20$1f699760$@packetizer.com> References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> Date: Tue, 13 Mar 2012 09:10:56 -0400 Message-ID: <CAA3wLqUxC=NwTeLhan8tBTZ2NQ_FqnY4xbiWNjjDU7dq7FoYgw@mail.gmail.com> From: Michael Hammer <mphmmr@gmail.com> To: "Paul E. Jones" <paulej@packetizer.com> Content-Type: multipart/alternative; boundary=485b390f7b54e7aeaa04bb1f9665 Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 13:11:00 -0000 --485b390f7b54e7aeaa04bb1f9665 Content-Type: text/plain; charset=ISO-8859-1 A judge once said: "I can't define pornography, but I can tell when I see it." The term immersive seems to be in the same category. With something so subjective, can you tell me how that helps interoperability? ISTM that it will be as useful as the evil bit. If I notice that it's use/non-use negatively impacts me, then I change it and get better service, is that cool with you? Mike On Mon, Mar 12, 2012 at 9:05 PM, Paul E. Jones <paulej@packetizer.com>wrote: > Dale, > > Thanks for the thorough review (as usual) :) > > > The definition of "immersive" (which seems to be synonymous with > > "telepresence") is not exact. That doesn't mean that the term isn't > > useful, but it is a warning that there may be no *technological* > > distinction. > > I personally view "immersive" as an adjective one can apply to > Telepresence, > but not all immersive systems are telepresence systems. For example, my > son > has an immersive video gaming experience each time puts his headset on his > head. > > While the definition of "immersive" can be debated, I think it is important > to differentiate immersive from Telepresence. A voice call could certainly > be immersive. Our intent was to allow this tag to be used as a user > preference in conjunction with audio and video tags to help route calls or > select devices. > > > In regard to admission control, I expect that in both architecture and > > practice, networks will want to base admission distinctions on more > > detailed information than "immersive". But maybe I'm wrong; I think > > networks have explicitly excluded all "video" media as an admission > > policy. So perhaps a network would refuse admission to any "immersive" > > video but allow non-immersive video, in order to conserve bandwidth. > > Admission control was viewed as just one possible usage. Quite likely, if > it were used for admission control, the tag would be policed somewhere. > Assuming the tag is policed on both ends and both ends seek an immersive > experience, this will have an influence on the admission control decisions. > This draft certainly does not intend to suggest every input that will go > into admission control logic, but this is just one potentially useful code > point. > > > Please, please, please do not use the word "leverage" to mean "utilize > (to > > gain a further advantage)". That word makes it sound like contact with > > marketing people has damaged your brain. > > :-) I cannot argue with you on that point. > > > In regard to routing decisions, a feature tag is useful if *some* calls > > *prefer* the feature and also *some* calls *reject* > > (anti-prefer) the feature. Unless this criterion is true, the callee's > > local network (or the callee's behavior) can obtain all possible benefit > > by statically prioritizing the alternative UAs. > > Since it's a caller preferences tag, all things are possible. A UA could > require tag, reject on the tag, etc. > > > There are two examples in the draft, but neither is an example of either > > stated motivation. The examples and the motivations should not be > > conceptually disjoint. > > The REGISTER example wasn't intended to provide an example of motivation of > the tag directly, but it shows how might be used in signaling to facilitate > device selection. Once the device is registered with this feature tag, > then > call routing logic can utilize this information in device selection. > > The INVITE example just shows its use, but I agree it does not help to > support the stated motivations. The intent was just to show its usage. > > I would have been happy without the examples, but others felt like the > examples were useful to show where this is signaled; that's about all the > examples are for. > > > As Paul notes, the tag would be expressed as "+sip.immersive". > > That was a point that was not entirely clear to me. I wish I had seen Paul > K's message, but I seem to lose some of his :-( > > Syntactically, the "immersive" tag is allowed per RFC 3261 syntax. Per RFC > 3640, it seemed to suggest +sip was needed, but it was not clear how one > can > define new "base" tags that do not require +sip. So, there is no > possibility for introducing new base tags -- ever? > > > A motivation which seems plausible to me is that a video UA would want to > > know if the *other* video UA was operating in an immersive manner or not, > > or whether it was capable of doing so, so as to adjust its behavior. > > E.g., if an immersive system is communicating with an "ordinary" system, > > it might want to (effectively) crop its transmitted video signal from > > "immersive surrounding" to "viewing screen" > > dimensions. > > That's certainly possible, yes. > > > The previous paragraph suggests that the set of existing video > > conferencing systems might be bimodal, that is, they might fall into two > > distinct classes: small-screen systems that people look at like > > televisions, and large-screen systems that surround the viewers, with no > > systems of intermediate size. If that is actually true (and it might > have > > become true in the market without people explicitly planning or noticing > > it), it should be documented, and might be a justification for labeling > > videoconferencing systems with a binary "immersive" attribute. > > I definitely think we will have such systems. One does not want to limit a > system that can provide a rich experience from communicating with a desktop > video phone or an iPad. Any communication is better than no communication. > In such cases, I can certainly see that a system might adjust behavior. > > The main idea we had in mind (or I did and let the others state their > thoughts) was that a user might have a plurality of callable devices. I > could use this tag to route calls to preferred devices. I could tell my > SIP > server that during the business day, I prefer to route all "immersive" > calls > to my single screen Telepresence system on my desk. In the evenings, I > might have those routed to my softphone. > > Of course, the caller can also indicate preferences: it may not want to > allow the call to go to a softphone. All of these things are possible with > the caller preferences framework. > > > I suspect that there are important aspects of this subject that the > > authors know (at least intuitively) but have not documented, and a > > revision of the draft might be very informative. > > Reading too much into this can be dangerous. It's certainly possible to > throw out a lot of ideas for this tag, but at the end of the day it is > nothing but a feature tag. In RFC 3840, no single tag is discussed at such > length. As such, I didn't feel like this one should. It was stated that > "immersive" is subjective and, to some extent, that's true. An "immersive" > system is what one says it is. Beyond that, though, the system behavior is > fairly well-defined in RFC 3840 and RFC 3841. > > > In any case, it seems to me that this draft falls squarely within the > > remit of CLUE. > > I do have to disagree with you on this point. :-) > > If CLUE did or did not exist, it would not change the desire to an > immersive > tag. We're not defining multiple streams, camera positioning, or the > multitude of things people are pouring into "Telepresence". None of that > makes any sense of an immersive audio call. > > This gets back to "what is immersive"? Like RFC 3840, one can ask "what is > text?" (That's another feature tag.) Is this instant messaging text? Or > is > this real-time text that is delivered character-at-a-time? There is also > the "mobility" tag. Is that a mobile phone? Is it a laptop with Wi-Fi? A > tablet? > > I'd like to separate the notion of "immersive" from Telepresence, because I > view it as an adjective that is a part of Telepresence. Nonetheless, it is > an adjective that we would like to use with or without Telepresence and in > conjunction with audio and video feature tags. > > Paul > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --485b390f7b54e7aeaa04bb1f9665 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A judge once said: =A0"I can't define pornography, but I can tell = when I see it."<div>The term immersive seems to be in the same categor= y.<br></div><div><br></div><div>With something so subjective, can you tell = me how that helps interoperability?</div> <div>ISTM that it will be as useful as the evil bit.</div><div><br></div><d= iv>If I notice that it's use/non-use negatively impacts me,=A0</div><di= v>then I change it and get better service, is that cool with you?</div><div= > <br></div><div>Mike</div><div><br></div><div><br></div><div><br><div class= =3D"gmail_quote">On Mon, Mar 12, 2012 at 9:05 PM, Paul E. Jones <span dir= =3D"ltr"><<a href=3D"mailto:paulej@packetizer.com">paulej@packetizer.com= </a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Dale,<br> <br> Thanks for the thorough review (as usual) :)<br> <br> > The definition of "immersive" (which seems to be synonymous = with<br> > "telepresence") is not exact. =A0That doesn't mean that = the term isn't<br> > useful, but it is a warning that there may be no *technological*<br> > distinction.<br> <br> I personally view "immersive" as an adjective one can apply to Te= lepresence,<br> but not all immersive systems are telepresence systems. =A0For example, my = son<br> has an immersive video gaming experience each time puts his headset on his<= br> head.<br> <br> While the definition of "immersive" can be debated, I think it is= important<br> to differentiate immersive from Telepresence. =A0A voice call could certain= ly<br> be immersive. =A0Our intent was to allow this tag to be used as a user<br> preference in conjunction with audio and video tags to help route calls or<= br> select devices.<br> <br> > In regard to admission control, I expect that in both architecture and= <br> > practice, networks will want to base admission distinctions on more<br= > > detailed information than "immersive". =A0But maybe I'm = wrong; I think<br> > networks have explicitly excluded all "video" media as an ad= mission<br> > policy. =A0So perhaps a network would refuse admission to any "im= mersive"<br> > video but allow non-immersive video, in order to conserve bandwidth.<b= r> <br> Admission control was viewed as just one possible usage. =A0Quite likely, i= f<br> it were used for admission control, the tag would be policed somewhere.<br> Assuming the tag is policed on both ends and both ends seek an immersive<br= > experience, this will have an influence on the admission control decisions.= <br> This draft certainly does not intend to suggest every input that will go<br= > into admission control logic, but this is just one potentially useful code<= br> point.<br> <br> > Please, please, please do not use the word "leverage" to mea= n "utilize (to<br> > gain a further advantage)". =A0That word makes it sound like cont= act with<br> > marketing people has damaged your brain.<br> <br> :-) =A0I cannot argue with you on that point.<br> <br> > In regard to routing decisions, a feature tag is useful if *some* call= s<br> > *prefer* the feature and also *some* calls *reject*<br> > (anti-prefer) the feature. =A0Unless this criterion is true, the calle= e's<br> > local network (or the callee's behavior) can obtain all possible b= enefit<br> > by statically prioritizing the alternative UAs.<br> <br> Since it's a caller preferences tag, all things are possible. =A0A UA c= ould<br> require tag, reject on the tag, etc.<br> <br> > There are two examples in the draft, but neither is an example of eith= er<br> > stated motivation. =A0The examples and the motivations should not be<b= r> > conceptually disjoint.<br> <br> The REGISTER example wasn't intended to provide an example of motivatio= n of<br> the tag directly, but it shows how might be used in signaling to facilitate= <br> device selection. =A0Once the device is registered with this feature tag, t= hen<br> call routing logic can utilize this information in device selection.<br> <br> The INVITE example just shows its use, but I agree it does not help to<br> support the stated motivations. =A0The intent was just to show its usage.<b= r> <br> I would have been happy without the examples, but others felt like the<br> examples were useful to show where this is signaled; that's about all t= he<br> examples are for.<br> <br> > As Paul notes, the tag would be expressed as "+sip.immersive"= ;.<br> <br> That was a point that was not entirely clear to me. =A0I wish I had seen Pa= ul<br> K's message, but I seem to lose some of his :-(<br> <br> Syntactically, the "immersive" tag is allowed per RFC 3261 syntax= . =A0Per RFC<br> 3640, it seemed to suggest +sip was needed, but it was not clear how one ca= n<br> define new "base" tags that do not require +sip. =A0So, there is = no<br> possibility for introducing new base tags -- ever?<br> <br> > A motivation which seems plausible to me is that a video UA would want= to<br> > know if the *other* video UA was operating in an immersive manner or n= ot,<br> > or whether it was capable of doing so, so as to adjust its behavior.<b= r> > E.g., if an immersive system is communicating with an "ordinary&q= uot; system,<br> > it might want to (effectively) crop its transmitted video signal from<= br> > "immersive surrounding" to "viewing screen"<br> > dimensions.<br> <br> That's certainly possible, yes.<br> <br> > The previous paragraph suggests that the set of existing video<br> > conferencing systems might be bimodal, that is, they might fall into t= wo<br> > distinct classes: =A0small-screen systems that people look at like<br> > televisions, and large-screen systems that surround the viewers, with = no<br> > systems of intermediate size. =A0If that is actually true (and it migh= t have<br> > become true in the market without people explicitly planning or notici= ng<br> > it), it should be documented, and might be a justification for labelin= g<br> > videoconferencing systems with a binary "immersive" attribut= e.<br> <br> I definitely think we will have such systems. =A0One does not want to limit= a<br> system that can provide a rich experience from communicating with a desktop= <br> video phone or an iPad. =A0Any communication is better than no communicatio= n.<br> In such cases, I can certainly see that a system might adjust behavior.<br> <br> The main idea we had in mind (or I did and let the others state their<br> thoughts) was that a user might have a plurality of callable devices. =A0I<= br> could use this tag to route calls to preferred devices. =A0I could tell my = SIP<br> server that during the business day, I prefer to route all "immersive&= quot; calls<br> to my single screen Telepresence system on my desk. =A0In the evenings, I<b= r> might have those routed to my softphone.<br> <br> Of course, the caller can also indicate preferences: it may not want to<br> allow the call to go to a softphone. =A0All of these things are possible wi= th<br> the caller preferences framework.<br> <br> > I suspect that there are important aspects of this subject that the<br= > > authors know (at least intuitively) but have not documented, and a<br> > revision of the draft might be very informative.<br> <br> Reading too much into this can be dangerous. =A0It's certainly possible= to<br> throw out a lot of ideas for this tag, but at the end of the day it is<br> nothing but a feature tag. =A0In RFC 3840, no single tag is discussed at su= ch<br> length. =A0As such, I didn't feel like this one should. =A0It was state= d that<br> "immersive" is subjective and, to some extent, that's true. = =A0An "immersive"<br> system is what one says it is. =A0Beyond that, though, the system behavior = is<br> fairly well-defined in RFC 3840 and RFC 3841.<br> <br> > In any case, it seems to me that this draft falls squarely within the<= br> > remit of CLUE.<br> <br> I do have to disagree with you on this point. :-)<br> <br> If CLUE did or did not exist, it would not change the desire to an immersiv= e<br> tag. =A0We're not defining multiple streams, camera positioning, or the= <br> multitude of things people are pouring into "Telepresence". =A0No= ne of that<br> makes any sense of an immersive audio call.<br> <br> This gets back to "what is immersive"? =A0Like RFC 3840, one can = ask "what is<br> text?" =A0(That's another feature tag.) Is this instant messaging = text? =A0Or is<br> this real-time text that is delivered character-at-a-time? =A0There is also= <br> the "mobility" tag. =A0Is that a mobile phone? =A0Is it a laptop = with Wi-Fi? =A0A<br> tablet?<br> <br> I'd like to separate the notion of "immersive" from Teleprese= nce, because I<br> view it as an adjective that is a part of Telepresence. =A0Nonetheless, it = is<br> an adjective that we would like to use with or without Telepresence and in<= br> conjunction with audio and video feature tags.<br> <br> Paul<br> <br> <br> <br> <br> <br> <br> _______________________________________________<br> dispatch mailing list<br> <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/dispatch</a><br> </blockquote></div><br></div> --485b390f7b54e7aeaa04bb1f9665-- From pp3129@att.com Tue Mar 13 08:11:41 2012 Return-Path: <pp3129@att.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1278A21F8716 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 08:11:41 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK5oUu-H17nl for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 08:11:40 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 756EC21F880B for <dispatch@ietf.org>; Tue, 13 Mar 2012 08:11:38 -0700 (PDT) X-Env-Sender: pp3129@att.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1331651497!14823129!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10220 invoked from network); 13 Mar 2012 15:11:37 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-13.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Mar 2012 15:11:37 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2DFC7TX022344; Tue, 13 Mar 2012 11:12:07 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2DFC0XK022216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2012 11:12:03 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint01.pst.cso.att.com (RSA Interceptor); Tue, 13 Mar 2012 11:11:02 -0400 Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([169.254.5.172]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0355.002; Tue, 13 Mar 2012 11:11:02 -0400 From: "PFAUTZ, PENN L" <pp3129@att.com> To: "Peterson, Jon" <jon.peterson@neustar.biz>, "'dispatch@ietf.org'" <dispatch@ietf.org> Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: AQHM+xQ7UaE2MYlCb0+6Ly0bNplLX5ZcQduAgAwc9tA= Date: Tue, 13 Mar 2012 15:11:01 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D6099674@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <55A5A9A87506CB4BA580BF9D531957DA23914ED0@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA23914ED0@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 15:11:41 -0000 I think this is an interesting activity and would not want to derail it, bu= t let me play devil's advocate for a moment... - if we were just starting out, as opposed to having lots of (at least inte= rnal and some external) deployments, I would be more optimistic - although I know that the proposal responds to many concerns that have bee= n raised with enum, I personally don't see the protocol issues or even the = semantics of the of what the protocol can address as ever having been the m= ajor thing that has held enum back from full potential. It's always been la= ck of consensus on administrative arrangements driven by business and -dare= I say- political concerns. Good luck! Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Peterson, Jon Sent: Monday, March 05, 2012 5:05 PM To: 'dispatch@ietf.org' Subject: Re: [dispatch] New Proposal for Telephone-Related Queries Oops, sorry, my mailer did not like the URL I submitted. The correct URL fo= r the draft is: https://datatracker.ietf.org/doc/draft-peterson-terq/ Jon Peterson Neustar, Inc. -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time To: dispatch@ietf.org Subject: [dispatch] New Proposal for Telephone-Related Queries I have a proposal to bounce off the group. Basically, this is a re-examinat= ion of some of the problems we've previously considered in the telephony-sp= ecific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through disc= ussions in the past couple years, it's become clear that we would need to s= ignificantly extend ENUM to get it to handle all of the sorts of sources, s= ubjects, and attributes that people want to factor into queries about telep= hone number routing and administration. Most of these discussions have gott= en wrapped around the axle on questions of the underlying syntax and semant= ics of the DNS, which were a good match for the original vision of a public= , user-driven ENUM, but don't seem to be such a good match for the uses peo= ple actually want to make of these protocols, in federated, service-provide= r-driven environments like those envisioned in SPEERMINT and provisioned in= DRINKS. While the discussion may have died down a bit, the requirements th= at motivated th e discussion definitely aren't going away. Rather than continue to debate the applicability of the DNS and the probity= of various extensions to it, we might make more progress if we work toward= s agreement on the semantics of queries for telephone-related data independ= ently of any underlying protocols. In other words, focus on what kinds of q= uestions about telephone numbers we want to be able to ask, and what kinds = of information needs to go into the answers, and incorporate all this into = an abstract data model. So for example, we know that we want to be able to = express the source of a request in a query. What do we mean by source? I ca= n think of a bunch of different kinds of source: the logical originator of = the query (the administrative entity asking), the logical identity of any i= ntermediary or aggregator forwarding the query, or even the point at the ne= twork from which the call originates (the originating trunk group, SBC or w= hat have you). All three of those concepts of source seem important when it= comes to answe ring questions about telephone numbers, so a data model would treat those = as separate elements which can vary independently - then we can then try to= figure out what's mandatory or optional, etc. We follow this same method f= or all the elements of queries and responses. Figure out what the attribute= s are of telephone numbers that we care about, sort them into buckets of ro= uting data and administrative data, and so on. Once we have an agreement on the data model, then people can map the model = to whatever underlying protocol they'd like - or just build it into a web A= PI, or what have you. Those proposals could advance as separate documents. = Having that flexibility would make it a lot easier to figure out what we re= ally want the questions and answers to be, rather than thinking about what = they realistically can be within the constraints of some existing underlyin= g protocol. That's the idea. I'm not going to present a proposed charter for work or an= ything like that in Paris, but I am interested in hearing if people think t= his is a promising approach, and if so, perhaps we'd put a charter on the a= genda for Vancouver. I have however submitted a -00 draft for this time whi= ch gives a high-level proposal for a data model and at least enumerates wha= t some of the elements might be that would be populated in queries and resp= onses. This is a pretty broad sketch, but it should convey the basic idea. = You can check it out here: https://exchcas.va.neustar.com/owa/thoughts about the direction or the spec= ifics of the data model are welcome. Thanks! Jon Peterson NeuStar, Inc. _______________________________________________ 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@alum.mit.edu Tue Mar 13 08:38:38 2012 Return-Path: <pkyzivat@alum.mit.edu> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305BF21F8929 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 08:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuoEvB3VSYGU for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 08:38:37 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id ED04D21F8927 for <dispatch@ietf.org>; Tue, 13 Mar 2012 08:38:36 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta05.westchester.pa.mail.comcast.net with comcast id l2tA1i00917dt5G553ed2E; Tue, 13 Mar 2012 15:38:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta13.westchester.pa.mail.comcast.net with comcast id l3ec1i01v07duvL3Z3edWM; Tue, 13 Mar 2012 15:38:37 +0000 Message-ID: <4F5F69FB.6060308@alum.mit.edu> Date: Tue, 13 Mar 2012 11:38:35 -0400 From: Paul Kyzivat <pkyzivat@alum.mit.edu> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> <3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com> <03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> In-Reply-To: <03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 15:38:38 -0000 On 3/13/12 3:21 AM, Paul E. Jones wrote: > Adam, > > The intent was to register a new capability and the registration appears > with sip. prepended in the I-D. What I’m missing is the message > apparently sent by Paul K. regarding usage of that new tag in the > contact header. Does it require a +sip. or can we use sip.? Is sip. > stripped or not? Reading page 7, it seems to suggest that tags that are > not the “base tags” (those defined and enumerated on page 7) sip. cannot > be stripped /and/ a + sign prepended. I may not be reading that > correctly, thus the reason for the question below. I can explain the history and rationale for the naming. For most of the time while the drafts of callerprefs were evolving, the capabilities were a namespace unto themselves, as were the matching rules. Somewhere toward the end of the process, I think after it went to the IESG, the authors (Jonathan Rosenberg and I) were instructed to unify this with the preexisting feature tag mechanism. (IMO this was a mistake, buts lets not go there now.) The feature tag mechanism already had a registry and rules for extending it. It also had the notion of sub-trees in the registry. Because the semantics of our tags was largely disjoint from the existing tags, it was decided to define a new sub-tree (sip.) for sip usage, except for a few tags that were perceived to have shared meaning. We also wanted a way for servers to distinguish feature tags from other parameters in Contact headers, so that it could do appropriate callerprefs processing even when tags were present that the server didn't understand. This led to the "+" prefix to distinguish them. We would have had all feature tags in Contact headers follow this syntax, but by this time the draft had been in the wild for a long time and we were concerned about backward compatibility. So we "grandfathered" the tags that had been in the draft. But all new usage must use the "+" syntax and use the full name of the tag. > The broader issue is why we propose the introduction of this feature > tag. We’re not trying to “jump to a broken, semantic-free mechanism.” > The intent is to define a user agent capability and, more specifically, > a feature tag. The intent is to introduce something similar to those > defined in RFC 3840. Just as a device might be mobile, or a device > might do video, we wanted something to indicate that a device has an > immersive quality. Why is sip.class defined to indicate that a device > is in a business setting or personal setting? With whatever logic was > applied there, I would think specifying that a device is classified as > “immersive” or not should apply. > > The issue is that the IETF has defined the car (RFC 3840) into which we > wish to install a radio, but folks are suggesting that we’re taking the > wrong approach because the car isn’t actually a car, but a horse drawn > carriage without electrical power and therefore impossible to support a > radio. Or, perhaps RFC 3840 is a defective Pinto that needs to be recalled? > > You’re a smart fellow. You understand the idea behind classifying a > device as “immersive”. I'm sure Adam will respond to this, but I also want to respond. IMO "immersive" is a marketing buzzword. For the purposes here is has no clear agreed upon meaning. In this regard it is quite different from "audio" or "video". You have stated that something can be immersive even though it has no video. Can something be immersive with video and no audio? Can something be immersive without either audio or video? (Perhaps floating in one of those isolation tanks. At least there you are truly immersed.) Nor is it at all clear what one should do differently after knowing that something is immersive. I suspect there is *something* distinct here worth investigating and talking about. But just defining a word whose meaning is in the eye of the beholder isn't going to be helpful. > There’s no magic to this, one does not need a > voluminous document to convey the idea, nor are we trying to invent > something that is out in left field that warrants such an elaborate > document. As with all of the other very short registrations appearing > in RFC 3840, we merely propose to register a “sip.immersive” tag so that > we can know when a device registers that it is an “immersive” device. > When the device calls another device, it can indicate via the > Accept-Contact and Reject-Contact headers its preferences for > communicating with another device that is classified as “immersive”. The feature tag namespace includes sub-trees that don't require an rfc. You can mint a tag in the "u." tree without any process at all. Or you can mint a tag in the global ("g.") tree with only expert review. If you just need a tag for proprietary use (about the only kind I can see would work given the fuzzy definitions provided so far) then going with the "u." form is probably your best bet. For instance you could use: u.http://features.cisco.com/immersive In sip the character set limitations require that to be transformed a bit (see 3840, section 5: "Each forward slash in the feature tag is converted to a single quote, and each colon are converted to an exclamation point"). So you would have something like: Contact:sip:foo.com;+u.http!''features.cisco.com'immersive > The definition of immersive might be in question; a portion of the > definition for Telepresence could be used. Telepresence brings with it > much more than the immersive quality, as I mentioned before. We could > work to define “immersive” if that was the only concern, but I don’t > think that is the issue. Yes, its a lot of the issue. > I’m certainly open to suggestions for how this should be accomplished. > If this absolutely does not fit within the RFC 3840 framework, then I > can accept the fact that I do not understand the point of RFC 3840. Whether it fits into the 3840 framework depends upon what you want to do with it. IMO doing admission control based on *capabilities* doesn't fit the framework. Thanks, Paul > Paul > > *From:*Adam Roach [mailto:adam@nostrum.com] > *Sent:* Tuesday, March 13, 2012 1:12 AM > *To:* Paul E. Jones > *Cc:* Worley, Dale R (Dale); Glen Lavers (glavers); <dispatch@ietf.org> > *Subject:* Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt > > On Mar 12, 2012, at 20:05, "Paul E. Jones" <paulej@packetizer.com > <mailto:paulej@packetizer.com>> wrote: > > Syntactically, the "immersive" tag is allowed per RFC 3261 syntax. > Per RFC > 3640, it seemed to suggest +sip was needed, but it was not clear how > one can > define new "base" tags that do not require +sip. So, there is no > possibility for introducing new base tags -- ever? > > You can define new parameters, sure. But they aren't capability tags > without the +sip.xxx syntax. You seem to think you want to define a > capability. If that turns out to be the case, you'll need the +sip prefix. > > Now, I personally think you have jumped to a broken, semantic-free > mechanism to satisfy implied and vaguely defined requirements, rather > than taking the more straightforward route of coming to the WG with > solid, clear requirements, and soliciting input on reasonable mechanisms > for meeting those requirements. The discussion around syntax of > capability tags is like arguing over whether the car you've specified > should have pin stripes, rather than discussing the broader issue of > whether a car is actually the best tool for cooking pancakes. > > Your requirements are probably valid, and it would be good to have them > stated in a clear /and exhaustive/ fashion. Your proposed mechanism, > however, is misguided. > > /a > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Tue Mar 13 09:17:56 2012 Return-Path: <dworley@avaya.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEE321E8021 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 09:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.426 X-Spam-Level: X-Spam-Status: No, score=-103.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXOI16y558GJ for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 09:17:55 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3F22A21E801F for <dispatch@ietf.org>; Tue, 13 Mar 2012 09:17:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAO9xX0/GmAcF/2dsb2JhbABDtWOBB4IJAQEBAQIBEmcFCwIBCA0IMTIlAgQOBQgah2MFoDGcGJACYwSbW4oYgwE X-IronPort-AV: E=Sophos;i="4.73,577,1325480400"; d="scan'208";a="296820221" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Mar 2012 12:17:53 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Mar 2012 12:10:01 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 13 Mar 2012 12:17:52 -0400 From: "Worley, Dale R (Dale)" <dworley@avaya.com> To: "Paul E. Jones" <paulej@packetizer.com> Date: Tue, 13 Mar 2012 12:16:52 -0400 Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: AQIGlAq4PGrll3yWVQrHLtOjxHlL0QGM5LtOApsegtMCwxqCqQIVAynKArlo1yYCM/uG3wIxpaqWlXOnG8CAAKDgVw== Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0958@DC-US1MBEX4.global.avaya.com> References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> <3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com>, <03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> In-Reply-To: <03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 16:17:56 -0000 > From: Paul E. Jones [paulej@packetizer.com] >=20 > Thanks for the thorough review (as usual) :) You'd be surprised how stateless the process is by which I've written these messages. If I thought the subject was important, I'd do a *properly* thorough review of the draft. > From: Paul E. Jones [paulej@packetizer.com] > > You=92re a smart fellow. You understand the idea behind classifying a > device as =93immersive=94. I may or may not be a smart fellow, but I don't understand the idea behind classifying a device as "immersive". More exactly, I understand it as a somewhat fuzzy property that a system may or may not have, but I don't understand why devices should declare it, or why a caller would care whether the destination UA had it or not. =20 > The intent is to introduce something similar to those defined in RFC 3840= . In this regard, it is very different from "audio" or "video", as those describe the ability to render particular types of media stream (a clearly-defined technological difference), and relate to the sensory modes by which the interlocutors communicate (a clearly-defined user experience difference). As I said before, the clear motivation for a feature tag is if some incoming calls would prefer the destination to have it, and some incoming calls would prefer the destination to *not* have it. Glen Lavers has provided some significant motivation based on bandwidth/QoS considerations. But in that regard, I think a generalized "device class" property would be more effective in the long run, as it would be extensible in whatever way the network operator wanted. Dale From glavers@cisco.com Tue Mar 13 10:32:58 2012 Return-Path: <glavers@cisco.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB8A21E8020 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 10:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.214 X-Spam-Level: X-Spam-Status: No, score=-10.214 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3cUXmjClmt8 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 10:32:56 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C5CA921E8015 for <dispatch@ietf.org>; Tue, 13 Mar 2012 10:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=glavers@cisco.com; l=8993; q=dns/txt; s=iport; t=1331659976; x=1332869576; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=0ByCePMGH8CsNq2PWE8OzIrV9qgIx7WK5m5xFeHENa0=; b=Ug0tTQBaOsKHHM4YWPvgw5WMT45YwPTkJL1+mGwCEHQzlC80hNraufll 8eWkuKys4mJ6MzTteX0W3anoL/PwGMNNtjL/F1L1dkx0E2y/EqOJWTnCw mRUZKKlJWrV2vJrI3FZm7OmpAA/vAkB5c76OCSBsWcu/dtt5RDJrs8HNt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHWDX0+rRDoG/2dsb2JhbABDDrVagQeCCQEBAQQBAQEPAR0KLQQDARYEAgEIDgMEAQEBCgYXAQYBJh8JCAEBBAESCBqHZwELnRsBllSIQJACYwSIVZ0egi5X X-IronPort-AV: E=Sophos;i="4.73,578,1325462400"; d="scan'208";a="35943850" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 13 Mar 2012 17:32:56 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2DHWuN7013107; Tue, 13 Mar 2012 17:32:56 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 10:32:56 -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: Tue, 13 Mar 2012 10:32:55 -0700 Message-ID: <DBF2B0884D5308458C2C5521C4F771320102247B@xmb-sjc-236.amer.cisco.com> In-Reply-To: <4F5F69FB.6060308@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Ac0BL2Ad4u8D0LoqRVCXF0cPNHDp6AACu5rA References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com><85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca><DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com><4F57BCBA.3020206@nostrum.com><DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com><CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com><035501cd00b5$5fcddd20$1f699760$@packetizer.com><3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com><03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> <4F5F69FB.6060308@alum.mit.edu> From: "Glen Lavers (glavers)" <glavers@cisco.com> To: "Paul Kyzivat" <pkyzivat@alum.mit.edu>, <dispatch@ietf.org>, <adam@nostrum.com>, "Worley, Dale R (Dale)" <dworley@avaya.com> X-OriginalArrivalTime: 13 Mar 2012 17:32:56.0246 (UTC) FILETIME=[53B39D60:01CD013F] Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 17:32:58 -0000 Paul, Adam, Dale, What is the criteria for a media feature tag? Can you define that for me? -glen > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Tuesday, March 13, 2012 8:39 AM > To: dispatch@ietf.org > Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt >=20 > On 3/13/12 3:21 AM, Paul E. Jones wrote: > > Adam, > > > > The intent was to register a new capability and the registration > > appears with sip. prepended in the I-D. What I'm missing is the > > message apparently sent by Paul K. regarding usage of that new tag in > > the contact header. Does it require a +sip. or can we use sip.? Is sip. > > stripped or not? Reading page 7, it seems to suggest that tags that > > are not the "base tags" (those defined and enumerated on page 7) sip. > > cannot be stripped /and/ a + sign prepended. I may not be reading > > that correctly, thus the reason for the question below. >=20 > I can explain the history and rationale for the naming. >=20 > For most of the time while the drafts of callerprefs were evolving, the > capabilities were a namespace unto themselves, as were the matching rules. > Somewhere toward the end of the process, I think after it went to the IESG, the > authors (Jonathan Rosenberg and I) were instructed to unify this with the > preexisting feature tag mechanism. (IMO this was a mistake, buts lets not go > there now.) >=20 > The feature tag mechanism already had a registry and rules for extending it. It > also had the notion of sub-trees in the registry. Because the semantics of our > tags was largely disjoint from the existing tags, it was decided to define a new > sub-tree (sip.) for sip usage, except for a few tags that were perceived to have > shared meaning. >=20 > We also wanted a way for servers to distinguish feature tags from other > parameters in Contact headers, so that it could do appropriate callerprefs > processing even when tags were present that the server didn't understand. This > led to the "+" prefix to distinguish them. >=20 > We would have had all feature tags in Contact headers follow this syntax, but > by this time the draft had been in the wild for a long time and we were > concerned about backward compatibility. So we "grandfathered" the tags that > had been in the draft. But all new usage must use the "+" syntax and use the > full name of the tag. >=20 > > The broader issue is why we propose the introduction of this feature > > tag. We're not trying to "jump to a broken, semantic-free mechanism." > > The intent is to define a user agent capability and, more > > specifically, a feature tag. The intent is to introduce something > > similar to those defined in RFC 3840. Just as a device might be > > mobile, or a device might do video, we wanted something to indicate > > that a device has an immersive quality. Why is sip.class defined to > > indicate that a device is in a business setting or personal setting? > > With whatever logic was applied there, I would think specifying that a > > device is classified as "immersive" or not should apply. > > > > The issue is that the IETF has defined the car (RFC 3840) into which > > we wish to install a radio, but folks are suggesting that we're taking > > the wrong approach because the car isn't actually a car, but a horse > > drawn carriage without electrical power and therefore impossible to > > support a radio. Or, perhaps RFC 3840 is a defective Pinto that needs to be > recalled? > > > > You're a smart fellow. You understand the idea behind classifying a > > device as "immersive". >=20 > I'm sure Adam will respond to this, but I also want to respond. > IMO "immersive" is a marketing buzzword. For the purposes here is has no > clear agreed upon meaning. In this regard it is quite different from "audio" or > "video". You have stated that something can be immersive even though it has > no video. Can something be immersive with video and no audio? Can > something be immersive without either audio or video? > (Perhaps floating in one of those isolation tanks. At least there you are truly > immersed.) >=20 > Nor is it at all clear what one should do differently after knowing that > something is immersive. >=20 > I suspect there is *something* distinct here worth investigating and talking > about. But just defining a word whose meaning is in the eye of the beholder > isn't going to be helpful. >=20 > > There's no magic to this, one does not need a voluminous document to > > convey the idea, nor are we trying to invent something that is out in > > left field that warrants such an elaborate document. As with all of > > the other very short registrations appearing in RFC 3840, we merely > > propose to register a "sip.immersive" tag so that we can know when a > > device registers that it is an "immersive" device. > > When the device calls another device, it can indicate via the > > Accept-Contact and Reject-Contact headers its preferences for > > communicating with another device that is classified as "immersive". >=20 > The feature tag namespace includes sub-trees that don't require an rfc. > You can mint a tag in the "u." tree without any process at all. Or you can mint a > tag in the global ("g.") tree with only expert review. >=20 > If you just need a tag for proprietary use (about the only kind I can see would > work given the fuzzy definitions provided so far) then going with the "u." form is > probably your best bet. >=20 > For instance you could use: u.http://features.cisco.com/immersive >=20 > In sip the character set limitations require that to be transformed a bit (see > 3840, section 5: "Each forward slash in the feature tag is converted to a single > quote, and each colon are converted to an exclamation point"). So you would > have something like: >=20 > Contact:sip:foo.com;+u.http!''features.cisco.com'immersive >=20 > > The definition of immersive might be in question; a portion of the > > definition for Telepresence could be used. Telepresence brings with > > it much more than the immersive quality, as I mentioned before. We > > could work to define "immersive" if that was the only concern, but I > > don't think that is the issue. >=20 > Yes, its a lot of the issue. >=20 > > I'm certainly open to suggestions for how this should be accomplished. > > If this absolutely does not fit within the RFC 3840 framework, then I > > can accept the fact that I do not understand the point of RFC 3840. >=20 > Whether it fits into the 3840 framework depends upon what you want to do > with it. >=20 > IMO doing admission control based on *capabilities* doesn't fit the framework. >=20 > Thanks, > Paul >=20 > > Paul > > > > *From:*Adam Roach [mailto:adam@nostrum.com] > > *Sent:* Tuesday, March 13, 2012 1:12 AM > > *To:* Paul E. Jones > > *Cc:* Worley, Dale R (Dale); Glen Lavers (glavers); > > <dispatch@ietf.org> > > *Subject:* Re: [dispatch] > > draft-lavers-sipcore-immersive-capability-00.txt > > > > On Mar 12, 2012, at 20:05, "Paul E. Jones" <paulej@packetizer.com > > <mailto:paulej@packetizer.com>> wrote: > > > > Syntactically, the "immersive" tag is allowed per RFC 3261 syntax. > > Per RFC > > 3640, it seemed to suggest +sip was needed, but it was not clear how > > one can > > define new "base" tags that do not require +sip. So, there is no > > possibility for introducing new base tags -- ever? > > > > You can define new parameters, sure. But they aren't capability tags > > without the +sip.xxx syntax. You seem to think you want to define a > > capability. If that turns out to be the case, you'll need the +sip prefix. > > > > Now, I personally think you have jumped to a broken, semantic-free > > mechanism to satisfy implied and vaguely defined requirements, rather > > than taking the more straightforward route of coming to the WG with > > solid, clear requirements, and soliciting input on reasonable > > mechanisms for meeting those requirements. The discussion around > > syntax of capability tags is like arguing over whether the car you've > > specified should have pin stripes, rather than discussing the broader > > issue of whether a car is actually the best tool for cooking pancakes. > > > > Your requirements are probably valid, and it would be good to have > > them stated in a clear /and exhaustive/ fashion. Your proposed > > mechanism, however, is misguided. > > > > /a > > > > > > > > _______________________________________________ > > 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 dworley@avaya.com Tue Mar 13 11:19:33 2012 Return-Path: <dworley@avaya.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38CE21F883D for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 11:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.43 X-Spam-Level: X-Spam-Status: No, score=-103.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zevUtlbRTXVA for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 11:19:32 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4C26E21F8839 for <dispatch@ietf.org>; Tue, 13 Mar 2012 11:19:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACyPX0+HCzI1/2dsb2JhbABDtWuBB4IJAQEBAQIBEihECwIBCA0IIRAyJQEBBAESCBqHYwWgBZwUiiyFVmMEm1uKGIMBgTg X-IronPort-AV: E=Sophos;i="4.73,578,1325480400"; d="scan'208";a="296848188" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Mar 2012 14:19:28 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Mar 2012 14:04:07 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 13 Mar 2012 14:19:26 -0400 From: "Worley, Dale R (Dale)" <dworley@avaya.com> To: "Glen Lavers (glavers)" <glavers@cisco.com>, "dispatch@ietf.org" <dispatch@ietf.org> Date: Tue, 13 Mar 2012 14:19:26 -0400 Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Ac0BL2Ad4u8D0LoqRVCXF0cPNHDp6AACu5rAAAKre5I= Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A095C@DC-US1MBEX4.global.avaya.com> References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com><85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca><DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com><4F57BCBA.3020206@nostrum.com><DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com><CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com><035501cd00b5$5fcddd20$1f699760$@packetizer.com><3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com><03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> <4F5F69FB.6060308@alum.mit.edu>, <DBF2B0884D5308458C2C5521C4F771320102247B@xmb-sjc-236.amer.cisco.com> In-Reply-To: <DBF2B0884D5308458C2C5521C4F771320102247B@xmb-sjc-236.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] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 18:19:33 -0000 > From: Glen Lavers (glavers) [glavers@cisco.com] >=20 > What is the criteria for a media feature tag? Can you define that for > me? At root, the registry is specified in RFC 3840: 12.1. SIP Media Feature Tag Registration Tree This specification serves to create a new media feature tag registration tree, per the guidelines of Section 3.1.4 of RFC 2506 [3]. The name of this tree is the "SIP Media Feature Tag Registration Tree", and its prefix is "sip.". It is used for the registration of media feature tags that are applicable to the Session Initiation Protocol, and whose meaning is only defined within that usage. The addition of entries into this registry occurs through IETF consensus, as defined in RFC 2434 [18]. This requires the publication of an RFC that contains the registration. The information required in the registration is identical to the IETF tree. As such, specifications adding entries to the registry should use the template provided in Section 3.4 of RFC 2506. Note that all media feature tags registered in the SIP tree will have names with a prefix of "sip.". No leading "+" is used in the registrations in any of the media feature tag trees. RFC 2506 says: 2.1 Media feature tag purpose Media feature tags represent individual and simple characteristics related to media capabilities or properties associated with the resource to which they are applied. Examples of such features are: * the color depth of the screen on which something is to be displayed * the type of paper available in a printer * the support of the `floating 5 dimensional tables' feature * the fonts which are available to the recipient * the capability to display graphical content Each media feature tag identifies a single characteristic. Values associated with a specific tag must use the data type defined for that tag. The list of allowed data types is presented below, in section 2.3. Examples of media feature tags with values are: * the width of a display in pixels per centimeter represented as an integer value. * a font available to a recipient, selected from an enumerated list. * the version of a protocol composed of integers "i.j.k", defined as either a value in an enumerated list or with a defined mapping to make the value isomorphic to a subset of integers (e.g. i*100 + j*10 +k, assuming j<=3D9 and k<=3D9). Further examples of media feature tags are defined in detail elsewhere [4]. Feature collections may be composed using a number of individual feature tags [2]. Composition of feature collections is described elsewhere [2]. Examples of feature collections requiring multiple media feature tags are: * the set of all fonts used by a document * the width and height of a display * the combination of color depth and resolution a display can support This registry presumes the availability of the MIME media type registry, and MIME media types MUST NOT be re-registered as media feature tags. Media feature tags which are currently in use by individual protocols or applications MAY be registered with this registry if they might be applied outside of their current domain. The media feature tag namespace is not bound to a particular transport protocol or capability exchange mechanism. The registry is limited, however, to feature tags which express a capability or preference related to how content is presented. Feature tags related to other axes of negotiation are not appropriate for this registry. Capability exchange mechanisms may, of course, be used to express a variety of capabilities or preferences. Which isn't very specific. I would say that something is an appropriate media feature tag if it is "simple" (not easily decomposed into a multiple, orthogonal features) and if it's useful (the other UA might consider modifying its media stream based on the feature tag and/or would have a preference for contacting one UA versus another UA based on the values of the feature tag). Dale From pkyzivat@alum.mit.edu Tue Mar 13 11:43:57 2012 Return-Path: <pkyzivat@alum.mit.edu> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA11821E8040 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 11:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNJ+DD4gt6nT for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 11:43:55 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id ACBD221F86B7 for <dispatch@ietf.org>; Tue, 13 Mar 2012 11:43:55 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id l4zD1i0011YDfWL5F6jssA; Tue, 13 Mar 2012 18:43:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id l6jr1i02N07duvL3g6jsTs; Tue, 13 Mar 2012 18:43:52 +0000 Message-ID: <4F5F9566.6000009@alum.mit.edu> Date: Tue, 13 Mar 2012 14:43:50 -0400 From: Paul Kyzivat <pkyzivat@alum.mit.edu> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com><85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca><DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com><4F57BCBA.3020206@nostrum.com><DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com><CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com><035501cd00b5$5fcddd20$1f699760$@packetizer.com><3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com><03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> <4F5F69FB.6060308@alum.mit.edu>, <DBF2B0884D5308458C2C5521C4F771320102247B@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A095C@DC-US1MBEX4.global.avaya.com> In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A095C@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 18:43:57 -0000 On 3/13/12 2:19 PM, Worley, Dale R (Dale) wrote: >> From: Glen Lavers (glavers) [glavers@cisco.com] >> >> What is the criteria for a media feature tag? Can you define that for >> me? Dale pretty much covered it below. Its not very clear. And the fact that its merged into the mechanisms and definitions of 2506 isn't particularly helpful. If I had it do to again I would want to be more specific. Dale's last paragraph is very similar to what I would say. In full disclosure - 2506 calls for expert review on new additions to the global tree. The last expert quit because all the requests he was getting were for sip usage (by 3gpp), and he didn't feel qualified. I was asked to take over this role. I'm not certain, but I think that was approved. But if so I have had no requests. But 2506 doesn't give a lot of guidance to the expert about this. (Note that expert review only applies to the global ("g.") tree. It doesn't apply to the "sip." tree (RFC required) or the "u." tree (no action required).) One thing I think is important is that the features should be independent of one another (orthogonal). Overlapping feature definitions will lead to ambiguities in how to tag things. And they need to be well specified so that reasonable and informed people will come to the same conclusion about whether a tag applies in a given situation. Thanks, Paul > At root, the registry is specified in RFC 3840: > > 12.1. SIP Media Feature Tag Registration Tree > > This specification serves to create a new media feature tag > registration tree, per the guidelines of Section 3.1.4 of RFC 2506 > [3]. The name of this tree is the "SIP Media Feature Tag > Registration Tree", and its prefix is "sip.". It is used for the > registration of media feature tags that are applicable to the Session > Initiation Protocol, and whose meaning is only defined within that > usage. > > The addition of entries into this registry occurs through IETF > consensus, as defined in RFC 2434 [18]. This requires the > publication of an RFC that contains the registration. The > information required in the registration is identical to the IETF > tree. As such, specifications adding entries to the registry should > use the template provided in Section 3.4 of RFC 2506. Note that all > media feature tags registered in the SIP tree will have names with a > prefix of "sip.". No leading "+" is used in the registrations in any > of the media feature tag trees. > > RFC 2506 says: > > 2.1 Media feature tag purpose > > Media feature tags represent individual and simple characteristics > related to media capabilities or properties associated with the > resource to which they are applied. Examples of such features are: > > * the color depth of the screen on which something is to be displayed > * the type of paper available in a printer > * the support of the `floating 5 dimensional tables' feature > * the fonts which are available to the recipient > * the capability to display graphical content > > Each media feature tag identifies a single characteristic. Values > associated with a specific tag must use the data type defined for > that tag. The list of allowed data types is presented below, in > section 2.3. > > Examples of media feature tags with values are: > > * the width of a display in pixels per centimeter represented as an > integer value. > * a font available to a recipient, selected from an enumerated list. > * the version of a protocol composed of integers "i.j.k", defined as > either a value in an enumerated list or with a defined mapping to > make the value isomorphic to a subset of integers (e.g. i*100 + j*10 > +k, assuming j<=9 and k<=9). > > Further examples of media feature tags are defined in detail > elsewhere [4]. > > Feature collections may be composed using a number of individual > feature tags [2]. Composition of feature collections is described > elsewhere [2]. Examples of feature collections requiring multiple > media feature tags are: > > * the set of all fonts used by a document > * the width and height of a display > * the combination of color depth and resolution a display can support > > This registry presumes the availability of the MIME media type > registry, and MIME media types MUST NOT be re-registered as media > feature tags. Media feature tags which are currently in use by > individual protocols or applications MAY be registered with this > registry if they might be applied outside of their current domain. > > The media feature tag namespace is not bound to a particular > transport protocol or capability exchange mechanism. The registry is > limited, however, to feature tags which express a capability or > preference related to how content is presented. Feature tags related > to other axes of negotiation are not appropriate for this registry. > Capability exchange mechanisms may, of course, be used to express a > variety of capabilities or preferences. > > Which isn't very specific. I would say that something is an > appropriate media feature tag if it is "simple" (not easily decomposed > into a multiple, orthogonal features) and if it's useful (the other UA > might consider modifying its media stream based on the feature tag > and/or would have a preference for contacting one UA versus another UA > based on the values of the feature tag). > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From jon.peterson@neustar.biz Tue Mar 13 11:54:45 2012 Return-Path: <jon.peterson@neustar.biz> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892E921F8726 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 11:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.255 X-Spam-Level: X-Spam-Status: No, score=-106.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UMfNVY4c44x for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 11:54:44 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id E6B1D21F8720 for <dispatch@ietf.org>; Tue, 13 Mar 2012 11:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1331664921; x=1647022495; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=BVxqoYnK4WZARdWMRfZjZ 4YTGBYwOlVHPO1EqCDi/f4=; b=Ll4bFkyQgq569Pt/cfcigdSlVu2Dio5GJTSfY BeKcM1vTJl8UFtCV6lSpdHfbr/K1l0uU29IFs2DSwv2KvwBBw== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.6269928; Tue, 13 Mar 2012 14:55:20 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 13 Mar 2012 14:54:40 -0400 From: "Peterson, Jon" <jon.peterson@neustar.biz> To: "PFAUTZ, PENN L" <pp3129@att.com>, "'dispatch@ietf.org'" <dispatch@ietf.org> Date: Tue, 13 Mar 2012 14:54:39 -0400 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: AQHM+xQ7UaE2MYlCb0+6Ly0bNplLX5ZcQduAgAwc9tCAAB7o5g== Message-ID: <55A5A9A87506CB4BA580BF9D531957DA239D6360@STNTEXCH01.cis.neustar.com> References: <55A5A9A87506CB4BA580BF9D531957DA23914ED0@STNTEXCH01.cis.neustar.com>, <38726EDA2109264987B45E29E758C4D6099674@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D6099674@MISOUT7MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: ukTz05poa5bsLvfXY0HPWA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 18:54:45 -0000 Hi Penn, Glad to hear this is of interest, at least. Certainly agreed that there is = ENUM deployment out there - in fact, my own company does a bit of it. When = protocols become successful and see deployment, people do start using them = in unexpected ways which sometimes require significant modifications, and e= ventually you can reach a tipping point where it makes sense to reconsider = the fundamentals. I think we've reached that point with ENUM, where we have= seen proposals to extend ENUM (and the DNS) that warrant taking a step bac= k and exploring whether or not we can get a better overall framework in pla= ce - at least a framework in which we can standardize features that have be= en proposed for ENUM but which fall outside the ways we can responsibly ext= end the DNS. Also agreed, by the by, that administrative and political factors have held= ENUM back from being all that it can be. You'll note that the TeRQ proposa= l does not prescribe any administrative framework like e164.arpa - it's rea= lly just a query/response protocol. The irony of e164.arpa is that it appli= ed well to the original, public vision of ENUM, but has sometimes ended up = hampering attempts to get the carrier-driven, more infrastructural deployme= nts off the ground. No one is expecting that the TeRQ proposal will snuff out ENUM deployment o= vernight. I'm sure ENUM will continue to serve a segment of the market for = the foreseeable future. But ENUM was standardized twelve years ago now - a = pretty good life cycle for any protocol. All I'm really proposing is that w= e see how much we could gain from starting on a different foundation. If we= end up with something better, it will eventually phase into the market and= get traction. All a standards activity can do is create that opportunity. Jon Peterson NeuStar, Inc. ________________________________________ From: PFAUTZ, PENN L [pp3129@att.com] Sent: Tuesday, March 13, 2012 8:11 AM To: Peterson, Jon; 'dispatch@ietf.org' Subject: RE: [dispatch] New Proposal for Telephone-Related Queries I think this is an interesting activity and would not want to derail it, bu= t let me play devil's advocate for a moment... - if we were just starting out, as opposed to having lots of (at least inte= rnal and some external) deployments, I would be more optimistic - although I know that the proposal responds to many concerns that have bee= n raised with enum, I personally don't see the protocol issues or even the = semantics of the of what the protocol can address as ever having been the m= ajor thing that has held enum back from full potential. It's always been la= ck of consensus on administrative arrangements driven by business and -dare= I say- political concerns. Good luck! Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Peterson, Jon Sent: Monday, March 05, 2012 5:05 PM To: 'dispatch@ietf.org' Subject: Re: [dispatch] New Proposal for Telephone-Related Queries Oops, sorry, my mailer did not like the URL I submitted. The correct URL fo= r the draft is: https://datatracker.ietf.org/doc/draft-peterson-terq/ Jon Peterson Neustar, Inc. -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time To: dispatch@ietf.org Subject: [dispatch] New Proposal for Telephone-Related Queries I have a proposal to bounce off the group. Basically, this is a re-examinat= ion of some of the problems we've previously considered in the telephony-sp= ecific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through disc= ussions in the past couple years, it's become clear that we would need to s= ignificantly extend ENUM to get it to handle all of the sorts of sources, s= ubjects, and attributes that people want to factor into queries about telep= hone number routing and administration. Most of these discussions have gott= en wrapped around the axle on questions of the underlying syntax and semant= ics of the DNS, which were a good match for the original vision of a public= , user-driven ENUM, but don't seem to be such a good match for the uses peo= ple actually want to make of these protocols, in federated, service-provide= r-driven environments like those envisioned in SPEERMINT and provisioned in= DRINKS. While the discussion may have died down a bit, the requirements th= at motivated th e discussion definitely aren't going away. Rather than continue to debate the applicability of the DNS and the probity= of various extensions to it, we might make more progress if we work toward= s agreement on the semantics of queries for telephone-related data independ= ently of any underlying protocols. In other words, focus on what kinds of q= uestions about telephone numbers we want to be able to ask, and what kinds = of information needs to go into the answers, and incorporate all this into = an abstract data model. So for example, we know that we want to be able to = express the source of a request in a query. What do we mean by source? I ca= n think of a bunch of different kinds of source: the logical originator of = the query (the administrative entity asking), the logical identity of any i= ntermediary or aggregator forwarding the query, or even the point at the ne= twork from which the call originates (the originating trunk group, SBC or w= hat have you). All three of those concepts of source seem important when it= comes to answe ring questions about telephone numbers, so a data model would treat those = as separate elements which can vary independently - then we can then try to= figure out what's mandatory or optional, etc. We follow this same method f= or all the elements of queries and responses. Figure out what the attribute= s are of telephone numbers that we care about, sort them into buckets of ro= uting data and administrative data, and so on. Once we have an agreement on the data model, then people can map the model = to whatever underlying protocol they'd like - or just build it into a web A= PI, or what have you. Those proposals could advance as separate documents. = Having that flexibility would make it a lot easier to figure out what we re= ally want the questions and answers to be, rather than thinking about what = they realistically can be within the constraints of some existing underlyin= g protocol. That's the idea. I'm not going to present a proposed charter for work or an= ything like that in Paris, but I am interested in hearing if people think t= his is a promising approach, and if so, perhaps we'd put a charter on the a= genda for Vancouver. I have however submitted a -00 draft for this time whi= ch gives a high-level proposal for a data model and at least enumerates wha= t some of the elements might be that would be populated in queries and resp= onses. This is a pretty broad sketch, but it should convey the basic idea. = You can check it out here: https://exchcas.va.neustar.com/owa/thoughts about the direction or the spec= ifics of the data model are welcome. Thanks! Jon Peterson NeuStar, Inc. _______________________________________________ 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 paulej@packetizer.com Tue Mar 13 14:12:17 2012 Return-Path: <paulej@packetizer.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA4521F8688 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 14:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzsG6V8xgwKU for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 14:12:17 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E40FC21F8687 for <dispatch@ietf.org>; Tue, 13 Mar 2012 14:12:16 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2DLCEmT018077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2012 17:12:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331673135; bh=4EfEqP2NRJF3YkidNbDkg5l14b+xuPRSEl2b7bLzv2o=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=V4APC2c1sTPUOJhxEfkgRt7AMPZCvI0+ER0IFl8A0IUQWajh0/khmlzZFui5pWWJU jrmIBJ9sj/q37l/YxfZb9N+fq+YPdjgMqM9Yr47NrI9Lu4QLKtfFPizu6ckXq/8b+s nUVzECHhetYuQCpcAAuCoJS4gxj3auZpEHelODEQ= From: "Paul E. Jones" <paulej@packetizer.com> To: "'Worley, Dale R \(Dale\)'" <dworley@avaya.com> References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> <3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com>, <03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> <CD5674C3CD99574EBA7432465FC13C1B22726A0958@DC-US1MBEX4.global.avaya.com> In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A0958@DC-US1MBEX4.global.avaya.com> Date: Tue, 13 Mar 2012 17:12:20 -0400 Message-ID: <051901cd015d$fa776f50$ef664df0$@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: AQIGlAq4PGrll3yWVQrHLtOjxHlL0QGM5LtOApsegtMCwxqCqQIVAynKArlo1yYCM/uG3wIxpaqWAO9fLk4CQjY7WpVbC3sQ Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 21:12:17 -0000 Dale, > I may or may not be a smart fellow, but I don't understand the idea behind > classifying a device as "immersive". More exactly, I understand it as a > somewhat fuzzy property that a system may or may not have, but I don't > understand why devices should declare it, or why a caller would care > whether the destination UA had it or not. Our expectation was that a user, and more likely a system administrator, will "declare" that a device is "immersive" or not. That becomes subjective, perhaps, but that is what the user preferred. Along with that preference, the system would be configured to have or not have a preference or requirement to establish a call to another device that advertises the same property. We viewed this as similar to a user wanting to place a call to a text-enabled device. There's no value for a deaf person connecting to an audio-only device. In the same spirit, we wanted to allow a user to indicate a preferred device. The meaning of "immersive" may be considered subjective, but the logic followed is clear. At least it appears so reading the RFCs on caller preferences. > > The intent is to introduce something similar to those defined in RFC > 3840. > > In this regard, it is very different from "audio" or "video", as those > describe the ability to render particular types of media stream (a > clearly-defined technological difference), and relate to the sensory modes > by which the interlocutors communicate (a clearly-defined user experience > difference). I understand that video is a "thing" you can point your finger at and identify, whereas immersive is not. However, what is "mobile"? What is "data"? I'd argue that "data" is equally as vague. Still, it is a property one can define and use. > As I said before, the clear motivation for a feature tag is if some > incoming calls would prefer the destination to have it, and some incoming > calls would prefer the destination to *not* have it. How is this not possible with RFC 3841 and with this draft? > Glen Lavers has provided some significant motivation based on > bandwidth/QoS considerations. But in that regard, I think a generalized > "device class" property would be more effective in the long run, as it > would be extensible in whatever way the network operator wanted. If that's the preferred way to solve the problem, I have no objection. I can see how a device might have any number of such properties, including screen resolution, stereo sound, have a recording function, etc. Paul From paulej@packetizer.com Tue Mar 13 14:15:03 2012 Return-Path: <paulej@packetizer.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE38821E8015 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 14:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p9z6+MK+x2P for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 14:14:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5E43B21E8012 for <dispatch@ietf.org>; Tue, 13 Mar 2012 14:14:58 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2DLEs9d018118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2012 17:14:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331673295; bh=PF87xnuK3+50U755C7xVeWPukPdUhw2k+WvFcohypWo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=IsgyS3m91s3IeB5+DfBZPSSlggat8/M1yc7A+5saYPImgXsh38saq/3Y3qK8QfaZG fISw7+y1nRg+FIKmAIgjMCjREXUYx7ZqpcD/NQ9SQkn3/XOIGYaSBeYm6uPahVpNyD rr+cxtfpoxIEY154huhxD7qPovI88nmxsrN7Ry7Y= From: "Paul E. Jones" <paulej@packetizer.com> To: "'Michael Hammer'" <mphmmr@gmail.com> References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> <CAA3wLqUxC=NwTeLhan8tBTZ2NQ_FqnY4xbiWNjjDU7dq7FoYgw@mail.gmail.com> In-Reply-To: <CAA3wLqUxC=NwTeLhan8tBTZ2NQ_FqnY4xbiWNjjDU7dq7FoYgw@mail.gmail.com> Date: Tue, 13 Mar 2012 17:14:59 -0400 Message-ID: <051b01cd015e$59b80c40$0d2824c0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_051C_01CD013C.D2A7F2E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGlAq4PGrll3yWVQrHLtOjxHlL0QGM5LtOApsegtMCwxqCqQIVAynKArlo1yYCM/uG3wHJWOqalXfdCkA= Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 21:15:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_051C_01CD013C.D2A7F2E0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Mike, Interoperability is in terms of "do you support this capability"? The answer is either yes or no. The declaration that a device is immersive might be subjective, but the use is not. If I indicate in my INVITE when I call you that I want to reject any device on your end that does not advertise itself as immersive and you have no such devices, the call fails. Likewise, if you have one that advertises the capability, it connects to that one. Paul From: Michael Hammer [mailto:mphmmr@gmail.com] Sent: Tuesday, March 13, 2012 9:11 AM To: Paul E. Jones Cc: Worley, Dale R (Dale); Glen Lavers (glavers); dispatch@ietf.org Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt A judge once said: "I can't define pornography, but I can tell when I see it." The term immersive seems to be in the same category. With something so subjective, can you tell me how that helps interoperability? ISTM that it will be as useful as the evil bit. If I notice that it's use/non-use negatively impacts me, then I change it and get better service, is that cool with you? Mike On Mon, Mar 12, 2012 at 9:05 PM, Paul E. Jones <paulej@packetizer.com> wrote: Dale, Thanks for the thorough review (as usual) :) > The definition of "immersive" (which seems to be synonymous with > "telepresence") is not exact. That doesn't mean that the term isn't > useful, but it is a warning that there may be no *technological* > distinction. I personally view "immersive" as an adjective one can apply to Telepresence, but not all immersive systems are telepresence systems. For example, my son has an immersive video gaming experience each time puts his headset on his head. While the definition of "immersive" can be debated, I think it is important to differentiate immersive from Telepresence. A voice call could certainly be immersive. Our intent was to allow this tag to be used as a user preference in conjunction with audio and video tags to help route calls or select devices. > In regard to admission control, I expect that in both architecture and > practice, networks will want to base admission distinctions on more > detailed information than "immersive". But maybe I'm wrong; I think > networks have explicitly excluded all "video" media as an admission > policy. So perhaps a network would refuse admission to any "immersive" > video but allow non-immersive video, in order to conserve bandwidth. Admission control was viewed as just one possible usage. Quite likely, if it were used for admission control, the tag would be policed somewhere. Assuming the tag is policed on both ends and both ends seek an immersive experience, this will have an influence on the admission control decisions. This draft certainly does not intend to suggest every input that will go into admission control logic, but this is just one potentially useful code point. > Please, please, please do not use the word "leverage" to mean "utilize (to > gain a further advantage)". That word makes it sound like contact with > marketing people has damaged your brain. :-) I cannot argue with you on that point. > In regard to routing decisions, a feature tag is useful if *some* calls > *prefer* the feature and also *some* calls *reject* > (anti-prefer) the feature. Unless this criterion is true, the callee's > local network (or the callee's behavior) can obtain all possible benefit > by statically prioritizing the alternative UAs. Since it's a caller preferences tag, all things are possible. A UA could require tag, reject on the tag, etc. > There are two examples in the draft, but neither is an example of either > stated motivation. The examples and the motivations should not be > conceptually disjoint. The REGISTER example wasn't intended to provide an example of motivation of the tag directly, but it shows how might be used in signaling to facilitate device selection. Once the device is registered with this feature tag, then call routing logic can utilize this information in device selection. The INVITE example just shows its use, but I agree it does not help to support the stated motivations. The intent was just to show its usage. I would have been happy without the examples, but others felt like the examples were useful to show where this is signaled; that's about all the examples are for. > As Paul notes, the tag would be expressed as "+sip.immersive". That was a point that was not entirely clear to me. I wish I had seen Paul K's message, but I seem to lose some of his :-( Syntactically, the "immersive" tag is allowed per RFC 3261 syntax. Per RFC 3640, it seemed to suggest +sip was needed, but it was not clear how one can define new "base" tags that do not require +sip. So, there is no possibility for introducing new base tags -- ever? > A motivation which seems plausible to me is that a video UA would want to > know if the *other* video UA was operating in an immersive manner or not, > or whether it was capable of doing so, so as to adjust its behavior. > E.g., if an immersive system is communicating with an "ordinary" system, > it might want to (effectively) crop its transmitted video signal from > "immersive surrounding" to "viewing screen" > dimensions. That's certainly possible, yes. > The previous paragraph suggests that the set of existing video > conferencing systems might be bimodal, that is, they might fall into two > distinct classes: small-screen systems that people look at like > televisions, and large-screen systems that surround the viewers, with no > systems of intermediate size. If that is actually true (and it might have > become true in the market without people explicitly planning or noticing > it), it should be documented, and might be a justification for labeling > videoconferencing systems with a binary "immersive" attribute. I definitely think we will have such systems. One does not want to limit a system that can provide a rich experience from communicating with a desktop video phone or an iPad. Any communication is better than no communication. In such cases, I can certainly see that a system might adjust behavior. The main idea we had in mind (or I did and let the others state their thoughts) was that a user might have a plurality of callable devices. I could use this tag to route calls to preferred devices. I could tell my SIP server that during the business day, I prefer to route all "immersive" calls to my single screen Telepresence system on my desk. In the evenings, I might have those routed to my softphone. Of course, the caller can also indicate preferences: it may not want to allow the call to go to a softphone. All of these things are possible with the caller preferences framework. > I suspect that there are important aspects of this subject that the > authors know (at least intuitively) but have not documented, and a > revision of the draft might be very informative. Reading too much into this can be dangerous. It's certainly possible to throw out a lot of ideas for this tag, but at the end of the day it is nothing but a feature tag. In RFC 3840, no single tag is discussed at such length. As such, I didn't feel like this one should. It was stated that "immersive" is subjective and, to some extent, that's true. An "immersive" system is what one says it is. Beyond that, though, the system behavior is fairly well-defined in RFC 3840 and RFC 3841. > In any case, it seems to me that this draft falls squarely within the > remit of CLUE. I do have to disagree with you on this point. :-) If CLUE did or did not exist, it would not change the desire to an immersive tag. We're not defining multiple streams, camera positioning, or the multitude of things people are pouring into "Telepresence". None of that makes any sense of an immersive audio call. This gets back to "what is immersive"? Like RFC 3840, one can ask "what is text?" (That's another feature tag.) Is this instant messaging text? Or is this real-time text that is delivered character-at-a-time? There is also the "mobility" tag. Is that a mobile phone? Is it a laptop with Wi-Fi? A tablet? I'd like to separate the notion of "immersive" from Telepresence, because I view it as an adjective that is a part of Telepresence. Nonetheless, it is an adjective that we would like to use with or without Telepresence and in conjunction with audio and video feature tags. Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_051C_01CD013C.D2A7F2E0 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 14 = (filtered medium)"><style><!-- /* Font Definitions */ @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;} /* 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;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></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><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'>Mike,<o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p> </o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'>Interoperability is in terms of “do you support this = capability”?  The answer is either yes or no.  The = declaration that a device is immersive might be subjective, but the use = is not.<o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p> </o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'>If I indicate in my INVITE when I call you that I want to reject any = device on your end that does not advertise itself as immersive and you = have no such devices, the call fails.  Likewise, if you have one = that advertises the capability, it connects to that = one.<o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p> </o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'>Paul<o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><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 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"'> = Michael Hammer [mailto:mphmmr@gmail.com] <br><b>Sent:</b> Tuesday, March = 13, 2012 9:11 AM<br><b>To:</b> Paul E. Jones<br><b>Cc:</b> Worley, Dale = R (Dale); Glen Lavers (glavers); dispatch@ietf.org<br><b>Subject:</b> = Re: [dispatch] = draft-lavers-sipcore-immersive-capability-00.txt<o:p></o:p></span></p></d= iv></div><p class=3DMsoNormal><o:p> </o:p></p><p = class=3DMsoNormal>A judge once said:  "I can't define = pornography, but I can tell when I see it."<o:p></o:p></p><div><p = class=3DMsoNormal>The term immersive seems to be in the same = category.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>With something so subjective, can you tell me how that = helps interoperability?<o:p></o:p></p></div><div><p = class=3DMsoNormal>ISTM that it will be as useful as the evil = bit.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>If I notice that it's use/non-use negatively impacts = me, <o:p></o:p></p></div><div><p class=3DMsoNormal>then I change it = and get better service, is that cool with = you?<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>Mike<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p><div><p class=3DMsoNormal>On Mon, = Mar 12, 2012 at 9:05 PM, Paul E. Jones <<a = href=3D"mailto:paulej@packetizer.com">paulej@packetizer.com</a>> = wrote:<o:p></o:p></p><p class=3DMsoNormal>Dale,<br><br>Thanks for the = thorough review (as usual) :)<br><br>> The definition of = "immersive" (which seems to be synonymous with<br>> = "telepresence") is not exact.  That doesn't mean that the = term isn't<br>> useful, but it is a warning that there may be no = *technological*<br>> distinction.<br><br>I personally view = "immersive" as an adjective one can apply to = Telepresence,<br>but not all immersive systems are telepresence systems. =  For example, my son<br>has an immersive video gaming experience = each time puts his headset on his<br>head.<br><br>While the definition = of "immersive" can be debated, I think it is important<br>to = differentiate immersive from Telepresence.  A voice call could = certainly<br>be immersive.  Our intent was to allow this tag to be = used as a user<br>preference in conjunction with audio and video tags to = help route calls or<br>select devices.<br><br>> In regard to = admission control, I expect that in both architecture and<br>> = practice, networks will want to base admission distinctions on = more<br>> detailed information than "immersive".  But = maybe I'm wrong; I think<br>> networks have explicitly excluded all = "video" media as an admission<br>> policy.  So perhaps = a network would refuse admission to any "immersive"<br>> = video but allow non-immersive video, in order to conserve = bandwidth.<br><br>Admission control was viewed as just one possible = usage.  Quite likely, if<br>it were used for admission control, the = tag would be policed somewhere.<br>Assuming the tag is policed on both = ends and both ends seek an immersive<br>experience, this will have an = influence on the admission control decisions.<br>This draft certainly = does not intend to suggest every input that will go<br>into admission = control logic, but this is just one potentially useful = code<br>point.<br><br>> Please, please, please do not use the word = "leverage" to mean "utilize (to<br>> gain a further = advantage)".  That word makes it sound like contact = with<br>> marketing people has damaged your brain.<br><br>:-)  I = cannot argue with you on that point.<br><br>> In regard to routing = decisions, a feature tag is useful if *some* calls<br>> *prefer* the = feature and also *some* calls *reject*<br>> (anti-prefer) the = feature.  Unless this criterion is true, the callee's<br>> local = network (or the callee's behavior) can obtain all possible = benefit<br>> by statically prioritizing the alternative = UAs.<br><br>Since it's a caller preferences tag, all things are = possible.  A UA could<br>require tag, reject on the tag, = etc.<br><br>> There are two examples in the draft, but neither is an = example of either<br>> stated motivation.  The examples and the = motivations should not be<br>> conceptually disjoint.<br><br>The = REGISTER example wasn't intended to provide an example of motivation = of<br>the tag directly, but it shows how might be used in signaling to = facilitate<br>device selection.  Once the device is registered with = this feature tag, then<br>call routing logic can utilize this = information in device selection.<br><br>The INVITE example just shows = its use, but I agree it does not help to<br>support the stated = motivations.  The intent was just to show its usage.<br><br>I would = have been happy without the examples, but others felt like = the<br>examples were useful to show where this is signaled; that's about = all the<br>examples are for.<br><br>> As Paul notes, the tag would be = expressed as "+sip.immersive".<br><br>That was a point that = was not entirely clear to me.  I wish I had seen Paul<br>K's = message, but I seem to lose some of his :-(<br><br>Syntactically, the = "immersive" tag is allowed per RFC 3261 syntax.  Per = RFC<br>3640, it seemed to suggest +sip was needed, but it was not clear = how one can<br>define new "base" tags that do not require = +sip.  So, there is no<br>possibility for introducing new base tags = -- ever?<br><br>> A motivation which seems plausible to me is that a = video UA would want to<br>> know if the *other* video UA was = operating in an immersive manner or not,<br>> or whether it was = capable of doing so, so as to adjust its behavior.<br>> E.g., if an = immersive system is communicating with an "ordinary" = system,<br>> it might want to (effectively) crop its transmitted = video signal from<br>> "immersive surrounding" to = "viewing screen"<br>> dimensions.<br><br>That's certainly = possible, yes.<br><br>> The previous paragraph suggests that the set = of existing video<br>> conferencing systems might be bimodal, that = is, they might fall into two<br>> distinct classes: =  small-screen systems that people look at like<br>> televisions, = and large-screen systems that surround the viewers, with no<br>> = systems of intermediate size.  If that is actually true (and it = might have<br>> become true in the market without people explicitly = planning or noticing<br>> it), it should be documented, and might be = a justification for labeling<br>> videoconferencing systems with a = binary "immersive" attribute.<br><br>I definitely think we = will have such systems.  One does not want to limit a<br>system = that can provide a rich experience from communicating with a = desktop<br>video phone or an iPad.  Any communication is better = than no communication.<br>In such cases, I can certainly see that a = system might adjust behavior.<br><br>The main idea we had in mind (or I = did and let the others state their<br>thoughts) was that a user might = have a plurality of callable devices.  I<br>could use this tag to = route calls to preferred devices.  I could tell my SIP<br>server = that during the business day, I prefer to route all = "immersive" calls<br>to my single screen Telepresence system = on my desk.  In the evenings, I<br>might have those routed to my = softphone.<br><br>Of course, the caller can also indicate preferences: = it may not want to<br>allow the call to go to a softphone.  All of = these things are possible with<br>the caller preferences = framework.<br><br>> I suspect that there are important aspects of = this subject that the<br>> authors know (at least intuitively) but = have not documented, and a<br>> revision of the draft might be very = informative.<br><br>Reading too much into this can be dangerous. =  It's certainly possible to<br>throw out a lot of ideas for this = tag, but at the end of the day it is<br>nothing but a feature tag. =  In RFC 3840, no single tag is discussed at such<br>length. =  As such, I didn't feel like this one should.  It was stated = that<br>"immersive" is subjective and, to some extent, that's = true.  An "immersive"<br>system is what one says it is. =  Beyond that, though, the system behavior is<br>fairly well-defined = in RFC 3840 and RFC 3841.<br><br>> In any case, it seems to me that = this draft falls squarely within the<br>> remit of CLUE.<br><br>I do = have to disagree with you on this point. :-)<br><br>If CLUE did or did = not exist, it would not change the desire to an immersive<br>tag. =  We're not defining multiple streams, camera positioning, or = the<br>multitude of things people are pouring into = "Telepresence".  None of that<br>makes any sense of an = immersive audio call.<br><br>This gets back to "what is = immersive"?  Like RFC 3840, one can ask "what = is<br>text?"  (That's another feature tag.) Is this instant = messaging text?  Or is<br>this real-time text that is delivered = character-at-a-time?  There is also<br>the "mobility" = tag.  Is that a mobile phone?  Is it a laptop with Wi-Fi? =  A<br>tablet?<br><br>I'd like to separate the notion of = "immersive" from Telepresence, because I<br>view it as an = adjective that is a part of Telepresence.  Nonetheless, it is<br>an = adjective that we would like to use with or without Telepresence and = in<br>conjunction with audio and video feature = tags.<br><br>Paul<br><br><br><br><br><br><br>____________________________= ___________________<br>dispatch mailing list<br><a = href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br><a = href=3D"https://www.ietf.org/mailman/listinfo/dispatch" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/dispatch</a><o:p>= </o:p></p></div><p = class=3DMsoNormal><o:p> </o:p></p></div></div></div></body></html> ------=_NextPart_000_051C_01CD013C.D2A7F2E0-- From gonzalo.camarillo@ericsson.com Tue Mar 13 14:18:27 2012 Return-Path: <gonzalo.camarillo@ericsson.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078D221E8012 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 14:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.315 X-Spam-Level: X-Spam-Status: No, score=-110.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8FqA4qRqPU0 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 14:18:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A793421E8015 for <dispatch@ietf.org>; Tue, 13 Mar 2012 14:18:25 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-f4-4f5fb9a0935b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D7.52.17856.0A9BF5F4; Tue, 13 Mar 2012 22:18:24 +0100 (CET) Received: from [131.160.126.200] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Mar 2012 22:18:23 +0100 Message-ID: <4F5FB99E.2000708@ericsson.com> Date: Tue, 13 Mar 2012 23:18:22 +0200 From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Dawes, Peter, VF-Group" <Peter.Dawes@vodafone.com> References: <4F4F5C19.9070607@ericsson.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99D39A@VOEXM25W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99D39A@VOEXM25W.internal.vodafone.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Charter process for the INSIPID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 21:18:27 -0000 Hi Peter, note that the paragraph you quoted simply says that the new identifier will have the same *aim*. It does not say or imply anything about what the solution needs to include. Cheers, Gonzalo On 12/03/2012 1:31 PM, Dawes, Peter, VF-Group wrote: > Hello Gonzalo, All, > I think the following paragraph of the INSIPID charter at http://www.ietf.org/iesg/evaluation/sessionid-charter.txt should be revised: > > "This group will focus on a document that will specify an SIP > identifier that have the same aim as the From-tag, To-tag and > Call-ID conjunction, but is less likely to be mangled by > intermediaries." > > This paragraph limits the charter to a single document, even though more than one draft already exists related to identifying sessions, and by mentioning the "From-tag" points to a solution that includes information from both ends of a session before INSIPID has started discussion. Therefore, I would like to propose the following re-wording: > > "This group will focus on specifying a SIP > identifier that has similar uniqueness and end-to-end properties as a dialog identifier (made up of the From-tag, To-tag and > Call-ID conjunction), but is less likely to be mangled by > intermediaries. Related identifiers and parameters to satisfy requirements for use cases like troubleshooting, > billing, session tracking, session recording, media and signalling > correlation, and so forth will also be specified." > > Regards, > Peter > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 01 March 2012 11:23 > To: DISPATCH > Subject: [dispatch] Charter process for the INSIPID WG > > Folks, > > Robert and I have been working on a charter proposal for the INSIPID WG. > This is the proposal that we have sent for review to the IESG and IAB: > > http://www.ietf.org/iesg/evaluation/sessionid-charter.txt > > We believe this proposal represents the consensus of the group. Note that we have left out some comments that failed to get rough consensus on this list. > >>From now on, I will be taking care of the chartering process for this WG. Today, I will discuss the charter proposal with the IESG and, if everything goes OK, we will be sending it for external review shortly. > If you have further comments on the charter proposal, please send them as part of its external review, which will be announced on the IETF announcement list as usual. > > Also, I am going to be requesting the creation of the insipid mailing list. > > Cheers, > > Gonzalo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@alum.mit.edu Tue Mar 13 14:29:48 2012 Return-Path: <pkyzivat@alum.mit.edu> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DCE21E8015 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 14:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9pKrgne63s3 for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 14:29:48 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id DF0D921E8012 for <dispatch@ietf.org>; Tue, 13 Mar 2012 14:29:47 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta09.westchester.pa.mail.comcast.net with comcast id l9Ui1i0010QuhwU599Vorl; Tue, 13 Mar 2012 21:29:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta02.westchester.pa.mail.comcast.net with comcast id l9Vn1i01C07duvL3N9VoDe; Tue, 13 Mar 2012 21:29:48 +0000 Message-ID: <4F5FBC4A.8090802@alum.mit.edu> Date: Tue, 13 Mar 2012 17:29:46 -0400 From: Paul Kyzivat <pkyzivat@alum.mit.edu> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> <3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com>, <03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> <CD5674C3CD99574EBA7432465FC13C1B22726A0958@DC-US1MBEX4.global.avaya.com> <051901cd015d$fa776f50$ef664df0$@packetizer.com> In-Reply-To: <051901cd015d$fa776f50$ef664df0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 21:29:48 -0000 On 3/13/12 5:12 PM, Paul E. Jones wrote: > Dale, > >> I may or may not be a smart fellow, but I don't understand the idea behind >> classifying a device as "immersive". More exactly, I understand it as a >> somewhat fuzzy property that a system may or may not have, but I don't >> understand why devices should declare it, or why a caller would care >> whether the destination UA had it or not. > > Our expectation was that a user, and more likely a system administrator, > will "declare" that a device is "immersive" or not. That becomes > subjective, perhaps, but that is what the user preferred. Along with that > preference, the system would be configured to have or not have a preference > or requirement to establish a call to another device that advertises the > same property. We viewed this as similar to a user wanting to place a call > to a text-enabled device. There's no value for a deaf person connecting to > an audio-only device. In the same spirit, we wanted to allow a user to > indicate a preferred device. To work as you describe, your administrator will have to be configuring both ends: the devices that declare the capability and the devices that express a preference for it. Hence it becomes an entirely proprietary mechanism, and there is no point in standardizing the name of the tag. If you want to have a tag that you can configure as you wish, I already suggested using a "u." tag. You need nothing from the IETF to do that. > The meaning of "immersive" may be considered subjective, but the logic > followed is clear. At least it appears so reading the RFCs on caller > preferences. > >>> The intent is to introduce something similar to those defined in RFC >> 3840. >> >> In this regard, it is very different from "audio" or "video", as those >> describe the ability to render particular types of media stream (a >> clearly-defined technological difference), and relate to the sensory modes >> by which the interlocutors communicate (a clearly-defined user experience >> difference). > > I understand that video is a "thing" you can point your finger at and > identify, whereas immersive is not. However, what is "mobile"? What is > "data"? I'd argue that "data" is equally as vague. Still, it is a property > one can define and use. I'm not going to defend everything that's there. We learn from our mistakes. The "data" tag is there as a parallel to video and audio - namely top level mime types. (I forget - is "application" there too?) But I agree that the data tag isn't really useful for anything. >> As I said before, the clear motivation for a feature tag is if some >> incoming calls would prefer the destination to have it, and some incoming >> calls would prefer the destination to *not* have it. > > How is this not possible with RFC 3841 and with this draft? We are talking about a *standard* here. With what you are describing there is nothing *standard* that I can do with this tag. Thanks, Paul >> Glen Lavers has provided some significant motivation based on >> bandwidth/QoS considerations. But in that regard, I think a generalized >> "device class" property would be more effective in the long run, as it >> would be extensible in whatever way the network operator wanted. > > If that's the preferred way to solve the problem, I have no objection. I > can see how a device might have any number of such properties, including > screen resolution, stereo sound, have a recording function, etc. > > Paul > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From kpfleming@digium.com Tue Mar 13 15:33:08 2012 Return-Path: <kpfleming@digium.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6116121E802C for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 15:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JphO3XEup4v for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 15:33:07 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id BBCD321E8028 for <dispatch@ietf.org>; Tue, 13 Mar 2012 15:33:07 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from <kpfleming@digium.com>) id 1S7aHC-0003th-It for dispatch@ietf.org; Tue, 13 Mar 2012 17:33:06 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 90667D8011 for <dispatch@ietf.org>; Tue, 13 Mar 2012 17:33:06 -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 MasYA2oJgZfe for <dispatch@ietf.org>; Tue, 13 Mar 2012 17:33:06 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 433F5D8004 for <dispatch@ietf.org>; Tue, 13 Mar 2012 17:33:06 -0500 (CDT) Message-ID: <4F5FCB21.2060301@digium.com> Date: Tue, 13 Mar 2012 17:33:05 -0500 From: "Kevin P. Fleming" <kpfleming@digium.com> Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dispatch@ietf.org References: <CB7F8CA4.1DB88%glavers@cisco.com> <4F5A6C5D.3030606@alum.mit.edu> In-Reply-To: <4F5A6C5D.3030606@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 22:33:08 -0000 On 03/09/2012 02:47 PM, Paul Kyzivat wrote: > But I would be more than pleased if people who know of actual uses piped > up here and told us about them. This discussion prompted those of us in the SIP Forum's FoIP Task Group to change our plans and start working on proposing a "+sip.fax" feature tag, intended for use by carriers who need to route calls differently if the calling endpoint is FAX-capable (which will more than likely mean the purpose of the call is to complete a FAX transaction). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From keith.drage@alcatel-lucent.com Tue Mar 13 15:59:11 2012 Return-Path: <keith.drage@alcatel-lucent.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E82621E803F; Tue, 13 Mar 2012 15:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.534 X-Spam-Level: X-Spam-Status: No, score=-109.534 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvAkQsTyqnAq; Tue, 13 Mar 2012 15:59:10 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7302021E8033; Tue, 13 Mar 2012 15:59:07 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2DMx5g3022561 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Mar 2012 23:59:05 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 13 Mar 2012 23:59:05 +0100 From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> To: "insipid@ietf.org" <insipid@ietf.org> Date: Tue, 13 Mar 2012 23:56:54 +0100 Thread-Topic: Compiling an agenda for INSIPID Thread-Index: Ac0BbJYB8xCK4eXZQXiA+pdlquFoYQ== Message-ID: <EDC0A1AE77C57744B664A310A0B23AE224C856B4@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: [dispatch] Compiling an agenda for INSIPID X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 22:59:11 -0000 I am in the process of compiling an agenda for the INSIPID meeting. The gro= up has yet to complete the chartering process, but there is some expectatio= n it will do that on Thursday. Assuming the group is chartered, we will not= be discussing the charter, only using the charter to scope the future work= . Obviously I am well aware of some of the drafts but just in case I miss som= e.... If you believe you have drafts, current or expired, that fall within the sc= ope of the INSIPID group, then please send me a private mail, identifying s= aid draft. If you believe it has been superseded or overtaken by another draft then pl= ease identify that. If you believe the draft is still current (i.e. it has valid input for the = group that we will not find elsewhere), then please identify a potential pr= esenter for the Paris meeting. Please note that we will only have an hour, so it may well be a matter of o= ne or two slides identifying key issues or use cases, and there is no guara= ntee of a slot. Finally if you do have views on the direction forward the group should take= , assuming that it is chartered, then do feel free to open that discussion = on the INSIPID list. Some lively discussion on list will help make progress= in Paris. Regards Keith From pkyzivat@alum.mit.edu Tue Mar 13 17:24:37 2012 Return-Path: <pkyzivat@alum.mit.edu> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E88A21E804C for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 17:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTlQE62eiNPI for <dispatch@ietfa.amsl.com>; Tue, 13 Mar 2012 17:24:36 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 59E3F21E8013 for <dispatch@ietf.org>; Tue, 13 Mar 2012 17:24:35 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta09.westchester.pa.mail.comcast.net with comcast id lC2o1i0041YDfWL59CQctP; Wed, 14 Mar 2012 00:24:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id lCQc1i00A07duvL3gCQc9w; Wed, 14 Mar 2012 00:24:36 +0000 Message-ID: <4F5FE542.8050709@alum.mit.edu> Date: Tue, 13 Mar 2012 20:24:34 -0400 From: Paul Kyzivat <pkyzivat@alum.mit.edu> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <CB7F8CA4.1DB88%glavers@cisco.com> <4F5A6C5D.3030606@alum.mit.edu> <4F5FCB21.2060301@digium.com> In-Reply-To: <4F5FCB21.2060301@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 00:24:37 -0000 On 3/13/12 6:33 PM, Kevin P. Fleming wrote: > On 03/09/2012 02:47 PM, Paul Kyzivat wrote: > >> But I would be more than pleased if people who know of actual uses piped >> up here and told us about them. > > This discussion prompted those of us in the SIP Forum's FoIP Task Group > to change our plans and start working on proposing a "+sip.fax" feature > tag, intended for use by carriers who need to route calls differently if > the calling endpoint is FAX-capable (which will more than likely mean > the purpose of the call is to complete a FAX transaction). I've already said it a couple of times in this thread, but I'll say it again: Routing to a target based on the *capabilities* of the caller is ill conceived. Those capabilities don't equate to what the caller intends to do. Routing based on caller *preferences* however makes perfect sense. But then you should actually implement 3841 to do it. Thanks, Paul From kpfleming@digium.com Wed Mar 14 06:24:48 2012 Return-Path: <kpfleming@digium.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367ED21E8073 for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 06:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+z0zauTeQ6t for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 06:24:47 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 709DB21F8766 for <dispatch@ietf.org>; Wed, 14 Mar 2012 06:24:47 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from <kpfleming@digium.com>) id 1S7oC5-0003Ks-Tp for dispatch@ietf.org; Wed, 14 Mar 2012 08:24:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id E7C83D8013 for <dispatch@ietf.org>; Wed, 14 Mar 2012 08:24:45 -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 TFUJJlCBAkOW for <dispatch@ietf.org>; Wed, 14 Mar 2012 08:24:45 -0500 (CDT) Received: from [192.168.1.10] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 72967D8010 for <dispatch@ietf.org>; Wed, 14 Mar 2012 08:24:45 -0500 (CDT) Message-ID: <4F609C1C.7050400@digium.com> Date: Wed, 14 Mar 2012 08:24:44 -0500 From: "Kevin P. Fleming" <kpfleming@digium.com> Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dispatch@ietf.org References: <CB7F8CA4.1DB88%glavers@cisco.com> <4F5A6C5D.3030606@alum.mit.edu> <4F5FCB21.2060301@digium.com> <4F5FE542.8050709@alum.mit.edu> In-Reply-To: <4F5FE542.8050709@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 13:24:48 -0000 On 03/13/2012 07:24 PM, Paul Kyzivat wrote: > On 3/13/12 6:33 PM, Kevin P. Fleming wrote: >> On 03/09/2012 02:47 PM, Paul Kyzivat wrote: >> >>> But I would be more than pleased if people who know of actual uses piped >>> up here and told us about them. >> >> This discussion prompted those of us in the SIP Forum's FoIP Task Group >> to change our plans and start working on proposing a "+sip.fax" feature >> tag, intended for use by carriers who need to route calls differently if >> the calling endpoint is FAX-capable (which will more than likely mean >> the purpose of the call is to complete a FAX transaction). > > I've already said it a couple of times in this thread, but I'll say it > again: > > Routing to a target based on the *capabilities* of the caller is ill > conceived. Those capabilities don't equate to what the caller intends to > do. > > Routing based on caller *preferences* however makes perfect sense. But > then you should actually implement 3841 to do it. In this case, the purpose isn't target selection, it's mid-path network element selection (carriers who need to send calls through different paths if the call is likely to use T.38), although I doubt that distinction matters much for your argument :-) The target does not change, but the network path in between the source and target uses this information to ensure that the network can support what the call could (is likely) to need in order to be successful. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From pkyzivat@alum.mit.edu Wed Mar 14 07:12:10 2012 Return-Path: <pkyzivat@alum.mit.edu> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAD021F8811 for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 07:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZqnxs3B2v6n for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 07:12:10 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5621F880D for <dispatch@ietf.org>; Wed, 14 Mar 2012 07:12:09 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta05.westchester.pa.mail.comcast.net with comcast id lQkd1i0031ei1Bg55SCA79; Wed, 14 Mar 2012 14:12:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta24.westchester.pa.mail.comcast.net with comcast id lSCA1i01j07duvL3kSCAmF; Wed, 14 Mar 2012 14:12:10 +0000 Message-ID: <4F60A739.4080605@alum.mit.edu> Date: Wed, 14 Mar 2012 10:12:09 -0400 From: Paul Kyzivat <pkyzivat@alum.mit.edu> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <CB7F8CA4.1DB88%glavers@cisco.com> <4F5A6C5D.3030606@alum.mit.edu> <4F5FCB21.2060301@digium.com> <4F5FE542.8050709@alum.mit.edu> <4F609C1C.7050400@digium.com> In-Reply-To: <4F609C1C.7050400@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 14:12:11 -0000 On 3/14/12 9:24 AM, Kevin P. Fleming wrote: > On 03/13/2012 07:24 PM, Paul Kyzivat wrote: >> On 3/13/12 6:33 PM, Kevin P. Fleming wrote: >>> On 03/09/2012 02:47 PM, Paul Kyzivat wrote: >>> >>>> But I would be more than pleased if people who know of actual uses >>>> piped >>>> up here and told us about them. >>> >>> This discussion prompted those of us in the SIP Forum's FoIP Task Group >>> to change our plans and start working on proposing a "+sip.fax" feature >>> tag, intended for use by carriers who need to route calls differently if >>> the calling endpoint is FAX-capable (which will more than likely mean >>> the purpose of the call is to complete a FAX transaction). >> >> I've already said it a couple of times in this thread, but I'll say it >> again: >> >> Routing to a target based on the *capabilities* of the caller is ill >> conceived. Those capabilities don't equate to what the caller intends to >> do. >> >> Routing based on caller *preferences* however makes perfect sense. But >> then you should actually implement 3841 to do it. > > In this case, the purpose isn't target selection, it's mid-path network > element selection (carriers who need to send calls through different > paths if the call is likely to use T.38), although I doubt that > distinction matters much for your argument :-) > > The target does not change, but the network path in between the source > and target uses this information to ensure that the network can support > what the call could (is likely) to need in order to be successful. Indicating capability doesn't even imply "is likely to use". Any phone capable of handling video could potentially support fax, and so might advertise that capability, even though the likelihood of doing so on any call may be slim. (There might be millions of phones that declare this capability and never use it. So making any resource decisions based on this could be unwise. Conversely, *not* indicating the capability is no guarantee that the feature won't be used in the course of the call. Or are you suggesting that the "network" impose a restriction that every feature that *might* be desired in the course of the call be declared at the beginning of the call? Thanks, Paul From dworley@avaya.com Wed Mar 14 09:02:18 2012 Return-Path: <dworley@avaya.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C325721F8705 for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 09:02:18 -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.492, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riiZE2hwo2Sb for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 09:02:18 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 29A7221F8702 for <dispatch@ietf.org>; Wed, 14 Mar 2012 09:02:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACLAYE+HCzI1/2dsb2JhbABDtiyBB4IKAQEEEigtIgIBCA0pEDIlAQEEGxqHaJ9knDeQG2MEm2OKG4MC X-IronPort-AV: E=Sophos;i="4.73,584,1325480400"; d="scan'208";a="238079976" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 Mar 2012 12:02:06 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Mar 2012 11:46:45 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 14 Mar 2012 12:02:05 -0400 From: "Worley, Dale R (Dale)" <dworley@avaya.com> To: "dispatch@ietf.org" <dispatch@ietf.org> Date: Wed, 14 Mar 2012 12:02:05 -0400 Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Ac0B7H1yMPX44IIYT4eQ/DR8BfECLgADf2BQ Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0967@DC-US1MBEX4.global.avaya.com> References: <CB7F8CA4.1DB88%glavers@cisco.com> <4F5A6C5D.3030606@alum.mit.edu> <4F5FCB21.2060301@digium.com> <4F5FE542.8050709@alum.mit.edu> <4F609C1C.7050400@digium.com>,<4F60A739.4080605@alum.mit.edu> In-Reply-To: <4F60A739.4080605@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 16:02:19 -0000 > >>> This discussion prompted those of us in the SIP Forum's FoIP Task Gro= up > >>> to change our plans and start working on proposing a "+sip.fax" featu= re > >>> tag, intended for use by carriers who need to route calls differently= if > >>> the calling endpoint is FAX-capable (which will more than likely mean > >>> the purpose of the call is to complete a FAX transaction). >=20 > > In this case, the purpose isn't target selection, it's mid-path network > > element selection (carriers who need to send calls through different > > paths if the call is likely to use T.38), although I doubt that > > distinction matters much for your argument :-) > > > > The target does not change, but the network path in between the source > > and target uses this information to ensure that the network can support > > what the call could (is likely) to need in order to be successful. >=20 > Indicating capability doesn't even imply "is likely to use". Any phone > capable of handling video could potentially support fax, and so might > advertise that capability, even though the likelihood of doing so on any > call may be slim. (There might be millions of phones that declare this > capability and never use it. So making any resource decisions based on > this could be unwise. But fax is an obnoxious special case: Fax machines start the communication as an ordinary voice connection, then switch to fax mode. The result is that the initial SDP doesn't declare the real *intention* of the call. This leads to the carriers' problem that Kevin mentioned: the carrier wants to route the call through different "trunks" if the call *will become* fax, but current SIP signaling gives them no clean way to distinguish that at call setup time. In addition, while any device that handles video *could* support fax, about 99.9% of all fax communications are between devices that are used *exclusively* for fax. So it's easy to get 99.9% of all fax communications to declare at dialog creation time "I'm going to do fax in a few seconds". It's one of the few situations where *capability* is highly predictive of the communication request that will be made in the near future (but is not indicated at present). Perhaps for "truth in advertising" the feature tag should be "+sip.going-to-ask-for-T38-soon". ;-) Dale From pkyzivat@alum.mit.edu Wed Mar 14 09:09:34 2012 Return-Path: <pkyzivat@alum.mit.edu> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D06A21F8636 for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 09:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61fGkdY4lFLV for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 09:09:33 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9252B21F865F for <dispatch@ietf.org>; Wed, 14 Mar 2012 09:09:33 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta06.westchester.pa.mail.comcast.net with comcast id lU3J1i00317dt5G56U9a9N; Wed, 14 Mar 2012 16:09:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta13.westchester.pa.mail.comcast.net with comcast id lU9Z1i00707duvL3ZU9ZMV; Wed, 14 Mar 2012 16:09:33 +0000 Message-ID: <4F60C2BC.6030605@alum.mit.edu> Date: Wed, 14 Mar 2012 12:09:32 -0400 From: Paul Kyzivat <pkyzivat@alum.mit.edu> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <CB7F8CA4.1DB88%glavers@cisco.com> <4F5A6C5D.3030606@alum.mit.edu> <4F5FCB21.2060301@digium.com> <4F5FE542.8050709@alum.mit.edu> <4F609C1C.7050400@digium.com>, <4F60A739.4080605@alum.mit.edu> <CD5674C3CD99574EBA7432465FC13C1B22726A0967@DC-US1MBEX4.global.avaya.com> In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A0967@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 16:09:34 -0000 On 3/14/12 12:02 PM, Worley, Dale R (Dale) wrote: >>>>> This discussion prompted those of us in the SIP Forum's FoIP Task Group >>>>> to change our plans and start working on proposing a "+sip.fax" feature >>>>> tag, intended for use by carriers who need to route calls differently if >>>>> the calling endpoint is FAX-capable (which will more than likely mean >>>>> the purpose of the call is to complete a FAX transaction). >> >>> In this case, the purpose isn't target selection, it's mid-path network >>> element selection (carriers who need to send calls through different >>> paths if the call is likely to use T.38), although I doubt that >>> distinction matters much for your argument :-) >>> >>> The target does not change, but the network path in between the source >>> and target uses this information to ensure that the network can support >>> what the call could (is likely) to need in order to be successful. >> >> Indicating capability doesn't even imply "is likely to use". Any phone >> capable of handling video could potentially support fax, and so might >> advertise that capability, even though the likelihood of doing so on any >> call may be slim. (There might be millions of phones that declare this >> capability and never use it. So making any resource decisions based on >> this could be unwise. > > But fax is an obnoxious special case: > > Fax machines start the communication as an ordinary voice connection, > then switch to fax mode. The result is that the initial SDP doesn't > declare the real *intention* of the call. This leads to the carriers' > problem that Kevin mentioned: the carrier wants to route the call > through different "trunks" if the call *will become* fax, but current > SIP signaling gives them no clean way to distinguish that at call > setup time. > > In addition, while any device that handles video *could* support fax, > about 99.9% of all fax communications are between devices that are > used *exclusively* for fax. So it's easy to get 99.9% of all fax > communications to declare at dialog creation time "I'm going to do fax > in a few seconds". > > It's one of the few situations where *capability* is highly predictive > of the communication request that will be made in the near future (but > is not indicated at present). Perhaps for "truth in advertising" the > feature tag should be "+sip.going-to-ask-for-T38-soon". ;-) For dedicated fax devices its also perfectly reasonable to include callerprefs requesting fax capability. Thanks, Paul From mphmmr@gmail.com Wed Mar 14 09:52:29 2012 Return-Path: <mphmmr@gmail.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B0321F876C for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 09:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgPb+KIt6m1n for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 09:52:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 956F721F85F8 for <dispatch@ietf.org>; Wed, 14 Mar 2012 09:52:27 -0700 (PDT) Received: by lbol12 with SMTP id l12so1088995lbo.31 for <dispatch@ietf.org>; Wed, 14 Mar 2012 09:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rMv5MITb3TKQaIeNvBV8+VnJTFC6xWCkAzcDTgPLvQA=; b=ZJKhVKvzDRITgYwnoS4dLq7y9uWDOSJ+PN76O1TeVyg553nH9Di6Rk0Rbw+/TsJvZW DIuezRTcha+5RZW811Jbz70Efq7m3A/w1xBwuoVz9kKiuTGw+WnFda8/z+0rE2I7tYC8 L34wv5lT13+vjc6oU3HOrCYlkFRZoJVt1aKIChsqogV9ffdP4GCqYes+iTzJHlNrV/X+ MTG2Otb8CZf/A0INWTzlcLuFKZYATRiuu9bZP+WqVW+rmogP/1a4zjv1tV1Ouk/5GXd6 /l3DFNRTFs9CBG9Yw2zlFCJsu/7uA+4+qNxmGcIhtTtTpT8gcXnfwufPkhQlAGrrnovo 8BTA== MIME-Version: 1.0 Received: by 10.112.40.163 with SMTP id y3mr1282432lbk.19.1331743940771; Wed, 14 Mar 2012 09:52:20 -0700 (PDT) Received: by 10.112.76.196 with HTTP; Wed, 14 Mar 2012 09:52:20 -0700 (PDT) In-Reply-To: <051b01cd015e$59b80c40$0d2824c0$@packetizer.com> References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> <CAA3wLqUxC=NwTeLhan8tBTZ2NQ_FqnY4xbiWNjjDU7dq7FoYgw@mail.gmail.com> <051b01cd015e$59b80c40$0d2824c0$@packetizer.com> Date: Wed, 14 Mar 2012 12:52:20 -0400 Message-ID: <CAA3wLqVmQdA1DNptoQFZyyqE1fzrsFTFFz=vu36BTsh5UW497w@mail.gmail.com> From: Michael Hammer <mphmmr@gmail.com> To: "Paul E. Jones" <paulej@packetizer.com> Content-Type: multipart/alternative; boundary=e0cb4efe2be8857eee04bb36cca7 Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 16:52:30 -0000 --e0cb4efe2be8857eee04bb36cca7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul, That subjective decision to use or not determines if it gets used or not, and hence the result. It is transitive. Interoperability will be inversely proportional to the vagueness of the mechanism. Many false positives or false negatives will reduce the usefulness of such a declarative capability. As suggested elsewhere, this may boil down to random value matching and non-standard value choices. Mike On Tue, Mar 13, 2012 at 5:14 PM, Paul E. Jones <paulej@packetizer.com>wrote= : > Mike,**** > > ** ** > > Interoperability is in terms of =93do you support this capability=94? Th= e > answer is either yes or no. The declaration that a device is immersive > might be subjective, but the use is not.**** > > ** ** > > If I indicate in my INVITE when I call you that I want to reject any > device on your end that does not advertise itself as immersive and you ha= ve > no such devices, the call fails. Likewise, if you have one that advertis= es > the capability, it connects to that one.**** > > ** ** > > Paul**** > > ** ** > > *From:* Michael Hammer [mailto:mphmmr@gmail.com] > *Sent:* Tuesday, March 13, 2012 9:11 AM > *To:* Paul E. Jones > *Cc:* Worley, Dale R (Dale); Glen Lavers (glavers); dispatch@ietf.org > *Subject:* Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.tx= t > **** > > ** ** > > A judge once said: "I can't define pornography, but I can tell when I se= e > it."**** > > The term immersive seems to be in the same category.**** > > ** ** > > With something so subjective, can you tell me how that helps > interoperability?**** > > ISTM that it will be as useful as the evil bit.**** > > ** ** > > If I notice that it's use/non-use negatively impacts me, **** > > then I change it and get better service, is that cool with you?**** > > ** ** > > Mike**** > > ** ** > > ** ** > > ** ** > > On Mon, Mar 12, 2012 at 9:05 PM, Paul E. Jones <paulej@packetizer.com> > wrote:**** > > Dale, > > Thanks for the thorough review (as usual) :) > > > The definition of "immersive" (which seems to be synonymous with > > "telepresence") is not exact. That doesn't mean that the term isn't > > useful, but it is a warning that there may be no *technological* > > distinction. > > I personally view "immersive" as an adjective one can apply to > Telepresence, > but not all immersive systems are telepresence systems. For example, my > son > has an immersive video gaming experience each time puts his headset on hi= s > head. > > While the definition of "immersive" can be debated, I think it is importa= nt > to differentiate immersive from Telepresence. A voice call could certain= ly > be immersive. Our intent was to allow this tag to be used as a user > preference in conjunction with audio and video tags to help route calls o= r > select devices. > > > In regard to admission control, I expect that in both architecture and > > practice, networks will want to base admission distinctions on more > > detailed information than "immersive". But maybe I'm wrong; I think > > networks have explicitly excluded all "video" media as an admission > > policy. So perhaps a network would refuse admission to any "immersive" > > video but allow non-immersive video, in order to conserve bandwidth. > > Admission control was viewed as just one possible usage. Quite likely, i= f > it were used for admission control, the tag would be policed somewhere. > Assuming the tag is policed on both ends and both ends seek an immersive > experience, this will have an influence on the admission control decision= s. > This draft certainly does not intend to suggest every input that will go > into admission control logic, but this is just one potentially useful cod= e > point. > > > Please, please, please do not use the word "leverage" to mean "utilize > (to > > gain a further advantage)". That word makes it sound like contact with > > marketing people has damaged your brain. > > :-) I cannot argue with you on that point. > > > In regard to routing decisions, a feature tag is useful if *some* calls > > *prefer* the feature and also *some* calls *reject* > > (anti-prefer) the feature. Unless this criterion is true, the callee's > > local network (or the callee's behavior) can obtain all possible benefi= t > > by statically prioritizing the alternative UAs. > > Since it's a caller preferences tag, all things are possible. A UA could > require tag, reject on the tag, etc. > > > There are two examples in the draft, but neither is an example of eithe= r > > stated motivation. The examples and the motivations should not be > > conceptually disjoint. > > The REGISTER example wasn't intended to provide an example of motivation = of > the tag directly, but it shows how might be used in signaling to facilita= te > device selection. Once the device is registered with this feature tag, > then > call routing logic can utilize this information in device selection. > > The INVITE example just shows its use, but I agree it does not help to > support the stated motivations. The intent was just to show its usage. > > I would have been happy without the examples, but others felt like the > examples were useful to show where this is signaled; that's about all the > examples are for. > > > As Paul notes, the tag would be expressed as "+sip.immersive". > > That was a point that was not entirely clear to me. I wish I had seen Pa= ul > K's message, but I seem to lose some of his :-( > > Syntactically, the "immersive" tag is allowed per RFC 3261 syntax. Per R= FC > 3640, it seemed to suggest +sip was needed, but it was not clear how one > can > define new "base" tags that do not require +sip. So, there is no > possibility for introducing new base tags -- ever? > > > A motivation which seems plausible to me is that a video UA would want = to > > know if the *other* video UA was operating in an immersive manner or no= t, > > or whether it was capable of doing so, so as to adjust its behavior. > > E.g., if an immersive system is communicating with an "ordinary" system= , > > it might want to (effectively) crop its transmitted video signal from > > "immersive surrounding" to "viewing screen" > > dimensions. > > That's certainly possible, yes. > > > The previous paragraph suggests that the set of existing video > > conferencing systems might be bimodal, that is, they might fall into tw= o > > distinct classes: small-screen systems that people look at like > > televisions, and large-screen systems that surround the viewers, with n= o > > systems of intermediate size. If that is actually true (and it might > have > > become true in the market without people explicitly planning or noticin= g > > it), it should be documented, and might be a justification for labeling > > videoconferencing systems with a binary "immersive" attribute. > > I definitely think we will have such systems. One does not want to limit= a > system that can provide a rich experience from communicating with a deskt= op > video phone or an iPad. Any communication is better than no communicatio= n. > In such cases, I can certainly see that a system might adjust behavior. > > The main idea we had in mind (or I did and let the others state their > thoughts) was that a user might have a plurality of callable devices. I > could use this tag to route calls to preferred devices. I could tell my > SIP > server that during the business day, I prefer to route all "immersive" > calls > to my single screen Telepresence system on my desk. In the evenings, I > might have those routed to my softphone. > > Of course, the caller can also indicate preferences: it may not want to > allow the call to go to a softphone. All of these things are possible wi= th > the caller preferences framework. > > > I suspect that there are important aspects of this subject that the > > authors know (at least intuitively) but have not documented, and a > > revision of the draft might be very informative. > > Reading too much into this can be dangerous. It's certainly possible to > throw out a lot of ideas for this tag, but at the end of the day it is > nothing but a feature tag. In RFC 3840, no single tag is discussed at su= ch > length. As such, I didn't feel like this one should. It was stated that > "immersive" is subjective and, to some extent, that's true. An "immersiv= e" > system is what one says it is. Beyond that, though, the system behavior = is > fairly well-defined in RFC 3840 and RFC 3841. > > > In any case, it seems to me that this draft falls squarely within the > > remit of CLUE. > > I do have to disagree with you on this point. :-) > > If CLUE did or did not exist, it would not change the desire to an > immersive > tag. We're not defining multiple streams, camera positioning, or the > multitude of things people are pouring into "Telepresence". None of that > makes any sense of an immersive audio call. > > This gets back to "what is immersive"? Like RFC 3840, one can ask "what = is > text?" (That's another feature tag.) Is this instant messaging text? Or > is > this real-time text that is delivered character-at-a-time? There is also > the "mobility" tag. Is that a mobile phone? Is it a laptop with Wi-Fi? = A > tablet? > > I'd like to separate the notion of "immersive" from Telepresence, because= I > view it as an adjective that is a part of Telepresence. Nonetheless, it = is > an adjective that we would like to use with or without Telepresence and i= n > conjunction with audio and video feature tags. > > > Paul > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch**** > > ** ** > --e0cb4efe2be8857eee04bb36cca7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul,<div><br></div><div>That subjective decision to use or not determines = if it gets used or not, and hence the result. =A0It is transitive.</div><di= v>Interoperability will be inversely proportional to the vagueness of the m= echanism.<br> </div><div><br></div><div>Many false positives or false negatives will redu= ce the usefulness of such a declarative capability.</div><div><br></div><di= v>As suggested elsewhere, this may boil down to random value matching and n= on-standard value choices.</div> <div><br></div><div>Mike</div><div><br><br><div class=3D"gmail_quote">On Tu= e, Mar 13, 2012 at 5:14 PM, Paul E. Jones <span dir=3D"ltr"><<a href=3D"= mailto:paulej@packetizer.com">paulej@packetizer.com</a>></span> wrote:<b= r> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"p= urple"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-fam= ily:"Calibri","sans-serif";color:#1f497d">Mike,<u></u><= u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=A0<u></u></span><= /p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif";color:#1f497d">Interoperability is in= terms of =93do you support this capability=94?=A0 The answer is either yes= or no.=A0 The declaration that a device is immersive might be subjective, = but the use is not.<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=A0<u></u></span><= /p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif";color:#1f497d">If I indicate in my IN= VITE when I call you that I want to reject any device on your end that does= not advertise itself as immersive and you have no such devices, the call f= ails.=A0 Likewise, if you have one that advertises the capability, it conne= cts to that one.<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=A0<u></u></span><= /p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif";color:#1f497d">Paul<u></u><u></u></sp= an></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1f497d"><u></u>=A0<u></u></span><= /p><div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0= in 4.0pt"> <div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt= 0in 0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;fon= t-family:"Tahoma","sans-serif"">From:</span></b><span s= tyle=3D"font-size:10.0pt;font-family:"Tahoma","sans-serif&qu= ot;"> Michael Hammer [mailto:<a href=3D"mailto:mphmmr@gmail.com" target=3D"= _blank">mphmmr@gmail.com</a>] <br> <b>Sent:</b> Tuesday, March 13, 2012 9:11 AM<br><b>To:</b> Paul E. Jones<br= ><b>Cc:</b> Worley, Dale R (Dale); Glen Lavers (glavers); <a href=3D"mailto= :dispatch@ietf.org" target=3D"_blank">dispatch@ietf.org</a><br><b>Subject:<= /b> Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt<u></u><= u></u></span></p> </div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNorm= al">A judge once said: =A0"I can't define pornography, but I can t= ell when I see it."<u></u><u></u></p><div><p class=3D"MsoNormal">The t= erm immersive seems to be in the same category.<u></u><u></u></p> </div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class= =3D"MsoNormal">With something so subjective, can you tell me how that helps= interoperability?<u></u><u></u></p></div><div><p class=3D"MsoNormal">ISTM = that it will be as useful as the evil bit.<u></u><u></u></p> </div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class= =3D"MsoNormal">If I notice that it's use/non-use negatively impacts me,= =A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">then I change it and= get better service, is that cool with you?<u></u><u></u></p> </div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class= =3D"MsoNormal">Mike<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u><= /u>=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></d= iv><div><p class=3D"MsoNormal"> <u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Mon, Mar 12, 2012 at 9:= 05 PM, Paul E. Jones <<a href=3D"mailto:paulej@packetizer.com" target=3D= "_blank">paulej@packetizer.com</a>> wrote:<u></u><u></u></p><p class=3D"= MsoNormal"> Dale,<br><br>Thanks for the thorough review (as usual) :)<br><br>> The d= efinition of "immersive" (which seems to be synonymous with<br>&g= t; "telepresence") is not exact. =A0That doesn't mean that th= e term isn't<br> > useful, but it is a warning that there may be no *technological*<br>&g= t; distinction.<br><br>I personally view "immersive" as an adject= ive one can apply to Telepresence,<br>but not all immersive systems are tel= epresence systems. =A0For example, my son<br> has an immersive video gaming experience each time puts his headset on his<= br>head.<br><br>While the definition of "immersive" can be debate= d, I think it is important<br>to differentiate immersive from Telepresence.= =A0A voice call could certainly<br> be immersive. =A0Our intent was to allow this tag to be used as a user<br>p= reference in conjunction with audio and video tags to help route calls or<b= r>select devices.<br><br>> In regard to admission control, I expect that= in both architecture and<br> > practice, networks will want to base admission distinctions on more<br= >> detailed information than "immersive". =A0But maybe I'm= wrong; I think<br>> networks have explicitly excluded all "video&q= uot; media as an admission<br> > policy. =A0So perhaps a network would refuse admission to any "im= mersive"<br>> video but allow non-immersive video, in order to cons= erve bandwidth.<br><br>Admission control was viewed as just one possible us= age. =A0Quite likely, if<br> it were used for admission control, the tag would be policed somewhere.<br>= Assuming the tag is policed on both ends and both ends seek an immersive<br= >experience, this will have an influence on the admission control decisions= .<br> This draft certainly does not intend to suggest every input that will go<br= >into admission control logic, but this is just one potentially useful code= <br>point.<br><br>> Please, please, please do not use the word "lev= erage" to mean "utilize (to<br> > gain a further advantage)". =A0That word makes it sound like cont= act with<br>> marketing people has damaged your brain.<br><br>:-) =A0I c= annot argue with you on that point.<br><br>> In regard to routing decisi= ons, a feature tag is useful if *some* calls<br> > *prefer* the feature and also *some* calls *reject*<br>> (anti-pref= er) the feature. =A0Unless this criterion is true, the callee's<br>>= local network (or the callee's behavior) can obtain all possible benef= it<br> > by statically prioritizing the alternative UAs.<br><br>Since it's = a caller preferences tag, all things are possible. =A0A UA could<br>require= tag, reject on the tag, etc.<br><br>> There are two examples in the dra= ft, but neither is an example of either<br> > stated motivation. =A0The examples and the motivations should not be<b= r>> conceptually disjoint.<br><br>The REGISTER example wasn't intend= ed to provide an example of motivation of<br>the tag directly, but it shows= how might be used in signaling to facilitate<br> device selection. =A0Once the device is registered with this feature tag, t= hen<br>call routing logic can utilize this information in device selection.= <br><br>The INVITE example just shows its use, but I agree it does not help= to<br> support the stated motivations. =A0The intent was just to show its usage.<b= r><br>I would have been happy without the examples, but others felt like th= e<br>examples were useful to show where this is signaled; that's about = all the<br> examples are for.<br><br>> As Paul notes, the tag would be expressed as = "+sip.immersive".<br><br>That was a point that was not entirely c= lear to me. =A0I wish I had seen Paul<br>K's message, but I seem to los= e some of his :-(<br> <br>Syntactically, the "immersive" tag is allowed per RFC 3261 sy= ntax. =A0Per RFC<br>3640, it seemed to suggest +sip was needed, but it was = not clear how one can<br>define new "base" tags that do not requi= re +sip. =A0So, there is no<br> possibility for introducing new base tags -- ever?<br><br>> A motivation= which seems plausible to me is that a video UA would want to<br>> know = if the *other* video UA was operating in an immersive manner or not,<br> > or whether it was capable of doing so, so as to adjust its behavior.<b= r>> E.g., if an immersive system is communicating with an "ordinary= " system,<br>> it might want to (effectively) crop its transmitted = video signal from<br> > "immersive surrounding" to "viewing screen"<br>>= ; dimensions.<br><br>That's certainly possible, yes.<br><br>> The pr= evious paragraph suggests that the set of existing video<br>> conferenci= ng systems might be bimodal, that is, they might fall into two<br> > distinct classes: =A0small-screen systems that people look at like<br>= > televisions, and large-screen systems that surround the viewers, with = no<br>> systems of intermediate size. =A0If that is actually true (and i= t might have<br> > become true in the market without people explicitly planning or notici= ng<br>> it), it should be documented, and might be a justification for l= abeling<br>> videoconferencing systems with a binary "immersive&quo= t; attribute.<br> <br>I definitely think we will have such systems. =A0One does not want to l= imit a<br>system that can provide a rich experience from communicating with= a desktop<br>video phone or an iPad. =A0Any communication is better than n= o communication.<br> In such cases, I can certainly see that a system might adjust behavior.<br>= <br>The main idea we had in mind (or I did and let the others state their<b= r>thoughts) was that a user might have a plurality of callable devices. =A0= I<br> could use this tag to route calls to preferred devices. =A0I could tell my = SIP<br>server that during the business day, I prefer to route all "imm= ersive" calls<br>to my single screen Telepresence system on my desk. = =A0In the evenings, I<br> might have those routed to my softphone.<br><br>Of course, the caller can a= lso indicate preferences: it may not want to<br>allow the call to go to a s= oftphone. =A0All of these things are possible with<br>the caller preference= s framework.<br> <br>> I suspect that there are important aspects of this subject that th= e<br>> authors know (at least intuitively) but have not documented, and = a<br>> revision of the draft might be very informative.<br><br>Reading t= oo much into this can be dangerous. =A0It's certainly possible to<br> throw out a lot of ideas for this tag, but at the end of the day it is<br>n= othing but a feature tag. =A0In RFC 3840, no single tag is discussed at suc= h<br>length. =A0As such, I didn't feel like this one should. =A0It was = stated that<br> "immersive" is subjective and, to some extent, that's true. = =A0An "immersive"<br>system is what one says it is. =A0Beyond tha= t, though, the system behavior is<br>fairly well-defined in RFC 3840 and RF= C 3841.<br> <br>> In any case, it seems to me that this draft falls squarely within = the<br>> remit of CLUE.<br><br>I do have to disagree with you on this po= int. :-)<br><br>If CLUE did or did not exist, it would not change the desir= e to an immersive<br> tag. =A0We're not defining multiple streams, camera positioning, or the= <br>multitude of things people are pouring into "Telepresence". = =A0None of that<br>makes any sense of an immersive audio call.<br><br>This = gets back to "what is immersive"? =A0Like RFC 3840, one can ask &= quot;what is<br> text?" =A0(That's another feature tag.) Is this instant messaging = text? =A0Or is<br>this real-time text that is delivered character-at-a-time= ? =A0There is also<br>the "mobility" tag. =A0Is that a mobile pho= ne? =A0Is it a laptop with Wi-Fi? =A0A<br> tablet?<br><br>I'd like to separate the notion of "immersive"= from Telepresence, because I<br>view it as an adjective that is a part of = Telepresence. =A0Nonetheless, it is<br>an adjective that we would like to u= se with or without Telepresence and in<br> conjunction with audio and video feature tags.</p><div class=3D"im"><br><br= >Paul<br><br><br><br><br><br><br>__________________________________________= _____<br>dispatch mailing list<br><a href=3D"mailto:dispatch@ietf.org" targ= et=3D"_blank">dispatch@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/dispatch</a><u></u><u></u></div><p>= </p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></d= iv></blockquote> </div><br></div> --e0cb4efe2be8857eee04bb36cca7-- From D.Malas@cablelabs.com Wed Mar 14 10:46:26 2012 Return-Path: <D.Malas@cablelabs.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC47221F8789 for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 10:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.317 X-Spam-Level: X-Spam-Status: No, score=-100.317 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWVgH6pA+ttR for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 10:46:25 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id BDC9121F8760 for <dispatch@ietf.org>; Wed, 14 Mar 2012 10:46:25 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2EHkGr9029215; Wed, 14 Mar 2012 11:46:23 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 14 Mar 2012 11:46:16 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 14 Mar 2012 11:16:25 -0600 From: Daryl Malas <D.Malas@cablelabs.com> To: "Peterson, Jon" <jon.peterson@neustar.biz>, "PFAUTZ, PENN L" <pp3129@att.com>, "'dispatch@ietf.org'" <dispatch@ietf.org> Date: Wed, 14 Mar 2012 11:16:24 -0600 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: Ac0CBi+GXQxkZtPJSTuC1A/hdDDdRw== Message-ID: <CB864974.CAD1%d.malas@cablelabs.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA239D6360@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 17:46:27 -0000 I think we should be careful in being presumptuous of what we will do or the effects we will impose on any protocol at this point. As part of this proposal, I think we should do some basic analysis of the suite of protocols (and extensions) existing today related to this. We may or may not find that some could be used or further extended. Of course, I'm open to creating a new mechanism as a result of this work, if necessary. --Daryl On 3/13/12 2:54 PM, "Peterson, Jon" <jon.peterson@neustar.biz> wrote: > >Hi Penn, > >Glad to hear this is of interest, at least. Certainly agreed that there >is ENUM deployment out there - in fact, my own company does a bit of it. >When protocols become successful and see deployment, people do start >using them in unexpected ways which sometimes require significant >modifications, and eventually you can reach a tipping point where it >makes sense to reconsider the fundamentals. I think we've reached that >point with ENUM, where we have seen proposals to extend ENUM (and the >DNS) that warrant taking a step back and exploring whether or not we can >get a better overall framework in place - at least a framework in which >we can standardize features that have been proposed for ENUM but which >fall outside the ways we can responsibly extend the DNS. > >Also agreed, by the by, that administrative and political factors have >held ENUM back from being all that it can be. You'll note that the TeRQ >proposal does not prescribe any administrative framework like e164.arpa - >it's really just a query/response protocol. The irony of e164.arpa is >that it applied well to the original, public vision of ENUM, but has >sometimes ended up hampering attempts to get the carrier-driven, more >infrastructural deployments off the ground. > >No one is expecting that the TeRQ proposal will snuff out ENUM deployment >overnight. I'm sure ENUM will continue to serve a segment of the market >for the foreseeable future. But ENUM was standardized twelve years ago >now - a pretty good life cycle for any protocol. All I'm really proposing >is that we see how much we could gain from starting on a different >foundation. If we end up with something better, it will eventually phase >into the market and get traction. All a standards activity can do is >create that opportunity. > >Jon Peterson >NeuStar, Inc. >________________________________________ >From: PFAUTZ, PENN L [pp3129@att.com] >Sent: Tuesday, March 13, 2012 8:11 AM >To: Peterson, Jon; 'dispatch@ietf.org' >Subject: RE: [dispatch] New Proposal for Telephone-Related Queries > >I think this is an interesting activity and would not want to derail it, >but let me play devil's advocate for a moment... > >- if we were just starting out, as opposed to having lots of (at least >internal and some external) deployments, I would be more optimistic >- although I know that the proposal responds to many concerns that have >been raised with enum, I personally don't see the protocol issues or even >the semantics of the of what the protocol can address as ever having been >the major thing that has held enum back from full potential. It's always >been lack of consensus on administrative arrangements driven by business >and -dare I say- political concerns. > >Good luck! > >Penn Pfautz >AT&T Access Management >+1-732-420-4962 >-----Original Message----- >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >Behalf Of Peterson, Jon >Sent: Monday, March 05, 2012 5:05 PM >To: 'dispatch@ietf.org' >Subject: Re: [dispatch] New Proposal for Telephone-Related Queries > > >Oops, sorry, my mailer did not like the URL I submitted. The correct URL >for the draft is: > >https://datatracker.ietf.org/doc/draft-peterson-terq/ > >Jon Peterson >Neustar, Inc. > > > > -----Original Message----- >From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time >To: dispatch@ietf.org >Subject: [dispatch] New Proposal for Telephone-Related Queries > > >I have a proposal to bounce off the group. Basically, this is a >re-examination of some of the problems we've previously considered in the >telephony-specific cluster of work surrounding ENUM, DRINKS and >SPEERMINT. Through discussions in the past couple years, it's become >clear that we would need to significantly extend ENUM to get it to handle >all of the sorts of sources, subjects, and attributes that people want to >factor into queries about telephone number routing and administration. >Most of these discussions have gotten wrapped around the axle on >questions of the underlying syntax and semantics of the DNS, which were a >good match for the original vision of a public, user-driven ENUM, but >don't seem to be such a good match for the uses people actually want to >make of these protocols, in federated, service-provider-driven >environments like those envisioned in SPEERMINT and provisioned in >DRINKS. While the discussion may have died down a bit, the requirements >that motivated th > e discussion definitely aren't going away. > >Rather than continue to debate the applicability of the DNS and the >probity of various extensions to it, we might make more progress if we >work towards agreement on the semantics of queries for telephone-related >data independently of any underlying protocols. In other words, focus on >what kinds of questions about telephone numbers we want to be able to >ask, and what kinds of information needs to go into the answers, and >incorporate all this into an abstract data model. So for example, we know >that we want to be able to express the source of a request in a query. >What do we mean by source? I can think of a bunch of different kinds of >source: the logical originator of the query (the administrative entity >asking), the logical identity of any intermediary or aggregator >forwarding the query, or even the point at the network from which the >call originates (the originating trunk group, SBC or what have you). All >three of those concepts of source seem important when it comes to answe > ring questions about telephone numbers, so a data model would treat >those as separate elements which can vary independently - then we can >then try to figure out what's mandatory or optional, etc. We follow this >same method for all the elements of queries and responses. Figure out >what the attributes are of telephone numbers that we care about, sort >them into buckets of routing data and administrative data, and so on. > >Once we have an agreement on the data model, then people can map the >model to whatever underlying protocol they'd like - or just build it into >a web API, or what have you. Those proposals could advance as separate >documents. Having that flexibility would make it a lot easier to figure >out what we really want the questions and answers to be, rather than >thinking about what they realistically can be within the constraints of >some existing underlying protocol. > >That's the idea. I'm not going to present a proposed charter for work or >anything like that in Paris, but I am interested in hearing if people >think this is a promising approach, and if so, perhaps we'd put a charter >on the agenda for Vancouver. I have however submitted a -00 draft for >this time which gives a high-level proposal for a data model and at least >enumerates what some of the elements might be that would be populated in >queries and responses. This is a pretty broad sketch, but it should >convey the basic idea. You can check it out here: >https://exchcas.va.neustar.com/owa/thoughts about the direction or the >specifics of the data model are welcome. Thanks! > >Jon Peterson >NeuStar, Inc. >_______________________________________________ >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 dworley@avaya.com Wed Mar 14 11:42:43 2012 Return-Path: <dworley@avaya.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6423D21F87AB for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 11:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x992Zb0cHrPZ for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 11:42:43 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id DA4CE21F87A8 for <dispatch@ietf.org>; Wed, 14 Mar 2012 11:42:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALTlYE/GmAcF/2dsb2JhbABDDrYfgQeCCQEBAQECARIoLSICAQgNASgQMiUBAQQBGhqHYwWeUpw6kBtjBJtjihuCL1M X-IronPort-AV: E=Sophos;i="4.73,585,1325480400"; d="scan'208";a="238113071" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 Mar 2012 14:42:40 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Mar 2012 14:34:45 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 14 Mar 2012 14:42:40 -0400 From: "Worley, Dale R (Dale)" <dworley@avaya.com> To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "dispatch@ietf.org" <dispatch@ietf.org> Date: Wed, 14 Mar 2012 14:42:40 -0400 Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Ac0B/Nv2llRz/s8jSTORITa7OknLUgAFKJ5i Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A096C@DC-US1MBEX4.global.avaya.com> References: <CB7F8CA4.1DB88%glavers@cisco.com> <4F5A6C5D.3030606@alum.mit.edu> <4F5FCB21.2060301@digium.com> <4F5FE542.8050709@alum.mit.edu> <4F609C1C.7050400@digium.com>, <4F60A739.4080605@alum.mit.edu> <CD5674C3CD99574EBA7432465FC13C1B22726A0967@DC-US1MBEX4.global.avaya.com>, <4F60C2BC.6030605@alum.mit.edu> In-Reply-To: <4F60C2BC.6030605@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 18:42:43 -0000 > > It's one of the few situations where *capability* is highly predictive > > of the communication request that will be made in the near future (but > > is not indicated at present). Perhaps for "truth in advertising" the > > feature tag should be "+sip.going-to-ask-for-T38-soon". ;-) >=20 > For dedicated fax devices its also perfectly reasonable to include > callerprefs requesting fax capability. Yeah. I thought more about it, and it seems that a better scheme would be: A sip.fax media feature tag to indicate the device is *capable* of doing fax. Then a caller who *intends* do to fax on this call uses "Accept-Contact: *;sip.fax" to select only fax-capable destinations. (If I understand the syntax and semantics of Accept-Contact correctly.) A carrier can key off of this Accept-Contact to know to assign a fax-capable trunk line for the call. Dale From dworley@avaya.com Wed Mar 14 12:14:07 2012 Return-Path: <dworley@avaya.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914DD21F85AC for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 12:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.109 X-Spam-Level: X-Spam-Status: No, score=-103.109 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NNwgXqh4Fhe for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 12:14:06 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 30A1521F8598 for <dispatch@ietf.org>; Wed, 14 Mar 2012 12:14:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJLtYE+HCzI1/2dsb2JhbAA5CrYugQeCAgcBAQEBAgESVhEFCwIBCA0IMTIlAgQKBAUIGoUmB4I2BZ5JnD6KMIVrYwSbY4obgwI X-IronPort-AV: E=Sophos;i="4.73,585,1325480400"; d="scan'208";a="297165656" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Mar 2012 15:14:04 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Mar 2012 14:58:41 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 14 Mar 2012 15:14:03 -0400 From: "Worley, Dale R (Dale)" <dworley@avaya.com> To: "Paul E. Jones" <paulej@packetizer.com> Date: Wed, 14 Mar 2012 15:11:33 -0400 Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: AQIGlAq4PGrll3yWVQrHLtOjxHlL0QGM5LtOApsegtMCwxqCqQIVAynKArlo1yYCM/uG3wIxpaqWAO9fLk4CQjY7WpVbC3sQgAFy9eQ= Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A096D@DC-US1MBEX4.global.avaya.com> References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> <3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com>, <03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> <CD5674C3CD99574EBA7432465FC13C1B22726A0958@DC-US1MBEX4.global.avaya.com>, <051901cd015d$fa776f50$ef664df0$@packetizer.com> In-Reply-To: <051901cd015d$fa776f50$ef664df0$@packetizer.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 19:14:07 -0000 > From: Paul E. Jones [paulej@packetizer.com] >=20 > Our expectation was that a user, and more likely a system administrator, > will "declare" that a device is "immersive" or not. That becomes > subjective, perhaps, but that is what the user preferred. Who is "the user" who preferred this? > I understand that video is a "thing" you can point your finger at and > identify, whereas immersive is not. However, what is "mobile"? What is > "data"? I'd argue that "data" is equally as vague. Still, it is a prope= rty > one can define and use. Well, if "data" is vague, that means you can't actually define it, and if you can't define it, you can't effectively use it. But in reality, the IANA registry defines "sip.data" as "This feature tag indicates that the device supports data as a streaming media type." and refers to RFC 3840. RFC 3840 says the same, and refers to RFC 2327: "The audio, video, application, data, and control feature tags in the SIP tree (each of which indicate a media type, as defined in RFC 2327) are different. They do not indicate top level MIME types which can be received in SIP requests. Rather, they indicate media types that can be used in media streams, and as a result, match up with the types defined in RFC 2327." Looking at RFC 2327 gives: m=3D<media> <port> <transport> <fmt list> [...] o The first sub-field is the media type. Currently defined media are "audio", "video", "application", "data" and "control", though this list may be extended as new communication modalities emerge (e.g., telepresense). The difference between "application" and "data" is that the former is a media flow such as whiteboard information, and the latter is bulk-data transfer such as multicasting of program executables which will not typically be displayed to the user. "control" is used to specify an additional conference control channel for the session. RFC 4566 updates RFC 2327 with: Note: The media types "control" and "data" were listed as valid in the previous version of this specification [6]; however, their semantics were never fully specified and they are not widely used. These media types have been removed in this specification, although they still remain valid media type capabilities for a SIP user agent as defined in RFC 3840 [24]. If these media types are considered useful in the future, a Standards Track RFC MUST be produced to document their use. Until that is done, applications SHOULD NOT use these types and SHOULD NOT declare support for them in SIP capabilities declarations (even though they exist in the registry created by RFC 3840). So the "sip.data" tag means that the UA supports "m=3Ddata ..." in SDP, which will be used to carry bulk-data transfer such as multicasting of program executables which will not typically be displayed to the user, and it is obsolete and should not be used. The IANA registry defines "sip.mobility" as "The sip.mobility feature tag indicates whether the device is fixed (meaning that it is associated with a fixed point of contact with the network), or mobile (meaning that it is not associated with a fixed point of contact). Note that cordless phones are fixed, not mobile, based on this definition." > Interoperability is in terms of =93do you support this capability=94? > The answer is either yes or no. The declaration that a device is > immersive might be subjective, but the use is not. Certainly "what would happen" is well-defined in a technical sense. But the question is whether a caller would *wish* to invoke this functionality. In order for this to be a matter of interoperability, there would need to be circumstances where a caller in one organization would want to contact a callee *with whom he had no previous arrangements* and desire the contact only be via an "immersive" UA (or only via a non-"immersive" UA). For this to be sensible, "immersive" has to have some sort of global meaning. If "immersive" is *freely* assigned by each user (or organizational system administrator), it has no global meaning, and there is no reason a caller would use it in caller-preferences generally, since he has no idea what its consequences would be at the callee's system. So if we want to *standardize* an immersive indicator, we need to (1) fix a (perhaps somewhat elastic) criterion for what constitutes "immersive", and (2) have a belief that callers might wish to distinguish between immersive and non-immersive UAs when calling destinations about which they have no information other than the RFC. Dale From mphmmr@gmail.com Wed Mar 14 12:20:24 2012 Return-Path: <mphmmr@gmail.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BF521F87E6 for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 12:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTuBbU+NwkPj for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 12:20:23 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0575C21F881F for <dispatch@ietf.org>; Wed, 14 Mar 2012 12:20:22 -0700 (PDT) Received: by lbol12 with SMTP id l12so1180889lbo.31 for <dispatch@ietf.org>; Wed, 14 Mar 2012 12:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XtPdkFq6PsoZBTSRdS9kAeao9M3/4wtv1QA0uhCZsVg=; b=rzxNRqz/KgculFTV9Yjk8x6AInKvcFkg28F6+Rb4pGtD8qrANz5yuOuh/UFtVnInrV b8k49WNqhoTMDCmJUvlUODREq3hQdLnpIRYfBLZjMe42bB/tk/vIogwFW4SpObG9bEdJ kJjVqUiBCLhuJmKa/bZ5xv+GrUb0nmzLpqDNgbRSdvWoplbioSIfurI+1NKKu737yHdJ ivU5HcDvG8UlNNCSikhX8zBjpXsiSSx/W3uhfwvAYhiw3K2OD9oDrGPRYS4f5cY6JrHl SQhxPzIICAaJyOB/jajxRHEJ4s1gSOSyDmH1SAWlRRsqw35LPyDQTYetKQDFfr7knobr Gowg== MIME-Version: 1.0 Received: by 10.152.134.2 with SMTP id pg2mr2933885lab.3.1331752821786; Wed, 14 Mar 2012 12:20:21 -0700 (PDT) Received: by 10.112.76.196 with HTTP; Wed, 14 Mar 2012 12:20:21 -0700 (PDT) In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A096D@DC-US1MBEX4.global.avaya.com> References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> <3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com> <03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> <CD5674C3CD99574EBA7432465FC13C1B22726A0958@DC-US1MBEX4.global.avaya.com> <051901cd015d$fa776f50$ef664df0$@packetizer.com> <CD5674C3CD99574EBA7432465FC13C1B22726A096D@DC-US1MBEX4.global.avaya.com> Date: Wed, 14 Mar 2012 15:20:21 -0400 Message-ID: <CAA3wLqVVGWPgsHLLYhY7OE_7Hn0uYCneZwTeR8T6d4K1GzLi3Q@mail.gmail.com> From: Michael Hammer <mphmmr@gmail.com> To: "Worley, Dale R (Dale)" <dworley@avaya.com> Content-Type: multipart/alternative; boundary=f46d042ef7a9df09f304bb38dd5f Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 19:20:24 -0000 --f46d042ef7a9df09f304bb38dd5f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If it can get down to identifying specific protocols to be used, that would be useful. Mike On Wed, Mar 14, 2012 at 3:11 PM, Worley, Dale R (Dale) <dworley@avaya.com>w= rote: > > From: Paul E. Jones [paulej@packetizer.com] > > > > Our expectation was that a user, and more likely a system administrator= , > > will "declare" that a device is "immersive" or not. That becomes > > subjective, perhaps, but that is what the user preferred. > > Who is "the user" who preferred this? > > > I understand that video is a "thing" you can point your finger at and > > identify, whereas immersive is not. However, what is "mobile"? What i= s > > "data"? I'd argue that "data" is equally as vague. Still, it is a > property > > one can define and use. > > Well, if "data" is vague, that means you can't actually define it, and > if you can't define it, you can't effectively use it. > > But in reality, the IANA registry defines "sip.data" as "This feature > tag indicates that the device supports data as a streaming media > type." and refers to RFC 3840. RFC 3840 says the same, and refers to > RFC 2327: "The audio, video, application, data, and control feature > tags in the SIP tree (each of which indicate a media type, as defined > in RFC 2327) are different. They do not indicate top level MIME types > which can be received in SIP requests. Rather, they indicate media > types that can be used in media streams, and as a result, match up > with the types defined in RFC 2327." Looking at RFC 2327 gives: > > m=3D<media> <port> <transport> <fmt list> > [...] > o The first sub-field is the media type. Currently defined media are > "audio", "video", "application", "data" and "control", though this > list may be extended as new communication modalities emerge (e.g., > telepresense). The difference between "application" and "data" is > that the former is a media flow such as whiteboard information, and > the latter is bulk-data transfer such as multicasting of program > executables which will not typically be displayed to the user. > "control" is used to specify an additional conference control > channel for the session. > > RFC 4566 updates RFC 2327 with: > > Note: The media types "control" and "data" were listed as valid in > the previous version of this specification [6]; however, their > semantics were never fully specified and they are not widely used. > These media types have been removed in this specification, although > they still remain valid media type capabilities for a SIP user agent > as defined in RFC 3840 [24]. If these media types are considered > useful in the future, a Standards Track RFC MUST be produced to > document their use. Until that is done, applications SHOULD NOT use > these types and SHOULD NOT declare support for them in SIP > capabilities declarations (even though they exist in the registry > created by RFC 3840). > > So the "sip.data" tag means that the UA supports "m=3Ddata ..." in SDP, > which will be used to carry bulk-data transfer such as multicasting of > program executables which will not typically be displayed to the user, > and it is obsolete and should not be used. > > The IANA registry defines "sip.mobility" as "The sip.mobility feature > tag indicates whether the device is fixed (meaning that it is > associated with a fixed point of contact with the network), or mobile > (meaning that it is not associated with a fixed point of > contact). Note that cordless phones are fixed, not mobile, based on > this definition." > > > Interoperability is in terms of =93do you support this capability=94? > > The answer is either yes or no. The declaration that a device is > > immersive might be subjective, but the use is not. > > Certainly "what would happen" is well-defined in a technical sense. > But the question is whether a caller would *wish* to invoke this > functionality. > > In order for this to be a matter of interoperability, there would need > to be circumstances where a caller in one organization would want to > contact a callee *with whom he had no previous arrangements* and > desire the contact only be via an "immersive" UA (or only via a > non-"immersive" UA). For this to be sensible, "immersive" has to have > some sort of global meaning. If "immersive" is *freely* assigned by > each user (or organizational system administrator), it has no global > meaning, and there is no reason a caller would use it in > caller-preferences generally, since he has no idea what its > consequences would be at the callee's system. > > So if we want to *standardize* an immersive indicator, we need to (1) > fix a (perhaps somewhat elastic) criterion for what constitutes > "immersive", and (2) have a belief that callers might wish to > distinguish between immersive and non-immersive UAs when calling > destinations about which they have no information other than the RFC. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --f46d042ef7a9df09f304bb38dd5f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If it can get down to identifying specific protocols to be used, that would= be useful.<div><br></div><div>Mike</div><div><br><br><div class=3D"gmail_q= uote">On Wed, Mar 14, 2012 at 3:11 PM, Worley, Dale R (Dale) <span dir=3D"l= tr"><<a href=3D"mailto:dworley@avaya.com">dworley@avaya.com</a>></spa= n> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">> From: Paul E. Jones [<a href=3D"mailto:= paulej@packetizer.com">paulej@packetizer.com</a>]<br> ><br> > Our expectation was that a user, and more likely a system administrato= r,<br> > will "declare" that a device is "immersive" or not= . =A0That becomes<br> > subjective, perhaps, but that is what the user preferred.<br> <br> Who is "the user" who preferred this?<br> <br> > I understand that video is a "thing" you can point your fing= er at and<br> > identify, whereas immersive is not. =A0However, what is "mobile&q= uot;? =A0What is<br> > "data"? =A0I'd argue that "data" is equally as= vague. =A0Still, it is a property<br> > one can define and use.<br> <br> Well, if "data" is vague, that means you can't actually defin= e it, and<br> if you can't define it, you can't effectively use it.<br> <br> But in reality, the IANA registry defines "sip.data" as "Thi= s feature<br> tag indicates that the device supports data as a streaming media<br> type." =A0and refers to RFC 3840. =A0RFC 3840 says the same, and refer= s to<br> RFC 2327: =A0"The audio, video, application, data, and control feature= <br> tags in the SIP tree (each of which indicate a media type, as defined<br> in RFC 2327) are different. =A0They do not indicate top level MIME types<br= > which can be received in SIP requests. =A0Rather, they indicate media<br> types that can be used in media streams, and as a result, match up<br> with the types defined in RFC 2327." =A0Looking at RFC 2327 gives:<br> <br> =A0 m=3D<media> <port> <transport> <fmt list><br> =A0 [...]<br> =A0 o The first sub-field is the media type. =A0Currently defined media ar= e<br> =A0 =A0 "audio", "video", "application", &qu= ot;data" and "control", though this<br> =A0 =A0 list may be extended as new communication modalities emerge (e.g.,= <br> =A0 =A0 telepresense). =A0The difference between "application" a= nd "data" is<br> =A0 =A0 that the former is a media flow such as whiteboard information, an= d<br> =A0 =A0 the latter is bulk-data transfer such as multicasting of program<b= r> =A0 =A0 executables which will not typically be displayed to the user.<br> =A0 =A0 "control" is used to specify an additional conference co= ntrol<br> =A0 =A0 channel for the session.<br> <br> RFC 4566 updates RFC 2327 with:<br> <br> =A0 Note: The media types "control" and "data" were li= sted as valid in<br> =A0 the previous version of this specification [6]; however, their<br> =A0 semantics were never fully specified and they are not widely used.<br> =A0 These media types have been removed in this specification, although<br= > =A0 they still remain valid media type capabilities for a SIP user agent<b= r> =A0 as defined in RFC 3840 [24]. =A0If these media types are considered<br= > =A0 useful in the future, a Standards Track RFC MUST be produced to<br> =A0 document their use. =A0Until that is done, applications SHOULD NOT use= <br> =A0 these types and SHOULD NOT declare support for them in SIP<br> =A0 capabilities declarations (even though they exist in the registry<br> =A0 created by RFC 3840).<br> <br> So the "sip.data" tag means that the UA supports "m=3Ddata .= .." in SDP,<br> which will be used to carry bulk-data transfer such as multicasting of<br> program executables which will not typically be displayed to the user,<br> and it is obsolete and should not be used.<br> <br> The IANA registry defines "sip.mobility" as "The sip.mobilit= y feature<br> tag indicates whether the device is fixed (meaning that it is<br> associated with a fixed point of contact with the network), or mobile<br> (meaning that it is not associated with a fixed point of<br> contact). Note that cordless phones are fixed, not mobile, based on<br> this definition."<br> <br> > Interoperability is in terms of =93do you support this capability=94?<= br> > The answer is either yes or no. =A0The declaration that a device is<br= > > immersive might be subjective, but the use is not.<br> <br> Certainly "what would happen" is well-defined in a technical sens= e.<br> But the question is whether a caller would *wish* to invoke this<br> functionality.<br> <br> In order for this to be a matter of interoperability, there would need<br> to be circumstances where a caller in one organization would want to<br> contact a callee *with whom he had no previous arrangements* and<br> desire the contact only be via an "immersive" UA (or only via a<b= r> non-"immersive" UA). =A0For this to be sensible, "immersive&= quot; has to have<br> some sort of global meaning. =A0If "immersive" is *freely* assign= ed by<br> each user (or organizational system administrator), it has no global<br> meaning, and there is no reason a caller would use it in<br> caller-preferences generally, since he has no idea what its<br> consequences would be at the callee's system.<br> <br> So if we want to *standardize* an immersive indicator, we need to (1)<br> fix a (perhaps somewhat elastic) criterion for what constitutes<br> "immersive", and (2) have a belief that callers might wish to<br> distinguish between immersive and non-immersive UAs when calling<br> destinations about which they have no information other than the RFC.<br> <br> Dale<br> _______________________________________________<br> dispatch mailing list<br> <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/dispatch</a><br> </blockquote></div><br></div> --f46d042ef7a9df09f304bb38dd5f-- From dean.willis@softarmor.com Wed Mar 14 12:38:12 2012 Return-Path: <dean.willis@softarmor.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BD621F8599 for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 12:38:12 -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=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0TLQXlwHWEi for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 12:38:12 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1D4821F85A4 for <dispatch@ietf.org>; Wed, 14 Mar 2012 12:38:11 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2519400ghb.31 for <dispatch@ietf.org>; Wed, 14 Mar 2012 12:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-mailer; bh=WjnfE66LENYb+X51Y4CdDIaLXk+OP178ZmW6scz9Z7w=; b=UUIYHHuH1s+/vm8Is7zTjg6OSgtCiaL83Yd1ykKpGrdc62aRISnKGFRJDJNF5cpQRR zy/A9h9awXuLtGula40WIdfupbsK6ubSFEurNU5OUCqquC3HStxWsEqSAQ+x0D6AZagK xkRwKWk3xwEc7SLQsZBsOw4klXAxijsQzUmqY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-mailer :x-gm-message-state; bh=WjnfE66LENYb+X51Y4CdDIaLXk+OP178ZmW6scz9Z7w=; b=DwZudbAmFW/reBTOEOXyzw7Ygbu5ZiGXb8UfR9Q0vlJ72Mvsd+Qm34NaeGNuCfhh4v TXVtzbNCI2WRYDDWCd7nM4GCq0VQ3cANXaSH8IXTgRHSxOMDikaTLXYA4D6do7J6WfrS EVk/dNohab6YRFGCsTKsMFYy+GhCjXQUyXwTAGAt+GxteDw5G9ZhLVg5YtBUv0Bmli4V QmrXkKeejDBZbThExTbr1rApiOhdWGSxbCCCNYPm4sNJB+SUScAla3iB4Dbzk8Cf9jKW tZGkIFIwG5+NEpzaQxwZjR9GvtQG7ExJz3qUAOvOYueQkfbD5H51MsKO9TJIsYIARA0c q/iQ== Received: by 10.60.20.163 with SMTP id o3mr4887998oee.55.1331753891371; Wed, 14 Mar 2012 12:38:11 -0700 (PDT) Received: from [192.168.2.124] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id n7sm5259786oeh.4.2012.03.14.12.38.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Mar 2012 12:38:10 -0700 (PDT) References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> <3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com>, <03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> <CD5674C3CD99574EBA7432465FC13C1B22726A0958@DC-US1MBEX4.global.avaya.com> In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A0958@DC-US1MBEX4.global.avaya.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 Message-Id: <233B4045-E10D-423B-A4FD-31EEEA2ED253@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis <dean.willis@softarmor.com> Date: Wed, 14 Mar 2012 14:38:07 -0500 To: DISPATCH list <dispatch@ietf.org> X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnJihd+1di9ZwYUTR8bt/0loEYhSoQfDhJLF0QnJ+m1KFkjh9/U+jnDOjtrnc+i2vfQs08D Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 19:38:12 -0000 On Mar 13, 2012, at 11:16 AM, Worley, Dale R (Dale) wrote: >>=20 >>=20 >> You=92re a smart fellow. You understand the idea behind classifying = a >> device as =93immersive=94. >=20 > I may or may not be a smart fellow, but I don't understand the idea > behind classifying a device as "immersive". More exactly, I > understand it as a somewhat fuzzy property that a system may or may > not have, but I don't understand why devices should declare it, or why > a caller would care whether the destination UA had it or not. =20 >=20 >> The intent is to introduce something similar to those defined in RFC = 3840. >=20 > In this regard, it is very different from "audio" or "video", as those > describe the ability to render particular types of media stream (a > clearly-defined technological difference), and relate to the sensory > modes by which the interlocutors communicate (a clearly-defined user > experience difference). I was reading a good book last night on my Nook. It was immersive. But = this morning, on the same Nook and and the same book-app, the technical = tutorial I was reading was not so immersive. How could this be, if "immersive" is a property of the device? Are we = talking about some kind of physical thing here like "is 3d", "has 180 = degree field-of-view", or a subjective concept like a PG-13 rating? Otherwise said, one man's immersion is the sprinkling of a few drops on = the next man. But neither is as physiologically distinct as = circumcision. And despite arguably equal significance to the persons = involved, past immersion is pretty much impossible to verify by = mechanical inspection, and might not be a feature of the "device" in = question. -- Dean= From jon.peterson@neustar.biz Wed Mar 14 12:39:50 2012 Return-Path: <jon.peterson@neustar.biz> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1AC21F85D3 for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 12:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.005 X-Spam-Level: X-Spam-Status: No, score=-106.005 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXYfn2JnFEgr for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 12:39:49 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 660D921F85B9 for <dispatch@ietf.org>; Wed, 14 Mar 2012 12:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1331754023; x=1647113842; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=q7iiicey02m26Zy6p3gIR hkqiWIKaoCiaKH7/P184mM=; b=mrfETByaC+GlvNEZqFLBLbDiDSX4XGEbRLprs keVqXDPEw1cbW7N6RS7OaOT+zPFf018lIZFrRf1tCVdbqdQBA== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.6309680; Wed, 14 Mar 2012 15:40:22 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 14 Mar 2012 15:39:42 -0400 From: "Peterson, Jon" <jon.peterson@neustar.biz> To: Daryl Malas <D.Malas@cablelabs.com> Date: Wed, 14 Mar 2012 15:39:41 -0400 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: Ac0CGjPkVxXBAUxmQ12nFbG5YpLCgw== Message-ID: <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> References: <CB864974.CAD1%d.malas@cablelabs.com> In-Reply-To: <CB864974.CAD1%d.malas@cablelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: w0YArQDBff4osHEhLA5O2A== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 19:39:50 -0000 Obviously yes, I don't mean to suggest that any existing protocol is off th= e table as a potential underlying binding for TeRQ, but the whole point of = approaching this from the semantics rather than the transport or encoding i= s to defer those latter questions so we can focus on what we want queries a= nd responses to say. I think the analysis you recommend of how existing pro= tocols could map to TeRQ would be part of the bindings development process = - this is situation where we will want to let a thousand flowers bloom, and= I'm sure there will be existing proposals that would be good bindings for = TeRQ.=20 However, let's not sweep the obvious under the rug - we wouldn't be having = this TeRQ discussion at all if we had a clear path to extend the ENUM and D= NS standards to handle the semantics that the use cases seem to require. Th= at doesn't mean that a DNS binding is off the table, just that it would see= m to face challenges. Jon Peterson NeuStar, Inc. On Mar 14, 2012, at 10:16 AM, Daryl Malas wrote: > I think we should be careful in being presumptuous of what we will do or > the effects we will impose on any protocol at this point. >=20 > As part of this proposal, I think we should do some basic analysis of the > suite of protocols (and extensions) existing today related to this. We > may or may not find that some could be used or further extended. >=20 > Of course, I'm open to creating a new mechanism as a result of this work, > if necessary. >=20 > --Daryl >=20 > On 3/13/12 2:54 PM, "Peterson, Jon" <jon.peterson@neustar.biz> wrote: >=20 >>=20 >> Hi Penn, >>=20 >> Glad to hear this is of interest, at least. Certainly agreed that there >> is ENUM deployment out there - in fact, my own company does a bit of it. >> When protocols become successful and see deployment, people do start >> using them in unexpected ways which sometimes require significant >> modifications, and eventually you can reach a tipping point where it >> makes sense to reconsider the fundamentals. I think we've reached that >> point with ENUM, where we have seen proposals to extend ENUM (and the >> DNS) that warrant taking a step back and exploring whether or not we can >> get a better overall framework in place - at least a framework in which >> we can standardize features that have been proposed for ENUM but which >> fall outside the ways we can responsibly extend the DNS. >>=20 >> Also agreed, by the by, that administrative and political factors have >> held ENUM back from being all that it can be. You'll note that the TeRQ >> proposal does not prescribe any administrative framework like e164.arpa = - >> it's really just a query/response protocol. The irony of e164.arpa is >> that it applied well to the original, public vision of ENUM, but has >> sometimes ended up hampering attempts to get the carrier-driven, more >> infrastructural deployments off the ground. >>=20 >> No one is expecting that the TeRQ proposal will snuff out ENUM deploymen= t >> overnight. I'm sure ENUM will continue to serve a segment of the market >> for the foreseeable future. But ENUM was standardized twelve years ago >> now - a pretty good life cycle for any protocol. All I'm really proposin= g >> is that we see how much we could gain from starting on a different >> foundation. If we end up with something better, it will eventually phase >> into the market and get traction. All a standards activity can do is >> create that opportunity. >>=20 >> Jon Peterson >> NeuStar, Inc. >> ________________________________________ >> From: PFAUTZ, PENN L [pp3129@att.com] >> Sent: Tuesday, March 13, 2012 8:11 AM >> To: Peterson, Jon; 'dispatch@ietf.org' >> Subject: RE: [dispatch] New Proposal for Telephone-Related Queries >>=20 >> I think this is an interesting activity and would not want to derail it, >> but let me play devil's advocate for a moment... >>=20 >> - if we were just starting out, as opposed to having lots of (at least >> internal and some external) deployments, I would be more optimistic >> - although I know that the proposal responds to many concerns that have >> been raised with enum, I personally don't see the protocol issues or eve= n >> the semantics of the of what the protocol can address as ever having bee= n >> the major thing that has held enum back from full potential. It's always >> been lack of consensus on administrative arrangements driven by business >> and -dare I say- political concerns. >>=20 >> Good luck! >>=20 >> Penn Pfautz >> AT&T Access Management >> +1-732-420-4962 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Peterson, Jon >> Sent: Monday, March 05, 2012 5:05 PM >> To: 'dispatch@ietf.org' >> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries >>=20 >>=20 >> Oops, sorry, my mailer did not like the URL I submitted. The correct URL >> for the draft is: >>=20 >> https://datatracker.ietf.org/doc/draft-peterson-terq/ >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >> Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time >> To: dispatch@ietf.org >> Subject: [dispatch] New Proposal for Telephone-Related Queries >>=20 >>=20 >> I have a proposal to bounce off the group. Basically, this is a >> re-examination of some of the problems we've previously considered in th= e >> telephony-specific cluster of work surrounding ENUM, DRINKS and >> SPEERMINT. Through discussions in the past couple years, it's become >> clear that we would need to significantly extend ENUM to get it to handl= e >> all of the sorts of sources, subjects, and attributes that people want t= o >> factor into queries about telephone number routing and administration. >> Most of these discussions have gotten wrapped around the axle on >> questions of the underlying syntax and semantics of the DNS, which were = a >> good match for the original vision of a public, user-driven ENUM, but >> don't seem to be such a good match for the uses people actually want to >> make of these protocols, in federated, service-provider-driven >> environments like those envisioned in SPEERMINT and provisioned in >> DRINKS. While the discussion may have died down a bit, the requirements >> that motivated th >> e discussion definitely aren't going away. >>=20 >> Rather than continue to debate the applicability of the DNS and the >> probity of various extensions to it, we might make more progress if we >> work towards agreement on the semantics of queries for telephone-related >> data independently of any underlying protocols. In other words, focus on >> what kinds of questions about telephone numbers we want to be able to >> ask, and what kinds of information needs to go into the answers, and >> incorporate all this into an abstract data model. So for example, we kno= w >> that we want to be able to express the source of a request in a query. >> What do we mean by source? I can think of a bunch of different kinds of >> source: the logical originator of the query (the administrative entity >> asking), the logical identity of any intermediary or aggregator >> forwarding the query, or even the point at the network from which the >> call originates (the originating trunk group, SBC or what have you). All >> three of those concepts of source seem important when it comes to answe >> ring questions about telephone numbers, so a data model would treat >> those as separate elements which can vary independently - then we can >> then try to figure out what's mandatory or optional, etc. We follow this >> same method for all the elements of queries and responses. Figure out >> what the attributes are of telephone numbers that we care about, sort >> them into buckets of routing data and administrative data, and so on. >>=20 >> Once we have an agreement on the data model, then people can map the >> model to whatever underlying protocol they'd like - or just build it int= o >> a web API, or what have you. Those proposals could advance as separate >> documents. Having that flexibility would make it a lot easier to figure >> out what we really want the questions and answers to be, rather than >> thinking about what they realistically can be within the constraints of >> some existing underlying protocol. >>=20 >> That's the idea. I'm not going to present a proposed charter for work or >> anything like that in Paris, but I am interested in hearing if people >> think this is a promising approach, and if so, perhaps we'd put a charte= r >> on the agenda for Vancouver. I have however submitted a -00 draft for >> this time which gives a high-level proposal for a data model and at leas= t >> enumerates what some of the elements might be that would be populated in >> queries and responses. This is a pretty broad sketch, but it should >> convey the basic idea. You can check it out here: >> https://exchcas.va.neustar.com/owa/thoughts about the direction or the >> specifics of the data model are welcome. Thanks! >>=20 >> Jon Peterson >> NeuStar, Inc. >> _______________________________________________ >> 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 >=20 From richard@shockey.us Wed Mar 14 13:20:13 2012 Return-Path: <richard@shockey.us> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5354E21F8767 for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 13:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.814 X-Spam-Level: X-Spam-Status: No, score=-99.814 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajixWtbzpbl8 for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 13:20:12 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id C66A421F8740 for <dispatch@ietf.org>; Wed, 14 Mar 2012 13:20:11 -0700 (PDT) Received: (qmail 16707 invoked by uid 0); 14 Mar 2012 20:20:11 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy8.bluehost.com with SMTP; 14 Mar 2012 20:20:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=qhNDD80eVjJR+VGxuPMU1zA9oVLlTl3K8zW8Mq8Jx04=; b=CIHq1YiKK5pPKj2Ky7+IbgUl9UwlcdXzWaZp2Z5M4lGZPK3/JJeyJNCyatxTRs6POAIS2f8drsxh7onCwvWrUZr9w2wZRbWv5ScyoxiihLkqtKxlxSSnGuDq79SarBwr; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from <richard@shockey.us>) id 1S7ug5-0006nS-Du; Wed, 14 Mar 2012 14:20:09 -0600 From: "Richard Shockey" <richard@shockey.us> To: <dispatch@ietf.org> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> In-Reply-To: <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> Date: Wed, 14 Mar 2012 16:20:08 -0400 Message-ID: <016d01cd021f$db9c55b0$92d50110$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0CGjPkVxXBAUxmQ12nFbG5YpLCgwAAqeqQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 20:20:13 -0000 "Challenges" is a understatement. We had a clear path to extend 6116 to "other data types" aka E2MD in private instantiations among others but, for reasons I still do not clearly understand, that was blocked by you and others. I completely concur with Daryl here. That said its certainly worth taking a fresh look at things in light of recent regulatory moves in North America toward the End of POTS. There has to be a solution to Number Translations in converged networks. If I had a clean sheet of paper today ..sure JSON over SHTTP. Solves lots of problems with Security ,AA and determinate response. A hierarchical structure may not be completely necessary in core carrier SIP/IMS networks. The problems you cite were with e164.arpa, however other uses have performed very well in the field. Including the Federal Communications Commission I-TRS system run by you know who. IMHO this is still NOT helpful to the discussion. http://www.ietf.org/internet-drafts/draft-iab-dns-applications-04.txt -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, March 14, 2012 3:40 PM To: Daryl Malas Cc: dispatch@ietf.org Subject: Re: [dispatch] New Proposal for Telephone-Related Queries Obviously yes, I don't mean to suggest that any existing protocol is off the table as a potential underlying binding for TeRQ, but the whole point of approaching this from the semantics rather than the transport or encoding is to defer those latter questions so we can focus on what we want queries and responses to say. I think the analysis you recommend of how existing protocols could map to TeRQ would be part of the bindings development process - this is situation where we will want to let a thousand flowers bloom, and I'm sure there will be existing proposals that would be good bindings for TeRQ. However, let's not sweep the obvious under the rug - we wouldn't be having this TeRQ discussion at all if we had a clear path to extend the ENUM and DNS standards to handle the semantics that the use cases seem to require. That doesn't mean that a DNS binding is off the table, just that it would seem to face challenges. Jon Peterson NeuStar, Inc. On Mar 14, 2012, at 10:16 AM, Daryl Malas wrote: > I think we should be careful in being presumptuous of what we will do or > the effects we will impose on any protocol at this point. > > As part of this proposal, I think we should do some basic analysis of the > suite of protocols (and extensions) existing today related to this. We > may or may not find that some could be used or further extended. > > Of course, I'm open to creating a new mechanism as a result of this work, > if necessary. > > --Daryl > > On 3/13/12 2:54 PM, "Peterson, Jon" <jon.peterson@neustar.biz> wrote: > >> >> Hi Penn, >> >> Glad to hear this is of interest, at least. Certainly agreed that there >> is ENUM deployment out there - in fact, my own company does a bit of it. >> When protocols become successful and see deployment, people do start >> using them in unexpected ways which sometimes require significant >> modifications, and eventually you can reach a tipping point where it >> makes sense to reconsider the fundamentals. I think we've reached that >> point with ENUM, where we have seen proposals to extend ENUM (and the >> DNS) that warrant taking a step back and exploring whether or not we can >> get a better overall framework in place - at least a framework in which >> we can standardize features that have been proposed for ENUM but which >> fall outside the ways we can responsibly extend the DNS. >> >> Also agreed, by the by, that administrative and political factors have >> held ENUM back from being all that it can be. You'll note that the TeRQ >> proposal does not prescribe any administrative framework like e164.arpa - >> it's really just a query/response protocol. The irony of e164.arpa is >> that it applied well to the original, public vision of ENUM, but has >> sometimes ended up hampering attempts to get the carrier-driven, more >> infrastructural deployments off the ground. >> >> No one is expecting that the TeRQ proposal will snuff out ENUM deployment >> overnight. I'm sure ENUM will continue to serve a segment of the market >> for the foreseeable future. But ENUM was standardized twelve years ago >> now - a pretty good life cycle for any protocol. All I'm really proposing >> is that we see how much we could gain from starting on a different >> foundation. If we end up with something better, it will eventually phase >> into the market and get traction. All a standards activity can do is >> create that opportunity. >> >> Jon Peterson >> NeuStar, Inc. >> ________________________________________ >> From: PFAUTZ, PENN L [pp3129@att.com] >> Sent: Tuesday, March 13, 2012 8:11 AM >> To: Peterson, Jon; 'dispatch@ietf.org' >> Subject: RE: [dispatch] New Proposal for Telephone-Related Queries >> >> I think this is an interesting activity and would not want to derail it, >> but let me play devil's advocate for a moment... >> >> - if we were just starting out, as opposed to having lots of (at least >> internal and some external) deployments, I would be more optimistic >> - although I know that the proposal responds to many concerns that have >> been raised with enum, I personally don't see the protocol issues or even >> the semantics of the of what the protocol can address as ever having been >> the major thing that has held enum back from full potential. It's always >> been lack of consensus on administrative arrangements driven by business >> and -dare I say- political concerns. >> >> Good luck! >> >> Penn Pfautz >> AT&T Access Management >> +1-732-420-4962 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Peterson, Jon >> Sent: Monday, March 05, 2012 5:05 PM >> To: 'dispatch@ietf.org' >> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries >> >> >> Oops, sorry, my mailer did not like the URL I submitted. The correct URL >> for the draft is: >> >> https://datatracker.ietf.org/doc/draft-peterson-terq/ >> >> Jon Peterson >> Neustar, Inc. >> >> >> >> -----Original Message----- >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >> Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time >> To: dispatch@ietf.org >> Subject: [dispatch] New Proposal for Telephone-Related Queries >> >> >> I have a proposal to bounce off the group. Basically, this is a >> re-examination of some of the problems we've previously considered in the >> telephony-specific cluster of work surrounding ENUM, DRINKS and >> SPEERMINT. Through discussions in the past couple years, it's become >> clear that we would need to significantly extend ENUM to get it to handle >> all of the sorts of sources, subjects, and attributes that people want to >> factor into queries about telephone number routing and administration. >> Most of these discussions have gotten wrapped around the axle on >> questions of the underlying syntax and semantics of the DNS, which were a >> good match for the original vision of a public, user-driven ENUM, but >> don't seem to be such a good match for the uses people actually want to >> make of these protocols, in federated, service-provider-driven >> environments like those envisioned in SPEERMINT and provisioned in >> DRINKS. While the discussion may have died down a bit, the requirements >> that motivated th >> e discussion definitely aren't going away. >> >> Rather than continue to debate the applicability of the DNS and the >> probity of various extensions to it, we might make more progress if we >> work towards agreement on the semantics of queries for telephone-related >> data independently of any underlying protocols. In other words, focus on >> what kinds of questions about telephone numbers we want to be able to >> ask, and what kinds of information needs to go into the answers, and >> incorporate all this into an abstract data model. So for example, we know >> that we want to be able to express the source of a request in a query. >> What do we mean by source? I can think of a bunch of different kinds of >> source: the logical originator of the query (the administrative entity >> asking), the logical identity of any intermediary or aggregator >> forwarding the query, or even the point at the network from which the >> call originates (the originating trunk group, SBC or what have you). All >> three of those concepts of source seem important when it comes to answe >> ring questions about telephone numbers, so a data model would treat >> those as separate elements which can vary independently - then we can >> then try to figure out what's mandatory or optional, etc. We follow this >> same method for all the elements of queries and responses. Figure out >> what the attributes are of telephone numbers that we care about, sort >> them into buckets of routing data and administrative data, and so on. >> >> Once we have an agreement on the data model, then people can map the >> model to whatever underlying protocol they'd like - or just build it into >> a web API, or what have you. Those proposals could advance as separate >> documents. Having that flexibility would make it a lot easier to figure >> out what we really want the questions and answers to be, rather than >> thinking about what they realistically can be within the constraints of >> some existing underlying protocol. >> >> That's the idea. I'm not going to present a proposed charter for work or >> anything like that in Paris, but I am interested in hearing if people >> think this is a promising approach, and if so, perhaps we'd put a charter >> on the agenda for Vancouver. I have however submitted a -00 draft for >> this time which gives a high-level proposal for a data model and at least >> enumerates what some of the elements might be that would be populated in >> queries and responses. This is a pretty broad sketch, but it should >> convey the basic idea. You can check it out here: >> https://exchcas.va.neustar.com/owa/thoughts about the direction or the >> specifics of the data model are welcome. Thanks! >> >> Jon Peterson >> NeuStar, Inc. >> _______________________________________________ >> 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 lconroy@insensate.co.uk Wed Mar 14 15:08:27 2012 Return-Path: <lconroy@insensate.co.uk> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B1D21F8864 for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 15:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sOxEGkh7GhG for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 15:08:26 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 1250921F8862 for <dispatch@ietf.org>; Wed, 14 Mar 2012 15:08:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 207205EBF14 for <dispatch@ietf.org>; Wed, 14 Mar 2012 22:08:24 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc3qxOReeHHo for <dispatch@ietf.org>; Wed, 14 Mar 2012 22:08:21 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 0A6895EBF04 for <dispatch@ietf.org>; Wed, 14 Mar 2012 22:08:21 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Lawrence Conroy <lconroy@insensate.co.uk> In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A096D@DC-US1MBEX4.global.avaya.com> Date: Wed, 14 Mar 2012 22:08:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3D742578-3B8B-4DF7-A32B-6ADD8EF86805@insensate.co.uk> References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> <3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com>, <03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> <CD5674C3CD99574EBA7432465FC13C1B22726A0958@DC-US1MBEX4.global.avaya.com>, <051901cd015d$fa776f50$ef664df0$@packetizer.com> <CD5674C3CD99574EBA7432465FC13C1B22726A096D@DC-US1MBEX4.global.avaya.com> To: DISPATCH list <dispatch@ietf.org> X-Mailer: Apple Mail (2.1084) Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 22:08:27 -0000 Hi Dale, Paul, folks, So Dale, what you're telling me is that these features are related to = the SDP m=3D line, and those sub-fields are related to the transport, as = well as the end device processing? I had always interpreted the sip.data type as meaning (in practice) that = intermediaries (e.g.,B2BUAs) might be able to interpret (or even = transcode) audio, video, or application type streams, but they shouldn't = mess with data (not even lossy compression). I have no idea whether it = is used out there IRL, but there's a way of handling it if it hits your = (middle)box. Re. the wonderfully wooly term "immersive" -- how does that help, and = who does it help; what happens if it hits an intermediary box? Agreed that fax is a nice hint for intermediaries (or multiple end = devices registered for a SIP identity). When capabilities were first = being developed, I had hoped that they would be more structured AND = wider than they ended up, BUT ... I can't see how this term helps, or could even discriminate between end = devices. Please, can anyone convince me that this is a technical feature and not = just the coke-laden ravings of a carrier marketeer? [No Paul, I don't mean you, but from your comments I wonder if that may = be "the customer" :] all the best from a bemused Lawrence On 14 Mar 2012, at 19:11, Worley, Dale R (Dale) wrote: >> From: Paul E. Jones [paulej@packetizer.com] >>=20 >> Our expectation was that a user, and more likely a system = administrator, >> will "declare" that a device is "immersive" or not. That becomes >> subjective, perhaps, but that is what the user preferred. >=20 > Who is "the user" who preferred this? >=20 >> I understand that video is a "thing" you can point your finger at and >> identify, whereas immersive is not. However, what is "mobile"? What = is >> "data"? I'd argue that "data" is equally as vague. Still, it is a = property >> one can define and use. >=20 > Well, if "data" is vague, that means you can't actually define it, and > if you can't define it, you can't effectively use it. >=20 > But in reality, the IANA registry defines "sip.data" as "This feature > tag indicates that the device supports data as a streaming media > type." and refers to RFC 3840. RFC 3840 says the same, and refers to > RFC 2327: "The audio, video, application, data, and control feature > tags in the SIP tree (each of which indicate a media type, as defined > in RFC 2327) are different. They do not indicate top level MIME types > which can be received in SIP requests. Rather, they indicate media > types that can be used in media streams, and as a result, match up > with the types defined in RFC 2327." Looking at RFC 2327 gives: >=20 > m=3D<media> <port> <transport> <fmt list> > [...] > o The first sub-field is the media type. Currently defined media = are > "audio", "video", "application", "data" and "control", though this > list may be extended as new communication modalities emerge (e.g., > telepresense). The difference between "application" and "data" is > that the former is a media flow such as whiteboard information, = and > the latter is bulk-data transfer such as multicasting of program > executables which will not typically be displayed to the user. > "control" is used to specify an additional conference control > channel for the session. >=20 > RFC 4566 updates RFC 2327 with: >=20 > Note: The media types "control" and "data" were listed as valid in > the previous version of this specification [6]; however, their > semantics were never fully specified and they are not widely used. > These media types have been removed in this specification, although > they still remain valid media type capabilities for a SIP user agent > as defined in RFC 3840 [24]. If these media types are considered > useful in the future, a Standards Track RFC MUST be produced to > document their use. Until that is done, applications SHOULD NOT use > these types and SHOULD NOT declare support for them in SIP > capabilities declarations (even though they exist in the registry > created by RFC 3840). >=20 > So the "sip.data" tag means that the UA supports "m=3Ddata ..." in = SDP, > which will be used to carry bulk-data transfer such as multicasting of > program executables which will not typically be displayed to the user, > and it is obsolete and should not be used. >=20 > The IANA registry defines "sip.mobility" as "The sip.mobility feature > tag indicates whether the device is fixed (meaning that it is > associated with a fixed point of contact with the network), or mobile > (meaning that it is not associated with a fixed point of > contact). Note that cordless phones are fixed, not mobile, based on > this definition." >=20 >> Interoperability is in terms of =93do you support this capability=94? >> The answer is either yes or no. The declaration that a device is >> immersive might be subjective, but the use is not. >=20 > Certainly "what would happen" is well-defined in a technical sense. > But the question is whether a caller would *wish* to invoke this > functionality. >=20 > In order for this to be a matter of interoperability, there would need > to be circumstances where a caller in one organization would want to > contact a callee *with whom he had no previous arrangements* and > desire the contact only be via an "immersive" UA (or only via a > non-"immersive" UA). For this to be sensible, "immersive" has to have > some sort of global meaning. If "immersive" is *freely* assigned by > each user (or organizational system administrator), it has no global > meaning, and there is no reason a caller would use it in > caller-preferences generally, since he has no idea what its > consequences would be at the callee's system. >=20 > So if we want to *standardize* an immersive indicator, we need to (1) > fix a (perhaps somewhat elastic) criterion for what constitutes > "immersive", and (2) have a belief that callers might wish to > distinguish between immersive and non-immersive UAs when calling > destinations about which they have no information other than the RFC. >=20 > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jon.peterson@neustar.biz Wed Mar 14 15:40:31 2012 Return-Path: <jon.peterson@neustar.biz> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72AC211E8075 for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 15:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.285 X-Spam-Level: X-Spam-Status: No, score=-106.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN5x7ZziBY5Z for <dispatch@ietfa.amsl.com>; Wed, 14 Mar 2012 15:40:30 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id BDFF321F867F for <dispatch@ietf.org>; Wed, 14 Mar 2012 15:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1331764861; x=1647119721; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=dWFEC1ifs6DEvlPfrxAwf ewt61lpURSmwK+W1oDiVXE=; b=im3+Aal/md0q+NXjmjyuUAMvNC6Ls9ax5Mc5i FZ3i90z86jkCnUnsgjUI+qXpfZwgjmKryCuzkzPDmWEkbcAmA== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.5632543; Wed, 14 Mar 2012 18:40:59 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 14 Mar 2012 18:40:24 -0400 From: "Peterson, Jon" <jon.peterson@neustar.biz> To: Richard Shockey <richard@shockey.us> Date: Wed, 14 Mar 2012 18:40:18 -0400 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: Ac0CM3GqY7KsKxqTTTKNKBSL+lNY0A== Message-ID: <076EA5CD-1DA8-4238-B53E-7764EC44B37E@neustar.biz> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> <016d01cd021f$db9c55b0$92d50110$@us> In-Reply-To: <016d01cd021f$db9c55b0$92d50110$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: jIPvhFPLPv7305VWl6VUfg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Mar 2012 22:40:31 -0000 I know that the criticisms of E2MD will remain a sore point, but the idea h= ere is to set those issues aside and focus on the data model in a protocol-= neutral venue. In order to get at the converged network solution for after = the end of POTS (aPOTScalypse now?), we need to consider requirements beyon= d the handful of things we debated in E2MD, anyway: the technical and opera= tional issues that have faced ENUM deployments, the questions surrounding s= ession establishment data in DRINKS, even the requirements of web-based ser= vices like those now considered in RTCWeb should be in play.=20 If there is, for example, a use case where we want to resolve things other = than telephone numbers (like SPIDs for LRF, say), then that might call for = a slightly different applicability than ENUM (which is really about the res= olution of telephone numbers). If the use cases really do support disentang= ling the original source of a query from a query intermediary, and distingu= ishing both of those from the "route source," that will require significant= syntactic complexity in query. If we do want to be able to communicate in = responses which authority provisioned the records, that too takes us into p= retty uncharted territory.=20 I wouldn't say it would be impossible to do these sorts of things with the = DNS as an underlying transport - it would require some work in other areas = of the IETF, I suspect, but it's not impossible - however, by the time we d= id, I'm not sure we'd be calling the end result "ENUM" anymore. What I don'= t want is to start off by limiting the semantics of queries and responses t= o meet the constraints of a particular potential transport. Jon Peterson NeuStar, Inc. On Mar 14, 2012, at 1:20 PM, Richard Shockey wrote: > "Challenges" is a understatement. We had a clear path to extend 6116 to > "other data types" aka E2MD in private instantiations among others but, f= or > reasons I still do not clearly understand, that was blocked by you and > others. >=20 > I completely concur with Daryl here. That said its certainly worth taking= a > fresh look at things in light of recent regulatory moves in North America > toward the End of POTS. There has to be a solution to Number Translations= in > converged networks. >=20 > If I had a clean sheet of paper today ..sure JSON over SHTTP. Solves lots= of > problems with Security ,AA and determinate response. A hierarchical > structure may not be completely necessary in core carrier SIP/IMS network= s. >=20 > The problems you cite were with e164.arpa, however other uses have perfor= med > very well in the field. Including the Federal Communications Commission > I-TRS system run by you know who. >=20 > IMHO this is still NOT helpful to the discussion. >=20 > http://www.ietf.org/internet-drafts/draft-iab-dns-applications-04.txt >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf > Of Peterson, Jon > Sent: Wednesday, March 14, 2012 3:40 PM > To: Daryl Malas > Cc: dispatch@ietf.org > Subject: Re: [dispatch] New Proposal for Telephone-Related Queries >=20 >=20 > Obviously yes, I don't mean to suggest that any existing protocol is off = the > table as a potential underlying binding for TeRQ, but the whole point of > approaching this from the semantics rather than the transport or encoding= is > to defer those latter questions so we can focus on what we want queries a= nd > responses to say. I think the analysis you recommend of how existing > protocols could map to TeRQ would be part of the bindings development > process - this is situation where we will want to let a thousand flowers > bloom, and I'm sure there will be existing proposals that would be good > bindings for TeRQ. >=20 > However, let's not sweep the obvious under the rug - we wouldn't be havin= g > this TeRQ discussion at all if we had a clear path to extend the ENUM and > DNS standards to handle the semantics that the use cases seem to require. > That doesn't mean that a DNS binding is off the table, just that it would > seem to face challenges. >=20 > Jon Peterson > NeuStar, Inc. >=20 > On Mar 14, 2012, at 10:16 AM, Daryl Malas wrote: >=20 >> I think we should be careful in being presumptuous of what we will do or >> the effects we will impose on any protocol at this point. >>=20 >> As part of this proposal, I think we should do some basic analysis of th= e >> suite of protocols (and extensions) existing today related to this. We >> may or may not find that some could be used or further extended. >>=20 >> Of course, I'm open to creating a new mechanism as a result of this work= , >> if necessary. >>=20 >> --Daryl >>=20 >> On 3/13/12 2:54 PM, "Peterson, Jon" <jon.peterson@neustar.biz> wrote: >>=20 >>>=20 >>> Hi Penn, >>>=20 >>> Glad to hear this is of interest, at least. Certainly agreed that there >>> is ENUM deployment out there - in fact, my own company does a bit of it= . >>> When protocols become successful and see deployment, people do start >>> using them in unexpected ways which sometimes require significant >>> modifications, and eventually you can reach a tipping point where it >>> makes sense to reconsider the fundamentals. I think we've reached that >>> point with ENUM, where we have seen proposals to extend ENUM (and the >>> DNS) that warrant taking a step back and exploring whether or not we ca= n >>> get a better overall framework in place - at least a framework in which >>> we can standardize features that have been proposed for ENUM but which >>> fall outside the ways we can responsibly extend the DNS. >>>=20 >>> Also agreed, by the by, that administrative and political factors have >>> held ENUM back from being all that it can be. You'll note that the TeRQ >>> proposal does not prescribe any administrative framework like e164.arpa= - >>> it's really just a query/response protocol. The irony of e164.arpa is >>> that it applied well to the original, public vision of ENUM, but has >>> sometimes ended up hampering attempts to get the carrier-driven, more >>> infrastructural deployments off the ground. >>>=20 >>> No one is expecting that the TeRQ proposal will snuff out ENUM deployme= nt >>> overnight. I'm sure ENUM will continue to serve a segment of the market >>> for the foreseeable future. But ENUM was standardized twelve years ago >>> now - a pretty good life cycle for any protocol. All I'm really proposi= ng >>> is that we see how much we could gain from starting on a different >>> foundation. If we end up with something better, it will eventually phas= e >>> into the market and get traction. All a standards activity can do is >>> create that opportunity. >>>=20 >>> Jon Peterson >>> NeuStar, Inc. >>> ________________________________________ >>> From: PFAUTZ, PENN L [pp3129@att.com] >>> Sent: Tuesday, March 13, 2012 8:11 AM >>> To: Peterson, Jon; 'dispatch@ietf.org' >>> Subject: RE: [dispatch] New Proposal for Telephone-Related Queries >>>=20 >>> I think this is an interesting activity and would not want to derail it= , >>> but let me play devil's advocate for a moment... >>>=20 >>> - if we were just starting out, as opposed to having lots of (at least >>> internal and some external) deployments, I would be more optimistic >>> - although I know that the proposal responds to many concerns that have >>> been raised with enum, I personally don't see the protocol issues or ev= en >>> the semantics of the of what the protocol can address as ever having be= en >>> the major thing that has held enum back from full potential. It's alway= s >>> been lack of consensus on administrative arrangements driven by busines= s >>> and -dare I say- political concerns. >>>=20 >>> Good luck! >>>=20 >>> Penn Pfautz >>> AT&T Access Management >>> +1-732-420-4962 >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Peterson, Jon >>> Sent: Monday, March 05, 2012 5:05 PM >>> To: 'dispatch@ietf.org' >>> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries >>>=20 >>>=20 >>> Oops, sorry, my mailer did not like the URL I submitted. The correct UR= L >>> for the draft is: >>>=20 >>> https://datatracker.ietf.org/doc/draft-peterson-terq/ >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>> Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time >>> To: dispatch@ietf.org >>> Subject: [dispatch] New Proposal for Telephone-Related Queries >>>=20 >>>=20 >>> I have a proposal to bounce off the group. Basically, this is a >>> re-examination of some of the problems we've previously considered in t= he >>> telephony-specific cluster of work surrounding ENUM, DRINKS and >>> SPEERMINT. Through discussions in the past couple years, it's become >>> clear that we would need to significantly extend ENUM to get it to hand= le >>> all of the sorts of sources, subjects, and attributes that people want = to >>> factor into queries about telephone number routing and administration. >>> Most of these discussions have gotten wrapped around the axle on >>> questions of the underlying syntax and semantics of the DNS, which were= a >>> good match for the original vision of a public, user-driven ENUM, but >>> don't seem to be such a good match for the uses people actually want to >>> make of these protocols, in federated, service-provider-driven >>> environments like those envisioned in SPEERMINT and provisioned in >>> DRINKS. While the discussion may have died down a bit, the requirements >>> that motivated th >>> e discussion definitely aren't going away. >>>=20 >>> Rather than continue to debate the applicability of the DNS and the >>> probity of various extensions to it, we might make more progress if we >>> work towards agreement on the semantics of queries for telephone-relate= d >>> data independently of any underlying protocols. In other words, focus o= n >>> what kinds of questions about telephone numbers we want to be able to >>> ask, and what kinds of information needs to go into the answers, and >>> incorporate all this into an abstract data model. So for example, we kn= ow >>> that we want to be able to express the source of a request in a query. >>> What do we mean by source? I can think of a bunch of different kinds of >>> source: the logical originator of the query (the administrative entity >>> asking), the logical identity of any intermediary or aggregator >>> forwarding the query, or even the point at the network from which the >>> call originates (the originating trunk group, SBC or what have you). Al= l >>> three of those concepts of source seem important when it comes to answe >>> ring questions about telephone numbers, so a data model would treat >>> those as separate elements which can vary independently - then we can >>> then try to figure out what's mandatory or optional, etc. We follow thi= s >>> same method for all the elements of queries and responses. Figure out >>> what the attributes are of telephone numbers that we care about, sort >>> them into buckets of routing data and administrative data, and so on. >>>=20 >>> Once we have an agreement on the data model, then people can map the >>> model to whatever underlying protocol they'd like - or just build it in= to >>> a web API, or what have you. Those proposals could advance as separate >>> documents. Having that flexibility would make it a lot easier to figure >>> out what we really want the questions and answers to be, rather than >>> thinking about what they realistically can be within the constraints of >>> some existing underlying protocol. >>>=20 >>> That's the idea. I'm not going to present a proposed charter for work o= r >>> anything like that in Paris, but I am interested in hearing if people >>> think this is a promising approach, and if so, perhaps we'd put a chart= er >>> on the agenda for Vancouver. I have however submitted a -00 draft for >>> this time which gives a high-level proposal for a data model and at lea= st >>> enumerates what some of the elements might be that would be populated i= n >>> queries and responses. This is a pretty broad sketch, but it should >>> convey the basic idea. You can check it out here: >>> https://exchcas.va.neustar.com/owa/thoughts about the direction or the >>> specifics of the data model are welcome. Thanks! >>>=20 >>> Jon Peterson >>> NeuStar, Inc. >>> _______________________________________________ >>> 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 >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From D.Malas@cablelabs.com Thu Mar 15 10:15:37 2012 Return-Path: <D.Malas@cablelabs.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8F321F87D1 for <dispatch@ietfa.amsl.com>; Thu, 15 Mar 2012 10:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.338 X-Spam-Level: X-Spam-Status: No, score=-100.338 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoWDnxLL7fEA for <dispatch@ietfa.amsl.com>; Thu, 15 Mar 2012 10:15:35 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7ED21F878A for <dispatch@ietf.org>; Thu, 15 Mar 2012 10:15:35 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2FHFU7K017781; Thu, 15 Mar 2012 11:15:30 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 15 Mar 2012 11:15:30 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 15 Mar 2012 11:15:30 -0600 From: Daryl Malas <D.Malas@cablelabs.com> To: "Peterson, Jon" <jon.peterson@neustar.biz> Date: Thu, 15 Mar 2012 11:15:31 -0600 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: Ac0Czziobtb49X7vQnC2GhfMs2ai2A== Message-ID: <CB877FB5.CB70%d.malas@cablelabs.com> In-Reply-To: <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 15 Mar 2012 17:15:37 -0000 I think we are in agreement. Thanks -- Daryl On 3/14/12 1:39 PM, "Peterson, Jon" <jon.peterson@neustar.biz> wrote: > >Obviously yes, I don't mean to suggest that any existing protocol is off >the table as a potential underlying binding for TeRQ, but the whole point >of approaching this from the semantics rather than the transport or >encoding is to defer those latter questions so we can focus on what we >want queries and responses to say. I think the analysis you recommend of >how existing protocols could map to TeRQ would be part of the bindings >development process - this is situation where we will want to let a >thousand flowers bloom, and I'm sure there will be existing proposals >that would be good bindings for TeRQ. > >However, let's not sweep the obvious under the rug - we wouldn't be >having this TeRQ discussion at all if we had a clear path to extend the >ENUM and DNS standards to handle the semantics that the use cases seem to >require. That doesn't mean that a DNS binding is off the table, just that >it would seem to face challenges. > >Jon Peterson >NeuStar, Inc. > >On Mar 14, 2012, at 10:16 AM, Daryl Malas wrote: > >> I think we should be careful in being presumptuous of what we will do or >> the effects we will impose on any protocol at this point. >>=20 >> As part of this proposal, I think we should do some basic analysis of >>the >> suite of protocols (and extensions) existing today related to this. We >> may or may not find that some could be used or further extended. >>=20 >> Of course, I'm open to creating a new mechanism as a result of this >>work, >> if necessary. >>=20 >> --Daryl >>=20 >> On 3/13/12 2:54 PM, "Peterson, Jon" <jon.peterson@neustar.biz> wrote: >>=20 >>>=20 >>> Hi Penn, >>>=20 >>> Glad to hear this is of interest, at least. Certainly agreed that there >>> is ENUM deployment out there - in fact, my own company does a bit of >>>it. >>> When protocols become successful and see deployment, people do start >>> using them in unexpected ways which sometimes require significant >>> modifications, and eventually you can reach a tipping point where it >>> makes sense to reconsider the fundamentals. I think we've reached that >>> point with ENUM, where we have seen proposals to extend ENUM (and the >>> DNS) that warrant taking a step back and exploring whether or not we >>>can >>> get a better overall framework in place - at least a framework in which >>> we can standardize features that have been proposed for ENUM but which >>> fall outside the ways we can responsibly extend the DNS. >>>=20 >>> Also agreed, by the by, that administrative and political factors have >>> held ENUM back from being all that it can be. You'll note that the TeRQ >>> proposal does not prescribe any administrative framework like >>>e164.arpa - >>> it's really just a query/response protocol. The irony of e164.arpa is >>> that it applied well to the original, public vision of ENUM, but has >>> sometimes ended up hampering attempts to get the carrier-driven, more >>> infrastructural deployments off the ground. >>>=20 >>> No one is expecting that the TeRQ proposal will snuff out ENUM >>>deployment >>> overnight. I'm sure ENUM will continue to serve a segment of the market >>> for the foreseeable future. But ENUM was standardized twelve years ago >>> now - a pretty good life cycle for any protocol. All I'm really >>>proposing >>> is that we see how much we could gain from starting on a different >>> foundation. If we end up with something better, it will eventually >>>phase >>> into the market and get traction. All a standards activity can do is >>> create that opportunity. >>>=20 >>> Jon Peterson >>> NeuStar, Inc. >>> ________________________________________ >>> From: PFAUTZ, PENN L [pp3129@att.com] >>> Sent: Tuesday, March 13, 2012 8:11 AM >>> To: Peterson, Jon; 'dispatch@ietf.org' >>> Subject: RE: [dispatch] New Proposal for Telephone-Related Queries >>>=20 >>> I think this is an interesting activity and would not want to derail >>>it, >>> but let me play devil's advocate for a moment... >>>=20 >>> - if we were just starting out, as opposed to having lots of (at least >>> internal and some external) deployments, I would be more optimistic >>> - although I know that the proposal responds to many concerns that have >>> been raised with enum, I personally don't see the protocol issues or >>>even >>> the semantics of the of what the protocol can address as ever having >>>been >>> the major thing that has held enum back from full potential. It's >>>always >>> been lack of consensus on administrative arrangements driven by >>>business >>> and -dare I say- political concerns. >>>=20 >>> Good luck! >>>=20 >>> Penn Pfautz >>> AT&T Access Management >>> +1-732-420-4962 >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Peterson, Jon >>> Sent: Monday, March 05, 2012 5:05 PM >>> To: 'dispatch@ietf.org' >>> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries >>>=20 >>>=20 >>> Oops, sorry, my mailer did not like the URL I submitted. The correct >>>URL >>> for the draft is: >>>=20 >>> https://datatracker.ietf.org/doc/draft-peterson-terq/ >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>> Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time >>> To: dispatch@ietf.org >>> Subject: [dispatch] New Proposal for Telephone-Related Queries >>>=20 >>>=20 >>> I have a proposal to bounce off the group. Basically, this is a >>> re-examination of some of the problems we've previously considered in >>>the >>> telephony-specific cluster of work surrounding ENUM, DRINKS and >>> SPEERMINT. Through discussions in the past couple years, it's become >>> clear that we would need to significantly extend ENUM to get it to >>>handle >>> all of the sorts of sources, subjects, and attributes that people want >>>to >>> factor into queries about telephone number routing and administration. >>> Most of these discussions have gotten wrapped around the axle on >>> questions of the underlying syntax and semantics of the DNS, which >>>were a >>> good match for the original vision of a public, user-driven ENUM, but >>> don't seem to be such a good match for the uses people actually want to >>> make of these protocols, in federated, service-provider-driven >>> environments like those envisioned in SPEERMINT and provisioned in >>> DRINKS. While the discussion may have died down a bit, the requirements >>> that motivated th >>> e discussion definitely aren't going away. >>>=20 >>> Rather than continue to debate the applicability of the DNS and the >>> probity of various extensions to it, we might make more progress if we >>> work towards agreement on the semantics of queries for >>>telephone-related >>> data independently of any underlying protocols. In other words, focus >>>on >>> what kinds of questions about telephone numbers we want to be able to >>> ask, and what kinds of information needs to go into the answers, and >>> incorporate all this into an abstract data model. So for example, we >>>know >>> that we want to be able to express the source of a request in a query. >>> What do we mean by source? I can think of a bunch of different kinds of >>> source: the logical originator of the query (the administrative entity >>> asking), the logical identity of any intermediary or aggregator >>> forwarding the query, or even the point at the network from which the >>> call originates (the originating trunk group, SBC or what have you). >>>All >>> three of those concepts of source seem important when it comes to answe >>> ring questions about telephone numbers, so a data model would treat >>> those as separate elements which can vary independently - then we can >>> then try to figure out what's mandatory or optional, etc. We follow >>>this >>> same method for all the elements of queries and responses. Figure out >>> what the attributes are of telephone numbers that we care about, sort >>> them into buckets of routing data and administrative data, and so on. >>>=20 >>> Once we have an agreement on the data model, then people can map the >>> model to whatever underlying protocol they'd like - or just build it >>>into >>> a web API, or what have you. Those proposals could advance as separate >>> documents. Having that flexibility would make it a lot easier to figure >>> out what we really want the questions and answers to be, rather than >>> thinking about what they realistically can be within the constraints of >>> some existing underlying protocol. >>>=20 >>> That's the idea. I'm not going to present a proposed charter for work >>>or >>> anything like that in Paris, but I am interested in hearing if people >>> think this is a promising approach, and if so, perhaps we'd put a >>>charter >>> on the agenda for Vancouver. I have however submitted a -00 draft for >>> this time which gives a high-level proposal for a data model and at >>>least >>> enumerates what some of the elements might be that would be populated >>>in >>> queries and responses. This is a pretty broad sketch, but it should >>> convey the basic idea. You can check it out here: >>> https://exchcas.va.neustar.com/owa/thoughts about the direction or the >>> specifics of the data model are welcome. Thanks! >>>=20 >>> Jon Peterson >>> NeuStar, Inc. >>> _______________________________________________ >>> 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 >>=20 > From magnus.westerlund@ericsson.com Fri Mar 16 08:32:35 2012 Return-Path: <magnus.westerlund@ericsson.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4405C21F8709 for <dispatch@ietfa.amsl.com>; Fri, 16 Mar 2012 08:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.368 X-Spam-Level: X-Spam-Status: No, score=-110.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KcNVfIl1OhU for <dispatch@ietfa.amsl.com>; Fri, 16 Mar 2012 08:32:34 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7C621F86D5 for <dispatch@ietf.org>; Fri, 16 Mar 2012 08:32:34 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-44-4f635d113923 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C4.11.17856.11D536F4; Fri, 16 Mar 2012 16:32:33 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Fri, 16 Mar 2012 16:32:32 +0100 Message-ID: <4F635D10.3040607@ericsson.com> Date: Fri, 16 Mar 2012 16:32:32 +0100 From: Magnus Westerlund <magnus.westerlund@ericsson.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: DISPATCH list <dispatch@ietf.org> References: <4F635AF9.9020605@ericsson.com> In-Reply-To: <4F635AF9.9020605@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Media Stream Related Signaling X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Mar 2012 15:32:35 -0000 Dispatch, With 10 days until the meeting I would like to provide a reminder on the upcoming discussion and some clarification on what we believe to be the high level question that Dispatch needs to resolve for us to be able to make progress. First of all we have not updated our drafts. They are still relevant background material for this discussion: Media Stream Selection: https://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selection/ Pause and Resume: https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/ The above drafts propose the need for two functionalities: Choose What Content to Receive - A media receiver wants to dynamically choose which media stream to receive, out of many possible, from a certain media sender, out of many possible Request to Pause Sending of a Content - A media receiver wants to ask the media sender to temporarily stop sending a specific media stream, and to resume it with short notice >From our perspective there exist three different high level methods for realizing this functionality: - Using a media control protocol, like BFCP or Media Control Framework - Using the media plane, like RTCP - Using the signaling plane, like SIP/SDP or other SIP carried data What we want out of the Dispatch session is clear indications on what are the most suitable method or methods (as we have two different functionalities) that should be worked out. That indication can then hopefully be turned into a decision pretty quickly to take the work to one or more WG. We want to be able to continue working on this and making progress. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From gonzalo.camarillo@ericsson.com Sat Mar 17 03:19:13 2012 Return-Path: <gonzalo.camarillo@ericsson.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A0221F862A for <dispatch@ietfa.amsl.com>; Sat, 17 Mar 2012 03:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.335 X-Spam-Level: X-Spam-Status: No, score=-110.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5PTdIOyzwUX for <dispatch@ietfa.amsl.com>; Sat, 17 Mar 2012 03:19:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5EA21F857A for <dispatch@ietf.org>; Sat, 17 Mar 2012 03:19:01 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-40-4f6465149eb1 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2F.F6.27041.415646F4; Sat, 17 Mar 2012 11:19:00 +0100 (CET) Received: from [131.160.126.134] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Sat, 17 Mar 2012 11:19:00 +0100 Message-ID: <4F646513.3020200@ericsson.com> Date: Sat, 17 Mar 2012 12:18:59 +0200 From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: DISPATCH <dispatch@ietf.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] The creation of the INSIPID WG has been approved X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Mar 2012 10:19:13 -0000 Folks, the IESG has approved the creation of the INSIPID WG. Keith and Hadriel will be cochairing the session in Paris. After Paris, we will announce the final chairs for the group. Now that the chartering discussions are over, please continue the technical discussions on the INSIPID mailing list. Thanks, Gonzalo From richard@shockey.us Sat Mar 17 09:20:22 2012 Return-Path: <richard@shockey.us> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CEE21F85B9 for <dispatch@ietfa.amsl.com>; Sat, 17 Mar 2012 09:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.704 X-Spam-Level: X-Spam-Status: No, score=-98.704 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FytFW54OQZl for <dispatch@ietfa.amsl.com>; Sat, 17 Mar 2012 09:20:21 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id DC1FD21F85D0 for <dispatch@ietf.org>; Sat, 17 Mar 2012 09:20:20 -0700 (PDT) Received: (qmail 3196 invoked by uid 0); 17 Mar 2012 16:20:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 17 Mar 2012 16:20:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=2UI4aqJnVE9Q4tyi+iB7g+vbXPyj6+hpCDwYyGF0jhw=; b=QkMoI53/SFqRzFkPBhO4NIytSv9R0aQvHkDRupTBZR2o2XxLkp+Egc2SzdDyHz6jikgQbDA1TLjhCRTMl3bInaY4d/L90o/5jeywg06g2nJ8BS63L+x+Stjb1o2qy7eJ; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from <richard@shockey.us>) id 1S8wMe-0001Mz-3s; Sat, 17 Mar 2012 10:20:20 -0600 From: "Richard Shockey" <richard@shockey.us> To: "'Peterson, Jon'" <jon.peterson@neustar.biz> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> <016d01cd021f$db9c55b0$92d50110$@us> <076EA5CD-1DA8-4238-B53E-7764EC44B37E@neustar.biz> In-Reply-To: <076EA5CD-1DA8-4238-B53E-7764EC44B37E@neustar.biz> Date: Sat, 17 Mar 2012 12:20:20 -0400 Message-ID: <00a701cd0459$da0518e0$8e0f4aa0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0CM3GqY7KsKxqTTTKNKBSL+lNY0ACIp26w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Mar 2012 16:20:22 -0000 Oh wow .. Oh Hadriel ... Hadriel we need a new insipid WG name :-) Seriously though. My patience with 6116 bashing is growing thin. The requirements here are the issue. E.164 numbers are names that have to be translated into useful things and there are multiple types of Session Establishment Data necessary to make common real-time communications (SIP) work properly across domain boundaries. The problem has NOT been adequately solved and collectively we are facing an serious issue since it is clear that some National Regulatory Authorities want to end POTS and it is equally clear we do not have a full protocol solution in place. I just don't think this as complex as you suggest, since there is ample evidence from the field that ENUM deployments DO work and work well, though as I have said before, knowing what we know now based on the current state of technology its worth a new look. This is complicated since it is fairly clear that you among others are hinting that that 6116 should be rendered Historic. If it is clear that what you propose can NEVER be used over private DNS instantiations then at least be up front about it. If it is also clear that you fundamentally object to the G-SPID draft than please let us know since some of us need to think about Plan B. My next question is are we seeing new requirements or concerns coming from 3GPP for instance ( Keith ?) that would help move this work along in a expedited manner? -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Wednesday, March 14, 2012 6:40 PM To: Richard Shockey Cc: dispatch@ietf.org; Daryl Malas; Peterson, Jon Subject: Re: [dispatch] New Proposal for Telephone-Related Queries I know that the criticisms of E2MD will remain a sore point, but the idea here is to set those issues aside and focus on the data model in a protocol-neutral venue. In order to get at the converged network solution for after the end of POTS (aPOTScalypse now?), we need to consider requirements beyond the handful of things we debated in E2MD, anyway: the technical and operational issues that have faced ENUM deployments, the questions surrounding session establishment data in DRINKS, even the requirements of web-based services like those now considered in RTCWeb should be in play. If there is, for example, a use case where we want to resolve things other than telephone numbers (like SPIDs for LRF, say), then that might call for a slightly different applicability than ENUM (which is really about the resolution of telephone numbers). If the use cases really do support disentangling the original source of a query from a query intermediary, and distinguishing both of those from the "route source," that will require significant syntactic complexity in query. If we do want to be able to communicate in responses which authority provisioned the records, that too takes us into pretty uncharted territory. I wouldn't say it would be impossible to do these sorts of things with the DNS as an underlying transport - it would require some work in other areas of the IETF, I suspect, but it's not impossible - however, by the time we did, I'm not sure we'd be calling the end result "ENUM" anymore. What I don't want is to start off by limiting the semantics of queries and responses to meet the constraints of a particular potential transport. Jon Peterson NeuStar, Inc. On Mar 14, 2012, at 1:20 PM, Richard Shockey wrote: > "Challenges" is a understatement. We had a clear path to extend 6116 to > "other data types" aka E2MD in private instantiations among others but, for > reasons I still do not clearly understand, that was blocked by you and > others. > > I completely concur with Daryl here. That said its certainly worth taking a > fresh look at things in light of recent regulatory moves in North America > toward the End of POTS. There has to be a solution to Number Translations in > converged networks. > > If I had a clean sheet of paper today ..sure JSON over SHTTP. Solves lots of > problems with Security ,AA and determinate response. A hierarchical > structure may not be completely necessary in core carrier SIP/IMS networks. > > The problems you cite were with e164.arpa, however other uses have performed > very well in the field. Including the Federal Communications Commission > I-TRS system run by you know who. > > IMHO this is still NOT helpful to the discussion. > > http://www.ietf.org/internet-drafts/draft-iab-dns-applications-04.txt > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Peterson, Jon > Sent: Wednesday, March 14, 2012 3:40 PM > To: Daryl Malas > Cc: dispatch@ietf.org > Subject: Re: [dispatch] New Proposal for Telephone-Related Queries > > > Obviously yes, I don't mean to suggest that any existing protocol is off the > table as a potential underlying binding for TeRQ, but the whole point of > approaching this from the semantics rather than the transport or encoding is > to defer those latter questions so we can focus on what we want queries and > responses to say. I think the analysis you recommend of how existing > protocols could map to TeRQ would be part of the bindings development > process - this is situation where we will want to let a thousand flowers > bloom, and I'm sure there will be existing proposals that would be good > bindings for TeRQ. > > However, let's not sweep the obvious under the rug - we wouldn't be having > this TeRQ discussion at all if we had a clear path to extend the ENUM and > DNS standards to handle the semantics that the use cases seem to require. > That doesn't mean that a DNS binding is off the table, just that it would > seem to face challenges. > > Jon Peterson > NeuStar, Inc. > > On Mar 14, 2012, at 10:16 AM, Daryl Malas wrote: > >> I think we should be careful in being presumptuous of what we will do or >> the effects we will impose on any protocol at this point. >> >> As part of this proposal, I think we should do some basic analysis of the >> suite of protocols (and extensions) existing today related to this. We >> may or may not find that some could be used or further extended. >> >> Of course, I'm open to creating a new mechanism as a result of this work, >> if necessary. >> >> --Daryl >> >> On 3/13/12 2:54 PM, "Peterson, Jon" <jon.peterson@neustar.biz> wrote: >> >>> >>> Hi Penn, >>> >>> Glad to hear this is of interest, at least. Certainly agreed that there >>> is ENUM deployment out there - in fact, my own company does a bit of it. >>> When protocols become successful and see deployment, people do start >>> using them in unexpected ways which sometimes require significant >>> modifications, and eventually you can reach a tipping point where it >>> makes sense to reconsider the fundamentals. I think we've reached that >>> point with ENUM, where we have seen proposals to extend ENUM (and the >>> DNS) that warrant taking a step back and exploring whether or not we can >>> get a better overall framework in place - at least a framework in which >>> we can standardize features that have been proposed for ENUM but which >>> fall outside the ways we can responsibly extend the DNS. >>> >>> Also agreed, by the by, that administrative and political factors have >>> held ENUM back from being all that it can be. You'll note that the TeRQ >>> proposal does not prescribe any administrative framework like e164.arpa - >>> it's really just a query/response protocol. The irony of e164.arpa is >>> that it applied well to the original, public vision of ENUM, but has >>> sometimes ended up hampering attempts to get the carrier-driven, more >>> infrastructural deployments off the ground. >>> >>> No one is expecting that the TeRQ proposal will snuff out ENUM deployment >>> overnight. I'm sure ENUM will continue to serve a segment of the market >>> for the foreseeable future. But ENUM was standardized twelve years ago >>> now - a pretty good life cycle for any protocol. All I'm really proposing >>> is that we see how much we could gain from starting on a different >>> foundation. If we end up with something better, it will eventually phase >>> into the market and get traction. All a standards activity can do is >>> create that opportunity. >>> >>> Jon Peterson >>> NeuStar, Inc. >>> ________________________________________ >>> From: PFAUTZ, PENN L [pp3129@att.com] >>> Sent: Tuesday, March 13, 2012 8:11 AM >>> To: Peterson, Jon; 'dispatch@ietf.org' >>> Subject: RE: [dispatch] New Proposal for Telephone-Related Queries >>> >>> I think this is an interesting activity and would not want to derail it, >>> but let me play devil's advocate for a moment... >>> >>> - if we were just starting out, as opposed to having lots of (at least >>> internal and some external) deployments, I would be more optimistic >>> - although I know that the proposal responds to many concerns that have >>> been raised with enum, I personally don't see the protocol issues or even >>> the semantics of the of what the protocol can address as ever having been >>> the major thing that has held enum back from full potential. It's always >>> been lack of consensus on administrative arrangements driven by business >>> and -dare I say- political concerns. >>> >>> Good luck! >>> >>> Penn Pfautz >>> AT&T Access Management >>> +1-732-420-4962 >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Peterson, Jon >>> Sent: Monday, March 05, 2012 5:05 PM >>> To: 'dispatch@ietf.org' >>> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries >>> >>> >>> Oops, sorry, my mailer did not like the URL I submitted. The correct URL >>> for the draft is: >>> >>> https://datatracker.ietf.org/doc/draft-peterson-terq/ >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> >>> >>> -----Original Message----- >>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>> Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time >>> To: dispatch@ietf.org >>> Subject: [dispatch] New Proposal for Telephone-Related Queries >>> >>> >>> I have a proposal to bounce off the group. Basically, this is a >>> re-examination of some of the problems we've previously considered in the >>> telephony-specific cluster of work surrounding ENUM, DRINKS and >>> SPEERMINT. Through discussions in the past couple years, it's become >>> clear that we would need to significantly extend ENUM to get it to handle >>> all of the sorts of sources, subjects, and attributes that people want to >>> factor into queries about telephone number routing and administration. >>> Most of these discussions have gotten wrapped around the axle on >>> questions of the underlying syntax and semantics of the DNS, which were a >>> good match for the original vision of a public, user-driven ENUM, but >>> don't seem to be such a good match for the uses people actually want to >>> make of these protocols, in federated, service-provider-driven >>> environments like those envisioned in SPEERMINT and provisioned in >>> DRINKS. While the discussion may have died down a bit, the requirements >>> that motivated th >>> e discussion definitely aren't going away. >>> >>> Rather than continue to debate the applicability of the DNS and the >>> probity of various extensions to it, we might make more progress if we >>> work towards agreement on the semantics of queries for telephone-related >>> data independently of any underlying protocols. In other words, focus on >>> what kinds of questions about telephone numbers we want to be able to >>> ask, and what kinds of information needs to go into the answers, and >>> incorporate all this into an abstract data model. So for example, we know >>> that we want to be able to express the source of a request in a query. >>> What do we mean by source? I can think of a bunch of different kinds of >>> source: the logical originator of the query (the administrative entity >>> asking), the logical identity of any intermediary or aggregator >>> forwarding the query, or even the point at the network from which the >>> call originates (the originating trunk group, SBC or what have you). All >>> three of those concepts of source seem important when it comes to answe >>> ring questions about telephone numbers, so a data model would treat >>> those as separate elements which can vary independently - then we can >>> then try to figure out what's mandatory or optional, etc. We follow this >>> same method for all the elements of queries and responses. Figure out >>> what the attributes are of telephone numbers that we care about, sort >>> them into buckets of routing data and administrative data, and so on. >>> >>> Once we have an agreement on the data model, then people can map the >>> model to whatever underlying protocol they'd like - or just build it into >>> a web API, or what have you. Those proposals could advance as separate >>> documents. Having that flexibility would make it a lot easier to figure >>> out what we really want the questions and answers to be, rather than >>> thinking about what they realistically can be within the constraints of >>> some existing underlying protocol. >>> >>> That's the idea. I'm not going to present a proposed charter for work or >>> anything like that in Paris, but I am interested in hearing if people >>> think this is a promising approach, and if so, perhaps we'd put a charter >>> on the agenda for Vancouver. I have however submitted a -00 draft for >>> this time which gives a high-level proposal for a data model and at least >>> enumerates what some of the elements might be that would be populated in >>> queries and responses. This is a pretty broad sketch, but it should >>> convey the basic idea. You can check it out here: >>> https://exchcas.va.neustar.com/owa/thoughts about the direction or the >>> specifics of the data model are welcome. Thanks! >>> >>> Jon Peterson >>> NeuStar, Inc. >>> _______________________________________________ >>> 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 HKaplan@acmepacket.com Sun Mar 18 12:52:58 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5537321F8552 for <dispatch@ietfa.amsl.com>; Sun, 18 Mar 2012 12:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V97a1jlxJYef for <dispatch@ietfa.amsl.com>; Sun, 18 Mar 2012 12:52:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B270E21F853C for <dispatch@ietf.org>; Sun, 18 Mar 2012 12:52:57 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 18 Mar 2012 15:52:50 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.166]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Sun, 18 Mar 2012 15:52:50 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: "Peterson, Jon" <jon.peterson@neustar.biz> Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: AQHNBUCy0NtZCuRe6k+hRnDANTPWmg== Date: Sun, 18 Mar 2012 19:52:49 +0000 Message-ID: <BC0C7F75-07F0-4B54-8DC1-07C72425C396@acmepacket.com> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> In-Reply-To: <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <4DEB75788EC6D8489DBDF3A11E1978D1@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 18 Mar 2012 19:52:58 -0000 On Mar 14, 2012, at 3:39 PM, Peterson, Jon wrote: > However, let's not sweep the obvious under the rug - we wouldn't be havin= g this TeRQ discussion at all if we had a clear path to extend the ENUM and= DNS standards to handle the semantics that the use cases seem to require. = That doesn't mean that a DNS binding is off the table, just that it would s= eem to face challenges. It faces challenges because the IAB does not distinguish between the *Proto= col* of DNS, the *database structure* defined by DNS RFCs, and the *databas= e instance* used for public Domain Name name resolution rooted in IANA root= s. Imagine if someone had defined SQL the language, a specific SQL database sc= hema, and a specific instance of a MySQL database; and then said "Sorry the= SQL language or schema cannot be extended because our particular MySQL dat= abase wasn't meant to have these new fields". Despite that no one cares ab= out using that person's particular MySQL database for the extended schema, = and even if a client (erroneously) used the extended language/schema on tha= t person's particular database it would just be ignored. I get that the IANA-rooted instance of DNS the database will not handle new= fields/semantics. But to restrict the DNS *protocol* to only be able to d= o what the IANA-rooted instance does is bizarre - either the IAB believes t= he IANA-rooted DNS database is so brittle that receiving some unknown field= s in a DNS query from erroneous clients would crash it, in which case US-CE= RT should be immediately notified, or the IAB believes that no distinction = can be made between the protocol, port 53, and the deployed IANA-rooted Dom= ain resolution databases. -hadriel From matthew.kaufman@skype.net Sun Mar 18 22:25:14 2012 Return-Path: <matthew.kaufman@skype.net> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A71A21F8542 for <dispatch@ietfa.amsl.com>; Sun, 18 Mar 2012 22:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmF3oPyaQakx for <dispatch@ietfa.amsl.com>; Sun, 18 Mar 2012 22:25:13 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 42CC321F8517 for <dispatch@ietf.org>; Sun, 18 Mar 2012 22:25:12 -0700 (PDT) Received: from mail103-am1-R.bigfish.com (10.3.201.249) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 19 Mar 2012 05:25:07 +0000 Received: from mail103-am1 (localhost [127.0.0.1]) by mail103-am1-R.bigfish.com (Postfix) with ESMTP id BF2D410056A; Mon, 19 Mar 2012 05:25:07 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh87h2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail103-am1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail103-am1 (localhost.localdomain [127.0.0.1]) by mail103-am1 (MessageSwitch) id 1332134705734209_17084; Mon, 19 Mar 2012 05:25:05 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.254]) by mail103-am1.bigfish.com (Postfix) with ESMTP id AEA302C0045; Mon, 19 Mar 2012 05:25:05 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 19 Mar 2012 05:25:05 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.175]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0283.004; Mon, 19 Mar 2012 05:25:06 +0000 From: Matthew Kaufman <matthew.kaufman@skype.net> To: Hadriel Kaplan <HKaplan@acmepacket.com>, "Peterson, Jon" <jon.peterson@neustar.biz> Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: AQHM+xQ7UaE2MYlCb0+6Ly0bNplLX5ZcQduAgAwc9tCAAB7o5oABmHsAgAAoCYCABkz/gIAAn7vA Date: Mon, 19 Mar 2012 05:25:05 +0000 Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A484064C99D8@TK5EX14MBXC273.redmond.corp.microsoft.com> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> <BC0C7F75-07F0-4B54-8DC1-07C72425C396@acmepacket.com> In-Reply-To: <BC0C7F75-07F0-4B54-8DC1-07C72425C396@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 19 Mar 2012 05:25:14 -0000 Hadriel Kaplan: "I get that the IANA-rooted instance of DNS the database will not handle ne= w fields/semantics. But to restrict the DNS *protocol* to only be able to = do what the IANA-rooted instance does is bizarre - either the IAB believes = the IANA-rooted DNS database is so brittle that receiving some unknown fiel= ds in a DNS query from erroneous clients would crash it, in which case US-C= ERT should be immediately notified, or the IAB believes that no distinction= can be made between the protocol, port 53, and the deployed IANA-rooted Do= main resolution databases." +1 Matthew Kaufman From jon.peterson@neustar.biz Mon Mar 19 10:49:54 2012 Return-Path: <jon.peterson@neustar.biz> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41E621F88A0 for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 10:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.302 X-Spam-Level: X-Spam-Status: No, score=-106.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zmm5xcEAxmnU for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 10:49:51 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4F63A21F888B for <dispatch@ietf.org>; Mon, 19 Mar 2012 10:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1332179424; x=1647527903; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=Qvl2YtKm8d7FARMX8EibE k3msX6J9jvo03NH7ygp9Dw=; b=db1GKkwfEXOAQSarDUclDf1Ue9C40S3Nof3S7 W3rQau2ZDTjK+mTjqcHjtQOVq42U/qqoL76qnaIgNiBpMx3Cg== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.6469870; Mon, 19 Mar 2012 13:50:23 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 19 Mar 2012 13:49:43 -0400 From: "Peterson, Jon" <jon.peterson@neustar.biz> To: Richard Shockey <richard@shockey.us> Date: Mon, 19 Mar 2012 13:49:42 -0400 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: Ac0CM3GqY7KsKxqTTTKNKBSL+lNY0ACIp26wAGf1c3I= Message-ID: <55A5A9A87506CB4BA580BF9D531957DA239D63C8@STNTEXCH01.cis.neustar.com> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> <016d01cd021f$db9c55b0$92d50110$@us> <076EA5CD-1DA8-4238-B53E-7764EC44B37E@neustar.biz>, <00a701cd0459$da0518e0$8e0f4aa0$@us> In-Reply-To: <00a701cd0459$da0518e0$8e0f4aa0$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: FnH1gtCwJDOh7rf9Gn6J0Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 19 Mar 2012 17:49:54 -0000 I do apologize if that came across as "bashing" ENUM, that really wasn't my= intention. You and I agree completely that the requirements going forward= is where we should be focusing, and indeed the whole point of the TeRQ pro= posal is to try to collect t a broader set of requirements and semantics th= an we did with ENUM in the past. When I said, for example, that ENUM resolv= es telephone numbers, and there might be identifiers other than telephone n= umbers (like SPIDs) that we might want to resolve, I'm not trying to knock = RFC6116, I'm just trying to motivate exactly the requirements survey you're= advocating. I have from the start said that ENUM deployments serve a usefu= l purpose today, up to and including providing revenue for companies I am a= ware of, and the point of TeRQ is not to turn that off. We both know that s= ome of the techniques that are used in ENUM deployments today face a tough = path to becoming standards, though, and that was the only point I was tryin= g to make. I wouldn't say that the TeRQ data model (in rough the form I've sketched it= ) could never be applied to private DNS instantiations, no. I wouldn't rule= out the DNS as a potential underlying protocol for TeRQ. I do speculate, t= hough, that the results of doing so would like a bit different from RFC6116= - taking the example in my last paragraph, resolving SPIDs or other identi= fiers as the Subject of a Query would look a bit different from the First W= ell Known Rule. Regarding GSPID, I think that work is somewhat orthogonal to the question h= ere - should there be IETF consensus around GSPID, obviously it's an identi= fier that TeRQ would include in the data model. Jon Peterson NeuStar, Inc. ________________________________________ From: Richard Shockey [richard@shockey.us] Sent: Saturday, March 17, 2012 9:20 AM To: Peterson, Jon Cc: dispatch@ietf.org; 'Daryl Malas' Subject: RE: [dispatch] New Proposal for Telephone-Related Queries Oh wow .. Oh Hadriel ... Hadriel we need a new insipid WG name :-) Seriously though. My patience with 6116 bashing is growing thin. The requirements here are the issue. E.164 numbers are names that have to be translated into useful things and there are multiple types of Session Establishment Data necessary to make common real-time communications (SIP) work properly across domain boundaries. The problem has NOT been adequately solved and collectively we are facing an serious issue since it is clear that some National Regulatory Authorities want to end POTS and it is equall= y clear we do not have a full protocol solution in place. I just don't think this as complex as you suggest, since there is ample evidence from the field that ENUM deployments DO work and work well, though as I have said before, knowing what we know now based on the current state of technology its worth a new look. This is complicated since it is fairly clear that you among others are hinting that that 6116 should be rendered Historic. If it is clear that what you propose can NEVER be used over private DNS instantiations then at least be up front about it. If it is also clear that you fundamentally object to the G-SPID draft than please let us know since some of us need to think about Plan B. My next question is are we seeing new requirements or concerns coming from 3GPP for instance ( Keith ?) that would help move this work along in a expedited manner? -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Wednesday, March 14, 2012 6:40 PM To: Richard Shockey Cc: dispatch@ietf.org; Daryl Malas; Peterson, Jon Subject: Re: [dispatch] New Proposal for Telephone-Related Queries I know that the criticisms of E2MD will remain a sore point, but the idea here is to set those issues aside and focus on the data model in a protocol-neutral venue. In order to get at the converged network solution for after the end of POTS (aPOTScalypse now?), we need to consider requirements beyond the handful of things we debated in E2MD, anyway: the technical and operational issues that have faced ENUM deployments, the questions surrounding session establishment data in DRINKS, even the requirements of web-based services like those now considered in RTCWeb should be in play. If there is, for example, a use case where we want to resolve things other than telephone numbers (like SPIDs for LRF, say), then that might call for = a slightly different applicability than ENUM (which is really about the resolution of telephone numbers). If the use cases really do support disentangling the original source of a query from a query intermediary, and distinguishing both of those from the "route source," that will require significant syntactic complexity in query. If we do want to be able to communicate in responses which authority provisioned the records, that too takes us into pretty uncharted territory. I wouldn't say it would be impossible to do these sorts of things with the DNS as an underlying transport - it would require some work in other areas of the IETF, I suspect, but it's not impossible - however, by the time we did, I'm not sure we'd be calling the end result "ENUM" anymore. What I don't want is to start off by limiting the semantics of queries and responses to meet the constraints of a particular potential transport. Jon Peterson NeuStar, Inc. On Mar 14, 2012, at 1:20 PM, Richard Shockey wrote: > "Challenges" is a understatement. We had a clear path to extend 6116 to > "other data types" aka E2MD in private instantiations among others but, for > reasons I still do not clearly understand, that was blocked by you and > others. > > I completely concur with Daryl here. That said its certainly worth taking a > fresh look at things in light of recent regulatory moves in North America > toward the End of POTS. There has to be a solution to Number Translations in > converged networks. > > If I had a clean sheet of paper today ..sure JSON over SHTTP. Solves lots of > problems with Security ,AA and determinate response. A hierarchical > structure may not be completely necessary in core carrier SIP/IMS networks. > > The problems you cite were with e164.arpa, however other uses have performed > very well in the field. Including the Federal Communications Commission > I-TRS system run by you know who. > > IMHO this is still NOT helpful to the discussion. > > http://www.ietf.org/internet-drafts/draft-iab-dns-applications-04.txt > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Peterson, Jon > Sent: Wednesday, March 14, 2012 3:40 PM > To: Daryl Malas > Cc: dispatch@ietf.org > Subject: Re: [dispatch] New Proposal for Telephone-Related Queries > > > Obviously yes, I don't mean to suggest that any existing protocol is off the > table as a potential underlying binding for TeRQ, but the whole point of > approaching this from the semantics rather than the transport or encoding is > to defer those latter questions so we can focus on what we want queries and > responses to say. I think the analysis you recommend of how existing > protocols could map to TeRQ would be part of the bindings development > process - this is situation where we will want to let a thousand flowers > bloom, and I'm sure there will be existing proposals that would be good > bindings for TeRQ. > > However, let's not sweep the obvious under the rug - we wouldn't be havin= g > this TeRQ discussion at all if we had a clear path to extend the ENUM and > DNS standards to handle the semantics that the use cases seem to require. > That doesn't mean that a DNS binding is off the table, just that it would > seem to face challenges. > > Jon Peterson > NeuStar, Inc. > > On Mar 14, 2012, at 10:16 AM, Daryl Malas wrote: > >> I think we should be careful in being presumptuous of what we will do or >> the effects we will impose on any protocol at this point. >> >> As part of this proposal, I think we should do some basic analysis of th= e >> suite of protocols (and extensions) existing today related to this. We >> may or may not find that some could be used or further extended. >> >> Of course, I'm open to creating a new mechanism as a result of this work= , >> if necessary. >> >> --Daryl >> >> On 3/13/12 2:54 PM, "Peterson, Jon" <jon.peterson@neustar.biz> wrote: >> >>> >>> Hi Penn, >>> >>> Glad to hear this is of interest, at least. Certainly agreed that there >>> is ENUM deployment out there - in fact, my own company does a bit of it= . >>> When protocols become successful and see deployment, people do start >>> using them in unexpected ways which sometimes require significant >>> modifications, and eventually you can reach a tipping point where it >>> makes sense to reconsider the fundamentals. I think we've reached that >>> point with ENUM, where we have seen proposals to extend ENUM (and the >>> DNS) that warrant taking a step back and exploring whether or not we ca= n >>> get a better overall framework in place - at least a framework in which >>> we can standardize features that have been proposed for ENUM but which >>> fall outside the ways we can responsibly extend the DNS. >>> >>> Also agreed, by the by, that administrative and political factors have >>> held ENUM back from being all that it can be. You'll note that the TeRQ >>> proposal does not prescribe any administrative framework like e164.arpa - >>> it's really just a query/response protocol. The irony of e164.arpa is >>> that it applied well to the original, public vision of ENUM, but has >>> sometimes ended up hampering attempts to get the carrier-driven, more >>> infrastructural deployments off the ground. >>> >>> No one is expecting that the TeRQ proposal will snuff out ENUM deployment >>> overnight. I'm sure ENUM will continue to serve a segment of the market >>> for the foreseeable future. But ENUM was standardized twelve years ago >>> now - a pretty good life cycle for any protocol. All I'm really proposing >>> is that we see how much we could gain from starting on a different >>> foundation. If we end up with something better, it will eventually phas= e >>> into the market and get traction. All a standards activity can do is >>> create that opportunity. >>> >>> Jon Peterson >>> NeuStar, Inc. >>> ________________________________________ >>> From: PFAUTZ, PENN L [pp3129@att.com] >>> Sent: Tuesday, March 13, 2012 8:11 AM >>> To: Peterson, Jon; 'dispatch@ietf.org' >>> Subject: RE: [dispatch] New Proposal for Telephone-Related Queries >>> >>> I think this is an interesting activity and would not want to derail it= , >>> but let me play devil's advocate for a moment... >>> >>> - if we were just starting out, as opposed to having lots of (at least >>> internal and some external) deployments, I would be more optimistic >>> - although I know that the proposal responds to many concerns that have >>> been raised with enum, I personally don't see the protocol issues or even >>> the semantics of the of what the protocol can address as ever having been >>> the major thing that has held enum back from full potential. It's alway= s >>> been lack of consensus on administrative arrangements driven by busines= s >>> and -dare I say- political concerns. >>> >>> Good luck! >>> >>> Penn Pfautz >>> AT&T Access Management >>> +1-732-420-4962 >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Peterson, Jon >>> Sent: Monday, March 05, 2012 5:05 PM >>> To: 'dispatch@ietf.org' >>> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries >>> >>> >>> Oops, sorry, my mailer did not like the URL I submitted. The correct UR= L >>> for the draft is: >>> >>> https://datatracker.ietf.org/doc/draft-peterson-terq/ >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> >>> >>> -----Original Message----- >>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>> Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time >>> To: dispatch@ietf.org >>> Subject: [dispatch] New Proposal for Telephone-Related Queries >>> >>> >>> I have a proposal to bounce off the group. Basically, this is a >>> re-examination of some of the problems we've previously considered in the >>> telephony-specific cluster of work surrounding ENUM, DRINKS and >>> SPEERMINT. Through discussions in the past couple years, it's become >>> clear that we would need to significantly extend ENUM to get it to handle >>> all of the sorts of sources, subjects, and attributes that people want to >>> factor into queries about telephone number routing and administration. >>> Most of these discussions have gotten wrapped around the axle on >>> questions of the underlying syntax and semantics of the DNS, which were a >>> good match for the original vision of a public, user-driven ENUM, but >>> don't seem to be such a good match for the uses people actually want to >>> make of these protocols, in federated, service-provider-driven >>> environments like those envisioned in SPEERMINT and provisioned in >>> DRINKS. While the discussion may have died down a bit, the requirements >>> that motivated th >>> e discussion definitely aren't going away. >>> >>> Rather than continue to debate the applicability of the DNS and the >>> probity of various extensions to it, we might make more progress if we >>> work towards agreement on the semantics of queries for telephone-relate= d >>> data independently of any underlying protocols. In other words, focus o= n >>> what kinds of questions about telephone numbers we want to be able to >>> ask, and what kinds of information needs to go into the answers, and >>> incorporate all this into an abstract data model. So for example, we know >>> that we want to be able to express the source of a request in a query. >>> What do we mean by source? I can think of a bunch of different kinds of >>> source: the logical originator of the query (the administrative entity >>> asking), the logical identity of any intermediary or aggregator >>> forwarding the query, or even the point at the network from which the >>> call originates (the originating trunk group, SBC or what have you). Al= l >>> three of those concepts of source seem important when it comes to answe >>> ring questions about telephone numbers, so a data model would treat >>> those as separate elements which can vary independently - then we can >>> then try to figure out what's mandatory or optional, etc. We follow thi= s >>> same method for all the elements of queries and responses. Figure out >>> what the attributes are of telephone numbers that we care about, sort >>> them into buckets of routing data and administrative data, and so on. >>> >>> Once we have an agreement on the data model, then people can map the >>> model to whatever underlying protocol they'd like - or just build it into >>> a web API, or what have you. Those proposals could advance as separate >>> documents. Having that flexibility would make it a lot easier to figure >>> out what we really want the questions and answers to be, rather than >>> thinking about what they realistically can be within the constraints of >>> some existing underlying protocol. >>> >>> That's the idea. I'm not going to present a proposed charter for work o= r >>> anything like that in Paris, but I am interested in hearing if people >>> think this is a promising approach, and if so, perhaps we'd put a charter >>> on the agenda for Vancouver. I have however submitted a -00 draft for >>> this time which gives a high-level proposal for a data model and at least >>> enumerates what some of the elements might be that would be populated i= n >>> queries and responses. This is a pretty broad sketch, but it should >>> convey the basic idea. You can check it out here: >>> https://exchcas.va.neustar.com/owa/thoughts about the direction or the >>> specifics of the data model are welcome. Thanks! >>> >>> Jon Peterson >>> NeuStar, Inc. >>> _______________________________________________ >>> 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 jon.peterson@neustar.biz Mon Mar 19 11:51:51 2012 Return-Path: <jon.peterson@neustar.biz> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D4321F88CE for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 11:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.041 X-Spam-Level: X-Spam-Status: No, score=-106.041 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0EwjvWmO8IT for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 11:51:49 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA0321F889A for <dispatch@ietf.org>; Mon, 19 Mar 2012 11:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1332183091; x=1647527903; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=YGr4dvLlIyqreBUEGafWs TRg5xl6lmCA0ANhLjbWsec=; b=qgNiOl/gtelMCWpRXaUCCHBDOp8jDK/OYD9QJ aQvVDVG8V/GmGhAXcVsh7/HNZQnYgmipK62ObHxBuCRWTYI/Q== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.6472496; Mon, 19 Mar 2012 14:51:30 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Mon, 19 Mar 2012 14:50:50 -0400 From: "Peterson, Jon" <jon.peterson@neustar.biz> To: Hadriel Kaplan <HKaplan@acmepacket.com> Date: Mon, 19 Mar 2012 14:50:49 -0400 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: AQHNBUCy0NtZCuRe6k+hRnDANTPWmpZx5uI5 Message-ID: <55A5A9A87506CB4BA580BF9D531957DA239D63C9@STNTEXCH01.cis.neustar.com> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz>, <BC0C7F75-07F0-4B54-8DC1-07C72425C396@acmepacket.com> In-Reply-To: <BC0C7F75-07F0-4B54-8DC1-07C72425C396@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: i2oQLJJRqHPjarThwSmheA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 19 Mar 2012 18:51:51 -0000 I hear you, but I'd argue that the protocol mechanisms built in to the DNS = reflect its intended deployment, and that when we decouple the protocol fro= m that deployment we can run into problems. To give one example from a priv= ate ENUM deployment I'm familiar with - there was a use case for multiple a= dministrative entities to be able to provision different records associated= with a given telephone number. However, people furthermore wanted to clien= t to be able to see which of the administrative entities providing records = was authoritative for the number in question, effectively which was the car= rier-of-record vs. inter-exchange carriers or other entities who happened t= o be able to offer a route to that number. Sounds like a reasonable require= ment, but it's clear why the DNS doesn't have any existing mechanism to sup= port it: because the DNS assumes a "golden root" where there is one authori= ty per name rather than a pluralist environment where different authorities= provide different resolutions for the same name. That universality of the = "golden root" data is also the reason why the DNS doesn't have mechanisms f= or authenticating clients, as all data is public, and so on. The design of = the DNS protocols was defined by the intended deployment. But your point is a bit different: if people in the real world are using th= e DNS protocols outside the "golden root," why can't we update the standard= protocols to provide the tools that we actually need in these private envi= ronments? Broadly, there might be a case to be made that we should, and not= just because of ENUM deployments, but a growing set of non-ENUM private DN= S usages. It may be that there is enough mindshare behind these deployments= to get IETF consensus to extend the DNS protocols in these directions. To = get this to become a standard, though, I think the discussion would need to= happen in the right venue (not the RAI area) and at the right level. These= would be important architectural changes to the DNS protocols, not small, = incremental additions to the edges. Going back to my example above, there w= as a proposal in that private ENUM deployment to overload some of the exist= ing authority flags in the DNS to express that the carrier-of-record provid= ed the record in question. I think this is a good example of an approach th= e IETF should not standardize, even though the requirement does seem reason= able within that private DNS deployment. I would feel similarly about overl= oading the transport-negotiation functions of EDNS0 to apply to matters out= side of its scope. If we want to extend the DNS to have these capabilities,= I don't think we can do in the margins - we need to do it out in the open,= in a frank discussion. I think proposals along these lines would face chal= lenges, but I wouldn't rule them out.=20 The point of the TeRQ proposal is to get past the questions of encoding the= se things into the DNS so we can really understand the core semantics. If a= nything, limiting the requirements to what we can squeeze out of the syntac= tic margins of the DNS protocols has only made it harder to understand what= the real needs are. TeRQ currently proposes, for example, building Authori= ty into the Records that appear in Responses, as deployment experience supp= orts this use case. Maybe having a TeRQ-like model in mind might even make = it easier to articulate how the DNS needs to change to support private appl= ications. Jon Peterson NeuStar, Inc. ________________________________________ From: Hadriel Kaplan [HKaplan@acmepacket.com] Sent: Sunday, March 18, 2012 12:52 PM To: Peterson, Jon Cc: Daryl Malas; dispatch@ietf.org Subject: Re: [dispatch] New Proposal for Telephone-Related Queries On Mar 14, 2012, at 3:39 PM, Peterson, Jon wrote: > However, let's not sweep the obvious under the rug - we wouldn't be havin= g this TeRQ discussion at all if we had a clear path to extend the ENUM and= DNS standards to handle the semantics that the use cases seem to require. = That doesn't mean that a DNS binding is off the table, just that it would s= eem to face challenges. It faces challenges because the IAB does not distinguish between the *Proto= col* of DNS, the *database structure* defined by DNS RFCs, and the *databas= e instance* used for public Domain Name name resolution rooted in IANA root= s. Imagine if someone had defined SQL the language, a specific SQL database sc= hema, and a specific instance of a MySQL database; and then said "Sorry the= SQL language or schema cannot be extended because our particular MySQL dat= abase wasn't meant to have these new fields". Despite that no one cares ab= out using that person's particular MySQL database for the extended schema, = and even if a client (erroneously) used the extended language/schema on tha= t person's particular database it would just be ignored. I get that the IANA-rooted instance of DNS the database will not handle new= fields/semantics. But to restrict the DNS *protocol* to only be able to d= o what the IANA-rooted instance does is bizarre - either the IAB believes t= he IANA-rooted DNS database is so brittle that receiving some unknown field= s in a DNS query from erroneous clients would crash it, in which case US-CE= RT should be immediately notified, or the IAB believes that no distinction = can be made between the protocol, port 53, and the deployed IANA-rooted Dom= ain resolution databases. -hadriel From mary.ietf.barnes@gmail.com Mon Mar 19 12:23:02 2012 Return-Path: <mary.ietf.barnes@gmail.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98D221E8015 for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 12:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4EwWPm8JqEF for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 12:23:01 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E38F21E800C for <dispatch@ietf.org>; Mon, 19 Mar 2012 12:23:01 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so8048618vcb.31 for <dispatch@ietf.org>; Mon, 19 Mar 2012 12:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GyX0kdeug9AlNIoazlBv0ltOpkZnsB0or6uPrDY6eN8=; b=nFeKoF7ACnLqykDAWoKML9whqv1yaoNKgr5YH4zs9NN6Ww8vAAk7ir1T06hNM3XTUK qs8Kjtv/ycFB2jSQXQ3Yjhu8jgCSZbTpK1be8+jey9mwQ1L26ohOhvWVcMe4HCHpec3n ie2RS1MgSxUiJLa3uUX1jW6iBo3LmdvJ4sb+zjofMZclAftDqPLtQSLNvz694YUEoNPh uHgLZkBL3xianTMoQhkP2Cxgqvq3mb2CWVEZjn9U62RQPVg34XYmnyzd7dtVAgPOhRIB 9UYf438BAL7Yqde64JnIRc5t0RABBPp4Li6ucEHY8fz7wzDE8of2kHHQguYIpeJ2rlfU KPOA== MIME-Version: 1.0 Received: by 10.52.28.4 with SMTP id x4mr5677739vdg.4.1332184978632; Mon, 19 Mar 2012 12:22:58 -0700 (PDT) Received: by 10.52.111.136 with HTTP; Mon, 19 Mar 2012 12:22:58 -0700 (PDT) Date: Mon, 19 Mar 2012 14:22:58 -0500 Message-ID: <CAHBDyN7MgxRUXmjaecn_RLDdNESDoy-Gcx66gAAphdgH5gQwMQ@mail.gmail.com> From: Mary Barnes <mary.ietf.barnes@gmail.com> To: DISPATCH <dispatch@ietf.org> Content-Type: multipart/alternative; boundary=20cf30780c846d2fa104bb9d7c08 Subject: [dispatch] Discussion (maybe) of combining XMPP and SIP in XMPP WG session on Wed. afternoon X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 19 Mar 2012 19:23:02 -0000 --20cf30780c846d2fa104bb9d7c08 Content-Type: text/plain; charset=ISO-8859-1 Folks might remember that we had a discussion of this topic (known as SIXPAC) at IETF-76 during a Friday afternoon session. A separate mailing list was setup, but no announcement made to DISPATCH. The topic was on the agenda for XMPP at IETF-80 (opposite the exciting SPLICE session) and it was decided at that meeting that there was not enough interest in the topic: http://www.ietf.org/proceedings/80/minutes/xmpp.txt There is a related item that may be discussed at the XMPP WG session next week on Wednesday afternoon: http://www.ietf.org/proceedings/83/agenda/agenda-83-xmpp.txt Folks that were interested in this topic may want to follow it on the XMPP WG mailing list and attend the session. Regards, Mary DISPATCH WG co-chair --20cf30780c846d2fa104bb9d7c08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Folks might remember that we had a discussion of this topic (known as = SIXPAC) at IETF-76 during a Friday afternoon session. A separate mailing li= st was setup, but no announcement made to DISPATCH. =A0The topic was on the= agenda for XMPP at IETF-80 (opposite the exciting SPLICE session) and it w= as decided at that meeting that there was not enough interest in the topic:= </div> <div><a href=3D"http://www.ietf.org/proceedings/80/minutes/xmpp.txt">http:/= /www.ietf.org/proceedings/80/minutes/xmpp.txt</a></div><div><br></div><div>= There is a related item that may be discussed at the XMPP WG session next w= eek on Wednesday afternoon:</div> <a href=3D"http://www.ietf.org/proceedings/83/agenda/agenda-83-xmpp.txt">ht= tp://www.ietf.org/proceedings/83/agenda/agenda-83-xmpp.txt</a><div><br></di= v><div>Folks that were interested in this topic may want to follow it on th= e XMPP WG mailing list and attend the session.=A0</div> <div><br></div><div>Regards,</div><div>Mary=A0</div><div>DISPATCH WG co-cha= ir</div> --20cf30780c846d2fa104bb9d7c08-- From mary.ietf.barnes@gmail.com Mon Mar 19 13:33:57 2012 Return-Path: <mary.ietf.barnes@gmail.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909BD21F8684 for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 13:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.478 X-Spam-Level: X-Spam-Status: No, score=-103.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGd8ctmA3pq4 for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 13:33:57 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18FAA21F864B for <dispatch@ietf.org>; Mon, 19 Mar 2012 13:33:56 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so8135028vcb.31 for <dispatch@ietf.org>; Mon, 19 Mar 2012 13:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=98bkIIRW38g77koZmHBEzO88ceMOCMrCR/NKoU4BGFI=; b=UEvNWiZEt9Lu8kujNyh0SqNqaHcROUzndQNkaZXYlJm68WPdrcADwiL34U+96SXZQ2 GH3/IPZhO0oGUPDHmhX7s0t94cqCCoLyBJWsdxPDGI6wb/uJqMHtrpi+JNYAtP7moRA2 Ijxgy6NTfwsxQohuL9w5EOVoFY5FG3Vaml+xllTq8xhs30ewHRHAye+pkow1l+uBkvUL nIb47Zeees2deIdrjuz+siHDqxfXjgL66FjiuFnPvqaTCRExa+yTqDaAP7AmkPTSI7Il /i4a28gyJ2Vh4psU0sLEq29YL4IX5j5OwG+/PcVgOvWA2AkRV6x+TNCHVGHmr1EVMiqy xGdg== MIME-Version: 1.0 Received: by 10.220.38.200 with SMTP id c8mr5375476vce.28.1332189235662; Mon, 19 Mar 2012 13:33:55 -0700 (PDT) Received: by 10.52.111.136 with HTTP; Mon, 19 Mar 2012 13:33:55 -0700 (PDT) Date: Mon, 19 Mar 2012 15:33:55 -0500 Message-ID: <CAHBDyN42rnGPhXOyrew+4XWeSjHyQL9eKh2kZaiuACSkmfbPcA@mail.gmail.com> From: Mary Barnes <mary.ietf.barnes@gmail.com> To: DISPATCH <dispatch@ietf.org> Content-Type: multipart/alternative; boundary=bcaec54ee6be2a4ed404bb9e7aed Subject: [dispatch] Updated agenda X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 19 Mar 2012 20:33:57 -0000 --bcaec54ee6be2a4ed404bb9e7aed Content-Type: text/plain; charset=ISO-8859-1 Hi all, We have added an additional item to the agenda @ http://www.ietf.org/proceedings/83/agenda/agenda-83-dispatch.html. (Note: you may have to refresh your browser to see the updated agenda). TERQ per the discussion thread has been added at the end of the agenda: http://www.ietf.org/mail-archive/web/dispatch/current/msg04165.html I will note that we are making an exception given that all the deadlines weren't met (we were made aware of the proposal by the first deadline, but just didn't get everything by the 2nd deadline). However, in consultation with our ADs and given the amount of discussion, we believe that the community would benefit from discussing this during the f2f session (and we did have 20 minutes at the end of the agenda). Regards, Mary DISPATCH WG co-chair --bcaec54ee6be2a4ed404bb9e7aed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,<div><br></div><div>We have added an additional item to the agenda @= =A0=A0<a href=3D"http://www.ietf.org/proceedings/83/agenda/agenda-83-dispat= ch.html">http://www.ietf.org/proceedings/83/agenda/agenda-83-dispatch.html<= /a>. (Note: you may have to refresh your browser to see the updated agenda)= .=A0</div> <div><br></div><div>TERQ per the discussion thread has been added at the en= d of the agenda:</div><div><a href=3D"http://www.ietf.org/mail-archive/web/= dispatch/current/msg04165.html">http://www.ietf.org/mail-archive/web/dispat= ch/current/msg04165.html</a></div> <div><br></div><div>I will note that we are making an exception given that = all the deadlines weren't met (we were made aware of the proposal by th= e first deadline, but just didn't get everything by the 2nd deadline). = =A0However, in consultation with our ADs and given the amount of discussion= , we believe that the community would benefit from discussing this during t= he f2f session (and we did have 20 minutes at the end of the agenda). =A0</= div> <div><br></div><div>Regards,</div><div>Mary</div><div>DISPATCH WG co-chair<= /div> --bcaec54ee6be2a4ed404bb9e7aed-- From lconroy@insensate.co.uk Mon Mar 19 18:07:59 2012 Return-Path: <lconroy@insensate.co.uk> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7F421F87A3 for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 18:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxfEzOi-i67M for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 18:07:58 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 7096221F879A for <dispatch@ietf.org>; Mon, 19 Mar 2012 18:07:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 94084605F8D; Tue, 20 Mar 2012 01:07:56 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcvGq7OjI8vM; Tue, 20 Mar 2012 01:07:55 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 4244E605F82; Tue, 20 Mar 2012 01:07:55 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy <lconroy@insensate.co.uk> In-Reply-To: <BC0C7F75-07F0-4B54-8DC1-07C72425C396@acmepacket.com> Date: Tue, 20 Mar 2012 01:07:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1638072E-7AA2-4834-949E-3F1A9AF997FF@insensate.co.uk> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> <BC0C7F75-07F0-4B54-8DC1-07C72425C396@acmepacket.com> To: Hadriel Kaplan <HKaplan@acmepacket.com> X-Mailer: Apple Mail (2.1084) Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 20 Mar 2012 01:07:59 -0000 On 18 Mar 2012, at 19:52, Hadriel Kaplan wrote: > On Mar 14, 2012, at 3:39 PM, Peterson, Jon wrote: >> However, let's not sweep the obvious under the rug - we wouldn't be = having this TeRQ discussion at all if we had a clear path to extend the = ENUM and DNS standards to handle the semantics that the use cases seem = to require. That doesn't mean that a DNS binding is off the table, just = that it would seem to face challenges. >=20 > It faces challenges because the IAB does not distinguish between the = *Protocol* of DNS, the *database structure* defined by DNS RFCs, and the = *database instance* used for public Domain Name name resolution rooted = in IANA roots. To which I reply: Hi Hadriel, Jon, Folks, Hadriel, Richard, what are your expected deployment timescales? IIUC, you need this already, you have a hammer that works, and whilst = the data structure is going to be different from ENUM, it surely will = blend. =46rom experience of other sterling work on abstracted task & data = models in the IETF, do you believe that TERQ (or any other rigorous = analysis) could complete, AND a protocol be selected (or designed from = scratch), AND be implemented, AND the distributed data architecture be = rolled out within the timescales that your customers are considering? If it can't, I can't see how this discussion improves on silence. Either you go ahead with the syntax definitions -- in TXT records (if = the way forth for any other RR is blocked) so no need for further = standardisation -- or you go ahead with the syntax definitions after a = hiatus to consider what those should be, and into what protocol it = should be rammed. You get to choose. all the best, Lawrence From HKaplan@acmepacket.com Mon Mar 19 21:33:40 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885BA21F88CC for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 21:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MvCdHAHxS0C for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 21:33:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B751721F88CA for <dispatch@ietf.org>; Mon, 19 Mar 2012 21:33:37 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Mar 2012 00:33:33 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.166]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Tue, 20 Mar 2012 00:33:32 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: Lawrence Conroy <lconroy@insensate.co.uk> Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: AQHNBlKaj4bEVPMueEaxnuCVvEKmKA== Date: Tue, 20 Mar 2012 04:33:31 +0000 Message-ID: <DCE5EA46-84EA-465B-B4E7-4A3F2D89CC3A@acmepacket.com> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> <BC0C7F75-07F0-4B54-8DC1-07C72425C396@acmepacket.com> <1638072E-7AA2-4834-949E-3F1A9AF997FF@insensate.co.uk> In-Reply-To: <1638072E-7AA2-4834-949E-3F1A9AF997FF@insensate.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <12DD404923D45D41A13B34C45891C463@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 20 Mar 2012 04:33:40 -0000 If I could answer your second question I'd be retired or earning money with= my crystal-ball services. I generally just use a magic-8-ball to make dec= isions. :) The hard part with these things is it's just not as easy as deciding "let's= start from scratch". Most engineers like the opportunity to re-factor cod= e, but we also have to earn a living, and it's always easier to extend exis= ting code so we can make the next opportunity or deadline. (this is not exa= ctly news to anyone here, obviously, and plenty has been written on the top= ic that extending existing protocols almost always beats out new ones in th= e marketplace, but just makin' the point) But who knows - sometimes these = things get people excited and enable stuff that couldn't be done before. So anyway... to answer your first question: in practice we use ENUM/DNS qui= te a bit, but yes we end up putting stuff in TXT or NAPTRs that should have= their own record types for, and for query keys we usually just play games = with DNS domain names. It's ugly as hell in Wireshark, but it generally wo= rks. :) It's not for every use-case, because it doesn't solve world-hunger= . It's meant to address the most common use-cases, with the least-overhead= /highest-performance. But beyond ENUM the only other real player/commonality for "database" acces= s is DIAMETER, afaict, since it's the other hammer for which everything is = a nail - at least for large service-providers. For Enterprises its databas= e protocol soup: from LDAP/ActiveDirectory to Web-APIs to Excel files. It's definitely true that for real interop the actual attributes/fields/syn= tax have to be spec'ed, since saying "DIAMETER" is like saying "XML" - with= out the schema it's meaningless text. The hard part's gonna be deciding wh= at things are really so important and wide-spread that they need to be spec= 'ed, vs. what can be ignored or left up to some other SDO/association to de= fine for themselves. Like for example Jon's carrier-of-record vs. routes authority use-case: I'v= e only ever seen that authority issue/need in one inter-carrier exchange co= alition (trying to keep their name anonymous :) It's probably the one he's= referring to. It's a huge group, of course, but it's really just one "use= -case". Would it be worth it for the IETF to define the syntax+semantics+b= ehavior for DIAMETER AVPs (or whatever) for just their use-case, or could w= e just let them define whatever they need themselves for their members? I = ask because from a "creating a WG" perspective usually you want some idea t= he thing can be accomplished and its scope. The use-case he's referring to isn't crazy, it's just fairly unique I think= ; but I'm always amazed how crazy some of the information is people want to= make routing decisions on. I mean there's a reason some routing databases= use SIP itself as the database lookup protocol (ie, sending them the INVIT= E and getting back 3xx with routes) - it's because when we ask them what in= fo/fields they need, they say "ALL of them". -hadriel On Mar 19, 2012, at 9:07 PM, Lawrence Conroy wrote: > On 18 Mar 2012, at 19:52, Hadriel Kaplan wrote: >=20 >> On Mar 14, 2012, at 3:39 PM, Peterson, Jon wrote: >>> However, let's not sweep the obvious under the rug - we wouldn't be hav= ing this TeRQ discussion at all if we had a clear path to extend the ENUM a= nd DNS standards to handle the semantics that the use cases seem to require= . That doesn't mean that a DNS binding is off the table, just that it would= seem to face challenges. >>=20 >> It faces challenges because the IAB does not distinguish between the *Pr= otocol* of DNS, the *database structure* defined by DNS RFCs, and the *data= base instance* used for public Domain Name name resolution rooted in IANA r= oots. >=20 > To which I reply: >=20 > Hi Hadriel, Jon, Folks, > Hadriel, Richard, what are your expected deployment timescales? > IIUC, you need this already, you have a hammer that works, and whilst the= data structure is going to be different from ENUM, it surely will blend. >=20 > From experience of other sterling work on abstracted task & data models i= n the IETF, do you believe that TERQ (or any other rigorous analysis) could= complete, AND a protocol be selected (or designed from scratch), AND be im= plemented, AND the distributed data architecture be rolled out within the t= imescales that your customers are considering? >=20 > If it can't, I can't see how this discussion improves on silence. >=20 > Either you go ahead with the syntax definitions -- in TXT records (if the= way forth for any other RR is blocked) so no need for further standardisat= ion -- or you go ahead with the syntax definitions after a hiatus to consid= er what those should be, and into what protocol it should be rammed. You ge= t to choose. >=20 > all the best, > Lawrence >=20 >=20 >=20 >=20 >=20 From mphmmr@gmail.com Mon Mar 19 21:46:48 2012 Return-Path: <mphmmr@gmail.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6879321F84D3 for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 21:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-TCNzGmZLEX for <dispatch@ietfa.amsl.com>; Mon, 19 Mar 2012 21:46:44 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3BF021F8559 for <dispatch@ietf.org>; Mon, 19 Mar 2012 21:46:42 -0700 (PDT) Received: by lagj5 with SMTP id j5so6174188lag.31 for <dispatch@ietf.org>; Mon, 19 Mar 2012 21:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OSY8TNY/kAphvb131+i47DkZraMDG2SfqU0nOOH/5j0=; b=fOJ85cnagSX6yM/xPscG3Sw1FtD/jhRI9gco8TCd2vo2aPFbe7f4qYIbv+XBWSG9Yf WzhVXctdm2PAnBt7MGQzfMb3RT2itqFjGlWyB/cvLyyHEAMEZFh9V1JrEkFoDOGPbJEi R3kBf/ZgT+B92fP732atyqNqWfFHi/QVYm6WuB0vaewIe4t64qrIfDvKrE5jAvswVR1f HzFs0Sm5qT1PlnlcUZrDwj2wG1ikSThxLdGf2hvvimPhYwrfks7K7IDBR+l/T7Oyt8So KKuPc0bzLrir3Oe/+8YsunFNz+BIXHtHg07Y82wFYW1D0nl5s4ZahRNk5ruie7rho4MX kUjw== MIME-Version: 1.0 Received: by 10.152.131.66 with SMTP id ok2mr10443197lab.10.1332218801819; Mon, 19 Mar 2012 21:46:41 -0700 (PDT) Received: by 10.112.76.196 with HTTP; Mon, 19 Mar 2012 21:46:41 -0700 (PDT) In-Reply-To: <DCE5EA46-84EA-465B-B4E7-4A3F2D89CC3A@acmepacket.com> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> <BC0C7F75-07F0-4B54-8DC1-07C72425C396@acmepacket.com> <1638072E-7AA2-4834-949E-3F1A9AF997FF@insensate.co.uk> <DCE5EA46-84EA-465B-B4E7-4A3F2D89CC3A@acmepacket.com> Date: Tue, 20 Mar 2012 00:46:41 -0400 Message-ID: <CAA3wLqW4MW88o6Bgf5J=eQoWWEOfz=wr+XV+E63q7HHL6o1T=w@mail.gmail.com> From: Michael Hammer <mphmmr@gmail.com> To: Hadriel Kaplan <HKaplan@acmepacket.com> Content-Type: multipart/alternative; boundary=f46d042c6b83720f4704bba55c1e Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 20 Mar 2012 04:46:48 -0000 --f46d042c6b83720f4704bba55c1e Content-Type: text/plain; charset=ISO-8859-1 If you didn't need all of them, sounds like a candidate for historic status. :) Mike On Tue, Mar 20, 2012 at 12:33 AM, Hadriel Kaplan <HKaplan@acmepacket.com>wrote: > If I could answer your second question I'd be retired or earning money > with my crystal-ball services. I generally just use a magic-8-ball to make > decisions. :) > > The hard part with these things is it's just not as easy as deciding > "let's start from scratch". Most engineers like the opportunity to > re-factor code, but we also have to earn a living, and it's always easier > to extend existing code so we can make the next opportunity or deadline. > (this is not exactly news to anyone here, obviously, and plenty has been > written on the topic that extending existing protocols almost always beats > out new ones in the marketplace, but just makin' the point) But who knows > - sometimes these things get people excited and enable stuff that couldn't > be done before. > > So anyway... to answer your first question: in practice we use ENUM/DNS > quite a bit, but yes we end up putting stuff in TXT or NAPTRs that should > have their own record types for, and for query keys we usually just play > games with DNS domain names. It's ugly as hell in Wireshark, but it > generally works. :) It's not for every use-case, because it doesn't solve > world-hunger. It's meant to address the most common use-cases, with the > least-overhead/highest-performance. > > But beyond ENUM the only other real player/commonality for "database" > access is DIAMETER, afaict, since it's the other hammer for which > everything is a nail - at least for large service-providers. For > Enterprises its database protocol soup: from LDAP/ActiveDirectory to > Web-APIs to Excel files. > > It's definitely true that for real interop the actual > attributes/fields/syntax have to be spec'ed, since saying "DIAMETER" is > like saying "XML" - without the schema it's meaningless text. The hard > part's gonna be deciding what things are really so important and > wide-spread that they need to be spec'ed, vs. what can be ignored or left > up to some other SDO/association to define for themselves. > > Like for example Jon's carrier-of-record vs. routes authority use-case: > I've only ever seen that authority issue/need in one inter-carrier exchange > coalition (trying to keep their name anonymous :) It's probably the one > he's referring to. It's a huge group, of course, but it's really just one > "use-case". Would it be worth it for the IETF to define the > syntax+semantics+behavior for DIAMETER AVPs (or whatever) for just their > use-case, or could we just let them define whatever they need themselves > for their members? I ask because from a "creating a WG" perspective > usually you want some idea the thing can be accomplished and its scope. > > The use-case he's referring to isn't crazy, it's just fairly unique I > think; but I'm always amazed how crazy some of the information is people > want to make routing decisions on. I mean there's a reason some routing > databases use SIP itself as the database lookup protocol (ie, sending them > the INVITE and getting back 3xx with routes) - it's because when we ask > them what info/fields they need, they say "ALL of them". > > -hadriel > > > On Mar 19, 2012, at 9:07 PM, Lawrence Conroy wrote: > > > On 18 Mar 2012, at 19:52, Hadriel Kaplan wrote: > > > >> On Mar 14, 2012, at 3:39 PM, Peterson, Jon wrote: > >>> However, let's not sweep the obvious under the rug - we wouldn't be > having this TeRQ discussion at all if we had a clear path to extend the > ENUM and DNS standards to handle the semantics that the use cases seem to > require. That doesn't mean that a DNS binding is off the table, just that > it would seem to face challenges. > >> > >> It faces challenges because the IAB does not distinguish between the > *Protocol* of DNS, the *database structure* defined by DNS RFCs, and the > *database instance* used for public Domain Name name resolution rooted in > IANA roots. > > > > To which I reply: > > > > Hi Hadriel, Jon, Folks, > > Hadriel, Richard, what are your expected deployment timescales? > > IIUC, you need this already, you have a hammer that works, and whilst > the data structure is going to be different from ENUM, it surely will blend. > > > > From experience of other sterling work on abstracted task & data models > in the IETF, do you believe that TERQ (or any other rigorous analysis) > could complete, AND a protocol be selected (or designed from scratch), AND > be implemented, AND the distributed data architecture be rolled out within > the timescales that your customers are considering? > > > > If it can't, I can't see how this discussion improves on silence. > > > > Either you go ahead with the syntax definitions -- in TXT records (if > the way forth for any other RR is blocked) so no need for further > standardisation -- or you go ahead with the syntax definitions after a > hiatus to consider what those should be, and into what protocol it should > be rammed. You get to choose. > > > > all the best, > > Lawrence > > > > > > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --f46d042c6b83720f4704bba55c1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you didn't need all of them, sounds like a candidate for historic st= atus. =A0:)<div><br></div><div>Mike</div><div><br><br><div class=3D"gmail_q= uote">On Tue, Mar 20, 2012 at 12:33 AM, Hadriel Kaplan <span dir=3D"ltr">&l= t;<a href=3D"mailto:HKaplan@acmepacket.com">HKaplan@acmepacket.com</a>><= /span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">If I could answer your second question I'= ;d be retired or earning money with my crystal-ball services. =A0I generall= y just use a magic-8-ball to make decisions. :)<br> <br> The hard part with these things is it's just not as easy as deciding &q= uot;let's start from scratch". =A0Most engineers like the opportun= ity to re-factor code, but we also have to earn a living, and it's alwa= ys easier to extend existing code so we can make the next opportunity or de= adline. (this is not exactly news to anyone here, obviously, and plenty has= been written on the topic that extending existing protocols almost always = beats out new ones in the marketplace, but just makin' the point) =A0Bu= t who knows - sometimes these things get people excited and enable stuff th= at couldn't be done before.<br> <br> So anyway... to answer your first question: in practice we use ENUM/DNS qui= te a bit, but yes we end up putting stuff in TXT or NAPTRs that should have= their own record types for, and for query keys we usually just play games = with DNS domain names. =A0It's ugly as hell in Wireshark, but it genera= lly works. :) =A0It's not for every use-case, because it doesn't so= lve world-hunger. =A0It's meant to address the most common use-cases, w= ith the least-overhead/highest-performance.<br> <br> But beyond ENUM the only other real player/commonality for "database&q= uot; access is DIAMETER, afaict, since it's the other hammer for which = everything is a nail - at least for large service-providers. =A0For Enterpr= ises its database protocol soup: from LDAP/ActiveDirectory to Web-APIs to E= xcel files.<br> <br> It's definitely true that for real interop the actual attributes/fields= /syntax have to be spec'ed, since saying "DIAMETER" is like s= aying "XML" - without the schema it's meaningless text. =A0Th= e hard part's gonna be deciding what things are really so important and= wide-spread that they need to be spec'ed, vs. what can be ignored or l= eft up to some other SDO/association to define for themselves.<br> <br> Like for example Jon's carrier-of-record vs. routes authority use-case:= I've only ever seen that authority issue/need in one inter-carrier exc= hange coalition (trying to keep their name anonymous :) =A0It's probabl= y the one he's referring to. =A0It's a huge group, of course, but i= t's really just one "use-case". =A0Would it be worth it for t= he IETF to define the syntax+semantics+behavior for DIAMETER AVPs (or whate= ver) for just their use-case, or could we just let them define whatever the= y need themselves for their members? =A0I ask because from a "creating= a WG" perspective usually you want some idea the thing can be accompl= ished and its scope.<br> <br> The use-case he's referring to isn't crazy, it's just fairly un= ique I think; but I'm always amazed how crazy some of the information i= s people want to make routing decisions on. =A0I mean there's a reason = some routing databases use SIP itself as the database lookup protocol (ie, = sending them the INVITE and getting back 3xx with routes) - it's becaus= e when we ask them what info/fields they need, they say "ALL of them&q= uot;.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> -hadriel<br> </font></span><div class=3D"HOEnZb"><div class=3D"h5"><br> <br> On Mar 19, 2012, at 9:07 PM, Lawrence Conroy wrote:<br> <br> > On 18 Mar 2012, at 19:52, Hadriel Kaplan wrote:<br> ><br> >> On Mar 14, 2012, at 3:39 PM, Peterson, Jon wrote:<br> >>> However, let's not sweep the obvious under the rug - we wo= uldn't be having this TeRQ discussion at all if we had a clear path to = extend the ENUM and DNS standards to handle the semantics that the use case= s seem to require. That doesn't mean that a DNS binding is off the tabl= e, just that it would seem to face challenges.<br> >><br> >> It faces challenges because the IAB does not distinguish between t= he *Protocol* of DNS, the *database structure* defined by DNS RFCs, and the= *database instance* used for public Domain Name name resolution rooted in = IANA roots.<br> ><br> > To which I reply:<br> ><br> > Hi Hadriel, Jon, Folks,<br> > Hadriel, Richard, what are your expected deployment timescales?<br> > IIUC, you need this already, you have a hammer that works, and whilst = the data structure is going to be different from ENUM, it surely will blend= .<br> ><br> > From experience of other sterling work on abstracted task & data m= odels in the IETF, do you believe that TERQ (or any other rigorous analysis= ) could complete, AND a protocol be selected (or designed from scratch), AN= D be implemented, AND the distributed data architecture be rolled out withi= n the timescales that your customers are considering?<br> ><br> > If it can't, I can't see how this discussion improves on silen= ce.<br> ><br> > Either you go ahead with the syntax definitions -- in TXT records (if = the way forth for any other RR is blocked) so no need for further standardi= sation -- or you go ahead with the syntax definitions after a hiatus to con= sider what those should be, and into what protocol it should be rammed. You= get to choose.<br> ><br> > all the best,<br> > =A0Lawrence<br> ><br> ><br> ><br> ><br> ><br> <br> _______________________________________________<br> dispatch mailing list<br> <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/dispatch</a><br> </div></div></blockquote></div><br></div> --f46d042c6b83720f4704bba55c1e-- From lconroy@insensate.co.uk Tue Mar 20 04:30:05 2012 Return-Path: <lconroy@insensate.co.uk> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E20821F866C for <dispatch@ietfa.amsl.com>; Tue, 20 Mar 2012 04:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyqWV94riaPF for <dispatch@ietfa.amsl.com>; Tue, 20 Mar 2012 04:30:04 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 6A75021F8647 for <dispatch@ietf.org>; Tue, 20 Mar 2012 04:30:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 02C186095D2; Tue, 20 Mar 2012 11:30:03 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ1tNeiPnJCu; Tue, 20 Mar 2012 11:30:02 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 1CADD6095C7; Tue, 20 Mar 2012 11:30:02 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy <lconroy@insensate.co.uk> In-Reply-To: <CAA3wLqW4MW88o6Bgf5J=eQoWWEOfz=wr+XV+E63q7HHL6o1T=w@mail.gmail.com> Date: Tue, 20 Mar 2012 11:30:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <05F836CB-1B73-4E11-9EE8-1BFBA3165B10@insensate.co.uk> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> <BC0C7F75-07F0-4B54-8DC1-07C72425C396@acmepacket.com> <1638072E-7AA2-4834-949E-3F1A9AF997FF@insensate.co.uk> <DCE5EA46-84EA-465B-B4E7-4A3F2D89CC3A@acmepacket.com> <CAA3wLqW4MW88o6Bgf5J=eQoWWEOfz=wr+XV+E63q7HHL6o1T=w@mail.gmail.com> To: Michael Hammer <mphmmr@gmail.com> X-Mailer: Apple Mail (2.1084) Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 20 Mar 2012 11:30:05 -0000 Hi Mike, folks, Hmm ... like RFC2397? No one needs that, so we're told. They're only using that because they don't understand, or ... "she only = does it to annoy, because she knows it teases" Lawrence On 20 Mar 2012, at 04:46, Michael Hammer wrote: > If you didn't need all of them, sounds like a candidate for historic = status. :) >=20 > Mike <snip> From emil@sip-communicator.org Tue Mar 20 04:44:14 2012 Return-Path: <emil@sip-communicator.org> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811D021F8659 for <dispatch@ietfa.amsl.com>; Tue, 20 Mar 2012 04:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAMUuU5tVOAY for <dispatch@ietfa.amsl.com>; Tue, 20 Mar 2012 04:44:13 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE0221F8652 for <dispatch@ietf.org>; Tue, 20 Mar 2012 04:44:13 -0700 (PDT) Received: by werb10 with SMTP id b10so8229175wer.31 for <dispatch@ietf.org>; Tue, 20 Mar 2012 04:44:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=P3JCQ2zSwxr6NYh1gshaGrjGIeokQpjhsQ3IhED8oWQ=; b=A5EFjvEAwWZNojG+E9mYGDvS7iXrPDIf37JTlLLKj9jqWxVrO63QZJhv+Mj/T613/H xIovIbSC4c9m6msRRl0aPFh/7Rvqi36bU9VvRHqhbI2PFBumjy33B0lOQ7V9WlUhBh1P sEO14fXrJFL9+qZHBUUCC/6rAYAQGA4OAxPBQnrT0O65ym4VrC/QwPn+BR2i0wIPRJXd 3GzZkASWYeKs9a+McQBIytIclIJ1iUJWIjSvx0Ake+/z+v9Ro464kbgQvfW5UOEwu2eY 9MroNxuC423pEXIwGtuXWLvQB/KLZ7obMt+mysZxuWzsYRc6greJW5XoW45kJOcc56s+ 4vew== Received: by 10.180.107.132 with SMTP id hc4mr6785320wib.21.1332243852460; Tue, 20 Mar 2012 04:44:12 -0700 (PDT) Received: from pastropnet.u-strasbg.fr (pastropnet.u-strasbg.fr. [130.79.90.87]) by mx.google.com with ESMTPS id ff9sm33447507wib.2.2012.03.20.04.44.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 04:44:11 -0700 (PDT) Message-ID: <4F686D89.8020605@jitsi.org> Date: Tue, 20 Mar 2012 12:44:09 +0100 From: Emil Ivov <emcho@jitsi.org> Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Mary Barnes <mary.ietf.barnes@gmail.com> References: <CAHBDyN7MgxRUXmjaecn_RLDdNESDoy-Gcx66gAAphdgH5gQwMQ@mail.gmail.com> In-Reply-To: <CAHBDyN7MgxRUXmjaecn_RLDdNESDoy-Gcx66gAAphdgH5gQwMQ@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmQ7hJVgLLur4iGH1Guw6Xydv16e3lllhdTG+ympHGDh8aRut/YlMMP9evY57Umthxr8MSv X-Mailman-Approved-At: Tue, 20 Mar 2012 06:54:45 -0700 Cc: DISPATCH <dispatch@ietf.org> Subject: Re: [dispatch] Discussion (maybe) of combining XMPP and SIP in XMPP WG session on Wed. afternoon X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 20 Mar 2012 11:44:14 -0000 Thanks Mary! The idea behind the draft is to handle SIP and XMPP coexistance (mostly) at the client side: http://tools.ietf.org/html/draft-ivov-xmpp-cusax It's similar to what was attempted with SIXPAC, the main difference being that we don't want to standardize any new SIP headers or XMPP stanza and only reuse existing things such as Contact headers for JID discovery through SIP or VCARDs for SIP AOR retrieval from an XMPP roster. The document is based on several deployments that we've participated in and we think a BCP (or informational) form would suit it well. Needless to say all comments are most welcome. Cheers, Emil P.S. We actually hesitated whether to submit this in DISPATCH or XMPP and finally went for the latter. Of course, if people here also find it interested we'd be happy to discuss it. On 19.03.12 20:22, Mary Barnes wrote: > Folks might remember that we had a discussion of this topic (known as > SIXPAC) at IETF-76 during a Friday afternoon session. A separate mailing > list was setup, but no announcement made to DISPATCH. The topic was on > the agenda for XMPP at IETF-80 (opposite the exciting SPLICE session) > and it was decided at that meeting that there was not enough interest in > the topic: > http://www.ietf.org/proceedings/80/minutes/xmpp.txt > > There is a related item that may be discussed at the XMPP WG session > next week on Wednesday afternoon: > http://www.ietf.org/proceedings/83/agenda/agenda-83-xmpp.txt > > Folks that were interested in this topic may want to follow it on the > XMPP WG mailing list and attend the session. > > Regards, > Mary > DISPATCH WG co-chair -- http://jitsi.org From jbakker@rim.com Tue Mar 20 11:53:09 2012 Return-Path: <jbakker@rim.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EA921F862A; Tue, 20 Mar 2012 11:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.971 X-Spam-Level: X-Spam-Status: No, score=-4.971 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo5R2CONDurM; Tue, 20 Mar 2012 11:53:08 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6F21B21F8629; Tue, 20 Mar 2012 11:53:08 -0700 (PDT) X-AuditID: 0a412830-b7f8a6d000006354-41-4f68d2135fac Received: from XHT106CNC.rim.net (xht106cnc.rim.net [10.65.22.53]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 13.1A.25428.312D86F4; Tue, 20 Mar 2012 18:53:07 +0000 (GMT) Received: from XCT102ADS.rim.net (10.67.111.43) by XHT106CNC.rim.net (10.65.22.53) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 20 Mar 2012 14:53:07 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.01.0339.001; Tue, 20 Mar 2012 13:53:04 -0500 From: John-Luc Bakker <jbakker@rim.com> To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "Gonzalo.Camarillo@ericsson.com" <Gonzalo.Camarillo@ericsson.com> Thread-Topic: I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt Thread-Index: AQHMseb4bKLd4Us8uUmMrgCGNjzffJZ0JATA Date: Tue, 20 Mar 2012 18:53:03 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> In-Reply-To: <4EDA6648.2040109@alum.mit.edu> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.252] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsXC5Shmqit8KcPfYN1UUYulkxawWmxavpLJ YsWGA6wWfxpmsDqwePx9/4HJ49fXq2weS5b8ZApgjmpgtEnMy8svSSxJVUhJLU62VfJJTU/M UQgoyixLTK5UcMksTs5JzMxNLVJSyEyxVTJRUijISUxOzU3NK7FVSiwoSM1LUbLjUsAANkBl mXkKqXnJ+SmZeem2Sp7B/roWFqaWuoZKdrpIIOEfd8a3va9ZCjp0Kt50/2RqYLyn3MXIySEh YCKxcP1ENghbTOLCvfVANheHkEAPk8Sk90eYIZyljBLzN25hgnA2M0pMv7yRGaSFTUBdYuuK 7WC2iECuRNOFj4wgNrOAu8T/OW/A4sICgRKN3zazQtQESVxf/R6q3kii6dcFdhCbRUBVYtrs t0wgNq+Am8S6t21gcSGBJIkNjR1gcU4BHYmrD5+C9TIKyErsPnudCWKXuMStJ/OZIF4QkFiy 5zwzhC0q8fLxP6C9HEC2osTy7VIQ5ToSC3Z/YoOwtSWWLXzNDLFWUOLkzCcsEGtlJFrbdrFN YJSYhWTDLCTts5C0z0LSvoCRZRWjYG5GsYGZYXJesl5RZq5eXmrJJkZw2tEw2ME4Ya/WIUYB DkYlHt6Qgxn+QqyJZcWVuYcYJTiYlUR4s1YBhXhTEiurUovy44tKc1KLDzFaAANoIrMUd3I+ MCXmlcQbGxigcJTEeZes1PIXEkgHprDs1NSC1CKYViYOTqkGxiua0zO4K+fOnnfr1ZwLv18z GlxiyTN/eOTFfJ3eeo8TBxPEHIvKp0qpmmaeiPlsN8P48ZWNv+8UCNhGF5nVfmddsjvS4ozr zKtxigX7ornayxYEZ96tS41inbbB6P1X3ai5wt2li0/9md01S1P1dM/f1WerQstkZc5LNVa0 X4g59ENsrcNpRyWW4oxEQy3mouJEAIKryN9UAwAA Cc: "dispatch@ietf.org" <dispatch@ietf.org>, sipping <sipping@ietf.org> Subject: Re: [dispatch] I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 20 Mar 2012 18:53:09 -0000 Hi, Thanks, Paul for reviewing the draft. Appologies for having delayed this response. Let me address first the question about this being a SIPPING draft: I intend= to ask Gonzallo to sponsor this draft. To collect any further comments and= ensure visibility (sine the sipping list is obsolete), I have copied the DI= SPATCH list. See also inline with <JL>. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Saturday, December 03, 2011 12:11 PM To: John-Luc Bakker Cc: sipping Subject: Re: I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.= txt I'm commenting on this on the (now obsolete) sipping list because this has sipping in its name. This may not be the best place. I suppose an alternative is rai. ISTM that there are three degrees of freedom here for identifying how to process these bodies: - content-disposition - content-type - the actual content of the body Of these, the content-disposition is the most heavy weight in terms of mechanism, while the actual content of the body is the least heavy-weight. So, I wonder why you have chosen to use one content-type, that seems to already contain distinct representations for the differing behaviors of interest, and yet use distinct content-dispositions. I think you could use a single content-disposition and get the same effect. I guess multiple content-dispositions might make sense if they are processed by different entities, so that only the intended entities need decode the body. <JL> The reason for having two content dispositions is because there are dif= ferent behaviors for the same content-type when received by different entiti= es. <JL> There are two different entities that apply a different behavior when r= eceiving the body, say behavior A and behavior B. However, XML elements pres= ent in the body trigger behavior A (in the abstract of the draft, behavior (= 2)) by entity A and if not present, no further behavior by entity A is speci= fied in this draft. Other XML elements present in the body trigger one of a= set of behaviors B (in the abstract of the draft, behaviors (1) and (3)) by= entity B and if not present, no further behavior by entity B is specified i= n this draft. It would also make sense if the same identical body representation was processed differently based on the content-disposition. <JL> The bodies triggering the different behaviors are indeed not identical.= <JL> However, the content-dispositions are processed by different entities,= which is a reason for proposing these content-disposition values. But I don't think either of those is the case here. So I would find it helpf= ul if this draft explained why it chooses to use multiple content-dispositio= ns. <JL> The draft illustrates that, in IMS, different entities receive bodies w= ith the content-type, and apply different behaviors. The draft further sugge= sts that the applicability of these values may be limited to IMS. Do you see= a need for a general discussion of this approach since the applicability is= limited to IMS? I also think it would be useful to say something about how you expect the handling parameter to be used with these dispositions. If handling=3Drequired (the default) is used, then any UA that gets this must fail the request unless it is able to handle the body. If handling=3Doptional is specified, then that need not be so. <JL> The handling parameter is mentioned in RFC 3261 and this draft refers t= o that RFC. RFC 3261 refers to RFC 3204. This draft does not change the beha= vior and interpretation of the parameter and its values. It should not be ne= cessary to repeat what has already been documented in RFC 3261. Do you see d= ifferent behavior that goes beyond what has been documented? Thanks, Paul On 12/3/11 5:08 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > Title : Specification of 3GPP IM CN Subsystem XML body handling > Author(s) : John-Luc Bakker > Filename : draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt > Pages : 7 > Date : 2011-12-02 > > This document registers new disposition-types for the Content- > Disposition header field that apply to the application/3gpp-ims+xml > body used by 3GPP. The applicability of these content-disposition > values are limited to 3GPP IMS. The application/3gpp-ims+xml body > has the following three distinct uses: (1) for redirecting the > emergency session to use a different domain (e.g. using a Circuit > Switched call), (2) for delivering user profile specific information > from the SIP registrar to an Application Server, and (3) for causing > a UAC to attempt to re-register with the IMS. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body= -handling-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-= handling-07.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From jon.peterson@neustar.biz Tue Mar 20 13:16:17 2012 Return-Path: <jon.peterson@neustar.biz> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3E421F853B for <dispatch@ietfa.amsl.com>; Tue, 20 Mar 2012 13:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock17=0.64, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzKcFFF0nB3i for <dispatch@ietfa.amsl.com>; Tue, 20 Mar 2012 13:16:16 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B03A121F8533 for <dispatch@ietf.org>; Tue, 20 Mar 2012 13:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1332274612; x=1647610702; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=a8tYJGwlbcbau9juLBW77 z+GdI6gN9etCFkVw9R6UII=; b=cHTBqNlIXJh00x4Ka0Ncrs8qRei4Ay34UjYSg ixzJuQFNcepjUb4WskW7VDNz1JbmCKZER8NomYJ3lc3p6+V8A== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.6512034; Tue, 20 Mar 2012 16:16:51 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 20 Mar 2012 16:16:12 -0400 From: "Peterson, Jon" <jon.peterson@neustar.biz> To: Lawrence Conroy <lconroy@insensate.co.uk>, Michael Hammer <mphmmr@gmail.com> Date: Tue, 20 Mar 2012 16:16:11 -0400 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: Ac0GjNCCT06mIiI7Qj+xLHYDeFpZpwAQwQYE Message-ID: <55A5A9A87506CB4BA580BF9D531957DA239D63CD@STNTEXCH01.cis.neustar.com> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> <BC0C7F75-07F0-4B54-8DC1-07C72425C396@acmepacket.com> <1638072E-7AA2-4834-949E-3F1A9AF997FF@insensate.co.uk> <DCE5EA46-84EA-465B-B4E7-4A3F2D89CC3A@acmepacket.com> <CAA3wLqW4MW88o6Bgf5J=eQoWWEOfz=wr+XV+E63q7HHL6o1T=w@mail.gmail.com>, <05F836CB-1B73-4E11-9EE8-1BFBA3165B10@insensate.co.uk> In-Reply-To: <05F836CB-1B73-4E11-9EE8-1BFBA3165B10@insensate.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: KGS0GIPszrkZn2yt0NvjXg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 20 Mar 2012 20:16:17 -0000 Historic? Hmm. Probably not. I hear of plenty of things people do out in th= e field with RFC2397. I remember in the early days of Apple's iOS, people w= ere encoding PDFs (even multi-megabyte ones) as data URLs in order to pass = them to Safari, since there weren't any PDF readers yet and the iOS URL han= dler automatically would hand the whole shebang over to Safari. The data UR= L serves a useful purpose as a hack when your syntax requires a URI but you= don't actually want to indicate or locate a resource, you just want to giv= e it as a literal. That much said, I understand iOS eventually defined som= e better ways to pass objects between its applications; the data URL hack, = while useful, didn't end up being the standard there. I guess I feel simila= rly about the data URL forming the basis for a standard way to give a liter= al, rather than indicating or locating a resource, in a NAPTR record. If we= want a way to give literals in the DNS, we should adopt something with a c= risp enough syntax and semantics that interoperability will be more than ju= st a pipe dream. It is possible that data URLs or derivatives thereof could= play a role in that sort of solution, but I suspect that there are superio= r alternatives. Anyway, I do share your concerns about timeliness and relevance. These are = always concerns whenever we consider a large undertaking. The good news abo= ut timeliness is that, as Rich Shockey reminds us, RFC6116 is deployed, and= in its deployments it is serving a large market, with a mix of standard an= d non-standard capabilities. Hopefully that status quo can buy us enough ti= me to take a step back. Relevance-wise, I do think we have a good community= in the IETF that is knowledgeable about the needs of the marketplace and w= ould be positioned to jump-start new standards in this space if we manage t= o come up with something good. We have a reasonable chance of that, provide= d that when it comes time to do the work, we can avoid rehashing the E2MD a= rguments (as we are a bit in this thread, I fear) and instead focus on what= the semantics of telephone-related queries and responses really should loo= k like. Jon Peterson NeuStar, Inc. ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of La= wrence Conroy [lconroy@insensate.co.uk] Sent: Tuesday, March 20, 2012 4:30 AM To: Michael Hammer Cc: dispatch@ietf.org list Subject: Re: [dispatch] New Proposal for Telephone-Related Queries Hi Mike, folks, Hmm ... like RFC2397? No one needs that, so we're told. They're only using that because they don't understand, or ... "she only doe= s it to annoy, because she knows it teases" Lawrence On 20 Mar 2012, at 04:46, Michael Hammer wrote: > If you didn't need all of them, sounds like a candidate for historic stat= us. :) > > Mike <snip> _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Wed Mar 21 19:30:13 2012 Return-Path: <paulej@packetizer.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2D021E8032 for <dispatch@ietfa.amsl.com>; Wed, 21 Mar 2012 19:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0mxYx2f7ZTN for <dispatch@ietfa.amsl.com>; Wed, 21 Mar 2012 19:30:13 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E40CC21E802C for <dispatch@ietf.org>; Wed, 21 Mar 2012 19:30:12 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2M2UAXA008395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Mar 2012 22:30:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332383411; bh=9mhblgkFxx0+eYcMZjrid7jHrYaA7005FbZfFPaXF+k=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xbsa9eeTradeOepvomx+tKYYNdbOBJl6CbeqF3jjytyb5S5NPsp4ONWJSAb0hEeiB RE8046aiNosX1wsMuXfAQJp1DI4HEh5jW29jSrVNg4LWX8e4L9pydHyvLzq9jsjRKW jnrWPNTVPEpaqvHfEzSRKAsZip5CD95whltCgXKI= From: "Paul E. Jones" <paulej@packetizer.com> To: "'Emil Ivov'" <emcho@jitsi.org>, "'Mary Barnes'" <mary.ietf.barnes@gmail.com> References: <CAHBDyN7MgxRUXmjaecn_RLDdNESDoy-Gcx66gAAphdgH5gQwMQ@mail.gmail.com> <4F686D89.8020605@jitsi.org> In-Reply-To: <4F686D89.8020605@jitsi.org> Date: Wed, 21 Mar 2012 22:30:15 -0400 Message-ID: <014101cd07d3$b77674e0$26635ea0$@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: AQFttPl9Vo1Z14TmNDgsT8SjlMsqPwJM14xMlyHS1sA= Content-Language: en-us Cc: 'DISPATCH' <dispatch@ietf.org> Subject: Re: [dispatch] Discussion (maybe) of combining XMPP and SIP in XMPP WG session on Wed. afternoon X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 22 Mar 2012 02:30:13 -0000 Emil, et al, I'm glad you're pushing this ahead. Having a dialog with folks about this sort of thing outside the IETF, I posted this the other day: http://www.packetizer.com/people/paulej/blog/30 It's just my ramblings, but basically: * We need a means of sharing address information for alternative protocols * We need to share presence information related to activities of separate applications In the end, I think this means that SIP devices need to implement a minimal amount of XMPP in order to convey application state information for the benefit of the XMPP clients. Of course, the XMPP client would need to do something similar for the benefit of the voice/video application. What I have in my mind is that on my IP phone or on my IM client, I can see the activity of the opposite device, allowing me to immediately initiate a new mode of communication and without having to enter the opposite party's address information. Paul > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: Tuesday, March 20, 2012 7:44 AM > To: Mary Barnes > Cc: DISPATCH > Subject: Re: [dispatch] Discussion (maybe) of combining XMPP and SIP in > XMPP WG session on Wed. afternoon > > Thanks Mary! > > The idea behind the draft is to handle SIP and XMPP coexistance (mostly) > at the client side: > > http://tools.ietf.org/html/draft-ivov-xmpp-cusax > > It's similar to what was attempted with SIXPAC, the main difference being > that we don't want to standardize any new SIP headers or XMPP stanza and > only reuse existing things such as Contact headers for JID discovery > through SIP or VCARDs for SIP AOR retrieval from an XMPP roster. The > document is based on several deployments that we've participated in and we > think a BCP (or informational) form would suit it well. > > Needless to say all comments are most welcome. > > Cheers, > Emil > > P.S. We actually hesitated whether to submit this in DISPATCH or XMPP and > finally went for the latter. Of course, if people here also find it > interested we'd be happy to discuss it. > > On 19.03.12 20:22, Mary Barnes wrote: > > Folks might remember that we had a discussion of this topic (known as > > SIXPAC) at IETF-76 during a Friday afternoon session. A separate > > mailing list was setup, but no announcement made to DISPATCH. The > > topic was on the agenda for XMPP at IETF-80 (opposite the exciting > > SPLICE session) and it was decided at that meeting that there was not > > enough interest in the topic: > > http://www.ietf.org/proceedings/80/minutes/xmpp.txt > > > > There is a related item that may be discussed at the XMPP WG session > > next week on Wednesday afternoon: > > http://www.ietf.org/proceedings/83/agenda/agenda-83-xmpp.txt > > > > Folks that were interested in this topic may want to follow it on the > > XMPP WG mailing list and attend the session. > > > > Regards, > > Mary > > DISPATCH WG co-chair > > -- > http://jitsi.org > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From kpfleming@digium.com Thu Mar 22 13:38:26 2012 Return-Path: <kpfleming@digium.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC78E21F84F9 for <dispatch@ietfa.amsl.com>; Thu, 22 Mar 2012 13:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.247 X-Spam-Level: X-Spam-Status: No, score=-106.247 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0dGatehLGHv for <dispatch@ietfa.amsl.com>; Thu, 22 Mar 2012 13:38:26 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3180B21F84EF for <dispatch@ietf.org>; Thu, 22 Mar 2012 13:38:26 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from <kpfleming@digium.com>) id 1SAom9-0003TC-Pz for dispatch@ietf.org; Thu, 22 Mar 2012 15:38:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id C3EEED8012 for <dispatch@ietf.org>; Thu, 22 Mar 2012 15:38: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 jim8QisYAGV6 for <dispatch@ietf.org>; Thu, 22 Mar 2012 15:38:25 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 74D3BD8011 for <dispatch@ietf.org>; Thu, 22 Mar 2012 15:38:25 -0500 (CDT) Message-ID: <4F6B8DC1.4070802@digium.com> Date: Thu, 22 Mar 2012 15:38:25 -0500 From: "Kevin P. Fleming" <kpfleming@digium.com> Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <CB7F8CA4.1DB88%glavers@cisco.com> <4F5A6C5D.3030606@alum.mit.edu> <4F5FCB21.2060301@digium.com> <4F5FE542.8050709@alum.mit.edu> <4F609C1C.7050400@digium.com>, <4F60A739.4080605@alum.mit.edu> <CD5674C3CD99574EBA7432465FC13C1B22726A0967@DC-US1MBEX4.global.avaya.com>, <4F60C2BC.6030605@alum.mit.edu> <CD5674C3CD99574EBA7432465FC13C1B22726A096C@DC-US1MBEX4.global.avaya.com> In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A096C@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 22 Mar 2012 20:38:27 -0000 On 03/14/2012 01:42 PM, Worley, Dale R (Dale) wrote: >>> It's one of the few situations where *capability* is highly predictive >>> of the communication request that will be made in the near future (but >>> is not indicated at present). Perhaps for "truth in advertising" the >>> feature tag should be "+sip.going-to-ask-for-T38-soon". ;-) >> >> For dedicated fax devices its also perfectly reasonable to include >> callerprefs requesting fax capability. > > Yeah. I thought more about it, and it seems that a better scheme > would be: > > A sip.fax media feature tag to indicate the device is *capable* of > doing fax. > > Then a caller who *intends* do to fax on this call uses > "Accept-Contact: *;sip.fax" to select only fax-capable destinations. > (If I understand the syntax and semantics of Accept-Contact > correctly.) Slight correction: if the UAC is mandating that the UAS be FAX-capable, it would use: Accept-Contact: *;require;+sip.fax > > A carrier can key off of this Accept-Contact to know to assign a > fax-capable trunk line for the call. Indeed they could. They wouldn't really have to do full RFC 3841 processing if they didn't wish to; their proxies/UASes could have 'special knowledge' of the sip.fax feature tag and not require that the downstream elements explicitly indicate support for this feature (it would be indicated via some administrative means instead). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From HKaplan@acmepacket.com Fri Mar 23 07:43:52 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6589821F845A for <dispatch@ietfa.amsl.com>; Fri, 23 Mar 2012 07:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[AWL=-1.148, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmMMsBDJ8Nhl for <dispatch@ietfa.amsl.com>; Fri, 23 Mar 2012 07:43:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5D721F846A for <dispatch@ietf.org>; Fri, 23 Mar 2012 07:43:51 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 23 Mar 2012 10:43:49 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Fri, 23 Mar 2012 10:43:49 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: Dean Willis <dean.willis@softarmor.com> Thread-Topic: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: AQHNCQNb9k0fNKzaNEm2oK3gFgW45A== Date: Fri, 23 Mar 2012 14:43:49 +0000 Message-ID: <1E45CD19-102D-4F21-98A4-C96982919B7E@acmepacket.com> References: <DBF2B0884D5308458C2C5521C4F77132F98820@xmb-sjc-236.amer.cisco.com> <85970508-0C5F-49FD-A98B-D91B4EA310FF@iii.ca> <DBF2B0884D5308458C2C5521C4F77132F98E50@xmb-sjc-236.amer.cisco.com> <4F57BCBA.3020206@nostrum.com> <DBF2B0884D5308458C2C5521C4F77132F98F02@xmb-sjc-236.amer.cisco.com> <CD5674C3CD99574EBA7432465FC13C1B22726A093F@DC-US1MBEX4.global.avaya.com> <035501cd00b5$5fcddd20$1f699760$@packetizer.com> <3061B8A6-8B3A-41B4-A741-61F7C2C85A45@nostrum.com>, <03d001cd00e9$efa8f5e0$cefae1a0$@packetizer.com> <CD5674C3CD99574EBA7432465FC13C1B22726A0958@DC-US1MBEX4.global.avaya.com> <233B4045-E10D-423B-A4FD-31EEEA2ED253@softarmor.com> In-Reply-To: <233B4045-E10D-423B-A4FD-31EEEA2ED253@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: <78B36602628FFC4B84BFE651F615BAD6@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Mar 2012 14:43:52 -0000 On Mar 14, 2012, at 3:38 PM, Dean Willis wrote: > I was reading a good book last night on my Nook. It was immersive. But th= is morning, on the same Nook and and the same book-app, the technical tutor= ial I was reading was not so immersive. >=20 > How could this be, if "immersive" is a property of the device? Are we tal= king about some kind of physical thing here like "is 3d", "has 180 degree f= ield-of-view", or a subjective concept like a PG-13 rating? >=20 > Otherwise said, one man's immersion is the sprinkling of a few drops on t= he next man. But neither is as physiologically distinct as circumcision.=20 That is the funniest email line I've read in a long time. =20 I was skimming the dispatch list to see what I've missed for the past coupl= e months=85 I did not expect to become drenched in a baptism of humor of th= at particular nature. Circumcision?!? You're a real cut above the rest. = ;) -hadriel From ietf@meetecho.com Mon Mar 26 09:30:54 2012 Return-Path: <ietf@meetecho.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03C121F8543 for <dispatch@ietfa.amsl.com>; Mon, 26 Mar 2012 09:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+hBDNu1mu86 for <dispatch@ietfa.amsl.com>; Mon, 26 Mar 2012 09:30:54 -0700 (PDT) Received: from smtplq02.aruba.it (smtplqs-out23.aruba.it [62.149.158.63]) by ietfa.amsl.com (Postfix) with SMTP id 7E2A321F8501 for <dispatch@ietf.org>; Mon, 26 Mar 2012 09:30:53 -0700 (PDT) Received: (qmail 13357 invoked by uid 89); 26 Mar 2012 16:30:50 -0000 Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq02.aruba.it with SMTP; 26 Mar 2012 16:30:50 -0000 Received: (qmail 8760 invoked by uid 89); 26 Mar 2012 16:30:50 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp4.ad.aruba.it with SMTP; 26 Mar 2012 16:30:50 -0000 Message-ID: <4F7099B9.5050106@meetecho.com> Date: Mon, 26 Mar 2012 18:30:49 +0200 From: Meetecho IETF support <ietf@meetecho.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp4.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho <team@meetecho.com> Subject: [dispatch] Meetecho support for DISPATCH WG session X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 26 Mar 2012 16:30:54 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Tuesday's DISPATCH WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf83/dispatch The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf83/tutorials Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From sohel_khan@cable.comcast.com Tue Mar 27 04:59:57 2012 Return-Path: <sohel_khan@cable.comcast.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B925221F89CA for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 04:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkND1WcEU3nE for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 04:59:57 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA3821F8864 for <dispatch@ietf.org>; Tue, 27 Mar 2012 04:59:54 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.11013575; Tue, 27 Mar 2012 05:47:36 -0600 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 07:59:50 -0400 From: "Khan, Sohel" <Sohel_Khan@cable.comcast.com> To: "dispatch@ietf.org" <dispatch@ietf.org> Thread-Topic: B2BUA charter/straw Thread-Index: AQHNDBDB4L/ysvgDpU2hyCI8tX9QpA== Date: Tue, 27 Mar 2012 11:59:49 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 11:59:57 -0000 Currently, a proxy can be statefull or stateless. The advantage of stateles= s is to have the proxy out of the path of a SIP call after initial session = messages. As I understand, currently deployed B2BUAs are " rigidly statefu= ll". They remain in the call path until the end of the session and all the = messages traverse through B2BUA. Can we convert the B2BUA to be a pseudo-= statefull--i.e., for certain SIP messages, the B2BUA is statefull for some = messages and for other messages of the same call, the B2BUA is stateless? = =0A= Can we add this in the current B2BUA charter initiative?=0A= =0A= Sohel=0A= From pravindran@sonusnet.com Tue Mar 27 05:19:15 2012 Return-Path: <pravindran@sonusnet.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09AC21F8822 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 05:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.136 X-Spam-Level: X-Spam-Status: No, score=-5.136 tagged_above=-999 required=5 tests=[AWL=1.463, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiirPYa1lJcs for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 05:19:15 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id CD83321F87D0 for <dispatch@ietf.org>; Tue, 27 Mar 2012 05:19:14 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT3GwO6LkCOkJeg7lrbmd2erqkaRawDEO@postini.com; Tue, 27 Mar 2012 05:19:14 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 27 Mar 2012 08:19:25 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 17:49:01 +0530 From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com> To: "Khan, Sohel" <Sohel_Khan@cable.comcast.com>, "dispatch@ietf.org" <dispatch@ietf.org> Thread-Topic: B2BUA charter/straw Thread-Index: AQHNDBDB4L/ysvgDpU2hyCI8tX9QpJZ+Dw6A Date: Tue, 27 Mar 2012 12:19:21 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E220D4B@inba-mail01.sonusnet.com> References: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com> In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 12:19:15 -0000 Sohel, Could you please explain the advantage of those new B2BUA over stateful pro= xy. Thanks Partha >-----Original Message----- >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >Behalf Of Khan, Sohel >Sent: Tuesday, March 27, 2012 5:30 PM >To: dispatch@ietf.org >Subject: [dispatch] B2BUA charter/straw > >Currently, a proxy can be statefull or stateless. The advantage of >stateless is to have the proxy out of the path of a SIP call after >initial session messages. As I understand, currently deployed B2BUAs >are " rigidly statefull". They remain in the call path until the end of >the session and all the messages traverse through B2BUA. Can we >convert the B2BUA to be a pseudo-statefull--i.e., for certain SIP >messages, the B2BUA is statefull for some messages and for other >messages of the same call, the B2BUA is stateless? >Can we add this in the current B2BUA charter initiative? > >Sohel >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From mperumal@cisco.com Tue Mar 27 05:22:48 2012 Return-Path: <mperumal@cisco.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFC021F86F6 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 05:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.711 X-Spam-Level: X-Spam-Status: No, score=-9.711 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEtz5K0fGivS for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 05:22:46 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3D821F8620 for <dispatch@ietf.org>; Tue, 27 Mar 2012 05:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=5012; q=dns/txt; s=iport; t=1332850963; x=1334060563; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=6vtLVRHRFMnYYVbtJfPljrNy2Xk1J49MZTLhS1MCbbQ=; b=XWTmrNarOna9HIyogKPhtF1A3B9/pnUePzUfLZZwhDj2OpeOT0U4EeD9 Xfbfi73w9eIBeS1kSRmTD3ZTSGEi/aYl0LpvZGVlc0T7qoohElYHCiFMS ngGhl3CXs2Hz79CV7ijxeC1StDQo06DzeCOrt5s4ci/ibxS4CwY7d8FJn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EACiwcU9Io8UY/2dsb2JhbABEuUiCCQEBAQQBAQEPAR0KNBcEAgEIDgMBAwEBCwYXAQYBJh8DBggCBAEKCAgah2gLmk6fDgSQLGMEiFabUIFogm8 X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="8716341" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 27 Mar 2012 12:22:41 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2RCMfmB009857; Tue, 27 Mar 2012 12:22:41 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, 27 Mar 2012 17:52:41 +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, 27 Mar 2012 17:52:38 +0530 Message-ID: <1D062974A4845E4D8A343C653804920207F1DDF2@XMB-BGL-414.cisco.com> In-Reply-To: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] STRAW Charter Proposal Thread-Index: AQHM2mf5LnZ1j84CGUegN4A8YOcfr5Z+bzBQ References: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> To: "Hadriel Kaplan" <HKaplan@acmepacket.com>, <dispatch@ietf.org> X-OriginalArrivalTime: 27 Mar 2012 12:22:41.0163 (UTC) FILETIME=[4E07DDB0:01CD0C14] Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 12:22:48 -0000 I think RTCP has similar issues with B2BUAs and getting RTCP/SRTCP working end-to-end across B2BUAs, in particular those B2BUAs that perform transcoding/transrating of media streams, is also important. I would suggest adding a deliverable for RTCP/SRTCP: 6) A document defining the requirements for B2BUAs to support RTCP/SRTCP end-to-end. Muthu |-----Original Message----- |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan |Sent: Tuesday, January 24, 2012 8:16 AM |To: dispatch@ietf.org list |Subject: [dispatch] STRAW Charter Proposal | |Howdy, |As instructed by DISPATCH chairs, I am re-posting the STRAW Charter Proposal, as a topic for the Paris |meeting. |The proposed charter is as follows: | |Description of STRAW Working Group |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |Name: Sip Traversal Required for Applications to Work (STRAW) | |Problem Statement: |Within the context of the SIP protocol and architecture, a Back-to-Back User Agent (B2BUA) is any SIP |device in the logical path between two User Agents performing a role beyond that of a Proxy as defined |in RFC 3261. The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order to |terminate dead sessions by generating BYEs; or it may be a 3PCC-style agent only modifying SDP; or it |may be a Session Border Controller performing such functions as in RFC 5853; or it may be an |Enterprise PBX terminating REFERs and such; or it may be a complete UAS and UAC implementation with a |PRI loopback in-between. | |In its most extreme form, the scope of the SIP protocol ends at the UAS of the B2BUA, and a new SIP |protocol scope begins on its UAC side. In practice, however, users expect some SIP protocol aspects |to go beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA |was not an end unto itself; this is similar to the expectation that emails work when they cross from |POP and IMAP to/from SMTP. | |It is impossible to normatively define all the behaviors of B2BUAs in general, or even subsets of them |such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying functions for purposes which may be |unique to their environment, unique to their architecture, or unique to the wishes of their |administrator. Instead of defining all things a given type of B2BUA must do, a more practical |objective would be to define what very few things any B2BUA must do to make a specific SIP mechanism |work, and let the market decide whether to do those things. | |The name of this working group reflects that practical objective: if there were a thin straw between |the SIP UAS and UAC of a B2BUA, what must be passed through that straw and used on each side. Or |viewed another way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and |if we could extend ISDN, what information would we carry in ISDN across the PRI for a specific SIP |mechanism to work end-to-end. | |For example, the WG could produce a document which specifies that the Max-Forwards header field value |should be copied and decremented across the B2BUA, if the B2BUA wishes to prevent loops. |Administrators could then tell their B2BUA vendors to comply with the document, if the administrator |so wishes. | |Objectives: |The objectives of the STRAW Working Group are to publish normative documents which define which SIP |header fields, parameters, MIME bodies, body content fields/information, or media-plane |characteristics are required to traverse between the User Agent "sides" of a B2BUA for specific |functions to work. | |Deliverables would indicate which types of B2BUAs would apply or not. For example, a document |defining the requirements for end-to-end DTLS-SRTP would not apply to B2BUAs which terminate media, |such as transcoders or recorders. | |The intention of this WG is to document such requirements in separate documents, per SIP or media |function, instead of as one document for all functions. That will both reduce the time to |publication, as well a provide B2BUA administrators and manufacturers with simple comply/no-comply |criteria. | | |Initial Deliverables: |1) A taxonomy document defining role-types of B2BUAs, as a reference for other deliverables. |2) A document defining the requirements for B2BUAs with respect to loop detection/prevention. |3) A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback |test calls. |4) A document defining the requirements for B2BUAs to support DTLS-SRTP (RFC 5764) end-to-end. |5) A document defining the requirements for B2BUAs to support STUN connectivity checks end-to-end. | | |_______________________________________________ |dispatch mailing list |dispatch@ietf.org |https://www.ietf.org/mailman/listinfo/dispatch From sohel_khan@cable.comcast.com Tue Mar 27 05:26:09 2012 Return-Path: <sohel_khan@cable.comcast.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68BD21F88FA for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 05:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.993 X-Spam-Level: X-Spam-Status: No, score=-101.993 tagged_above=-999 required=5 tests=[AWL=-1.096, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RHi6E2QCvvN for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 05:26:08 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7A63521F88F0 for <dispatch@ietf.org>; Tue, 27 Mar 2012 05:26:06 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.7276694; Tue, 27 Mar 2012 08:19:57 -0400 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 08:26:01 -0400 From: "Khan, Sohel" <Sohel_Khan@cable.comcast.com> To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>, "dispatch@ietf.org" <dispatch@ietf.org> Thread-Topic: B2BUA charter/straw Thread-Index: AQHNDBDB4L/ysvgDpU2hyCI8tX9QpJZ+Dw6AgAAA7Ms= Date: Tue, 27 Mar 2012 12:26:00 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF5A92D20D@PACDCEXMB02.cable.comcast.com> References: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D4B@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E220D4B@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 12:26:09 -0000 Thanks Partha.=0A= We want to take the advantage of topology hiding of the B2BUA; however, we = want to save the B2BUA's implementation package (i.e., SBC) from excessive = chatting to improve processing. In addition, for the persistent connection = for incoming messages, we would like to pass the incoming new session messa= ges bypassing the B2BUA.=0A= =0A= =0A= ________________________________________=0A= From: Ravindran, Parthasarathi [pravindran@sonusnet.com]=0A= Sent: Tuesday, March 27, 2012 6:19 AM=0A= To: Khan, Sohel; dispatch@ietf.org=0A= Subject: RE: B2BUA charter/straw=0A= =0A= Sohel,=0A= =0A= Could you please explain the advantage of those new B2BUA over stateful pro= xy.=0A= =0A= Thanks=0A= Partha=0A= =0A= >-----Original Message-----=0A= >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=0A= >Behalf Of Khan, Sohel=0A= >Sent: Tuesday, March 27, 2012 5:30 PM=0A= >To: dispatch@ietf.org=0A= >Subject: [dispatch] B2BUA charter/straw=0A= >=0A= >Currently, a proxy can be statefull or stateless. The advantage of=0A= >stateless is to have the proxy out of the path of a SIP call after=0A= >initial session messages. As I understand, currently deployed B2BUAs=0A= >are " rigidly statefull". They remain in the call path until the end of=0A= >the session and all the messages traverse through B2BUA. Can we=0A= >convert the B2BUA to be a pseudo-statefull--i.e., for certain SIP=0A= >messages, the B2BUA is statefull for some messages and for other=0A= >messages of the same call, the B2BUA is stateless?=0A= >Can we add this in the current B2BUA charter initiative?=0A= >=0A= >Sohel=0A= >_______________________________________________=0A= >dispatch mailing list=0A= >dispatch@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/dispatch=0A= From HKaplan@acmepacket.com Tue Mar 27 05:39:20 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4432321E8087 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 05:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZvQ8JPEQlqH for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 05:39:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0015721E8129 for <dispatch@ietf.org>; Tue, 27 Mar 2012 05:39:18 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Mar 2012 08:39:05 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Tue, 27 Mar 2012 08:39:05 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Thread-Topic: [dispatch] STRAW Charter Proposal Thread-Index: AQHNDBaYjrZLb/Ki/kyz30u7qjliGg== Date: Tue, 27 Mar 2012 12:39:04 +0000 Message-ID: <B03EBC9C-57F8-48AA-A722-98AD5DB658C0@acmepacket.com> References: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> <1D062974A4845E4D8A343C653804920207F1DDF2@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920207F1DDF2@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <30770AA91DB7F74A85A39BB1192BB51F@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "<dispatch@ietf.org>" <dispatch@ietf.org> Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 12:39:20 -0000 Umm sure, but just to be clear - if a B2BUA does transcoding it *is* the en= d of RTCP (and a new RTCP beginning on the other side). As far as I know, = it is illogical to expect RTCP to go "through" a transcoder. Are you proposing we should have a milestone for documenting specific funct= ionality of RTCP, such as by passing through specific fields of RTCP, that = needs to work through a transcoder? -hadriel On Mar 27, 2012, at 2:22 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: > I think RTCP has similar issues with B2BUAs and getting RTCP/SRTCP > working end-to-end across B2BUAs, in particular those B2BUAs that > perform transcoding/transrating of media streams, is also important. I > would suggest adding a deliverable for RTCP/SRTCP: >=20 > 6) A document defining the requirements for B2BUAs to support RTCP/SRTCP > end-to-end. >=20 > Muthu >=20 > |-----Original Message----- > |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > |Sent: Tuesday, January 24, 2012 8:16 AM > |To: dispatch@ietf.org list > |Subject: [dispatch] STRAW Charter Proposal > | > |Howdy, > |As instructed by DISPATCH chairs, I am re-posting the STRAW Charter > Proposal, as a topic for the Paris > |meeting. > |The proposed charter is as follows: > | > |Description of STRAW Working Group > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > |Name: Sip Traversal Required for Applications to Work (STRAW) > | > |Problem Statement: > |Within the context of the SIP protocol and architecture, a Back-to-Back > User Agent (B2BUA) is any SIP > |device in the logical path between two User Agents performing a role > beyond that of a Proxy as defined > |in RFC 3261. The B2BUA may be as simple as a session-stateful Proxy > becoming a B2BUA in order to > |terminate dead sessions by generating BYEs; or it may be a 3PCC-style > agent only modifying SDP; or it > |may be a Session Border Controller performing such functions as in RFC > 5853; or it may be an > |Enterprise PBX terminating REFERs and such; or it may be a complete UAS > and UAC implementation with a > |PRI loopback in-between. > | > |In its most extreme form, the scope of the SIP protocol ends at the UAS > of the B2BUA, and a new SIP > |protocol scope begins on its UAC side. In practice, however, users > expect some SIP protocol aspects > |to go beyond the scope of the B2BUA's UAS side, and be traversed onto > its UAC side, as if the B2BUA > |was not an end unto itself; this is similar to the expectation that > emails work when they cross from > |POP and IMAP to/from SMTP. > | > |It is impossible to normatively define all the behaviors of B2BUAs in > general, or even subsets of them > |such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying > functions for purposes which may be > |unique to their environment, unique to their architecture, or unique to > the wishes of their > |administrator. Instead of defining all things a given type of B2BUA > must do, a more practical > |objective would be to define what very few things any B2BUA must do to > make a specific SIP mechanism > |work, and let the market decide whether to do those things. > | > |The name of this working group reflects that practical objective: if > there were a thin straw between > |the SIP UAS and UAC of a B2BUA, what must be passed through that straw > and used on each side. Or > |viewed another way, if a B2BUA were in fact a UAS and UAC connected > with a PRI loopback circuit, and > |if we could extend ISDN, what information would we carry in ISDN across > the PRI for a specific SIP > |mechanism to work end-to-end. > | > |For example, the WG could produce a document which specifies that the > Max-Forwards header field value > |should be copied and decremented across the B2BUA, if the B2BUA wishes > to prevent loops. > |Administrators could then tell their B2BUA vendors to comply with the > document, if the administrator > |so wishes. > | > |Objectives: > |The objectives of the STRAW Working Group are to publish normative > documents which define which SIP > |header fields, parameters, MIME bodies, body content > fields/information, or media-plane > |characteristics are required to traverse between the User Agent "sides" > of a B2BUA for specific > |functions to work. > | > |Deliverables would indicate which types of B2BUAs would apply or not. > For example, a document > |defining the requirements for end-to-end DTLS-SRTP would not apply to > B2BUAs which terminate media, > |such as transcoders or recorders. > | > |The intention of this WG is to document such requirements in separate > documents, per SIP or media > |function, instead of as one document for all functions. That will both > reduce the time to > |publication, as well a provide B2BUA administrators and manufacturers > with simple comply/no-comply > |criteria. > | > | > |Initial Deliverables: > |1) A taxonomy document defining role-types of B2BUAs, as a reference > for other deliverables. > |2) A document defining the requirements for B2BUAs with respect to loop > detection/prevention. > |3) A document defining the requirements for B2BUAs to support > end-to-end and hop-by-hop media-loopback > |test calls. > |4) A document defining the requirements for B2BUAs to support DTLS-SRTP > (RFC 5764) end-to-end. > |5) A document defining the requirements for B2BUAs to support STUN > connectivity checks end-to-end. > | > | > |_______________________________________________ > |dispatch mailing list > |dispatch@ietf.org > |https://www.ietf.org/mailman/listinfo/dispatch From pravindran@sonusnet.com Tue Mar 27 05:52:50 2012 Return-Path: <pravindran@sonusnet.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B150A21E8159 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 05:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.159 X-Spam-Level: X-Spam-Status: No, score=-5.159 tagged_above=-999 required=5 tests=[AWL=1.440, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzzRKuJWqJvo for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 05:52:46 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with ESMTP id 48A3E21E8129 for <dispatch@ietf.org>; Tue, 27 Mar 2012 05:52:46 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKT3G4HTo/rQDE2UKvb0V4lxcMGR2YZE3k@postini.com; Tue, 27 Mar 2012 05:52:46 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 27 Mar 2012 08:53:04 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 18:22:40 +0530 From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com> To: "Khan, Sohel" <Sohel_Khan@cable.comcast.com>, "dispatch@ietf.org" <dispatch@ietf.org> Thread-Topic: B2BUA charter/straw Thread-Index: AQHNDBDB4L/ysvgDpU2hyCI8tX9QpJZ+Dw6AgAAA7MuAAAdokA== Date: Tue, 27 Mar 2012 12:53:01 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E220D8C@inba-mail01.sonusnet.com> References: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D4B@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D20D@PACDCEXMB02.cable.comcast.com> In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF5A92D20D@PACDCEXMB02.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 12:52:50 -0000 Sohel, Topology hiding is not possible for the mid-dialog without dialog-stateful = B2BUA. I'm not clear how stateless B2BUA entity helps here.. Also, Please explain in the separate mail thread about persistent connectio= n usecase as discussed in Dispatch meeting today. Thanks Partha >-----Original Message----- >From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com] >Sent: Tuesday, March 27, 2012 5:56 PM >To: Ravindran, Parthasarathi; dispatch@ietf.org >Subject: RE: B2BUA charter/straw > >Thanks Partha. >We want to take the advantage of topology hiding of the B2BUA; however, >we want to save the B2BUA's implementation package (i.e., SBC) from >excessive chatting to improve processing. In addition, for the >persistent connection for incoming messages, we would like to pass the >incoming new session messages bypassing the B2BUA. > > >________________________________________ >From: Ravindran, Parthasarathi [pravindran@sonusnet.com] >Sent: Tuesday, March 27, 2012 6:19 AM >To: Khan, Sohel; dispatch@ietf.org >Subject: RE: B2BUA charter/straw > >Sohel, > >Could you please explain the advantage of those new B2BUA over stateful >proxy. > >Thanks >Partha > >>-----Original Message----- >>From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>Behalf Of Khan, Sohel >>Sent: Tuesday, March 27, 2012 5:30 PM >>To: dispatch@ietf.org >>Subject: [dispatch] B2BUA charter/straw >> >>Currently, a proxy can be statefull or stateless. The advantage of >>stateless is to have the proxy out of the path of a SIP call after >>initial session messages. As I understand, currently deployed B2BUAs >>are " rigidly statefull". They remain in the call path until the end of >>the session and all the messages traverse through B2BUA. Can we >>convert the B2BUA to be a pseudo-statefull--i.e., for certain SIP >>messages, the B2BUA is statefull for some messages and for other >>messages of the same call, the B2BUA is stateless? >>Can we add this in the current B2BUA charter initiative? >> >>Sohel >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch From sohel_khan@cable.comcast.com Tue Mar 27 06:04:01 2012 Return-Path: <sohel_khan@cable.comcast.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6AA21F893E for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 06:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.003 X-Spam-Level: X-Spam-Status: No, score=-102.003 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gjqa+y2voNHY for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 06:04:00 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id BE92B21F8931 for <dispatch@ietf.org>; Tue, 27 Mar 2012 06:04:00 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.11021926; Tue, 27 Mar 2012 06:51:42 -0600 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 09:03:56 -0400 From: "Khan, Sohel" <Sohel_Khan@cable.comcast.com> To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>, "dispatch@ietf.org" <dispatch@ietf.org> Thread-Topic: B2BUA charter/straw Thread-Index: AQHNDBDB4L/ysvgDpU2hyCI8tX9QpJZ+Dw6AgAAA7MuAAAdokIAAAzEf Date: Tue, 27 Mar 2012 13:03:55 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF5A92D23C@PACDCEXMB02.cable.comcast.com> References: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D4B@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D20D@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D8C@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E220D8C@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 13:04:01 -0000 Thanks Partha. =0A= In technological innovation, nothing is impossible. =0A= We will need to innovate something (e.g., a B2BUA) with following requirem= ents:=0A= 1. Topology hiding=0A= 2. pseudo-stateful.=0A= =0A= For example, only SIP messages with offer-answer information and BYE passes= the B2BUA. All other messages bypass B2BUA.=0A= =0A= =0A= ________________________________________=0A= From: Ravindran, Parthasarathi [pravindran@sonusnet.com]=0A= Sent: Tuesday, March 27, 2012 6:53 AM=0A= To: Khan, Sohel; dispatch@ietf.org=0A= Subject: RE: B2BUA charter/straw=0A= =0A= Sohel,=0A= =0A= Topology hiding is not possible for the mid-dialog without dialog-stateful = B2BUA. I'm not clear how stateless B2BUA entity helps here..=0A= =0A= Also, Please explain in the separate mail thread about persistent connectio= n usecase as discussed in Dispatch meeting today.=0A= =0A= Thanks=0A= Partha=0A= =0A= >-----Original Message-----=0A= >From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com]=0A= >Sent: Tuesday, March 27, 2012 5:56 PM=0A= >To: Ravindran, Parthasarathi; dispatch@ietf.org=0A= >Subject: RE: B2BUA charter/straw=0A= >=0A= >Thanks Partha.=0A= >We want to take the advantage of topology hiding of the B2BUA; however,=0A= >we want to save the B2BUA's implementation package (i.e., SBC) from=0A= >excessive chatting to improve processing. In addition, for the=0A= >persistent connection for incoming messages, we would like to pass the=0A= >incoming new session messages bypassing the B2BUA.=0A= >=0A= >=0A= >________________________________________=0A= >From: Ravindran, Parthasarathi [pravindran@sonusnet.com]=0A= >Sent: Tuesday, March 27, 2012 6:19 AM=0A= >To: Khan, Sohel; dispatch@ietf.org=0A= >Subject: RE: B2BUA charter/straw=0A= >=0A= >Sohel,=0A= >=0A= >Could you please explain the advantage of those new B2BUA over stateful=0A= >proxy.=0A= >=0A= >Thanks=0A= >Partha=0A= >=0A= >>-----Original Message-----=0A= >>From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=0A= >>Behalf Of Khan, Sohel=0A= >>Sent: Tuesday, March 27, 2012 5:30 PM=0A= >>To: dispatch@ietf.org=0A= >>Subject: [dispatch] B2BUA charter/straw=0A= >>=0A= >>Currently, a proxy can be statefull or stateless. The advantage of=0A= >>stateless is to have the proxy out of the path of a SIP call after=0A= >>initial session messages. As I understand, currently deployed B2BUAs=0A= >>are " rigidly statefull". They remain in the call path until the end of= =0A= >>the session and all the messages traverse through B2BUA. Can we=0A= >>convert the B2BUA to be a pseudo-statefull--i.e., for certain SIP=0A= >>messages, the B2BUA is statefull for some messages and for other=0A= >>messages of the same call, the B2BUA is stateless?=0A= >>Can we add this in the current B2BUA charter initiative?=0A= >>=0A= >>Sohel=0A= >>_______________________________________________=0A= >>dispatch mailing list=0A= >>dispatch@ietf.org=0A= >>https://www.ietf.org/mailman/listinfo/dispatch=0A= From pravindran@sonusnet.com Tue Mar 27 06:34:35 2012 Return-Path: <pravindran@sonusnet.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5689821F89F0 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.182 X-Spam-Level: X-Spam-Status: No, score=-5.182 tagged_above=-999 required=5 tests=[AWL=1.417, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2z+B-BE4oSK for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 06:34:34 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1760621F8992 for <dispatch@ietf.org>; Tue, 27 Mar 2012 06:34:34 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKT3HB6fS6SqJVsACn/8DuK89++pZOQv3u@postini.com; Tue, 27 Mar 2012 06:34:34 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 27 Mar 2012 09:34:52 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 19:04:28 +0530 From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com> To: "Khan, Sohel" <Sohel_Khan@cable.comcast.com>, "dispatch@ietf.org" <dispatch@ietf.org> Thread-Topic: B2BUA charter/straw Thread-Index: AQHNDBDB4L/ysvgDpU2hyCI8tX9QpJZ+Dw6AgAAA7MuAAAdokIAAAzEfgAAJFAA= Date: Tue, 27 Mar 2012 13:34:48 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E220DBD@inba-mail01.sonusnet.com> References: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D4B@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D20D@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D8C@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D23C@PACDCEXMB02.cable.comcast.com> In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF5A92D23C@PACDCEXMB02.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 13:34:35 -0000 Sohel, Thanks for the clarification. You propose to introduce new SIP entity which= is in between B2BUA and stateful proxy for Topology hiding and pseudo-stat= eful. IMO, your new entity is not B2BUA and pls define new entity for more = discussion. Thanks Partha >-----Original Message----- >From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com] >Sent: Tuesday, March 27, 2012 6:34 PM >To: Ravindran, Parthasarathi; dispatch@ietf.org >Subject: RE: B2BUA charter/straw > >Thanks Partha. >In technological innovation, nothing is impossible. >We will need to innovate something (e.g., a B2BUA) with following >requirements: >1. Topology hiding >2. pseudo-stateful. > >For example, only SIP messages with offer-answer information and BYE >passes the B2BUA. All other messages bypass B2BUA. > > >________________________________________ >From: Ravindran, Parthasarathi [pravindran@sonusnet.com] >Sent: Tuesday, March 27, 2012 6:53 AM >To: Khan, Sohel; dispatch@ietf.org >Subject: RE: B2BUA charter/straw > >Sohel, > >Topology hiding is not possible for the mid-dialog without dialog- >stateful B2BUA. I'm not clear how stateless B2BUA entity helps here.. > >Also, Please explain in the separate mail thread about persistent >connection usecase as discussed in Dispatch meeting today. > >Thanks >Partha > >>-----Original Message----- >>From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com] >>Sent: Tuesday, March 27, 2012 5:56 PM >>To: Ravindran, Parthasarathi; dispatch@ietf.org >>Subject: RE: B2BUA charter/straw >> >>Thanks Partha. >>We want to take the advantage of topology hiding of the B2BUA; however, >>we want to save the B2BUA's implementation package (i.e., SBC) from >>excessive chatting to improve processing. In addition, for the >>persistent connection for incoming messages, we would like to pass the >>incoming new session messages bypassing the B2BUA. >> >> >>________________________________________ >>From: Ravindran, Parthasarathi [pravindran@sonusnet.com] >>Sent: Tuesday, March 27, 2012 6:19 AM >>To: Khan, Sohel; dispatch@ietf.org >>Subject: RE: B2BUA charter/straw >> >>Sohel, >> >>Could you please explain the advantage of those new B2BUA over stateful >>proxy. >> >>Thanks >>Partha >> >>>-----Original Message----- >>>From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>Behalf Of Khan, Sohel >>>Sent: Tuesday, March 27, 2012 5:30 PM >>>To: dispatch@ietf.org >>>Subject: [dispatch] B2BUA charter/straw >>> >>>Currently, a proxy can be statefull or stateless. The advantage of >>>stateless is to have the proxy out of the path of a SIP call after >>>initial session messages. As I understand, currently deployed B2BUAs >>>are " rigidly statefull". They remain in the call path until the end >of >>>the session and all the messages traverse through B2BUA. Can we >>>convert the B2BUA to be a pseudo-statefull--i.e., for certain SIP >>>messages, the B2BUA is statefull for some messages and for other >>>messages of the same call, the B2BUA is stateless? >>>Can we add this in the current B2BUA charter initiative? >>> >>>Sohel >>>_______________________________________________ >>>dispatch mailing list >>>dispatch@ietf.org >>>https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Tue Mar 27 06:34:38 2012 Return-Path: <pkyzivat@alum.mit.edu> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C1B21F89A8 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 06:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIPGwnqsV24D for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 06:34:38 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC6821F89F3 for <dispatch@ietf.org>; Tue, 27 Mar 2012 06:34:37 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta01.westchester.pa.mail.comcast.net with comcast id qcla1i0081ZXKqc51daeyi; Tue, 27 Mar 2012 13:34:38 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta21.westchester.pa.mail.comcast.net with comcast id qdaV1i00W5EhBnE3hdaYjH; Tue, 27 Mar 2012 13:34:36 +0000 Message-ID: <4F71C1E4.70007@alum.mit.edu> Date: Tue, 27 Mar 2012 15:34:28 +0200 From: Paul Kyzivat <pkyzivat@alum.mit.edu> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D4B@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D20D@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D8C@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D23C@PACDCEXMB02.cable.comcast.com> In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF5A92D23C@PACDCEXMB02.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 13:34:38 -0000 On 3/27/12 3:03 PM, Khan, Sohel wrote: > Thanks Partha. > In technological innovation, nothing is impossible. Unfortunately too many people believe that. > We will need to innovate something (e.g., a B2BUA) with following requirements: > 1. Topology hiding > 2. pseudo-stateful. > > For example, only SIP messages with offer-answer information and BYE passes the B2BUA. All other messages bypass B2BUA. IMO that makes no sense. To receive any of the in dialog messages the B2BUA must be in the signaling path. That same signaling path is used for *all* the in-dialog messages, so they all go there. OTOH, you are free to decompose the implementation of your B2BUA, into internal components that communicate with one another without regard to sip signaling. Then, if you like you can put your o/a handling into a *component* of the b2bua that is only invoked for messages containing offers and answers. But that is an *implementation* issue, not an issue for IETF. Paul From csp@csperkins.org Tue Mar 27 06:42:49 2012 Return-Path: <csp@csperkins.org> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D322221E8090 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 06:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVPaeJL9DpIJ for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 06:42:49 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id AEF0121E8089 for <dispatch@ietf.org>; Tue, 27 Mar 2012 06:42:48 -0700 (PDT) Received: from dhcp-20d9.meeting.ietf.org ([130.129.32.217]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SCWff-0004mc-oQ; Tue, 27 Mar 2012 13:42:47 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Colin Perkins <csp@csperkins.org> In-Reply-To: <B03EBC9C-57F8-48AA-A722-98AD5DB658C0@acmepacket.com> Date: Tue, 27 Mar 2012 15:42:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <E456066D-E8A0-4462-AF6D-5B2D566E3FFA@csperkins.org> References: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> <1D062974A4845E4D8A343C653804920207F1DDF2@XMB-BGL-414.cisco.com> <B03EBC9C-57F8-48AA-A722-98AD5DB658C0@acmepacket.com> To: Hadriel Kaplan <HKaplan@acmepacket.com> X-Mailer: Apple Mail (2.1257) Cc: "<dispatch@ietf.org>" <dispatch@ietf.org> Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 13:42:49 -0000 While I'm sure it's more common to terminate RTCP at the transcoder, RTP = Translators [RFC3550 section 7.2; Topo-Media-Translator in RFC5117] were = intended to support the case where RTCP goes through the transcoder.=20 Colin On 27 Mar 2012, at 14:39, Hadriel Kaplan wrote: > Umm sure, but just to be clear - if a B2BUA does transcoding it *is* = the end of RTCP (and a new RTCP beginning on the other side). As far as = I know, it is illogical to expect RTCP to go "through" a transcoder. >=20 > Are you proposing we should have a milestone for documenting specific = functionality of RTCP, such as by passing through specific fields of = RTCP, that needs to work through a transcoder? >=20 > -hadriel >=20 >=20 > On Mar 27, 2012, at 2:22 PM, Muthu Arul Mozhi Perumal (mperumal) = wrote: >=20 >> I think RTCP has similar issues with B2BUAs and getting RTCP/SRTCP >> working end-to-end across B2BUAs, in particular those B2BUAs that >> perform transcoding/transrating of media streams, is also important. = I >> would suggest adding a deliverable for RTCP/SRTCP: >>=20 >> 6) A document defining the requirements for B2BUAs to support = RTCP/SRTCP >> end-to-end. >>=20 >> Muthu >>=20 >> |-----Original Message----- >> |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On >> Behalf Of Hadriel Kaplan >> |Sent: Tuesday, January 24, 2012 8:16 AM >> |To: dispatch@ietf.org list >> |Subject: [dispatch] STRAW Charter Proposal >> | >> |Howdy, >> |As instructed by DISPATCH chairs, I am re-posting the STRAW Charter >> Proposal, as a topic for the Paris >> |meeting. >> |The proposed charter is as follows: >> | >> |Description of STRAW Working Group >> |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> |Name: Sip Traversal Required for Applications to Work (STRAW) >> | >> |Problem Statement: >> |Within the context of the SIP protocol and architecture, a = Back-to-Back >> User Agent (B2BUA) is any SIP >> |device in the logical path between two User Agents performing a role >> beyond that of a Proxy as defined >> |in RFC 3261. The B2BUA may be as simple as a session-stateful Proxy >> becoming a B2BUA in order to >> |terminate dead sessions by generating BYEs; or it may be a = 3PCC-style >> agent only modifying SDP; or it >> |may be a Session Border Controller performing such functions as in = RFC >> 5853; or it may be an >> |Enterprise PBX terminating REFERs and such; or it may be a complete = UAS >> and UAC implementation with a >> |PRI loopback in-between. >> | >> |In its most extreme form, the scope of the SIP protocol ends at the = UAS >> of the B2BUA, and a new SIP >> |protocol scope begins on its UAC side. In practice, however, users >> expect some SIP protocol aspects >> |to go beyond the scope of the B2BUA's UAS side, and be traversed = onto >> its UAC side, as if the B2BUA >> |was not an end unto itself; this is similar to the expectation that >> emails work when they cross from >> |POP and IMAP to/from SMTP. >> | >> |It is impossible to normatively define all the behaviors of B2BUAs = in >> general, or even subsets of them >> |such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying >> functions for purposes which may be >> |unique to their environment, unique to their architecture, or unique = to >> the wishes of their >> |administrator. Instead of defining all things a given type of B2BUA >> must do, a more practical >> |objective would be to define what very few things any B2BUA must do = to >> make a specific SIP mechanism >> |work, and let the market decide whether to do those things. >> | >> |The name of this working group reflects that practical objective: if >> there were a thin straw between >> |the SIP UAS and UAC of a B2BUA, what must be passed through that = straw >> and used on each side. Or >> |viewed another way, if a B2BUA were in fact a UAS and UAC connected >> with a PRI loopback circuit, and >> |if we could extend ISDN, what information would we carry in ISDN = across >> the PRI for a specific SIP >> |mechanism to work end-to-end. >> | >> |For example, the WG could produce a document which specifies that = the >> Max-Forwards header field value >> |should be copied and decremented across the B2BUA, if the B2BUA = wishes >> to prevent loops. >> |Administrators could then tell their B2BUA vendors to comply with = the >> document, if the administrator >> |so wishes. >> | >> |Objectives: >> |The objectives of the STRAW Working Group are to publish normative >> documents which define which SIP >> |header fields, parameters, MIME bodies, body content >> fields/information, or media-plane >> |characteristics are required to traverse between the User Agent = "sides" >> of a B2BUA for specific >> |functions to work. >> | >> |Deliverables would indicate which types of B2BUAs would apply or = not. >> For example, a document >> |defining the requirements for end-to-end DTLS-SRTP would not apply = to >> B2BUAs which terminate media, >> |such as transcoders or recorders. >> | >> |The intention of this WG is to document such requirements in = separate >> documents, per SIP or media >> |function, instead of as one document for all functions. That will = both >> reduce the time to >> |publication, as well a provide B2BUA administrators and = manufacturers >> with simple comply/no-comply >> |criteria. >> | >> | >> |Initial Deliverables: >> |1) A taxonomy document defining role-types of B2BUAs, as a reference >> for other deliverables. >> |2) A document defining the requirements for B2BUAs with respect to = loop >> detection/prevention. >> |3) A document defining the requirements for B2BUAs to support >> end-to-end and hop-by-hop media-loopback >> |test calls. >> |4) A document defining the requirements for B2BUAs to support = DTLS-SRTP >> (RFC 5764) end-to-end. >> |5) A document defining the requirements for B2BUAs to support STUN >> connectivity checks end-to-end. >> | >> | >> |_______________________________________________ >> |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 Colin Perkins http://csperkins.org/ From sohel_khan@cable.comcast.com Tue Mar 27 06:46:35 2012 Return-Path: <sohel_khan@cable.comcast.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5EC21E8090 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 06:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.907 X-Spam-Level: X-Spam-Status: No, score=-101.907 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWL4kSj3Mz88 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 06:46:35 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 4605821E819E for <dispatch@ietf.org>; Tue, 27 Mar 2012 06:46:34 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.11031427; Tue, 27 Mar 2012 07:34:15 -0600 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 09:46:30 -0400 From: "Khan, Sohel" <Sohel_Khan@cable.comcast.com> To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>, "dispatch@ietf.org" <dispatch@ietf.org> Thread-Topic: B2BUA charter/straw Thread-Index: AQHNDBDB4L/ysvgDpU2hyCI8tX9QpJZ+Dw6AgAAA7MuAAAdokIAAAzEfgAAJFACAAAK0Zg== Date: Tue, 27 Mar 2012 13:46:29 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF5A92D271@PACDCEXMB02.cable.comcast.com> References: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D4B@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D20D@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D8C@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D23C@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220DBD@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E220DBD@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 13:46:35 -0000 Thank you Partha. Actually, proposing a new entity and creating new charter= process will take a long time.=0A= I am simply trying to see whether we can include it as a task in the new B2= BUA charter.=0A= The task may provide recommendation which messages must pass through B2BUA = and which messages must not.=0A= =0A= Subscribe/Notify is an example. Can we recommend Subscribe message passing = through B2BUA but Notify bypasses B2BUA. You may say it is an implementatio= n method not a responsibility of the IETF. The issue is that multiple provi= ders/implementations creates interoperability issues. Thus, an IETF guideli= ne/recommendation will be very helpful.=0A= =0A= =0A= =0A= =0A= ________________________________________=0A= From: Ravindran, Parthasarathi [pravindran@sonusnet.com]=0A= Sent: Tuesday, March 27, 2012 7:34 AM=0A= To: Khan, Sohel; dispatch@ietf.org=0A= Subject: RE: B2BUA charter/straw=0A= =0A= Sohel,=0A= =0A= Thanks for the clarification. You propose to introduce new SIP entity which= is in between B2BUA and stateful proxy for Topology hiding and pseudo-stat= eful. IMO, your new entity is not B2BUA and pls define new entity for more = discussion.=0A= =0A= Thanks=0A= Partha=0A= =0A= >-----Original Message-----=0A= >From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com]=0A= >Sent: Tuesday, March 27, 2012 6:34 PM=0A= >To: Ravindran, Parthasarathi; dispatch@ietf.org=0A= >Subject: RE: B2BUA charter/straw=0A= >=0A= >Thanks Partha.=0A= >In technological innovation, nothing is impossible.=0A= >We will need to innovate something (e.g., a B2BUA) with following=0A= >requirements:=0A= >1. Topology hiding=0A= >2. pseudo-stateful.=0A= >=0A= >For example, only SIP messages with offer-answer information and BYE=0A= >passes the B2BUA. All other messages bypass B2BUA.=0A= >=0A= >=0A= >________________________________________=0A= >From: Ravindran, Parthasarathi [pravindran@sonusnet.com]=0A= >Sent: Tuesday, March 27, 2012 6:53 AM=0A= >To: Khan, Sohel; dispatch@ietf.org=0A= >Subject: RE: B2BUA charter/straw=0A= >=0A= >Sohel,=0A= >=0A= >Topology hiding is not possible for the mid-dialog without dialog-=0A= >stateful B2BUA. I'm not clear how stateless B2BUA entity helps here..=0A= >=0A= >Also, Please explain in the separate mail thread about persistent=0A= >connection usecase as discussed in Dispatch meeting today.=0A= >=0A= >Thanks=0A= >Partha=0A= >=0A= >>-----Original Message-----=0A= >>From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com]=0A= >>Sent: Tuesday, March 27, 2012 5:56 PM=0A= >>To: Ravindran, Parthasarathi; dispatch@ietf.org=0A= >>Subject: RE: B2BUA charter/straw=0A= >>=0A= >>Thanks Partha.=0A= >>We want to take the advantage of topology hiding of the B2BUA; however,= =0A= >>we want to save the B2BUA's implementation package (i.e., SBC) from=0A= >>excessive chatting to improve processing. In addition, for the=0A= >>persistent connection for incoming messages, we would like to pass the=0A= >>incoming new session messages bypassing the B2BUA.=0A= >>=0A= >>=0A= >>________________________________________=0A= >>From: Ravindran, Parthasarathi [pravindran@sonusnet.com]=0A= >>Sent: Tuesday, March 27, 2012 6:19 AM=0A= >>To: Khan, Sohel; dispatch@ietf.org=0A= >>Subject: RE: B2BUA charter/straw=0A= >>=0A= >>Sohel,=0A= >>=0A= >>Could you please explain the advantage of those new B2BUA over stateful= =0A= >>proxy.=0A= >>=0A= >>Thanks=0A= >>Partha=0A= >>=0A= >>>-----Original Message-----=0A= >>>From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=0A= >>>Behalf Of Khan, Sohel=0A= >>>Sent: Tuesday, March 27, 2012 5:30 PM=0A= >>>To: dispatch@ietf.org=0A= >>>Subject: [dispatch] B2BUA charter/straw=0A= >>>=0A= >>>Currently, a proxy can be statefull or stateless. The advantage of=0A= >>>stateless is to have the proxy out of the path of a SIP call after=0A= >>>initial session messages. As I understand, currently deployed B2BUAs=0A= >>>are " rigidly statefull". They remain in the call path until the end=0A= >of=0A= >>>the session and all the messages traverse through B2BUA. Can we=0A= >>>convert the B2BUA to be a pseudo-statefull--i.e., for certain SIP=0A= >>>messages, the B2BUA is statefull for some messages and for other=0A= >>>messages of the same call, the B2BUA is stateless?=0A= >>>Can we add this in the current B2BUA charter initiative?=0A= >>>=0A= >>>Sohel=0A= >>>_______________________________________________=0A= >>>dispatch mailing list=0A= >>>dispatch@ietf.org=0A= >>>https://www.ietf.org/mailman/listinfo/dispatch=0A= From pkyzivat@alum.mit.edu Tue Mar 27 07:03:57 2012 Return-Path: <pkyzivat@alum.mit.edu> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA49B21E81FC for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 07:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDIviREe0WGk for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 07:03:57 -0700 (PDT) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1F24B21E81FB for <dispatch@ietf.org>; Tue, 27 Mar 2012 07:03:57 -0700 (PDT) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta11.emeryville.ca.mail.comcast.net with comcast id qdj21i0050cQ2SLABe3wC8; Tue, 27 Mar 2012 14:03:56 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta10.emeryville.ca.mail.comcast.net with comcast id qe3m1i0175EhBnE8We3phi; Tue, 27 Mar 2012 14:03:54 +0000 Message-ID: <4F71C8C2.8050805@alum.mit.edu> Date: Tue, 27 Mar 2012 16:03:46 +0200 From: Paul Kyzivat <pkyzivat@alum.mit.edu> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D4B@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D20D@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D8C@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D23C@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220DBD@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D271@PACDCEXMB02.cable.comcast.com> In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF5A92D271@PACDCEXMB02.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 14:03:57 -0000 On 3/27/12 3:46 PM, Khan, Sohel wrote: > Thank you Partha. Actually, proposing a new entity and creating new charter process will take a long time. > I am simply trying to see whether we can include it as a task in the new B2BUA charter. > The task may provide recommendation which messages must pass through B2BUA and which messages must not. > > Subscribe/Notify is an example. Can we recommend Subscribe message passing through B2BUA but Notify bypasses B2BUA. You may say it is an implementation method not a responsibility of the IETF. The issue is that multiple providers/implementations creates interoperability issues. Thus, an IETF guideline/recommendation will be very helpful. If the SUBSCRIBE establishes a new dialog, then your "B2BUA" may elect to act as a proxy and not Record-Route. It will than not be in the signaling path for the dialog. But in that case you will not be able to do topology hiding. There are other possibilities with different tradeoffs. None of this requires any changes to existing standards. Paul > ________________________________________ > From: Ravindran, Parthasarathi [pravindran@sonusnet.com] > Sent: Tuesday, March 27, 2012 7:34 AM > To: Khan, Sohel; dispatch@ietf.org > Subject: RE: B2BUA charter/straw > > Sohel, > > Thanks for the clarification. You propose to introduce new SIP entity which is in between B2BUA and stateful proxy for Topology hiding and pseudo-stateful. IMO, your new entity is not B2BUA and pls define new entity for more discussion. > > Thanks > Partha > >> -----Original Message----- >> From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com] >> Sent: Tuesday, March 27, 2012 6:34 PM >> To: Ravindran, Parthasarathi; dispatch@ietf.org >> Subject: RE: B2BUA charter/straw >> >> Thanks Partha. >> In technological innovation, nothing is impossible. >> We will need to innovate something (e.g., a B2BUA) with following >> requirements: >> 1. Topology hiding >> 2. pseudo-stateful. >> >> For example, only SIP messages with offer-answer information and BYE >> passes the B2BUA. All other messages bypass B2BUA. >> >> >> ________________________________________ >> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] >> Sent: Tuesday, March 27, 2012 6:53 AM >> To: Khan, Sohel; dispatch@ietf.org >> Subject: RE: B2BUA charter/straw >> >> Sohel, >> >> Topology hiding is not possible for the mid-dialog without dialog- >> stateful B2BUA. I'm not clear how stateless B2BUA entity helps here.. >> >> Also, Please explain in the separate mail thread about persistent >> connection usecase as discussed in Dispatch meeting today. >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com] >>> Sent: Tuesday, March 27, 2012 5:56 PM >>> To: Ravindran, Parthasarathi; dispatch@ietf.org >>> Subject: RE: B2BUA charter/straw >>> >>> Thanks Partha. >>> We want to take the advantage of topology hiding of the B2BUA; however, >>> we want to save the B2BUA's implementation package (i.e., SBC) from >>> excessive chatting to improve processing. In addition, for the >>> persistent connection for incoming messages, we would like to pass the >>> incoming new session messages bypassing the B2BUA. >>> >>> >>> ________________________________________ >>> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] >>> Sent: Tuesday, March 27, 2012 6:19 AM >>> To: Khan, Sohel; dispatch@ietf.org >>> Subject: RE: B2BUA charter/straw >>> >>> Sohel, >>> >>> Could you please explain the advantage of those new B2BUA over stateful >>> proxy. >>> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Khan, Sohel >>>> Sent: Tuesday, March 27, 2012 5:30 PM >>>> To: dispatch@ietf.org >>>> Subject: [dispatch] B2BUA charter/straw >>>> >>>> Currently, a proxy can be statefull or stateless. The advantage of >>>> stateless is to have the proxy out of the path of a SIP call after >>>> initial session messages. As I understand, currently deployed B2BUAs >>>> are " rigidly statefull". They remain in the call path until the end >> of >>>> the session and all the messages traverse through B2BUA. Can we >>>> convert the B2BUA to be a pseudo-statefull--i.e., for certain SIP >>>> messages, the B2BUA is statefull for some messages and for other >>>> messages of the same call, the B2BUA is stateless? >>>> Can we add this in the current B2BUA charter initiative? >>>> >>>> Sohel >>>> _______________________________________________ >>>> 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 sohel_khan@cable.comcast.com Tue Mar 27 07:06:07 2012 Return-Path: <sohel_khan@cable.comcast.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EF621E81FC for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 07:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.832 X-Spam-Level: X-Spam-Status: No, score=-101.832 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIbzkn5oBcVm for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 07:06:07 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 37C1821E81DA for <dispatch@ietf.org>; Tue, 27 Mar 2012 07:06:07 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.11035981; Tue, 27 Mar 2012 07:53:48 -0600 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 10:06:03 -0400 From: "Khan, Sohel" <Sohel_Khan@cable.comcast.com> To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "dispatch@ietf.org" <dispatch@ietf.org> Thread-Topic: [dispatch] B2BUA charter/straw Thread-Index: AQHNDBDB4L/ysvgDpU2hyCI8tX9QpJZ+Dw6AgAAA7MuAAAdokIAAAzEfgABNAwD//8RYMA== Date: Tue, 27 Mar 2012 14:06:02 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF5A92D2AE@PACDCEXMB02.cable.comcast.com> References: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D4B@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D20D@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D8C@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D23C@PACDCEXMB02.cable.comcast.com>, <4F71C1E4.70007@alum.mit.edu> In-Reply-To: <4F71C1E4.70007@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 14:06:07 -0000 Thank you Paul.=0A= The "very bad" B2BUA is sitting in the border of two providers using differ= ent implementations. For a provider's internal implementation, your recomme= ndation is valid. In additino, it will be helpful for IETF to provide a gu= ideline/recommendation to providers/vendors with options to anchor some mes= sages in the B2BUA while providing options not to anchor some other message= s in the B2BUA. SIP Subsribe/notify is such an example.=0A= =0A= Sohel=0A= =0A= ________________________________________=0A= From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] on behalf of Pa= ul Kyzivat [pkyzivat@alum.mit.edu]=0A= Sent: Tuesday, March 27, 2012 7:34 AM=0A= To: dispatch@ietf.org=0A= Subject: Re: [dispatch] B2BUA charter/straw=0A= =0A= On 3/27/12 3:03 PM, Khan, Sohel wrote:=0A= > Thanks Partha.=0A= > In technological innovation, nothing is impossible.=0A= =0A= Unfortunately too many people believe that.=0A= =0A= > We will need to innovate something (e.g., a B2BUA) with following requir= ements:=0A= > 1. Topology hiding=0A= > 2. pseudo-stateful.=0A= >=0A= > For example, only SIP messages with offer-answer information and BYE pass= es the B2BUA. All other messages bypass B2BUA.=0A= =0A= IMO that makes no sense.=0A= To receive any of the in dialog messages the B2BUA must be in the=0A= signaling path. That same signaling path is used for *all* the in-dialog=0A= messages, so they all go there.=0A= =0A= OTOH, you are free to decompose the implementation of your B2BUA, into=0A= internal components that communicate with one another without regard to=0A= sip signaling. Then, if you like you can put your o/a handling into a=0A= *component* of the b2bua that is only invoked for messages containing=0A= offers and answers.=0A= =0A= But that is an *implementation* issue, not an issue for IETF.=0A= =0A= Paul=0A= _______________________________________________=0A= dispatch mailing list=0A= dispatch@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dispatch=0A= From sohel_khan@cable.comcast.com Tue Mar 27 07:11:31 2012 Return-Path: <sohel_khan@cable.comcast.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6C021E820E for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 07:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.772 X-Spam-Level: X-Spam-Status: No, score=-101.772 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0bgEJcdVXMR for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 07:11:30 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id A865A21E820F for <dispatch@ietf.org>; Tue, 27 Mar 2012 07:11:30 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.11037366; Tue, 27 Mar 2012 07:59:12 -0600 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 10:11:33 -0400 From: "Khan, Sohel" <Sohel_Khan@cable.comcast.com> To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "dispatch@ietf.org" <dispatch@ietf.org> Thread-Topic: [dispatch] B2BUA charter/straw Thread-Index: AQHNDBDB4L/ysvgDpU2hyCI8tX9QpJZ+Dw6AgAAA7MuAAAdokIAAAzEfgAAJFACAAAK0ZoAASWsA//+9+8o= Date: Tue, 27 Mar 2012 14:11:26 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF5A92D2C3@PACDCEXMB02.cable.comcast.com> References: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D4B@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D20D@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D8C@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D23C@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220DBD@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D271@PACDCEXMB02.cable.comcast.com>, <4F71C8C2.8050805@alum.mit.edu> In-Reply-To: <4F71C8C2.8050805@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 14:11:32 -0000 Thank you Paul.=0A= How about "innovative" B2BUAs.=0A= The Border B2BUA provides its "outbound" address to the Internal B2BUA acti= ng as a "Internal Switch".=0A= The Internal B2BUA sends "Outbound" address instead of "internal address" i= n the notify message.=0A= In a such a case the outside provider sees both the B2BUAs as one virtual B= 2BUA.=0A= Does it make any sense?=0A= =0A= Sohel=0A= ________________________________________=0A= From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] on behalf of Pa= ul Kyzivat [pkyzivat@alum.mit.edu]=0A= Sent: Tuesday, March 27, 2012 8:03 AM=0A= To: dispatch@ietf.org=0A= Subject: Re: [dispatch] B2BUA charter/straw=0A= =0A= On 3/27/12 3:46 PM, Khan, Sohel wrote:=0A= > Thank you Partha. Actually, proposing a new entity and creating new chart= er process will take a long time.=0A= > I am simply trying to see whether we can include it as a task in the new = B2BUA charter.=0A= > The task may provide recommendation which messages must pass through B2BU= A and which messages must not.=0A= >=0A= > Subscribe/Notify is an example. Can we recommend Subscribe message passin= g through B2BUA but Notify bypasses B2BUA. You may say it is an implementat= ion method not a responsibility of the IETF. The issue is that multiple pro= viders/implementations creates interoperability issues. Thus, an IETF guide= line/recommendation will be very helpful.=0A= =0A= If the SUBSCRIBE establishes a new dialog, then your "B2BUA" may elect=0A= to act as a proxy and not Record-Route. It will than not be in the=0A= signaling path for the dialog.=0A= =0A= But in that case you will not be able to do topology hiding.=0A= =0A= There are other possibilities with different tradeoffs.=0A= None of this requires any changes to existing standards.=0A= =0A= Paul=0A= =0A= > ________________________________________=0A= > From: Ravindran, Parthasarathi [pravindran@sonusnet.com]=0A= > Sent: Tuesday, March 27, 2012 7:34 AM=0A= > To: Khan, Sohel; dispatch@ietf.org=0A= > Subject: RE: B2BUA charter/straw=0A= >=0A= > Sohel,=0A= >=0A= > Thanks for the clarification. You propose to introduce new SIP entity whi= ch is in between B2BUA and stateful proxy for Topology hiding and pseudo-st= ateful. IMO, your new entity is not B2BUA and pls define new entity for mor= e discussion.=0A= >=0A= > Thanks=0A= > Partha=0A= >=0A= >> -----Original Message-----=0A= >> From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com]=0A= >> Sent: Tuesday, March 27, 2012 6:34 PM=0A= >> To: Ravindran, Parthasarathi; dispatch@ietf.org=0A= >> Subject: RE: B2BUA charter/straw=0A= >>=0A= >> Thanks Partha.=0A= >> In technological innovation, nothing is impossible.=0A= >> We will need to innovate something (e.g., a B2BUA) with following=0A= >> requirements:=0A= >> 1. Topology hiding=0A= >> 2. pseudo-stateful.=0A= >>=0A= >> For example, only SIP messages with offer-answer information and BYE=0A= >> passes the B2BUA. All other messages bypass B2BUA.=0A= >>=0A= >>=0A= >> ________________________________________=0A= >> From: Ravindran, Parthasarathi [pravindran@sonusnet.com]=0A= >> Sent: Tuesday, March 27, 2012 6:53 AM=0A= >> To: Khan, Sohel; dispatch@ietf.org=0A= >> Subject: RE: B2BUA charter/straw=0A= >>=0A= >> Sohel,=0A= >>=0A= >> Topology hiding is not possible for the mid-dialog without dialog-=0A= >> stateful B2BUA. I'm not clear how stateless B2BUA entity helps here..=0A= >>=0A= >> Also, Please explain in the separate mail thread about persistent=0A= >> connection usecase as discussed in Dispatch meeting today.=0A= >>=0A= >> Thanks=0A= >> Partha=0A= >>=0A= >>> -----Original Message-----=0A= >>> From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com]=0A= >>> Sent: Tuesday, March 27, 2012 5:56 PM=0A= >>> To: Ravindran, Parthasarathi; dispatch@ietf.org=0A= >>> Subject: RE: B2BUA charter/straw=0A= >>>=0A= >>> Thanks Partha.=0A= >>> We want to take the advantage of topology hiding of the B2BUA; however,= =0A= >>> we want to save the B2BUA's implementation package (i.e., SBC) from=0A= >>> excessive chatting to improve processing. In addition, for the=0A= >>> persistent connection for incoming messages, we would like to pass the= =0A= >>> incoming new session messages bypassing the B2BUA.=0A= >>>=0A= >>>=0A= >>> ________________________________________=0A= >>> From: Ravindran, Parthasarathi [pravindran@sonusnet.com]=0A= >>> Sent: Tuesday, March 27, 2012 6:19 AM=0A= >>> To: Khan, Sohel; dispatch@ietf.org=0A= >>> Subject: RE: B2BUA charter/straw=0A= >>>=0A= >>> Sohel,=0A= >>>=0A= >>> Could you please explain the advantage of those new B2BUA over stateful= =0A= >>> proxy.=0A= >>>=0A= >>> Thanks=0A= >>> Partha=0A= >>>=0A= >>>> -----Original Message-----=0A= >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On= =0A= >>>> Behalf Of Khan, Sohel=0A= >>>> Sent: Tuesday, March 27, 2012 5:30 PM=0A= >>>> To: dispatch@ietf.org=0A= >>>> Subject: [dispatch] B2BUA charter/straw=0A= >>>>=0A= >>>> Currently, a proxy can be statefull or stateless. The advantage of=0A= >>>> stateless is to have the proxy out of the path of a SIP call after=0A= >>>> initial session messages. As I understand, currently deployed B2BUAs= =0A= >>>> are " rigidly statefull". They remain in the call path until the end= =0A= >> of=0A= >>>> the session and all the messages traverse through B2BUA. Can we=0A= >>>> convert the B2BUA to be a pseudo-statefull--i.e., for certain SIP=0A= >>>> messages, the B2BUA is statefull for some messages and for other=0A= >>>> messages of the same call, the B2BUA is stateless?=0A= >>>> Can we add this in the current B2BUA charter initiative?=0A= >>>>=0A= >>>> Sohel=0A= >>>> _______________________________________________=0A= >>>> dispatch mailing list=0A= >>>> dispatch@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/dispatch=0A= > _______________________________________________=0A= > dispatch mailing list=0A= > dispatch@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/dispatch=0A= >=0A= =0A= _______________________________________________=0A= dispatch mailing list=0A= dispatch@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dispatch=0A= From dworley@avaya.com Tue Mar 27 07:11:57 2012 Return-Path: <dworley@avaya.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D6321E81DA for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 07:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.405 X-Spam-Level: X-Spam-Status: No, score=-103.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0neBDYICWF8 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 07:11:57 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id B3C5721E820F for <dispatch@ietf.org>; Tue, 27 Mar 2012 07:11:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPLJcU/GmAcF/2dsb2JhbABFuD+BB4IJAQEBAQIBEihECwIBCA0IIRAyJQIEARIIGodjBZ4TnBuQLGMEm3KKHIMD X-IronPort-AV: E=Sophos;i="4.75,326,1330923600"; d="scan'208";a="339213561" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Mar 2012 10:10:51 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Mar 2012 10:02:12 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 27 Mar 2012 10:10:50 -0400 From: "Worley, Dale R (Dale)" <dworley@avaya.com> To: "Khan, Sohel" <Sohel_Khan@cable.comcast.com>, "dispatch@ietf.org" <dispatch@ietf.org> Date: Tue, 27 Mar 2012 10:10:49 -0400 Thread-Topic: B2BUA charter/straw Thread-Index: AQHNDBDB4L/ysvgDpU2hyCI8tX9QpJZ+K2IV Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A09BA@DC-US1MBEX4.global.avaya.com> References: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com> In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.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] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 14:11:57 -0000 > From: Khan, Sohel [Sohel_Khan@cable.comcast.com] >=20 > Currently, a proxy can be statefull or stateless. The advantage of > stateless is to have the proxy out of the path of a SIP call after > initial session messages. Actually, proxies can be: - transaction stateless (and thus necessarily dialog stateless) - transaction stateful but dialog stateless - dialog stateful (and thus necessarily transaction stateful) Dialog-stateful proxies need to Record-Route themselves into all dialogs. (Unless for a particular dialog, the proxy decides that it does not need to retain the dialog's state.) The first two types can Record-Route themselves (and thus remain in the path of the call) for various reasons. One reason is to control the path that future requests take. Another possibility is that the proxy puts some sort of state or long-term information in the Record-Route URI that will be useful in the handling of later requests. > As I understand, currently deployed B2BUAs are " rigidly > statefull". They remain in the call path until the end of the > session and all the messages traverse through B2BUA. And this is often considered to be a goal in itself, as well as a means to other goals. > Can we convert the B2BUA to be a pseudo-statefull--i.e., for certain > SIP messages, the B2BUA is statefull for some messages and for other > messages of the same call, the B2BUA is stateless? Can we add this > in the current B2BUA charter initiative? It depends on what you mean by "statefull"... Given that a B2BUA (by definition) is addressed by the Contact URIs that it generates for the dialogs on each side, it unavoidably remains in the signaling path. Given the need to rewrite the requests as they pass through and the desire for the B2BUA to hide topology, it would be very hard to implement a B2BUA without having it retain dialog state (to feed into the rewriting process), although a clever Ph.D. thesis might figure out how to do so. I would back up and ask for a more detailed explanation of the sort of behavior you are interested in, and what the benefits would be. Dale From HKaplan@acmepacket.com Tue Mar 27 08:16:39 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A53D21F88F4 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 08:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tne7K5uOW8yv for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 08:16:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E685421F88F3 for <dispatch@ietf.org>; Tue, 27 Mar 2012 08:16:37 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Mar 2012 11:16:33 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Tue, 27 Mar 2012 11:16:33 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: Colin Perkins <csp@csperkins.org>, "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Thread-Topic: [dispatch] STRAW Charter Proposal Thread-Index: AQHNDCyXRGmlJ5oFgEWQ4ypJEHAGIw== Date: Tue, 27 Mar 2012 15:16:32 +0000 Message-ID: <B5BD2B31-DE70-40BC-AEF4-9F0DAB48ACB4@acmepacket.com> References: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> <1D062974A4845E4D8A343C653804920207F1DDF2@XMB-BGL-414.cisco.com> <B03EBC9C-57F8-48AA-A722-98AD5DB658C0@acmepacket.com> <E456066D-E8A0-4462-AF6D-5B2D566E3FFA@csperkins.org> In-Reply-To: <E456066D-E8A0-4462-AF6D-5B2D566E3FFA@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <B142A0BB1BC18D43A8BACD4177FFB700@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 15:16:39 -0000 As far as I can tell from wireshark captures, some or even many transcoders= act as full endpoints, and generate their own RTCP - as if there were a TD= M loopback internally - not as RFC 3550 "translators". I am definitely not= an expert in that area, however - is it the case that most transcoders act= as translators, or as full endpoints? Should the taxonomy document for STRAW distinguish between B2BUAs that tran= scoders as RFC 3550 translators, vs. ones that transcode as full back-to-ba= ck media endpoints? Muthu - did you mean it in that context of a translator? Or did you mean i= t in the context of getting RTCP/SRTCP passed through transcoding B2BUAs, w= ithout modification? (my impression was you meant passing it through withou= t modification) -hadriel On Mar 27, 2012, at 3:42 PM, Colin Perkins wrote: > While I'm sure it's more common to terminate RTCP at the transcoder, RTP = Translators [RFC3550 section 7.2; Topo-Media-Translator in RFC5117] were in= tended to support the case where RTCP goes through the transcoder.=20 >=20 > Colin >=20 >=20 > On 27 Mar 2012, at 14:39, Hadriel Kaplan wrote: >> Umm sure, but just to be clear - if a B2BUA does transcoding it *is* the= end of RTCP (and a new RTCP beginning on the other side). As far as I kno= w, it is illogical to expect RTCP to go "through" a transcoder. >>=20 >> Are you proposing we should have a milestone for documenting specific fu= nctionality of RTCP, such as by passing through specific fields of RTCP, th= at needs to work through a transcoder? >>=20 >> -hadriel >>=20 >>=20 >> On Mar 27, 2012, at 2:22 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: >>=20 >>> I think RTCP has similar issues with B2BUAs and getting RTCP/SRTCP >>> working end-to-end across B2BUAs, in particular those B2BUAs that >>> perform transcoding/transrating of media streams, is also important. I >>> would suggest adding a deliverable for RTCP/SRTCP: >>>=20 >>> 6) A document defining the requirements for B2BUAs to support RTCP/SRTC= P >>> end-to-end. >>>=20 >>> Muthu >>>=20 >>> |-----Original Message----- >>> |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Hadriel Kaplan >>> |Sent: Tuesday, January 24, 2012 8:16 AM >>> |To: dispatch@ietf.org list >>> |Subject: [dispatch] STRAW Charter Proposal >>> | >>> |Howdy, >>> |As instructed by DISPATCH chairs, I am re-posting the STRAW Charter >>> Proposal, as a topic for the Paris >>> |meeting. >>> |The proposed charter is as follows: >>> | >>> |Description of STRAW Working Group >>> |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> |Name: Sip Traversal Required for Applications to Work (STRAW) >>> | >>> |Problem Statement: >>> |Within the context of the SIP protocol and architecture, a Back-to-Bac= k >>> User Agent (B2BUA) is any SIP >>> |device in the logical path between two User Agents performing a role >>> beyond that of a Proxy as defined >>> |in RFC 3261. The B2BUA may be as simple as a session-stateful Proxy >>> becoming a B2BUA in order to >>> |terminate dead sessions by generating BYEs; or it may be a 3PCC-style >>> agent only modifying SDP; or it >>> |may be a Session Border Controller performing such functions as in RFC >>> 5853; or it may be an >>> |Enterprise PBX terminating REFERs and such; or it may be a complete UA= S >>> and UAC implementation with a >>> |PRI loopback in-between. >>> | >>> |In its most extreme form, the scope of the SIP protocol ends at the UA= S >>> of the B2BUA, and a new SIP >>> |protocol scope begins on its UAC side. In practice, however, users >>> expect some SIP protocol aspects >>> |to go beyond the scope of the B2BUA's UAS side, and be traversed onto >>> its UAC side, as if the B2BUA >>> |was not an end unto itself; this is similar to the expectation that >>> emails work when they cross from >>> |POP and IMAP to/from SMTP. >>> | >>> |It is impossible to normatively define all the behaviors of B2BUAs in >>> general, or even subsets of them >>> |such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying >>> functions for purposes which may be >>> |unique to their environment, unique to their architecture, or unique t= o >>> the wishes of their >>> |administrator. Instead of defining all things a given type of B2BUA >>> must do, a more practical >>> |objective would be to define what very few things any B2BUA must do to >>> make a specific SIP mechanism >>> |work, and let the market decide whether to do those things. >>> | >>> |The name of this working group reflects that practical objective: if >>> there were a thin straw between >>> |the SIP UAS and UAC of a B2BUA, what must be passed through that straw >>> and used on each side. Or >>> |viewed another way, if a B2BUA were in fact a UAS and UAC connected >>> with a PRI loopback circuit, and >>> |if we could extend ISDN, what information would we carry in ISDN acros= s >>> the PRI for a specific SIP >>> |mechanism to work end-to-end. >>> | >>> |For example, the WG could produce a document which specifies that the >>> Max-Forwards header field value >>> |should be copied and decremented across the B2BUA, if the B2BUA wishes >>> to prevent loops. >>> |Administrators could then tell their B2BUA vendors to comply with the >>> document, if the administrator >>> |so wishes. >>> | >>> |Objectives: >>> |The objectives of the STRAW Working Group are to publish normative >>> documents which define which SIP >>> |header fields, parameters, MIME bodies, body content >>> fields/information, or media-plane >>> |characteristics are required to traverse between the User Agent "sides= " >>> of a B2BUA for specific >>> |functions to work. >>> | >>> |Deliverables would indicate which types of B2BUAs would apply or not. >>> For example, a document >>> |defining the requirements for end-to-end DTLS-SRTP would not apply to >>> B2BUAs which terminate media, >>> |such as transcoders or recorders. >>> | >>> |The intention of this WG is to document such requirements in separate >>> documents, per SIP or media >>> |function, instead of as one document for all functions. That will bot= h >>> reduce the time to >>> |publication, as well a provide B2BUA administrators and manufacturers >>> with simple comply/no-comply >>> |criteria. >>> | >>> | >>> |Initial Deliverables: >>> |1) A taxonomy document defining role-types of B2BUAs, as a reference >>> for other deliverables. >>> |2) A document defining the requirements for B2BUAs with respect to loo= p >>> detection/prevention. >>> |3) A document defining the requirements for B2BUAs to support >>> end-to-end and hop-by-hop media-loopback >>> |test calls. >>> |4) A document defining the requirements for B2BUAs to support DTLS-SRT= P >>> (RFC 5764) end-to-end. >>> |5) A document defining the requirements for B2BUAs to support STUN >>> connectivity checks end-to-end. >>> | >>> | >>> |_______________________________________________ >>> |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 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 From keith.drage@alcatel-lucent.com Tue Mar 27 09:02:43 2012 Return-Path: <keith.drage@alcatel-lucent.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DC121E8040 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 09:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.643 X-Spam-Level: X-Spam-Status: No, score=-109.643 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0IUmVTcBGUm for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 09:02:41 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBD321E80B7 for <dispatch@ietf.org>; Tue, 27 Mar 2012 09:02:41 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2RG2ZTe018376 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 27 Mar 2012 18:02:35 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 27 Mar 2012 18:02:34 +0200 From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> To: "Khan, Sohel" <Sohel_Khan@cable.comcast.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "dispatch@ietf.org" <dispatch@ietf.org> Date: Tue, 27 Mar 2012 18:02:31 +0200 Thread-Topic: [dispatch] B2BUA charter/straw Thread-Index: AQHNDBDB4L/ysvgDpU2hyCI8tX9QpJZ+Dw6AgAAA7MuAAAdokIAAAzEfgAAJFACAAAK0ZoAASWsA//+9+8qAAB99kA== Message-ID: <EDC0A1AE77C57744B664A310A0B23AE225636759@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <837E772D16C77141BFA5FEC3F30487FF5A92D1B5@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D4B@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D20D@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220D8C@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D23C@PACDCEXMB02.cable.comcast.com>, <387F9047F55E8C42850AD6B3A7A03C6C0E220DBD@inba-mail01.sonusnet.com> <837E772D16C77141BFA5FEC3F30487FF5A92D271@PACDCEXMB02.cable.comcast.com>, <4F71C8C2.8050805@alum.mit.edu> <837E772D16C77141BFA5FEC3F30487FF5A92D2C3@PACDCEXMB02.cable.comcast.com> In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF5A92D2C3@PACDCEXMB02.cable.comcast.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-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [dispatch] B2BUA charter/straw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 16:02:43 -0000 Essentially you are attempting to label something that is undefined. Hadrie= ls usage of the term B2BUA is still referencing something that implements t= he UA state machine on each side. Given that the idea of the new group is to define behaviour on top of such = an entity you must understand its underlying behaviour. That means either you must define that underlying behaviour to include it (= and then see Dale's reponse which I entirely agree with) or that we cannot = do it. Regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Khan, Sohel > Sent: 27 March 2012 15:11 > To: Paul Kyzivat; dispatch@ietf.org > Subject: Re: [dispatch] B2BUA charter/straw >=20 > Thank you Paul. > How about "innovative" B2BUAs. > The Border B2BUA provides its "outbound" address to the Internal B2BUA > acting as a "Internal Switch". > The Internal B2BUA sends "Outbound" address instead of "internal address" > in the notify message. > In a such a case the outside provider sees both the B2BUAs as one virtual > B2BUA. > Does it make any sense? >=20 > Sohel > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] on behalf of > Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Tuesday, March 27, 2012 8:03 AM > To: dispatch@ietf.org > Subject: Re: [dispatch] B2BUA charter/straw >=20 > On 3/27/12 3:46 PM, Khan, Sohel wrote: > > Thank you Partha. Actually, proposing a new entity and creating new > charter process will take a long time. > > I am simply trying to see whether we can include it as a task in the ne= w > B2BUA charter. > > The task may provide recommendation which messages must pass through > B2BUA and which messages must not. > > > > Subscribe/Notify is an example. Can we recommend Subscribe message > passing through B2BUA but Notify bypasses B2BUA. You may say it is an > implementation method not a responsibility of the IETF. The issue is that > multiple providers/implementations creates interoperability issues. Thus, > an IETF guideline/recommendation will be very helpful. >=20 > If the SUBSCRIBE establishes a new dialog, then your "B2BUA" may elect > to act as a proxy and not Record-Route. It will than not be in the > signaling path for the dialog. >=20 > But in that case you will not be able to do topology hiding. >=20 > There are other possibilities with different tradeoffs. > None of this requires any changes to existing standards. >=20 > Paul >=20 > > ________________________________________ > > From: Ravindran, Parthasarathi [pravindran@sonusnet.com] > > Sent: Tuesday, March 27, 2012 7:34 AM > > To: Khan, Sohel; dispatch@ietf.org > > Subject: RE: B2BUA charter/straw > > > > Sohel, > > > > Thanks for the clarification. You propose to introduce new SIP entity > which is in between B2BUA and stateful proxy for Topology hiding and > pseudo-stateful. IMO, your new entity is not B2BUA and pls define new > entity for more discussion. > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com] > >> Sent: Tuesday, March 27, 2012 6:34 PM > >> To: Ravindran, Parthasarathi; dispatch@ietf.org > >> Subject: RE: B2BUA charter/straw > >> > >> Thanks Partha. > >> In technological innovation, nothing is impossible. > >> We will need to innovate something (e.g., a B2BUA) with following > >> requirements: > >> 1. Topology hiding > >> 2. pseudo-stateful. > >> > >> For example, only SIP messages with offer-answer information and BYE > >> passes the B2BUA. All other messages bypass B2BUA. > >> > >> > >> ________________________________________ > >> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] > >> Sent: Tuesday, March 27, 2012 6:53 AM > >> To: Khan, Sohel; dispatch@ietf.org > >> Subject: RE: B2BUA charter/straw > >> > >> Sohel, > >> > >> Topology hiding is not possible for the mid-dialog without dialog- > >> stateful B2BUA. I'm not clear how stateless B2BUA entity helps here.. > >> > >> Also, Please explain in the separate mail thread about persistent > >> connection usecase as discussed in Dispatch meeting today. > >> > >> Thanks > >> Partha > >> > >>> -----Original Message----- > >>> From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com] > >>> Sent: Tuesday, March 27, 2012 5:56 PM > >>> To: Ravindran, Parthasarathi; dispatch@ietf.org > >>> Subject: RE: B2BUA charter/straw > >>> > >>> Thanks Partha. > >>> We want to take the advantage of topology hiding of the B2BUA; > however, > >>> we want to save the B2BUA's implementation package (i.e., SBC) from > >>> excessive chatting to improve processing. In addition, for the > >>> persistent connection for incoming messages, we would like to pass th= e > >>> incoming new session messages bypassing the B2BUA. > >>> > >>> > >>> ________________________________________ > >>> From: Ravindran, Parthasarathi [pravindran@sonusnet.com] > >>> Sent: Tuesday, March 27, 2012 6:19 AM > >>> To: Khan, Sohel; dispatch@ietf.org > >>> Subject: RE: B2BUA charter/straw > >>> > >>> Sohel, > >>> > >>> Could you please explain the advantage of those new B2BUA over > stateful > >>> proxy. > >>> > >>> Thanks > >>> Partha > >>> > >>>> -----Original Message----- > >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] O= n > >>>> Behalf Of Khan, Sohel > >>>> Sent: Tuesday, March 27, 2012 5:30 PM > >>>> To: dispatch@ietf.org > >>>> Subject: [dispatch] B2BUA charter/straw > >>>> > >>>> Currently, a proxy can be statefull or stateless. The advantage of > >>>> stateless is to have the proxy out of the path of a SIP call after > >>>> initial session messages. As I understand, currently deployed B2BUA= s > >>>> are " rigidly statefull". They remain in the call path until the end > >> of > >>>> the session and all the messages traverse through B2BUA. Can we > >>>> convert the B2BUA to be a pseudo-statefull--i.e., for certain SIP > >>>> messages, the B2BUA is statefull for some messages and for other > >>>> messages of the same call, the B2BUA is stateless? > >>>> Can we add this in the current B2BUA charter initiative? > >>>> > >>>> Sohel > >>>> _______________________________________________ > >>>> 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mperumal@cisco.com Tue Mar 27 09:09:45 2012 Return-Path: <mperumal@cisco.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AEB21F89B3 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 09:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.77 X-Spam-Level: X-Spam-Status: No, score=-9.77 tagged_above=-999 required=5 tests=[AWL=0.829, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtNiPeqPj+mb for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 09:09:43 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2C72D21F89AF for <dispatch@ietf.org>; Tue, 27 Mar 2012 09:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=8555; q=dns/txt; s=iport; t=1332864582; x=1334074182; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6DTlZ8VWiPwXWUF+0lNnJDshbzB1e7lx6KgzaQzR7ag=; b=G6RCSbt6xr9DpRyBkui1DlDgyXKis9EBW/okrrscLlvNqMCGaNjTlAs+ JPCXE/xTeYbxtQnZPIcL2cBwgiutjWXL2Gk1iNWkwOiQ6mk5c7KWIaqQK vrh/Ya0c9NuGq6/hvRYb/2s3TzxJ4+Nx2HMJpbMxB4lot9UjDUw1+kN9N g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAEflcU9Io8UY/2dsb2JhbABFuUyCCQEBAQQBAQEPAR0KLQQDCwwEAgEIDgMBAwEBCwYXAQYBJh8DBggCBAEKCAgah2gLmyafE5AsYwSIVo4cjTSBaIJv X-IronPort-AV: E=Sophos;i="4.73,658,1325462400"; d="scan'208";a="8727766" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 27 Mar 2012 16:09:40 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2RG9eGn022476; Tue, 27 Mar 2012 16:09:40 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, 27 Mar 2012 21:39:40 +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, 27 Mar 2012 21:39:37 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020803E417@XMB-BGL-414.cisco.com> In-Reply-To: <B5BD2B31-DE70-40BC-AEF4-9F0DAB48ACB4@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] STRAW Charter Proposal Thread-Index: AQHNDCyXRGmlJ5oFgEWQ4ypJEHAGI5Z+SZJA References: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> <1D062974A4845E4D8A343C653804920207F1DDF2@XMB-BGL-414.cisco.com> <B03EBC9C-57F8-48AA-A722-98AD5DB658C0@acmepacket.com> <E456066D-E8A0-4462-AF6D-5B2D566E3FFA@csperkins.org> <B5BD2B31-DE70-40BC-AEF4-9F0DAB48ACB4@acmepacket.com> From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> To: "Hadriel Kaplan" <HKaplan@acmepacket.com>, "Colin Perkins" <csp@csperkins.org> X-OriginalArrivalTime: 27 Mar 2012 16:09:40.0110 (UTC) FILETIME=[038E42E0:01CD0C34] Cc: dispatch@ietf.org Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 16:09:45 -0000 Guess I wasn't clear when I said "getting RTCP/SRTCP working end-to-end across B2BUAs". I only meant getting RTCP working across B2BUAs so that the endpoints can take useful decisions based on RTCP. I agree there would be cases like transcoding where a B2BUA would have to terminate RTCP coming from one side and generate its own RTCP and there would also be cases where a B2BUA would have to simply pass across RTCP. However, information like IP addresses carried inside RTCP CNAME might have impact on B2BUA policies like address hiding when RTCP is passed across. So, similar to STUN, documenting how a B2BUA should handle RTCP for the various use cases would be useful I think. Muthu |-----Original Message----- |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |Sent: Tuesday, March 27, 2012 5:17 PM |To: Colin Perkins; Muthu Arul Mozhi Perumal (mperumal) |Cc: dispatch@ietf.org list |Subject: Re: [dispatch] STRAW Charter Proposal | | |As far as I can tell from wireshark captures, some or even many transcoders act as full endpoints, and |generate their own RTCP - as if there were a TDM loopback internally - not as RFC 3550 "translators". |I am definitely not an expert in that area, however - is it the case that most transcoders act as |translators, or as full endpoints? | |Should the taxonomy document for STRAW distinguish between B2BUAs that transcoders as RFC 3550 |translators, vs. ones that transcode as full back-to-back media endpoints? | |Muthu - did you mean it in that context of a translator? Or did you mean it in the context of getting |RTCP/SRTCP passed through transcoding B2BUAs, without modification? (my impression was you meant |passing it through without modification) | |-hadriel | | |On Mar 27, 2012, at 3:42 PM, Colin Perkins wrote: | |> While I'm sure it's more common to terminate RTCP at the transcoder, RTP Translators [RFC3550 |section 7.2; Topo-Media-Translator in RFC5117] were intended to support the case where RTCP goes |through the transcoder. |> |> Colin |> |> |> On 27 Mar 2012, at 14:39, Hadriel Kaplan wrote: |>> Umm sure, but just to be clear - if a B2BUA does transcoding it *is* the end of RTCP (and a new |RTCP beginning on the other side). As far as I know, it is illogical to expect RTCP to go "through" a |transcoder. |>> |>> Are you proposing we should have a milestone for documenting specific functionality of RTCP, such |as by passing through specific fields of RTCP, that needs to work through a transcoder? |>> |>> -hadriel |>> |>> |>> On Mar 27, 2012, at 2:22 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: |>> |>>> I think RTCP has similar issues with B2BUAs and getting RTCP/SRTCP |>>> working end-to-end across B2BUAs, in particular those B2BUAs that |>>> perform transcoding/transrating of media streams, is also important. I |>>> would suggest adding a deliverable for RTCP/SRTCP: |>>> |>>> 6) A document defining the requirements for B2BUAs to support RTCP/SRTCP |>>> end-to-end. |>>> |>>> Muthu |>>> |>>> |-----Original Message----- |>>> |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On |>>> Behalf Of Hadriel Kaplan |>>> |Sent: Tuesday, January 24, 2012 8:16 AM |>>> |To: dispatch@ietf.org list |>>> |Subject: [dispatch] STRAW Charter Proposal |>>> | |>>> |Howdy, |>>> |As instructed by DISPATCH chairs, I am re-posting the STRAW Charter |>>> Proposal, as a topic for the Paris |>>> |meeting. |>>> |The proposed charter is as follows: |>>> | |>>> |Description of STRAW Working Group |>>> = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |>>> |Name: Sip Traversal Required for Applications to Work (STRAW) |>>> | |>>> |Problem Statement: |>>> |Within the context of the SIP protocol and architecture, a Back-to-Back |>>> User Agent (B2BUA) is any SIP |>>> |device in the logical path between two User Agents performing a role |>>> beyond that of a Proxy as defined |>>> |in RFC 3261. The B2BUA may be as simple as a session-stateful Proxy |>>> becoming a B2BUA in order to |>>> |terminate dead sessions by generating BYEs; or it may be a 3PCC-style |>>> agent only modifying SDP; or it |>>> |may be a Session Border Controller performing such functions as in RFC |>>> 5853; or it may be an |>>> |Enterprise PBX terminating REFERs and such; or it may be a complete UAS |>>> and UAC implementation with a |>>> |PRI loopback in-between. |>>> | |>>> |In its most extreme form, the scope of the SIP protocol ends at the UAS |>>> of the B2BUA, and a new SIP |>>> |protocol scope begins on its UAC side. In practice, however, users |>>> expect some SIP protocol aspects |>>> |to go beyond the scope of the B2BUA's UAS side, and be traversed onto |>>> its UAC side, as if the B2BUA |>>> |was not an end unto itself; this is similar to the expectation that |>>> emails work when they cross from |>>> |POP and IMAP to/from SMTP. |>>> | |>>> |It is impossible to normatively define all the behaviors of B2BUAs in |>>> general, or even subsets of them |>>> |such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying |>>> functions for purposes which may be |>>> |unique to their environment, unique to their architecture, or unique to |>>> the wishes of their |>>> |administrator. Instead of defining all things a given type of B2BUA |>>> must do, a more practical |>>> |objective would be to define what very few things any B2BUA must do to |>>> make a specific SIP mechanism |>>> |work, and let the market decide whether to do those things. |>>> | |>>> |The name of this working group reflects that practical objective: if |>>> there were a thin straw between |>>> |the SIP UAS and UAC of a B2BUA, what must be passed through that straw |>>> and used on each side. Or |>>> |viewed another way, if a B2BUA were in fact a UAS and UAC connected |>>> with a PRI loopback circuit, and |>>> |if we could extend ISDN, what information would we carry in ISDN across |>>> the PRI for a specific SIP |>>> |mechanism to work end-to-end. |>>> | |>>> |For example, the WG could produce a document which specifies that the |>>> Max-Forwards header field value |>>> |should be copied and decremented across the B2BUA, if the B2BUA wishes |>>> to prevent loops. |>>> |Administrators could then tell their B2BUA vendors to comply with the |>>> document, if the administrator |>>> |so wishes. |>>> | |>>> |Objectives: |>>> |The objectives of the STRAW Working Group are to publish normative |>>> documents which define which SIP |>>> |header fields, parameters, MIME bodies, body content |>>> fields/information, or media-plane |>>> |characteristics are required to traverse between the User Agent "sides" |>>> of a B2BUA for specific |>>> |functions to work. |>>> | |>>> |Deliverables would indicate which types of B2BUAs would apply or not. |>>> For example, a document |>>> |defining the requirements for end-to-end DTLS-SRTP would not apply to |>>> B2BUAs which terminate media, |>>> |such as transcoders or recorders. |>>> | |>>> |The intention of this WG is to document such requirements in separate |>>> documents, per SIP or media |>>> |function, instead of as one document for all functions. That will both |>>> reduce the time to |>>> |publication, as well a provide B2BUA administrators and manufacturers |>>> with simple comply/no-comply |>>> |criteria. |>>> | |>>> | |>>> |Initial Deliverables: |>>> |1) A taxonomy document defining role-types of B2BUAs, as a reference |>>> for other deliverables. |>>> |2) A document defining the requirements for B2BUAs with respect to loop |>>> detection/prevention. |>>> |3) A document defining the requirements for B2BUAs to support |>>> end-to-end and hop-by-hop media-loopback |>>> |test calls. |>>> |4) A document defining the requirements for B2BUAs to support DTLS-SRTP |>>> (RFC 5764) end-to-end. |>>> |5) A document defining the requirements for B2BUAs to support STUN |>>> connectivity checks end-to-end. |>>> | |>>> | |>>> |_______________________________________________ |>>> |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 |> |> |> -- |> Colin Perkins |> http://csperkins.org/ |> |> |> From jbakker@rim.com Tue Mar 27 10:37:07 2012 Return-Path: <jbakker@rim.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E2E21F85A1 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 10:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.017 X-Spam-Level: X-Spam-Status: No, score=-5.017 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baC71HfwFdTz for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 10:37:07 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3DE21F8455 for <dispatch@ietf.org>; Tue, 27 Mar 2012 10:37:06 -0700 (PDT) X-AuditID: 0a41282f-b7f5a6d00000743d-60-4f71fabfb759 Received: from XHT110CNC.rim.net (xht110cnc.rim.net [10.65.22.55]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id F8.7A.29757.FBAF17F4; Tue, 27 Mar 2012 17:37:04 +0000 (GMT) Received: from XCT104ADS.rim.net (10.67.111.45) by XHT110CNC.rim.net (10.65.22.55) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 27 Mar 2012 13:37:03 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.01.0339.001; Tue, 27 Mar 2012 12:37:02 -0500 From: John-Luc Bakker <jbakker@rim.com> To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "Gonzalo.Camarillo@ericsson.com" <Gonzalo.Camarillo@ericsson.com> Thread-Topic: draft-bakker-sipping-3gpp-ims-xml-body-handling-07 (was: RE: [dispatch] I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt) Thread-Index: AQHNDEA4nHIjIWeYK0SVL4/+gfx+Dw== Date: Tue, 27 Mar 2012 17:37:01 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.254] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPKsWRmVeSWpSXmKPExsXC5ShmrnvgV6G/wfL1zBZLJy1gtdi0fCWT xYoNB1gdmD3+vv/A5PHr61U2jyVLfjIFMEc1MNok5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTtdJJDwjztj/aUNrAVPLSrmvdjI3MB4Ta+LkZNDQsBE4seP w6wQtpjEhXvr2boYuTiEBHqYJNoW3IdyljJK7D96jxnC2cwoceRmGwtIC5uAusTWFduZQWwR gVyJpgsfGUFsZgFtif/X1zGCNAgLzGCUuNo2AWyUiMBcRom325+yQ3ToSTz/fIEJxGYRUJXY ffUKmM0r4CbR3z2VBWLdfEaJVdsvg63gFHCXWNZ4H2w1I9C130+tYYJYJy5x68l8JogvBCSW 7DnPDGGLSrx8/A/oOw4gW1Hi9ek6iHIdiQW7P7HBXLps4WtmiL2CEidnPgEbLyQgI9Hatott AqPELCQbZiFpn4WkfRaS9gWMLKsYBXMzig3MDJLzkvWKMnP18lJLNjGCU46G/g7Gvr1ahxgF OBiVeHj5Phf6C7EmlhVX5h5ilOBgVhLh1Y4CCvGmJFZWpRblxxeV5qQWH2K0AIbQRGYp7uR8 YDrMK4k3NjBA4SiJ8y5eqeUvJJAOTGTZqakFqUUwrUwcnFINjAuZzWrXKUmWRt3J+Hlpx9z/ rj/yCtbW/jkneuPhd8tpf9gm/d6Y6lxlueBMeaXZl94z77mepltFr73CWVDmk/OMXXSp2e19 2VK3XinIqNQZ7F89PzP7WNTv14+XH16r+NbyaJHI8ZjL83NDKyy5g3z3K9s5MZ8uenPBY6q8 OOuv8JVsro4/7iixFGckGmoxFxUnAgBiBl+NUgMAAA== Cc: "dispatch@ietf.org" <dispatch@ietf.org> Subject: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 (was: RE: I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 17:37:08 -0000 Dear all, I have just made revision 8 of draft-bakker-sipping-3gpp-ims-xml-body-handli= ng available following offline discussion. Biggest addition is the new secti= on 2.1 which aims to further motivate the need for the ID. You can find the HTML formatted version here: http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-handling-0= 8 I am looking forward to hearing about any concerns you may have. Kind regards, John-Luc -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf= Of John-Luc Bakker Sent: Tuesday, March 20, 2012 1:53 PM To: Paul Kyzivat; Gonzalo.Camarillo@ericsson.com Cc: dispatch@ietf.org; sipping Subject: Re: [dispatch] I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-h= andling-07.txt Hi, Thanks, Paul for reviewing the draft. Appologies for having delayed this response. Let me address first the question about this being a SIPPING draft: I intend= to ask Gonzallo to sponsor this draft. To collect any further comments and= ensure visibility (sine the sipping list is obsolete), I have copied the DI= SPATCH list. See also inline with <JL>. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Saturday, December 03, 2011 12:11 PM To: John-Luc Bakker Cc: sipping Subject: Re: I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.= txt I'm commenting on this on the (now obsolete) sipping list because this has sipping in its name. This may not be the best place. I suppose an alternative is rai. ISTM that there are three degrees of freedom here for identifying how to process these bodies: - content-disposition - content-type - the actual content of the body Of these, the content-disposition is the most heavy weight in terms of mechanism, while the actual content of the body is the least heavy-weight. So, I wonder why you have chosen to use one content-type, that seems to already contain distinct representations for the differing behaviors of interest, and yet use distinct content-dispositions. I think you could use a single content-disposition and get the same effect. I guess multiple content-dispositions might make sense if they are processed by different entities, so that only the intended entities need decode the body. <JL> The reason for having two content dispositions is because there are dif= ferent behaviors for the same content-type when received by different entiti= es. <JL> There are two different entities that apply a different behavior when r= eceiving the body, say behavior A and behavior B. However, XML elements pres= ent in the body trigger behavior A (in the abstract of the draft, behavior (= 2)) by entity A and if not present, no further behavior by entity A is speci= fied in this draft. Other XML elements present in the body trigger one of a= set of behaviors B (in the abstract of the draft, behaviors (1) and (3)) by= entity B and if not present, no further behavior by entity B is specified i= n this draft. It would also make sense if the same identical body representation was processed differently based on the content-disposition. <JL> The bodies triggering the different behaviors are indeed not identical.= <JL> However, the content-dispositions are processed by different entities,= which is a reason for proposing these content-disposition values. But I don't think either of those is the case here. So I would find it helpf= ul if this draft explained why it chooses to use multiple content-dispositio= ns. <JL> The draft illustrates that, in IMS, different entities receive bodies w= ith the content-type, and apply different behaviors. The draft further sugge= sts that the applicability of these values may be limited to IMS. Do you see= a need for a general discussion of this approach since the applicability is= limited to IMS? I also think it would be useful to say something about how you expect the handling parameter to be used with these dispositions. If handling=3Drequired (the default) is used, then any UA that gets this must fail the request unless it is able to handle the body. If handling=3Doptional is specified, then that need not be so. <JL> The handling parameter is mentioned in RFC 3261 and this draft refers t= o that RFC. RFC 3261 refers to RFC 3204. This draft does not change the beha= vior and interpretation of the parameter and its values. It should not be ne= cessary to repeat what has already been documented in RFC 3261. Do you see d= ifferent behavior that goes beyond what has been documented? Thanks, Paul On 12/3/11 5:08 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > Title : Specification of 3GPP IM CN Subsystem XML body handling > Author(s) : John-Luc Bakker > Filename : draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt > Pages : 7 > Date : 2011-12-02 > > This document registers new disposition-types for the Content- > Disposition header field that apply to the application/3gpp-ims+xml > body used by 3GPP. The applicability of these content-disposition > values are limited to 3GPP IMS. The application/3gpp-ims+xml body > has the following three distinct uses: (1) for redirecting the > emergency session to use a different domain (e.g. using a Circuit > Switched call), (2) for delivering user profile specific information > from the SIP registrar to an Application Server, and (3) for causing > a UAC to attempt to re-register with the IMS. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body= -handling-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-= handling-07.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From ietf@meetecho.com Tue Mar 27 12:24:21 2012 Return-Path: <ietf@meetecho.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C756321E80AD for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 12:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Lo8SVn02Pyz for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 12:24:21 -0700 (PDT) Received: from smtplq02.aruba.it (smtplqs-out28.aruba.it [62.149.158.68]) by ietfa.amsl.com (Postfix) with SMTP id CC16B21E804B for <dispatch@ietf.org>; Tue, 27 Mar 2012 12:24:20 -0700 (PDT) Received: (qmail 6931 invoked by uid 89); 27 Mar 2012 19:24:19 -0000 Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq02.aruba.it with SMTP; 27 Mar 2012 19:24:19 -0000 Received: (qmail 32628 invoked by uid 89); 27 Mar 2012 19:24:19 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp1.ad.aruba.it with SMTP; 27 Mar 2012 19:24:19 -0000 Message-ID: <4F7213DF.4050605@meetecho.com> Date: Tue, 27 Mar 2012 21:24:15 +0200 From: Meetecho IETF support <ietf@meetecho.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho <team@meetecho.com> Subject: [dispatch] Meetecho session recording available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 19:24:21 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of DISPATCH session at IETF-83 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/83/remote-participation.html#Meetecho), or by directly accessing the following URL: http://www.meetecho.com/ietf83/recordings#DISPATCH_IETF83 For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From HKaplan@acmepacket.com Tue Mar 27 14:08:00 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BFD21E80F2 for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 14:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FkSMIqZB9ky for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 14:07:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F0B9221E80F0 for <dispatch@ietf.org>; Tue, 27 Mar 2012 14:07:58 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Mar 2012 17:07:54 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Tue, 27 Mar 2012 17:07:54 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Thread-Topic: [dispatch] STRAW Charter Proposal Thread-Index: AQHNDF2sPz1lVkPkGkeq+R6Mgxn0zA== Date: Tue, 27 Mar 2012 21:07:53 +0000 Message-ID: <2EF74DA4-83EB-4978-B0DF-E65FC9EAE7CC@acmepacket.com> References: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> <1D062974A4845E4D8A343C653804920207F1DDF2@XMB-BGL-414.cisco.com> <B03EBC9C-57F8-48AA-A722-98AD5DB658C0@acmepacket.com> <E456066D-E8A0-4462-AF6D-5B2D566E3FFA@csperkins.org> <B5BD2B31-DE70-40BC-AEF4-9F0DAB48ACB4@acmepacket.com> <1D062974A4845E4D8A343C65380492020803E417@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020803E417@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <8E9FB65852D1234CA520B485581C0D0B@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "<dispatch@ietf.org>" <dispatch@ietf.org>, Colin Perkins <csp@csperkins.org> Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 27 Mar 2012 21:08:01 -0000 Can you suggest milestone text for it? -hadriel On Mar 27, 2012, at 6:09 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: > Guess I wasn't clear when I said "getting RTCP/SRTCP working end-to-end > across B2BUAs". I only meant getting RTCP working across B2BUAs so that > the endpoints can take useful decisions based on RTCP. I agree there > would be cases like transcoding where a B2BUA would have to terminate > RTCP coming from one side and generate its own RTCP and there would also > be cases where a B2BUA would have to simply pass across RTCP. However, > information like IP addresses carried inside RTCP CNAME might have > impact on B2BUA policies like address hiding when RTCP is passed across. >=20 > So, similar to STUN, documenting how a B2BUA should handle RTCP for the > various use cases would be useful I think. >=20 > Muthu >=20 > |-----Original Message----- > |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > |Sent: Tuesday, March 27, 2012 5:17 PM > |To: Colin Perkins; Muthu Arul Mozhi Perumal (mperumal) > |Cc: dispatch@ietf.org list > |Subject: Re: [dispatch] STRAW Charter Proposal > | > | > |As far as I can tell from wireshark captures, some or even many > transcoders act as full endpoints, and > |generate their own RTCP - as if there were a TDM loopback internally - > not as RFC 3550 "translators". > |I am definitely not an expert in that area, however - is it the case > that most transcoders act as > |translators, or as full endpoints? > | > |Should the taxonomy document for STRAW distinguish between B2BUAs that > transcoders as RFC 3550 > |translators, vs. ones that transcode as full back-to-back media > endpoints? > | > |Muthu - did you mean it in that context of a translator? Or did you > mean it in the context of getting > |RTCP/SRTCP passed through transcoding B2BUAs, without modification? (my > impression was you meant > |passing it through without modification) > | > |-hadriel > | > | > |On Mar 27, 2012, at 3:42 PM, Colin Perkins wrote: > | > |> While I'm sure it's more common to terminate RTCP at the transcoder, > RTP Translators [RFC3550 > |section 7.2; Topo-Media-Translator in RFC5117] were intended to support > the case where RTCP goes > |through the transcoder. > |> > |> Colin > |> > |> > |> On 27 Mar 2012, at 14:39, Hadriel Kaplan wrote: > |>> Umm sure, but just to be clear - if a B2BUA does transcoding it *is* > the end of RTCP (and a new > |RTCP beginning on the other side). As far as I know, it is illogical > to expect RTCP to go "through" a > |transcoder. > |>> > |>> Are you proposing we should have a milestone for documenting > specific functionality of RTCP, such > |as by passing through specific fields of RTCP, that needs to work > through a transcoder? > |>> > |>> -hadriel > |>> > |>> > |>> On Mar 27, 2012, at 2:22 PM, Muthu Arul Mozhi Perumal (mperumal) > wrote: > |>> > |>>> I think RTCP has similar issues with B2BUAs and getting RTCP/SRTCP > |>>> working end-to-end across B2BUAs, in particular those B2BUAs that > |>>> perform transcoding/transrating of media streams, is also > important. I > |>>> would suggest adding a deliverable for RTCP/SRTCP: > |>>> > |>>> 6) A document defining the requirements for B2BUAs to support > RTCP/SRTCP > |>>> end-to-end. > |>>> > |>>> Muthu > |>>> > |>>> |-----Original Message----- > |>>> |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > |>>> Behalf Of Hadriel Kaplan > |>>> |Sent: Tuesday, January 24, 2012 8:16 AM > |>>> |To: dispatch@ietf.org list > |>>> |Subject: [dispatch] STRAW Charter Proposal > |>>> | > |>>> |Howdy, > |>>> |As instructed by DISPATCH chairs, I am re-posting the STRAW > Charter > |>>> Proposal, as a topic for the Paris > |>>> |meeting. > |>>> |The proposed charter is as follows: > |>>> | > |>>> |Description of STRAW Working Group > |>>> |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > |>>> |Name: Sip Traversal Required for Applications to Work (STRAW) > |>>> | > |>>> |Problem Statement: > |>>> |Within the context of the SIP protocol and architecture, a > Back-to-Back > |>>> User Agent (B2BUA) is any SIP > |>>> |device in the logical path between two User Agents performing a > role > |>>> beyond that of a Proxy as defined > |>>> |in RFC 3261. The B2BUA may be as simple as a session-stateful > Proxy > |>>> becoming a B2BUA in order to > |>>> |terminate dead sessions by generating BYEs; or it may be a > 3PCC-style > |>>> agent only modifying SDP; or it > |>>> |may be a Session Border Controller performing such functions as in > RFC > |>>> 5853; or it may be an > |>>> |Enterprise PBX terminating REFERs and such; or it may be a > complete UAS > |>>> and UAC implementation with a > |>>> |PRI loopback in-between. > |>>> | > |>>> |In its most extreme form, the scope of the SIP protocol ends at > the UAS > |>>> of the B2BUA, and a new SIP > |>>> |protocol scope begins on its UAC side. In practice, however, > users > |>>> expect some SIP protocol aspects > |>>> |to go beyond the scope of the B2BUA's UAS side, and be traversed > onto > |>>> its UAC side, as if the B2BUA > |>>> |was not an end unto itself; this is similar to the expectation > that > |>>> emails work when they cross from > |>>> |POP and IMAP to/from SMTP. > |>>> | > |>>> |It is impossible to normatively define all the behaviors of B2BUAs > in > |>>> general, or even subsets of them > |>>> |such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying > |>>> functions for purposes which may be > |>>> |unique to their environment, unique to their architecture, or > unique to > |>>> the wishes of their > |>>> |administrator. Instead of defining all things a given type of > B2BUA > |>>> must do, a more practical > |>>> |objective would be to define what very few things any B2BUA must > do to > |>>> make a specific SIP mechanism > |>>> |work, and let the market decide whether to do those things. > |>>> | > |>>> |The name of this working group reflects that practical objective: > if > |>>> there were a thin straw between > |>>> |the SIP UAS and UAC of a B2BUA, what must be passed through that > straw > |>>> and used on each side. Or > |>>> |viewed another way, if a B2BUA were in fact a UAS and UAC > connected > |>>> with a PRI loopback circuit, and > |>>> |if we could extend ISDN, what information would we carry in ISDN > across > |>>> the PRI for a specific SIP > |>>> |mechanism to work end-to-end. > |>>> | > |>>> |For example, the WG could produce a document which specifies that > the > |>>> Max-Forwards header field value > |>>> |should be copied and decremented across the B2BUA, if the B2BUA > wishes > |>>> to prevent loops. > |>>> |Administrators could then tell their B2BUA vendors to comply with > the > |>>> document, if the administrator > |>>> |so wishes. > |>>> | > |>>> |Objectives: > |>>> |The objectives of the STRAW Working Group are to publish normative > |>>> documents which define which SIP > |>>> |header fields, parameters, MIME bodies, body content > |>>> fields/information, or media-plane > |>>> |characteristics are required to traverse between the User Agent > "sides" > |>>> of a B2BUA for specific > |>>> |functions to work. > |>>> | > |>>> |Deliverables would indicate which types of B2BUAs would apply or > not. > |>>> For example, a document > |>>> |defining the requirements for end-to-end DTLS-SRTP would not apply > to > |>>> B2BUAs which terminate media, > |>>> |such as transcoders or recorders. > |>>> | > |>>> |The intention of this WG is to document such requirements in > separate > |>>> documents, per SIP or media > |>>> |function, instead of as one document for all functions. That will > both > |>>> reduce the time to > |>>> |publication, as well a provide B2BUA administrators and > manufacturers > |>>> with simple comply/no-comply > |>>> |criteria. > |>>> | > |>>> | > |>>> |Initial Deliverables: > |>>> |1) A taxonomy document defining role-types of B2BUAs, as a > reference > |>>> for other deliverables. > |>>> |2) A document defining the requirements for B2BUAs with respect to > loop > |>>> detection/prevention. > |>>> |3) A document defining the requirements for B2BUAs to support > |>>> end-to-end and hop-by-hop media-loopback > |>>> |test calls. > |>>> |4) A document defining the requirements for B2BUAs to support > DTLS-SRTP > |>>> (RFC 5764) end-to-end. > |>>> |5) A document defining the requirements for B2BUAs to support STUN > |>>> connectivity checks end-to-end. > |>>> | > |>>> | > |>>> |_______________________________________________ > |>>> |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 > |> > |> > |> -- > |> Colin Perkins > |> http://csperkins.org/ > |> > |> > |> >=20 From HKaplan@acmepacket.com Tue Mar 27 17:47:30 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5161221E80FE for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 17:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoIqshfFEmVc for <dispatch@ietfa.amsl.com>; Tue, 27 Mar 2012 17:47:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6115C21E8036 for <dispatch@ietf.org>; Tue, 27 Mar 2012 17:47:29 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Mar 2012 20:47:27 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Tue, 27 Mar 2012 20:47:27 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: "dispatch@ietf.org list" <dispatch@ietf.org> Thread-Topic: Updated STRAW Charter Thread-Index: AQHNDHxYvQzp4HD8R0uPK/1ZqdVL3g== Date: Wed, 28 Mar 2012 00:47:26 +0000 Message-ID: <1B990F50-65BF-4A42-B9AC-4A1702DC25BF@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <305E2864D00D6740B1A983C1CCB40832@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [dispatch] Updated STRAW Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Mar 2012 00:47:30 -0000 Howdy, I have reviewed today's DISPATCH Meetecho recording, and modified the chart= er as below - I can't attest to it representing everyone's input accurately= , so please review it and provide feedback if it does not reflect your wish= es. --------------------------------------------- Major changes: - removed the paragraph about delivering separate documents of discrete fun= ctions - added a paragraph in objectives about it covering existing work - removed the deliverable for identifying specific features/capabilities su= pport - added a deliverable for the taxonomy doc - added a deliverable for a framework doc - added a deliverable for end-to-end RTCP --------------------------------------------- Description of STRAW Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Name: Sip Traversal Required for Applications to Work (STRAW) Problem Statement:=20 Within the context of the SIP protocol and architecture, a Back-to-Back Use= r Agent (B2BUA) is any SIP device in the logical path between two User Agen= ts performing a role beyond that of a Proxy as defined in RFC 3261. The B2= BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order = to terminate dead sessions by generating BYEs; or it may be a 3PCC-style ag= ent only modifying SDP; or it may be a Session Border Controller performing= such functions as in RFC 5853; or it may be an Enterprise PBX terminating = REFERs and such; or it may be a complete UAS and UAC implementation with a = PRI loopback in-between.=20 In its most extreme form, the scope of the SIP protocol ends at the UAS of = the B2BUA, and a new SIP protocol scope begins on its UAC side. In practic= e, however, users expect some SIP protocol aspects to go beyond the scope o= f the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA= was not an end unto itself; this is similar to the expectation that emails= work when they cross from POP and IMAP to/from SMTP. It is impossible to normatively define all the behaviors of B2BUAs in gener= al, or even subsets of them such as SBCs or PBXs. Unlike consumer NATs, B2B= UAs perform widely varying functions for purposes which may be unique to th= eir environment, unique to their architecture, or unique to the wishes of t= heir administrator. Instead of defining all things a given type of B2BUA m= ust do, a more practical objective would be to define what very few things = any B2BUA must do to make a specific SIP mechanism work, and let the market= decide whether to do those things. The name of this working group reflects that practical objective: if there = were a thin straw between the SIP UAS and UAC of a B2BUA, what must be pass= ed through that straw and used on each side. Or viewed another way, if a B= 2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and = if we could extend ISDN, what information would we carry in ISDN across the= PRI for a specific SIP mechanism to work end-to-end. For example, the WG could produce a document which specifies that the Max-F= orwards header field value should be copied and decremented across the B2BU= A, if the B2BUA wishes to prevent infinite loops. Administrators could the= n tell their B2BUA vendors to comply with the document, if the administrato= r so wishes. Objectives: The objectives of the STRAW Working Group are to publish normative document= s which define which SIP header fields, parameters, MIME bodies, body conte= nt fields/information, or media-plane characteristics are required to trave= rse between the User Agent "sides" of a B2BUA for specific functions to wor= k. =20 The specific functions covered are expected to relate to already-published = RFCs or existing RAI area work, as opposed to all future IETF work. In oth= er words, the Working Group is not meant to be a never-ending source for B2= BUA requirements in the RAI area. Deliverables would indicate which types of B2BUAs would apply or not. For = example, a document defining the requirements for end-to-end DTLS-SRTP woul= d not apply to B2BUAs which terminate media, such as transcoders or recorde= rs. Initial Deliverables: 1) A taxonomy document defining role-types of B2BUAs, as a reference for ot= her deliverables. 2) A framework document for future IETF RFCs to use as considerations for t= heir own B2BUA requirements. 3) A document defining the requirements for B2BUAs with respect to loop det= ection/prevention. 4) A document defining the requirements for B2BUAs to support end-to-end an= d hop-by-hop media-loopback test calls. 5) A document defining the requirements for B2BUAs to support DTLS-SRTP (RF= C 5764) end-to-end. 6) A document defining the requirements for B2BUAs to support STUN message = transactions end-to-end. 7) A document defining the requirements for B2BUAs to support RTCP end-to-e= nd. From D.Malas@cablelabs.com Wed Mar 28 00:44:02 2012 Return-Path: <D.Malas@cablelabs.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B378921F880E for <dispatch@ietfa.amsl.com>; Wed, 28 Mar 2012 00:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.365 X-Spam-Level: X-Spam-Status: No, score=-100.365 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4YFjLBX3Ba3 for <dispatch@ietfa.amsl.com>; Wed, 28 Mar 2012 00:44:02 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id CF97421F880B for <dispatch@ietf.org>; Wed, 28 Mar 2012 00:44:01 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2S7hxKu026048; Wed, 28 Mar 2012 01:43:59 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 28 Mar 2012 01:43:59 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 28 Mar 2012 01:43:59 -0600 From: Daryl Malas <D.Malas@cablelabs.com> To: Hadriel Kaplan <HKaplan@acmepacket.com>, "dispatch@ietf.org list" <dispatch@ietf.org> Date: Wed, 28 Mar 2012 01:43:57 -0600 Thread-Topic: [dispatch] Updated STRAW Charter Thread-Index: Ac0Mtolwr94I3FmRR1qAXByNShZpkA== Message-ID: <CB988C2B.D9DB%d.malas@cablelabs.com> In-Reply-To: <1B990F50-65BF-4A42-B9AC-4A1702DC25BF@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dispatch] Updated STRAW Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Mar 2012 07:44:03 -0000 Hadriel, Thank you for quickly turning around a new charter. In general, I'm good with the proposed changes. With regards to the "framework" deliverable, I was envisioning a framework for creating relevant requirements for a B2BUA AND detailing appropriate text for "considerations" sections of IETF drafts. This may apply to unidentified past I-Ds/RFCs or future I-Ds/RFCs. With this in mind, I suggest the following change to the deliverable: From: "A framework document for future IETF RFCs to use as considerations for their own B2BUA requirements." To: "A framework document for defining requirements and considerations for traversing B2BUAs." --Daryl On 3/28/12 2:47 AM, "Hadriel Kaplan" <HKaplan@acmepacket.com> wrote: >Howdy, >I have reviewed today's DISPATCH Meetecho recording, and modified the >charter as below - I can't attest to it representing everyone's input >accurately, so please review it and provide feedback if it does not >reflect your wishes. > >--------------------------------------------- >Major changes: >- removed the paragraph about delivering separate documents of discrete >functions >- added a paragraph in objectives about it covering existing work >- removed the deliverable for identifying specific features/capabilities >support >- added a deliverable for the taxonomy doc >- added a deliverable for a framework doc >- added a deliverable for end-to-end RTCP >--------------------------------------------- > >Description of STRAW Working Group >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Name: Sip Traversal Required for Applications to Work (STRAW) > >Problem Statement: >Within the context of the SIP protocol and architecture, a Back-to-Back >User Agent (B2BUA) is any SIP device in the logical path between two User >Agents performing a role beyond that of a Proxy as defined in RFC 3261. >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA >in order to terminate dead sessions by generating BYEs; or it may be a >3PCC-style agent only modifying SDP; or it may be a Session Border >Controller performing such functions as in RFC 5853; or it may be an >Enterprise PBX terminating REFERs and such; or it may be a complete UAS >and UAC implementation with a PRI loopback in-between. > >In its most extreme form, the scope of the SIP protocol ends at the UAS >of the B2BUA, and a new SIP protocol scope begins on its UAC side. In >practice, however, users expect some SIP protocol aspects to go beyond >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as >if the B2BUA was not an end unto itself; this is similar to the >expectation that emails work when they cross from POP and IMAP to/from >SMTP. > >It is impossible to normatively define all the behaviors of B2BUAs in >general, or even subsets of them such as SBCs or PBXs. Unlike consumer >NATs, B2BUAs perform widely varying functions for purposes which may be >unique to their environment, unique to their architecture, or unique to >the wishes of their administrator. Instead of defining all things a >given type of B2BUA must do, a more practical objective would be to >define what very few things any B2BUA must do to make a specific SIP >mechanism work, and let the market decide whether to do those things. > >The name of this working group reflects that practical objective: if >there were a thin straw between the SIP UAS and UAC of a B2BUA, what must >be passed through that straw and used on each side. Or viewed another >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback >circuit, and if we could extend ISDN, what information would we carry in >ISDN across the PRI for a specific SIP mechanism to work end-to-end. > >For example, the WG could produce a document which specifies that the >Max-Forwards header field value should be copied and decremented across >the B2BUA, if the B2BUA wishes to prevent infinite loops. Administrators >could then tell their B2BUA vendors to comply with the document, if the >administrator so wishes. > > >Objectives: >The objectives of the STRAW Working Group are to publish normative >documents which define which SIP header fields, parameters, MIME bodies, >body content fields/information, or media-plane characteristics are >required to traverse between the User Agent "sides" of a B2BUA for >specific functions to work. > >The specific functions covered are expected to relate to >already-published RFCs or existing RAI area work, as opposed to all >future IETF work. In other words, the Working Group is not meant to be a >never-ending source for B2BUA requirements in the RAI area. > >Deliverables would indicate which types of B2BUAs would apply or not. >For example, a document defining the requirements for end-to-end >DTLS-SRTP would not apply to B2BUAs which terminate media, such as >transcoders or recorders. > > >Initial Deliverables: >1) A taxonomy document defining role-types of B2BUAs, as a reference for >other deliverables. >2) A framework document for future IETF RFCs to use as considerations for >their own B2BUA requirements. >3) A document defining the requirements for B2BUAs with respect to loop >detection/prevention. >4) A document defining the requirements for B2BUAs to support end-to-end >and hop-by-hop media-loopback test calls. >5) A document defining the requirements for B2BUAs to support DTLS-SRTP >(RFC 5764) end-to-end. >6) A document defining the requirements for B2BUAs to support STUN >message transactions end-to-end. >7) A document defining the requirements for B2BUAs to support RTCP >end-to-end. > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Wed Mar 28 03:57:35 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7784621F88FC for <dispatch@ietfa.amsl.com>; Wed, 28 Mar 2012 03:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRJn8zxQ5rb4 for <dispatch@ietfa.amsl.com>; Wed, 28 Mar 2012 03:57:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 67C9E21F88F1 for <dispatch@ietf.org>; Wed, 28 Mar 2012 03:57:34 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Mar 2012 06:57:33 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Wed, 28 Mar 2012 06:57:33 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: "dispatch@ietf.org list" <dispatch@ietf.org> Thread-Topic: [dispatch] Updated STRAW Charter Thread-Index: AQHNDNGToNbNkKSTqEaCkT4wAB7xSg== Date: Wed, 28 Mar 2012 10:57:33 +0000 Message-ID: <0F49B42A-4308-45F2-BC0C-84DA1779B836@acmepacket.com> References: <CB988C2B.D9DB%d.malas@cablelabs.com> In-Reply-To: <CB988C2B.D9DB%d.malas@cablelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <E7DC0043904981409BB68954FAB8E355@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: Re: [dispatch] Updated STRAW Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Mar 2012 10:57:35 -0000 Works for me - anyone object? -hadriel On Mar 28, 2012, at 9:43 AM, Daryl Malas wrote: > Hadriel, >=20 > Thank you for quickly turning around a new charter. In general, I'm good > with the proposed changes. With regards to the "framework" deliverable, = I > was envisioning a framework for creating relevant requirements for a B2BU= A > AND detailing appropriate text for "considerations" sections of IETF > drafts. This may apply to unidentified past I-Ds/RFCs or future > I-Ds/RFCs. With this in mind, I suggest the following change to the > deliverable: >=20 > From: "A framework document for future IETF RFCs to use as considerations > for their own B2BUA requirements." >=20 > To: "A framework document for defining requirements and considerations fo= r > traversing B2BUAs." >=20 > --Daryl >=20 > On 3/28/12 2:47 AM, "Hadriel Kaplan" <HKaplan@acmepacket.com> wrote: >=20 >> Howdy, >> I have reviewed today's DISPATCH Meetecho recording, and modified the >> charter as below - I can't attest to it representing everyone's input >> accurately, so please review it and provide feedback if it does not >> reflect your wishes. >>=20 >> --------------------------------------------- >> Major changes: >> - removed the paragraph about delivering separate documents of discrete >> functions >> - added a paragraph in objectives about it covering existing work >> - removed the deliverable for identifying specific features/capabilities >> support >> - added a deliverable for the taxonomy doc >> - added a deliverable for a framework doc >> - added a deliverable for end-to-end RTCP >> --------------------------------------------- >>=20 >> Description of STRAW Working Group >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Name: Sip Traversal Required for Applications to Work (STRAW) >>=20 >> Problem Statement: >> Within the context of the SIP protocol and architecture, a Back-to-Back >> User Agent (B2BUA) is any SIP device in the logical path between two Use= r >> Agents performing a role beyond that of a Proxy as defined in RFC 3261. >> The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA >> in order to terminate dead sessions by generating BYEs; or it may be a >> 3PCC-style agent only modifying SDP; or it may be a Session Border >> Controller performing such functions as in RFC 5853; or it may be an >> Enterprise PBX terminating REFERs and such; or it may be a complete UAS >> and UAC implementation with a PRI loopback in-between. >>=20 >> In its most extreme form, the scope of the SIP protocol ends at the UAS >> of the B2BUA, and a new SIP protocol scope begins on its UAC side. In >> practice, however, users expect some SIP protocol aspects to go beyond >> the scope of the B2BUA's UAS side, and be traversed onto its UAC side, a= s >> if the B2BUA was not an end unto itself; this is similar to the >> expectation that emails work when they cross from POP and IMAP to/from >> SMTP. >>=20 >> It is impossible to normatively define all the behaviors of B2BUAs in >> general, or even subsets of them such as SBCs or PBXs. Unlike consumer >> NATs, B2BUAs perform widely varying functions for purposes which may be >> unique to their environment, unique to their architecture, or unique to >> the wishes of their administrator. Instead of defining all things a >> given type of B2BUA must do, a more practical objective would be to >> define what very few things any B2BUA must do to make a specific SIP >> mechanism work, and let the market decide whether to do those things. >>=20 >> The name of this working group reflects that practical objective: if >> there were a thin straw between the SIP UAS and UAC of a B2BUA, what mus= t >> be passed through that straw and used on each side. Or viewed another >> way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback >> circuit, and if we could extend ISDN, what information would we carry in >> ISDN across the PRI for a specific SIP mechanism to work end-to-end. >>=20 >> For example, the WG could produce a document which specifies that the >> Max-Forwards header field value should be copied and decremented across >> the B2BUA, if the B2BUA wishes to prevent infinite loops. Administrator= s >> could then tell their B2BUA vendors to comply with the document, if the >> administrator so wishes. >>=20 >>=20 >> Objectives: >> The objectives of the STRAW Working Group are to publish normative >> documents which define which SIP header fields, parameters, MIME bodies, >> body content fields/information, or media-plane characteristics are >> required to traverse between the User Agent "sides" of a B2BUA for >> specific functions to work. >>=20 >> The specific functions covered are expected to relate to >> already-published RFCs or existing RAI area work, as opposed to all >> future IETF work. In other words, the Working Group is not meant to be = a >> never-ending source for B2BUA requirements in the RAI area. >>=20 >> Deliverables would indicate which types of B2BUAs would apply or not. >> For example, a document defining the requirements for end-to-end >> DTLS-SRTP would not apply to B2BUAs which terminate media, such as >> transcoders or recorders. >>=20 >>=20 >> Initial Deliverables: >> 1) A taxonomy document defining role-types of B2BUAs, as a reference for >> other deliverables. >> 2) A framework document for future IETF RFCs to use as considerations fo= r >> their own B2BUA requirements. >> 3) A document defining the requirements for B2BUAs with respect to loop >> detection/prevention. >> 4) A document defining the requirements for B2BUAs to support end-to-end >> and hop-by-hop media-loopback test calls. >> 5) A document defining the requirements for B2BUAs to support DTLS-SRTP >> (RFC 5764) end-to-end. >> 6) A document defining the requirements for B2BUAs to support STUN >> message transactions end-to-end. >> 7) A document defining the requirements for B2BUAs to support RTCP >> end-to-end. >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 From dean.willis@softarmor.com Wed Mar 28 07:10:43 2012 Return-Path: <dean.willis@softarmor.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED67E21E825E for <dispatch@ietfa.amsl.com>; Wed, 28 Mar 2012 07:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.743 X-Spam-Level: X-Spam-Status: No, score=-102.743 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrpDOEH1aK1H for <dispatch@ietfa.amsl.com>; Wed, 28 Mar 2012 07:10:41 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8D6321E825F for <dispatch@ietf.org>; Wed, 28 Mar 2012 07:10:41 -0700 (PDT) Received: by ggmi1 with SMTP id i1so790746ggm.31 for <dispatch@ietf.org>; Wed, 28 Mar 2012 07:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q0JV5ZQItNfe3czAvAui+dndFhmgJPRyUOHe1VM1LjM=; b=aC5kKaVADvSRA9pQbgkKpyL8g8XRvGSlIIIlTTfjNGGhYE5hj4+dZwN3GUQpEDtpwE YtOkwLbof2pJKIdSnZdvP4deJ7ZaFqWBqJxOelxgm5/3VWUssok/0snRsSFPFQ6HqFni wX+hFo+O35sn0yzY5C+RNZcCj9KK0NBObZI+4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Q0JV5ZQItNfe3czAvAui+dndFhmgJPRyUOHe1VM1LjM=; b=E6y5yyPM98kzXY9KKj2rP2wYPDbRKNw38BpFbZR5ibd18YL9Wtk+i2oa5krSEfXJfR QJvcFeJExict4TOs9XR9h1W37sAutH0ezQw6U7t5Hgd/0c3t0+yrEuJKJMQL8/CpGdTB 6sddJYXUqGTizH1x918OK26xBKfbJbgs1GJx6kTQ+bpyz2wP1/GV7ZsBs04V2uGsFfcs mlkFmuaVIS1WL7His7QxIB+wcXwrlAvGkJPIyuQ1/XVVf79HNIckSy0FQe7I/T0Hl656 +wVSMz5lHMqbdPljlgoK8Mc2W4WTUclY7PV+wWablxuZlFVdCr3cjH0wB64ERIcqL9ic IkXQ== MIME-Version: 1.0 Received: by 10.68.129.74 with SMTP id nu10mr71696787pbb.157.1332943840986; Wed, 28 Mar 2012 07:10:40 -0700 (PDT) Received: by 10.68.9.104 with HTTP; Wed, 28 Mar 2012 07:10:40 -0700 (PDT) In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA239D63CD@STNTEXCH01.cis.neustar.com> References: <CB864974.CAD1%d.malas@cablelabs.com> <916D1441-3AC9-4FC1-B723-F64EBDAC00B8@neustar.biz> <BC0C7F75-07F0-4B54-8DC1-07C72425C396@acmepacket.com> <1638072E-7AA2-4834-949E-3F1A9AF997FF@insensate.co.uk> <DCE5EA46-84EA-465B-B4E7-4A3F2D89CC3A@acmepacket.com> <CAA3wLqW4MW88o6Bgf5J=eQoWWEOfz=wr+XV+E63q7HHL6o1T=w@mail.gmail.com> <05F836CB-1B73-4E11-9EE8-1BFBA3165B10@insensate.co.uk> <55A5A9A87506CB4BA580BF9D531957DA239D63CD@STNTEXCH01.cis.neustar.com> Date: Wed, 28 Mar 2012 16:10:40 +0200 Message-ID: <CAOHm=4vEmskYGsyGeL1xXHRQ=fb277B7qY_+bbyf-3BXUQuC7A@mail.gmail.com> From: Dean Willis <dean.willis@softarmor.com> To: "Peterson, Jon" <jon.peterson@neustar.biz> Content-Type: multipart/alternative; boundary=e89a8f234f3125c7b704bc4e2cd8 X-Gm-Message-State: ALoCoQncZpjd+oDZC/bN+2ipQT9zBMVUAf231z31aK8L2sGAcgWaB/REYcS4PJmC8BxzKzSvrDYb Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Mar 2012 14:10:43 -0000 --e89a8f234f3125c7b704bc4e2cd8 Content-Type: text/plain; charset=ISO-8859-1 I think if we had a working group for Jon's number- routing service that Plain Old Telephone Service Porting And Numbering, or POTSPAN, might make a good name. -- Dean --e89a8f234f3125c7b704bc4e2cd8 Content-Type: text/html; charset=ISO-8859-1 <div><br></div><div>I think if we had a working group for Jon's number- routing service that Plain Old Telephone Service Porting And Numbering, or POTSPAN, might make a good name.<span></span></div><div><br></div>--<div> Dean</div> --e89a8f234f3125c7b704bc4e2cd8-- From mperumal@cisco.com Thu Mar 29 01:10:13 2012 Return-Path: <mperumal@cisco.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845C721F87A9 for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 01:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.822 X-Spam-Level: X-Spam-Status: No, score=-9.822 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8VY57Tg-ltQ for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 01:10:11 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4272821F86CF for <dispatch@ietf.org>; Thu, 29 Mar 2012 01:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=10085; q=dns/txt; s=iport; t=1333008607; x=1334218207; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=UvzFcYwFXsei50673VJQS2GhNOH+pL9yRSN8Do8C1D0=; b=c6BAQB2iv3tgKnTs7Fs/ZgqUVGMOAIbQTRH9TJ21GE79ZkWSqQrGvFp5 O86bSf9mocjAnYdgprE0ELziiHkp8U2PfVKVyiRf+3vFojel4QhTNI4Ae oY8g3dtyISaBf1Vtjp8Rir9SkwA8dhdH4xLZtUHnm6Z5Zr0E/F4IYuy2e 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EANMXdE9Io8UY/2dsb2JhbABFuhKCCQEBAQQBAQEPAR0KLQQDCwwEAgEIDgMBAwEBCwYXAQYBJh8DBggCBAsICBqHaAubSp8WkDxjBIhWjhyNNIFogm8 X-IronPort-AV: E=Sophos;i="4.73,665,1325462400"; d="scan'208";a="8874857" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 29 Mar 2012 08:10:04 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2T8A4LO011415; Thu, 29 Mar 2012 08:10:04 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); Thu, 29 Mar 2012 13:40:04 +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, 29 Mar 2012 13:40:02 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020803E8FB@XMB-BGL-414.cisco.com> In-Reply-To: <2EF74DA4-83EB-4978-B0DF-E65FC9EAE7CC@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] STRAW Charter Proposal Thread-Index: AQHNDF2sPz1lVkPkGkeq+R6Mgxn0zJaA5dvQ References: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> <1D062974A4845E4D8A343C653804920207F1DDF2@XMB-BGL-414.cisco.com> <B03EBC9C-57F8-48AA-A722-98AD5DB658C0@acmepacket.com> <E456066D-E8A0-4462-AF6D-5B2D566E3FFA@csperkins.org> <B5BD2B31-DE70-40BC-AEF4-9F0DAB48ACB4@acmepacket.com> <1D062974A4845E4D8A343C65380492020803E417@XMB-BGL-414.cisco.com> <2EF74DA4-83EB-4978-B0DF-E65FC9EAE7CC@acmepacket.com> From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> To: "Hadriel Kaplan" <HKaplan@acmepacket.com> X-OriginalArrivalTime: 29 Mar 2012 08:10:04.0121 (UTC) FILETIME=[588E4C90:01CD0D83] Cc: dispatch@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 29 Mar 2012 08:10:13 -0000 I see you have already added it in the updated charter and text looks ok to me. RTCP is probably not as big an issue compared to STUN or DTLS-SRTP for B2BUAs, however if one of the B2BUAs breaks RTCP it would be good to have a document to point to what the best current practice is. It is a way of future proofing RTCP for B2BUA use case, IMHO. Muthu=20 |-----Original Message----- |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |Sent: Tuesday, March 27, 2012 11:08 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: Colin Perkins; <dispatch@ietf.org> |Subject: Re: [dispatch] STRAW Charter Proposal | | |Can you suggest milestone text for it? | |-hadriel | | |On Mar 27, 2012, at 6:09 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: | |> Guess I wasn't clear when I said "getting RTCP/SRTCP working end-to-end |> across B2BUAs". I only meant getting RTCP working across B2BUAs so that |> the endpoints can take useful decisions based on RTCP. I agree there |> would be cases like transcoding where a B2BUA would have to terminate |> RTCP coming from one side and generate its own RTCP and there would also |> be cases where a B2BUA would have to simply pass across RTCP. However, |> information like IP addresses carried inside RTCP CNAME might have |> impact on B2BUA policies like address hiding when RTCP is passed across. |> |> So, similar to STUN, documenting how a B2BUA should handle RTCP for the |> various use cases would be useful I think. |> |> Muthu |> |> |-----Original Message----- |> |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |> |Sent: Tuesday, March 27, 2012 5:17 PM |> |To: Colin Perkins; Muthu Arul Mozhi Perumal (mperumal) |> |Cc: dispatch@ietf.org list |> |Subject: Re: [dispatch] STRAW Charter Proposal |> | |> | |> |As far as I can tell from wireshark captures, some or even many |> transcoders act as full endpoints, and |> |generate their own RTCP - as if there were a TDM loopback internally - |> not as RFC 3550 "translators". |> |I am definitely not an expert in that area, however - is it the case |> that most transcoders act as |> |translators, or as full endpoints? |> | |> |Should the taxonomy document for STRAW distinguish between B2BUAs that |> transcoders as RFC 3550 |> |translators, vs. ones that transcode as full back-to-back media |> endpoints? |> | |> |Muthu - did you mean it in that context of a translator? Or did you |> mean it in the context of getting |> |RTCP/SRTCP passed through transcoding B2BUAs, without modification? (my |> impression was you meant |> |passing it through without modification) |> | |> |-hadriel |> | |> | |> |On Mar 27, 2012, at 3:42 PM, Colin Perkins wrote: |> | |> |> While I'm sure it's more common to terminate RTCP at the transcoder, |> RTP Translators [RFC3550 |> |section 7.2; Topo-Media-Translator in RFC5117] were intended to support |> the case where RTCP goes |> |through the transcoder. |> |> |> |> Colin |> |> |> |> |> |> On 27 Mar 2012, at 14:39, Hadriel Kaplan wrote: |> |>> Umm sure, but just to be clear - if a B2BUA does transcoding it *is* |> the end of RTCP (and a new |> |RTCP beginning on the other side). As far as I know, it is illogical |> to expect RTCP to go "through" a |> |transcoder. |> |>> |> |>> Are you proposing we should have a milestone for documenting |> specific functionality of RTCP, such |> |as by passing through specific fields of RTCP, that needs to work |> through a transcoder? |> |>> |> |>> -hadriel |> |>> |> |>> |> |>> On Mar 27, 2012, at 2:22 PM, Muthu Arul Mozhi Perumal (mperumal) |> wrote: |> |>> |> |>>> I think RTCP has similar issues with B2BUAs and getting RTCP/SRTCP |> |>>> working end-to-end across B2BUAs, in particular those B2BUAs that |> |>>> perform transcoding/transrating of media streams, is also |> important. I |> |>>> would suggest adding a deliverable for RTCP/SRTCP: |> |>>> |> |>>> 6) A document defining the requirements for B2BUAs to support |> RTCP/SRTCP |> |>>> end-to-end. |> |>>> |> |>>> Muthu |> |>>> |> |>>> |-----Original Message----- |> |>>> |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] |> On |> |>>> Behalf Of Hadriel Kaplan |> |>>> |Sent: Tuesday, January 24, 2012 8:16 AM |> |>>> |To: dispatch@ietf.org list |> |>>> |Subject: [dispatch] STRAW Charter Proposal |> |>>> | |> |>>> |Howdy, |> |>>> |As instructed by DISPATCH chairs, I am re-posting the STRAW |> Charter |> |>>> Proposal, as a topic for the Paris |> |>>> |meeting. |> |>>> |The proposed charter is as follows: |> |>>> | |> |>>> |Description of STRAW Working Group |> |>>> = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |> |>>> |Name: Sip Traversal Required for Applications to Work (STRAW) |> |>>> | |> |>>> |Problem Statement: |> |>>> |Within the context of the SIP protocol and architecture, a |> Back-to-Back |> |>>> User Agent (B2BUA) is any SIP |> |>>> |device in the logical path between two User Agents performing a |> role |> |>>> beyond that of a Proxy as defined |> |>>> |in RFC 3261. The B2BUA may be as simple as a session-stateful |> Proxy |> |>>> becoming a B2BUA in order to |> |>>> |terminate dead sessions by generating BYEs; or it may be a |> 3PCC-style |> |>>> agent only modifying SDP; or it |> |>>> |may be a Session Border Controller performing such functions as in |> RFC |> |>>> 5853; or it may be an |> |>>> |Enterprise PBX terminating REFERs and such; or it may be a |> complete UAS |> |>>> and UAC implementation with a |> |>>> |PRI loopback in-between. |> |>>> | |> |>>> |In its most extreme form, the scope of the SIP protocol ends at |> the UAS |> |>>> of the B2BUA, and a new SIP |> |>>> |protocol scope begins on its UAC side. In practice, however, |> users |> |>>> expect some SIP protocol aspects |> |>>> |to go beyond the scope of the B2BUA's UAS side, and be traversed |> onto |> |>>> its UAC side, as if the B2BUA |> |>>> |was not an end unto itself; this is similar to the expectation |> that |> |>>> emails work when they cross from |> |>>> |POP and IMAP to/from SMTP. |> |>>> | |> |>>> |It is impossible to normatively define all the behaviors of B2BUAs |> in |> |>>> general, or even subsets of them |> |>>> |such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying |> |>>> functions for purposes which may be |> |>>> |unique to their environment, unique to their architecture, or |> unique to |> |>>> the wishes of their |> |>>> |administrator. Instead of defining all things a given type of |> B2BUA |> |>>> must do, a more practical |> |>>> |objective would be to define what very few things any B2BUA must |> do to |> |>>> make a specific SIP mechanism |> |>>> |work, and let the market decide whether to do those things. |> |>>> | |> |>>> |The name of this working group reflects that practical objective: |> if |> |>>> there were a thin straw between |> |>>> |the SIP UAS and UAC of a B2BUA, what must be passed through that |> straw |> |>>> and used on each side. Or |> |>>> |viewed another way, if a B2BUA were in fact a UAS and UAC |> connected |> |>>> with a PRI loopback circuit, and |> |>>> |if we could extend ISDN, what information would we carry in ISDN |> across |> |>>> the PRI for a specific SIP |> |>>> |mechanism to work end-to-end. |> |>>> | |> |>>> |For example, the WG could produce a document which specifies that |> the |> |>>> Max-Forwards header field value |> |>>> |should be copied and decremented across the B2BUA, if the B2BUA |> wishes |> |>>> to prevent loops. |> |>>> |Administrators could then tell their B2BUA vendors to comply with |> the |> |>>> document, if the administrator |> |>>> |so wishes. |> |>>> | |> |>>> |Objectives: |> |>>> |The objectives of the STRAW Working Group are to publish normative |> |>>> documents which define which SIP |> |>>> |header fields, parameters, MIME bodies, body content |> |>>> fields/information, or media-plane |> |>>> |characteristics are required to traverse between the User Agent |> "sides" |> |>>> of a B2BUA for specific |> |>>> |functions to work. |> |>>> | |> |>>> |Deliverables would indicate which types of B2BUAs would apply or |> not. |> |>>> For example, a document |> |>>> |defining the requirements for end-to-end DTLS-SRTP would not apply |> to |> |>>> B2BUAs which terminate media, |> |>>> |such as transcoders or recorders. |> |>>> | |> |>>> |The intention of this WG is to document such requirements in |> separate |> |>>> documents, per SIP or media |> |>>> |function, instead of as one document for all functions. That will |> both |> |>>> reduce the time to |> |>>> |publication, as well a provide B2BUA administrators and |> manufacturers |> |>>> with simple comply/no-comply |> |>>> |criteria. |> |>>> | |> |>>> | |> |>>> |Initial Deliverables: |> |>>> |1) A taxonomy document defining role-types of B2BUAs, as a |> reference |> |>>> for other deliverables. |> |>>> |2) A document defining the requirements for B2BUAs with respect to |> loop |> |>>> detection/prevention. |> |>>> |3) A document defining the requirements for B2BUAs to support |> |>>> end-to-end and hop-by-hop media-loopback |> |>>> |test calls. |> |>>> |4) A document defining the requirements for B2BUAs to support |> DTLS-SRTP |> |>>> (RFC 5764) end-to-end. |> |>>> |5) A document defining the requirements for B2BUAs to support STUN |> |>>> connectivity checks end-to-end. |> |>>> | |> |>>> | |> |>>> |_______________________________________________ |> |>>> |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 |> |> |> |> |> |> -- |> |> Colin Perkins |> |> http://csperkins.org/ |> |> |> |> |> |> |> From HKaplan@acmepacket.com Thu Mar 29 03:25:44 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E761721F89BF for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 03:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0TzGkBgEhxD for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 03:25:44 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF9D21F89BD for <dispatch@ietf.org>; Thu, 29 Mar 2012 03:25:37 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Mar 2012 06:25:26 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Thu, 29 Mar 2012 03:33:00 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: "dispatch@ietf.org list" <dispatch@ietf.org> Thread-Topic: [dispatch] Updated STRAW Charter v2 Thread-Index: AQHNDX4qxkF3r0mnY0KxCjlH7InEVw== Date: Thu, 29 Mar 2012 07:32:59 +0000 Message-ID: <508400E8-A05B-406A-B9A7-F7DE5106F878@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <6C3A713DB719574FBE9A69A35711E954@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [dispatch] Updated STRAW Charter v2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 29 Mar 2012 10:25:45 -0000 Howdy, Updated charter below... Description of STRAW Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Name: Sip Traversal Required for Applications to Work (STRAW) Problem Statement:=20 Within the context of the SIP protocol and architecture, a Back-to-Back Use= r Agent (B2BUA) is any SIP device in the logical path between two User Agen= ts performing a role beyond that of a Proxy as defined in RFC 3261. The B2= BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order = to terminate dead sessions by generating BYEs; or it may be a 3PCC-style ag= ent only modifying SDP; or it may be a Session Border Controller performing= such functions as in RFC 5853; or it may be an Enterprise PBX terminating = REFERs and such; or it may be a complete UAS and UAC implementation with a = PRI loopback in-between.=20 In its most extreme form, the scope of the SIP protocol ends at the UAS of = the B2BUA, and a new SIP protocol scope begins on its UAC side. In practic= e, however, users expect some SIP protocol aspects to go beyond the scope o= f the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA= was not an end unto itself; this is similar to the expectation that emails= work when they cross from POP and IMAP to/from SMTP. It is impossible to normatively define all the behaviors of B2BUAs in gener= al, or even subsets of them such as SBCs or PBXs. Unlike consumer NATs, B2B= UAs perform widely varying functions for purposes which may be unique to th= eir environment, unique to their architecture, or unique to the wishes of t= heir administrator. Instead of defining all things a given type of B2BUA m= ust do, a more practical objective would be to define what very few things = any B2BUA must do to make a specific SIP mechanism work, and let the market= decide whether to do those things. The name of this working group reflects that practical objective: if there = were a thin straw between the SIP UAS and UAC of a B2BUA, what must be pass= ed through that straw and used on each side. Or viewed another way, if a B= 2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and = if we could extend ISDN, what information would we carry in ISDN across the= PRI for a specific SIP mechanism to work end-to-end. For example, the WG could produce a document which specifies that the Max-F= orwards header field value should be copied and decremented across the B2BU= A, if the B2BUA wishes to prevent infinite loops. Administrators could the= n tell their B2BUA vendors to comply with the document, if the administrato= r so wishes. Objectives: The objectives of the STRAW Working Group are to publish normative document= s which define which SIP header fields, parameters, MIME bodies, body conte= nt fields/information, or media-plane characteristics are required to trave= rse between the User Agent "sides" of a B2BUA for specific functions to wor= k. =20 The specific functions covered are expected to relate to already-published = RFCs or existing RAI area work, as opposed to all future IETF work. In oth= er words, the Working Group is not meant to be a never-ending source for B2= BUA requirements in the RAI area. Deliverables would indicate which types of B2BUAs would apply or not. For = example, a document defining the requirements for end-to-end DTLS-SRTP woul= d not apply to B2BUAs which terminate media, such as transcoders or recorde= rs. Initial Deliverables: 1) A taxonomy document defining role-types of B2BUAs, as a reference for ot= her deliverables. 2) A framework document for defining requirements and considerations for tr= aversing B2BUAs. 3) A document defining the requirements for B2BUAs with respect to loop det= ection/prevention. 4) A document defining the requirements for B2BUAs to support end-to-end an= d hop-by-hop media-loopback test calls. 5) A document defining the requirements for B2BUAs to support DTLS-SRTP (RF= C 5764) end-to-end. 6) A document defining the requirements for B2BUAs to support STUN message = transactions end-to-end. 7) A document defining the requirements for B2BUAs to support RTCP end-to-e= nd. From christer.holmberg@ericsson.com Thu Mar 29 04:20:47 2012 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D7F21F893E for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 04:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.234 X-Spam-Level: X-Spam-Status: No, score=-10.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XntJ-lCExEi7 for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 04:20:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1188A21F8935 for <dispatch@ietf.org>; Thu, 29 Mar 2012 04:20:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7b5aae000002dcb-e9-4f74458ad3ef Authentication-Results: mailgw10.se.ericsson.net x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DB.C0.11723.A85447F4; Thu, 29 Mar 2012 13:20:42 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 29 Mar 2012 13:20:42 +0200 From: Christer Holmberg <christer.holmberg@ericsson.com> To: 'Hadriel Kaplan' <HKaplan@acmepacket.com>, "dispatch@ietf.org list" <dispatch@ietf.org> Date: Thu, 29 Mar 2012 13:20:41 +0200 Thread-Topic: [dispatch] Updated STRAW Charter v2 Thread-Index: AQHNDX4qxkF3r0mnY0KxCjlH7InEV5aBH9Qg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C429F5D8F@ESESSCMS0356.eemea.ericsson.se> References: <508400E8-A05B-406A-B9A7-F7DE5106F878@acmepacket.com> In-Reply-To: <508400E8-A05B-406A-B9A7-F7DE5106F878@acmepacket.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== Subject: Re: [dispatch] Updated STRAW Charter v2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 29 Mar 2012 11:20:47 -0000 Hi, I support this work, and after a quick look the proposed charter looks good= , but I have a question for clarification regarding the suggested deliverab= le 2). A question for clarification (my appologies if it has already been clarifie= d). "2) A framework document for defining requirements and considerations for t= raversing B2BUAs." Deliverables 3) - 7) talk about requirements in order for specific features= to "survive" a B2BUA, but I am not sure what requirements 2) is talking ab= out? Regards, Christer -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Hadriel Kaplan Sent: 29. maaliskuuta 2012 10:33 To: dispatch@ietf.org list Subject: [dispatch] Updated STRAW Charter v2 Howdy, Updated charter below... Description of STRAW Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Name: Sip Traversal Required for Applications to Work (STRAW) Problem Statement:=20 Within the context of the SIP protocol and architecture, a Back-to-Back Use= r Agent (B2BUA) is any SIP device in the logical path between two User Agen= ts performing a role beyond that of a Proxy as defined in RFC 3261. The B2= BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order = to terminate dead sessions by generating BYEs; or it may be a 3PCC-style ag= ent only modifying SDP; or it may be a Session Border Controller performing= such functions as in RFC 5853; or it may be an Enterprise PBX terminating = REFERs and such; or it may be a complete UAS and UAC implementation with a = PRI loopback in-between.=20 In its most extreme form, the scope of the SIP protocol ends at the UAS of = the B2BUA, and a new SIP protocol scope begins on its UAC side. In practic= e, however, users expect some SIP protocol aspects to go beyond the scope o= f the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA= was not an end unto itself; this is similar to the expectation that emails= work when they cross from POP and IMAP to/from SMTP. It is impossible to normatively define all the behaviors of B2BUAs in gener= al, or even subsets of them such as SBCs or PBXs. Unlike consumer NATs, B2B= UAs perform widely varying functions for purposes which may be unique to th= eir environment, unique to their architecture, or unique to the wishes of t= heir administrator. Instead of defining all things a given type of B2BUA m= ust do, a more practical objective would be to define what very few things = any B2BUA must do to make a specific SIP mechanism work, and let the market= decide whether to do those things. The name of this working group reflects that practical objective: if there = were a thin straw between the SIP UAS and UAC of a B2BUA, what must be pass= ed through that straw and used on each side. Or viewed another way, if a B= 2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and = if we could extend ISDN, what information would we carry in ISDN across the= PRI for a specific SIP mechanism to work end-to-end. For example, the WG could produce a document which specifies that the Max-F= orwards header field value should be copied and decremented across the B2BU= A, if the B2BUA wishes to prevent infinite loops. Administrators could the= n tell their B2BUA vendors to comply with the document, if the administrato= r so wishes. Objectives: The objectives of the STRAW Working Group are to publish normative document= s which define which SIP header fields, parameters, MIME bodies, body conte= nt fields/information, or media-plane characteristics are required to trave= rse between the User Agent "sides" of a B2BUA for specific functions to wor= k. =20 The specific functions covered are expected to relate to already-published = RFCs or existing RAI area work, as opposed to all future IETF work. In oth= er words, the Working Group is not meant to be a never-ending source for B2= BUA requirements in the RAI area. Deliverables would indicate which types of B2BUAs would apply or not. For = example, a document defining the requirements for end-to-end DTLS-SRTP woul= d not apply to B2BUAs which terminate media, such as transcoders or recorde= rs. Initial Deliverables: 1) A taxonomy document defining role-types of B2BUAs, as a reference for ot= her deliverables. 2) A framework document for defining requirements and considerations for tr= aversing B2BUAs. 3) A document defining the requirements for B2BUAs with respect to loop det= ection/prevention. 4) A document defining the requirements for B2BUAs to support end-to-end an= d hop-by-hop media-loopback test calls. 5) A document defining the requirements for B2BUAs to support DTLS-SRTP (RF= C 5764) end-to-end. 6) A document defining the requirements for B2BUAs to support STUN message = transactions end-to-end. 7) A document defining the requirements for B2BUAs to support RTCP end-to-e= nd. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From D.Malas@cablelabs.com Thu Mar 29 06:43:09 2012 Return-Path: <D.Malas@cablelabs.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B9A21F8AF4 for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 06:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.375 X-Spam-Level: X-Spam-Status: No, score=-100.375 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WczNcyMcESOI for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 06:43:08 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 421A621F8AB4 for <dispatch@ietf.org>; Thu, 29 Mar 2012 06:43:08 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2TDh3jx018795; Thu, 29 Mar 2012 07:43:03 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 29 Mar 2012 07:43:03 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 29 Mar 2012 07:43:03 -0600 From: Daryl Malas <D.Malas@cablelabs.com> To: Christer Holmberg <christer.holmberg@ericsson.com>, Hadriel Kaplan <HKaplan@acmepacket.com>, "dispatch@ietf.org list" <dispatch@ietf.org> Date: Thu, 29 Mar 2012 07:43:03 -0600 Thread-Topic: [dispatch] Updated STRAW Charter v2 Thread-Index: Ac0Nsd0OvTgFC9htTQ2DeLOgBosIaQ== Message-ID: <CB9A3140.DBF1%d.malas@cablelabs.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C429F5D8F@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dispatch] Updated STRAW Charter v2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 29 Mar 2012 13:43:09 -0000 Christer, Deliverable "2" will be used to create documents defining the requirements for B2BUAs to support future/undefined "specific features." It allows the working group to not persist indefinitely. I am assuming the deliverables are not listed as a prioritized list. I would expect the framework to be completed towards the end, based on previous experience. Framework Examples: http://tools.ietf.org/html/rfc6117 http://tools.ietf.org/html/rfc6390 --Daryl On 3/29/12 1:20 PM, "Christer Holmberg" <christer.holmberg@ericsson.com> wrote: > >Hi, > >I support this work, and after a quick look the proposed charter looks >good, but I have a question for clarification regarding the suggested >deliverable 2). > >A question for clarification (my appologies if it has already been >clarified). > >"2) A framework document for defining requirements and considerations for >traversing B2BUAs." > >Deliverables 3) - 7) talk about requirements in order for specific >features to "survive" a B2BUA, but I am not sure what requirements 2) is >talking about? > >Regards, > >Christer > > > > >-----Original Message----- >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >Behalf Of Hadriel Kaplan >Sent: 29. maaliskuuta 2012 10:33 >To: dispatch@ietf.org list >Subject: [dispatch] Updated STRAW Charter v2 > >Howdy, >Updated charter below... > > >Description of STRAW Working Group >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Name: Sip Traversal Required for Applications to Work (STRAW) > >Problem Statement: >Within the context of the SIP protocol and architecture, a Back-to-Back >User Agent (B2BUA) is any SIP device in the logical path between two User >Agents performing a role beyond that of a Proxy as defined in RFC 3261. >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA >in order to terminate dead sessions by generating BYEs; or it may be a >3PCC-style agent only modifying SDP; or it may be a Session Border >Controller performing such functions as in RFC 5853; or it may be an >Enterprise PBX terminating REFERs and such; or it may be a complete UAS >and UAC implementation with a PRI loopback in-between. > >In its most extreme form, the scope of the SIP protocol ends at the UAS >of the B2BUA, and a new SIP protocol scope begins on its UAC side. In >practice, however, users expect some SIP protocol aspects to go beyond >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as >if the B2BUA was not an end unto itself; this is similar to the >expectation that emails work when they cross from POP and IMAP to/from >SMTP. > >It is impossible to normatively define all the behaviors of B2BUAs in >general, or even subsets of them such as SBCs or PBXs. Unlike consumer >NATs, B2BUAs perform widely varying functions for purposes which may be >unique to their environment, unique to their architecture, or unique to >the wishes of their administrator. Instead of defining all things a >given type of B2BUA must do, a more practical objective would be to >define what very few things any B2BUA must do to make a specific SIP >mechanism work, and let the market decide whether to do those things. > >The name of this working group reflects that practical objective: if >there were a thin straw between the SIP UAS and UAC of a B2BUA, what must >be passed through that straw and used on each side. Or viewed another >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback >circuit, and if we could extend ISDN, what information would we carry in >ISDN across the PRI for a specific SIP mechanism to work end-to-end. > >For example, the WG could produce a document which specifies that the >Max-Forwards header field value should be copied and decremented across >the B2BUA, if the B2BUA wishes to prevent infinite loops. Administrators >could then tell their B2BUA vendors to comply with the document, if the >administrator so wishes. > > >Objectives: >The objectives of the STRAW Working Group are to publish normative >documents which define which SIP header fields, parameters, MIME bodies, >body content fields/information, or media-plane characteristics are >required to traverse between the User Agent "sides" of a B2BUA for >specific functions to work. > >The specific functions covered are expected to relate to >already-published RFCs or existing RAI area work, as opposed to all >future IETF work. In other words, the Working Group is not meant to be a >never-ending source for B2BUA requirements in the RAI area. > >Deliverables would indicate which types of B2BUAs would apply or not. >For example, a document defining the requirements for end-to-end >DTLS-SRTP would not apply to B2BUAs which terminate media, such as >transcoders or recorders. > > >Initial Deliverables: >1) A taxonomy document defining role-types of B2BUAs, as a reference for >other deliverables. >2) A framework document for defining requirements and considerations for >traversing B2BUAs. >3) A document defining the requirements for B2BUAs with respect to loop >detection/prevention. >4) A document defining the requirements for B2BUAs to support end-to-end >and hop-by-hop media-loopback test calls. >5) A document defining the requirements for B2BUAs to support DTLS-SRTP >(RFC 5764) end-to-end. >6) A document defining the requirements for B2BUAs to support STUN >message transactions end-to-end. >7) A document defining the requirements for B2BUAs to support RTCP >end-to-end. > > >_______________________________________________ >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 mphmmr@gmail.com Thu Mar 29 07:43:15 2012 Return-Path: <mphmmr@gmail.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D3721F8936 for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 07:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htnZIKhUcxUl for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 07:43:14 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B12A221F8929 for <dispatch@ietf.org>; Thu, 29 Mar 2012 07:43:12 -0700 (PDT) Received: by lagj5 with SMTP id j5so3050033lag.31 for <dispatch@ietf.org>; Thu, 29 Mar 2012 07:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3MqxySv6x1VbfAWsiBj+4tCOIui0FmWhEln0B5kClNM=; b=iUW99HVjnVs6KmPYdORwCXdaTxeQwH4tv1MXEmKlrbESwMx4n2SXePNSHPfmOAkuqR YF+f/DsEqFpe3uc9HSoLjzaI9bdE6lEKlDhOvQ9ZoDuIbNJ5/qt50RexzgdKanRMAklk RPZoN2VnVC4hmDXtj5V9rvtL6+XwOQ8etvZbWhrBrLx8LOCQ4dmdhk2+jWUnBgkQdMKf KbYOs8u+F1DynmxV2kxiKP52/+TZJpD3aCz52p498YxrgLMz0D0wpaJ5GohpLWfE95Hi WCB4zSoVfQN66UPWEELmiCdR6ThvHe5hIEYOO18sqc1/4loVjrwNTwTwnFqQjkATm8iY dvwg== MIME-Version: 1.0 Received: by 10.152.108.84 with SMTP id hi20mr27983351lab.22.1333032191436; Thu, 29 Mar 2012 07:43:11 -0700 (PDT) Received: by 10.112.76.196 with HTTP; Thu, 29 Mar 2012 07:43:11 -0700 (PDT) In-Reply-To: <CB9A3140.DBF1%d.malas@cablelabs.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C429F5D8F@ESESSCMS0356.eemea.ericsson.se> <CB9A3140.DBF1%d.malas@cablelabs.com> Date: Thu, 29 Mar 2012 10:43:11 -0400 Message-ID: <CAA3wLqWXufOGXnbsQ8hwWwLHvjLQjTBQtTkC3fF2RmpQ_Nn7OA@mail.gmail.com> From: Michael Hammer <mphmmr@gmail.com> To: Daryl Malas <D.Malas@cablelabs.com> Content-Type: multipart/alternative; boundary=bcaec54eebf83ea81d04bc62bec7 Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] Updated STRAW Charter v2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 29 Mar 2012 14:43:15 -0000 --bcaec54eebf83ea81d04bc62bec7 Content-Type: text/plain; charset=ISO-8859-1 Daryl, That sounds like signing a blank check. Will certain implementations be declared non-compliant to the RFC for some unknown future feature? Would this also require future SIP features to add a section, say just prior to the Security section, that would need to declare handling by B2BUAs? Mike On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <D.Malas@cablelabs.com> wrote: > Christer, > > Deliverable "2" will be used to create documents defining the requirements > for B2BUAs to support future/undefined "specific features." It allows the > working group to not persist indefinitely. > > I am assuming the deliverables are not listed as a prioritized list. I > would expect the framework to be completed towards the end, based on > previous experience. > > Framework Examples: > > http://tools.ietf.org/html/rfc6117 > > http://tools.ietf.org/html/rfc6390 > > --Daryl > > On 3/29/12 1:20 PM, "Christer Holmberg" <christer.holmberg@ericsson.com> > wrote: > > > > >Hi, > > > >I support this work, and after a quick look the proposed charter looks > >good, but I have a question for clarification regarding the suggested > >deliverable 2). > > > >A question for clarification (my appologies if it has already been > >clarified). > > > >"2) A framework document for defining requirements and considerations for > >traversing B2BUAs." > > > >Deliverables 3) - 7) talk about requirements in order for specific > >features to "survive" a B2BUA, but I am not sure what requirements 2) is > >talking about? > > > >Regards, > > > >Christer > > > > > > > > > >-----Original Message----- > >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >Behalf Of Hadriel Kaplan > >Sent: 29. maaliskuuta 2012 10:33 > >To: dispatch@ietf.org list > >Subject: [dispatch] Updated STRAW Charter v2 > > > >Howdy, > >Updated charter below... > > > > > >Description of STRAW Working Group > >==================================== > >Name: Sip Traversal Required for Applications to Work (STRAW) > > > >Problem Statement: > >Within the context of the SIP protocol and architecture, a Back-to-Back > >User Agent (B2BUA) is any SIP device in the logical path between two User > >Agents performing a role beyond that of a Proxy as defined in RFC 3261. > >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA > >in order to terminate dead sessions by generating BYEs; or it may be a > >3PCC-style agent only modifying SDP; or it may be a Session Border > >Controller performing such functions as in RFC 5853; or it may be an > >Enterprise PBX terminating REFERs and such; or it may be a complete UAS > >and UAC implementation with a PRI loopback in-between. > > > >In its most extreme form, the scope of the SIP protocol ends at the UAS > >of the B2BUA, and a new SIP protocol scope begins on its UAC side. In > >practice, however, users expect some SIP protocol aspects to go beyond > >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as > >if the B2BUA was not an end unto itself; this is similar to the > >expectation that emails work when they cross from POP and IMAP to/from > >SMTP. > > > >It is impossible to normatively define all the behaviors of B2BUAs in > >general, or even subsets of them such as SBCs or PBXs. Unlike consumer > >NATs, B2BUAs perform widely varying functions for purposes which may be > >unique to their environment, unique to their architecture, or unique to > >the wishes of their administrator. Instead of defining all things a > >given type of B2BUA must do, a more practical objective would be to > >define what very few things any B2BUA must do to make a specific SIP > >mechanism work, and let the market decide whether to do those things. > > > >The name of this working group reflects that practical objective: if > >there were a thin straw between the SIP UAS and UAC of a B2BUA, what must > >be passed through that straw and used on each side. Or viewed another > >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback > >circuit, and if we could extend ISDN, what information would we carry in > >ISDN across the PRI for a specific SIP mechanism to work end-to-end. > > > >For example, the WG could produce a document which specifies that the > >Max-Forwards header field value should be copied and decremented across > >the B2BUA, if the B2BUA wishes to prevent infinite loops. Administrators > >could then tell their B2BUA vendors to comply with the document, if the > >administrator so wishes. > > > > > >Objectives: > >The objectives of the STRAW Working Group are to publish normative > >documents which define which SIP header fields, parameters, MIME bodies, > >body content fields/information, or media-plane characteristics are > >required to traverse between the User Agent "sides" of a B2BUA for > >specific functions to work. > > > >The specific functions covered are expected to relate to > >already-published RFCs or existing RAI area work, as opposed to all > >future IETF work. In other words, the Working Group is not meant to be a > >never-ending source for B2BUA requirements in the RAI area. > > > >Deliverables would indicate which types of B2BUAs would apply or not. > >For example, a document defining the requirements for end-to-end > >DTLS-SRTP would not apply to B2BUAs which terminate media, such as > >transcoders or recorders. > > > > > >Initial Deliverables: > >1) A taxonomy document defining role-types of B2BUAs, as a reference for > >other deliverables. > >2) A framework document for defining requirements and considerations for > >traversing B2BUAs. > >3) A document defining the requirements for B2BUAs with respect to loop > >detection/prevention. > >4) A document defining the requirements for B2BUAs to support end-to-end > >and hop-by-hop media-loopback test calls. > >5) A document defining the requirements for B2BUAs to support DTLS-SRTP > >(RFC 5764) end-to-end. > >6) A document defining the requirements for B2BUAs to support STUN > >message transactions end-to-end. > >7) A document defining the requirements for B2BUAs to support RTCP > >end-to-end. > > > > > >_______________________________________________ > >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 > --bcaec54eebf83ea81d04bc62bec7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daryl,<div><br></div><div>That sounds like signing a blank check. =A0</div>= <div>Will certain implementations be declared non-compliant to the RFC for = some unknown future feature?</div><div><br></div><div>Would this also requi= re future SIP features to add a section, say just prior to the Security sec= tion,</div> <div>that would need to declare handling by B2BUAs?</div><div><br></div><di= v>Mike</div><div><br><br><div class=3D"gmail_quote">On Thu, Mar 29, 2012 at= 9:43 AM, Daryl Malas <span dir=3D"ltr"><<a href=3D"mailto:D.Malas@cable= labs.com">D.Malas@cablelabs.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Christer,<br> <br> Deliverable "2" will be used to create documents defining the req= uirements<br> for B2BUAs to support future/undefined "specific features." It al= lows the<br> working group to not persist indefinitely.<br> <br> I am assuming the deliverables are not listed as a prioritized list. =A0I<b= r> would expect the framework to be completed towards the end, based on<br> previous experience.<br> <br> Framework Examples:<br> <br> <a href=3D"http://tools.ietf.org/html/rfc6117" target=3D"_blank">http://too= ls.ietf.org/html/rfc6117</a><br> <br> <a href=3D"http://tools.ietf.org/html/rfc6390" target=3D"_blank">http://too= ls.ietf.org/html/rfc6390</a><br> <br> --Daryl<br> <br> On 3/29/12 1:20 PM, "Christer Holmberg" <<a href=3D"mailto:chr= ister.holmberg@ericsson.com">christer.holmberg@ericsson.com</a>><br> wrote:<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> ><br> >Hi,<br> ><br> >I support this work, and after a quick look the proposed charter looks<= br> >good, but I have a question for clarification regarding the suggested<b= r> >deliverable 2).<br> ><br> >A question for clarification (my appologies if it has already been<br> >clarified).<br> ><br> >"2) A framework document for defining requirements and considerati= ons for<br> >traversing B2BUAs."<br> ><br> >Deliverables 3) - 7) talk about requirements in order for specific<br> >features to "survive" a B2BUA, but I am not sure what require= ments 2) is<br> >talking about?<br> ><br> >Regards,<br> ><br> >Christer<br> ><br> ><br> ><br> ><br> >-----Original Message-----<br> >From: <a href=3D"mailto:dispatch-bounces@ietf.org">dispatch-bounces@iet= f.org</a> [mailto:<a href=3D"mailto:dispatch-bounces@ietf.org">dispatch-bou= nces@ietf.org</a>] On<br> >Behalf Of Hadriel Kaplan<br> >Sent: 29. maaliskuuta 2012 10:33<br> >To: <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a> list<br> >Subject: [dispatch] Updated STRAW Charter v2<br> ><br> >Howdy,<br> >Updated charter below...<br> ><br> ><br> >Description of STRAW Working Group<br> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> >Name: Sip Traversal Required for Applications to Work (STRAW)<br> ><br> >Problem Statement:<br> >Within the context of the SIP protocol and architecture, a Back-to-Back= <br> >User Agent (B2BUA) is any SIP device in the logical path between two Us= er<br> >Agents performing a role beyond that of a Proxy as defined in RFC 3261.= <br> >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA= <br> >in order to terminate dead sessions by generating BYEs; or it may be a<= br> >3PCC-style agent only modifying SDP; or it may be a Session Border<br> >Controller performing such functions as in RFC 5853; or it may be an<br= > >Enterprise PBX terminating REFERs and such; or it may be a complete UAS= <br> >and UAC implementation with a PRI loopback in-between.<br> ><br> >In its most extreme form, the scope of the SIP protocol ends at the UAS= <br> >of the B2BUA, and a new SIP protocol scope begins on its UAC side. =A0I= n<br> >practice, however, users expect some SIP protocol aspects to go beyond<= br> >the scope of the B2BUA's UAS side, and be traversed onto its UAC si= de, as<br> >if the B2BUA was not an end unto itself; this is similar to the<br> >expectation that emails work when they cross from POP and IMAP to/from<= br> >SMTP.<br> ><br> >It is impossible to normatively define all the behaviors of B2BUAs in<b= r> >general, or even subsets of them such as SBCs or PBXs. Unlike consumer<= br> >NATs, B2BUAs perform widely varying functions for purposes which may be= <br> >unique to their environment, unique to their architecture, or unique to= <br> >the wishes of their administrator. =A0Instead of defining all things a<= br> >given type of B2BUA must do, a more practical objective would be to<br> >define what very few things any B2BUA must do to make a specific SIP<br= > >mechanism work, and let the market decide whether to do those things.<b= r> ><br> >The name of this working group reflects that practical objective: if<br= > >there were a thin straw between the SIP UAS and UAC of a B2BUA, what mu= st<br> >be passed through that straw and used on each side. =A0Or viewed anothe= r<br> >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopbac= k<br> >circuit, and if we could extend ISDN, what information would we carry i= n<br> >ISDN across the PRI for a specific SIP mechanism to work end-to-end.<br= > ><br> >For example, the WG could produce a document which specifies that the<b= r> >Max-Forwards header field value should be copied and decremented across= <br> >the B2BUA, if the B2BUA wishes to prevent infinite loops. =A0Administra= tors<br> >could then tell their B2BUA vendors to comply with the document, if the= <br> >administrator so wishes.<br> ><br> ><br> >Objectives:<br> >The objectives of the STRAW Working Group are to publish normative<br> >documents which define which SIP header fields, parameters, MIME bodies= ,<br> >body content fields/information, or media-plane characteristics are<br> >required to traverse between the User Agent "sides" of a B2BU= A for<br> >specific functions to work.<br> ><br> >The specific functions covered are expected to relate to<br> >already-published RFCs or existing RAI area work, as opposed to all<br> >future IETF work. =A0In other words, the Working Group is not meant to = be a<br> >never-ending source for B2BUA requirements in the RAI area.<br> ><br> >Deliverables would indicate which types of B2BUAs would apply or not.<b= r> >For example, a document defining the requirements for end-to-end<br> >DTLS-SRTP would not apply to B2BUAs which terminate media, such as<br> >transcoders or recorders.<br> ><br> ><br> >Initial Deliverables:<br> >1) A taxonomy document defining role-types of B2BUAs, as a reference fo= r<br> >other deliverables.<br> >2) A framework document for defining requirements and considerations fo= r<br> >traversing B2BUAs.<br> >3) A document defining the requirements for B2BUAs with respect to loop= <br> >detection/prevention.<br> >4) A document defining the requirements for B2BUAs to support end-to-en= d<br> >and hop-by-hop media-loopback test calls.<br> >5) A document defining the requirements for B2BUAs to support DTLS-SRTP= <br> >(RFC 5764) end-to-end.<br> >6) A document defining the requirements for B2BUAs to support STUN<br> >message transactions end-to-end.<br> >7) A document defining the requirements for B2BUAs to support RTCP<br> >end-to-end.<br> ><br> ><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br> <br> _______________________________________________<br> dispatch mailing list<br> <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/dispatch</a><br> </div></div></blockquote></div><br></div> --bcaec54eebf83ea81d04bc62bec7-- From D.Malas@cablelabs.com Thu Mar 29 07:56:10 2012 Return-Path: <D.Malas@cablelabs.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C1621E819C for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 07:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.383 X-Spam-Level: X-Spam-Status: No, score=-100.383 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnO1v2MvQbcL for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 07:56:09 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id BF7C321E809C for <dispatch@ietf.org>; Thu, 29 Mar 2012 07:56:08 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2TEtu2O026392; Thu, 29 Mar 2012 08:55:56 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 29 Mar 2012 08:55:56 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 29 Mar 2012 08:55:57 -0600 From: Daryl Malas <D.Malas@cablelabs.com> To: Michael Hammer <mphmmr@gmail.com> Date: Thu, 29 Mar 2012 08:55:53 -0600 Thread-Topic: [dispatch] Updated STRAW Charter v2 Thread-Index: Ac0NvAt88k7IxO2lTQK9hZw77JEqwg== Message-ID: <CB9A431C.DC38%d.malas@cablelabs.com> In-Reply-To: <CAA3wLqWXufOGXnbsQ8hwWwLHvjLQjTBQtTkC3fF2RmpQ_Nn7OA@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB9A431CDC38dmalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] Updated STRAW Charter v2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 29 Mar 2012 14:56:10 -0000 --_000_CB9A431CDC38dmalascablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael, I do not view it this way. If someone develops a requirements document bas= ed on the framework, it would still need to be approved by a directorate (o= nly used as an example, may not really apply) or something similar. The ma= iling list could also be kept open for these. There are existing examples = of processes for this. With regards to the considerations, the document would provide details of v= ariables to include in a considerations section. Again, the considerations= section, part of an Internet Draft, would still need to be reviewed and pr= ocessed by the working group, AD's, IESG, etc. --Daryl From: Michael Hammer <mphmmr@gmail.com<mailto:mphmmr@gmail.com>> Date: Thu, 29 Mar 2012 08:43:11 -0600 To: Daryl Malas <d.malas@cablelabs.com<mailto:d.malas@cablelabs.com>> Cc: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmb= erg@ericsson.com>>, Hadriel Kaplan <HKaplan@acmepacket.com<mailto:HKaplan@a= cmepacket.com>>, "dispatch@ietf.org<mailto:dispatch@ietf.org> list" <dispat= ch@ietf.org<mailto:dispatch@ietf.org>> Subject: Re: [dispatch] Updated STRAW Charter v2 Daryl, That sounds like signing a blank check. Will certain implementations be declared non-compliant to the RFC for some = unknown future feature? Would this also require future SIP features to add a section, say just prio= r to the Security section, that would need to declare handling by B2BUAs? Mike On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <D.Malas@cablelabs.com<mailto:= D.Malas@cablelabs.com>> wrote: Christer, Deliverable "2" will be used to create documents defining the requirements for B2BUAs to support future/undefined "specific features." It allows the working group to not persist indefinitely. I am assuming the deliverables are not listed as a prioritized list. I would expect the framework to be completed towards the end, based on previous experience. Framework Examples: http://tools.ietf.org/html/rfc6117 http://tools.ietf.org/html/rfc6390 --Daryl On 3/29/12 1:20 PM, "Christer Holmberg" <christer.holmberg@ericsson.com<mai= lto:christer.holmberg@ericsson.com>> wrote: > >Hi, > >I support this work, and after a quick look the proposed charter looks >good, but I have a question for clarification regarding the suggested >deliverable 2). > >A question for clarification (my appologies if it has already been >clarified). > >"2) A framework document for defining requirements and considerations for >traversing B2BUAs." > >Deliverables 3) - 7) talk about requirements in order for specific >features to "survive" a B2BUA, but I am not sure what requirements 2) is >talking about? > >Regards, > >Christer > > > > >-----Original Message----- >From: dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org> [mailto:= dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org>] On >Behalf Of Hadriel Kaplan >Sent: 29. maaliskuuta 2012 10:33 >To: dispatch@ietf.org<mailto:dispatch@ietf.org> list >Subject: [dispatch] Updated STRAW Charter v2 > >Howdy, >Updated charter below... > > >Description of STRAW Working Group >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Name: Sip Traversal Required for Applications to Work (STRAW) > >Problem Statement: >Within the context of the SIP protocol and architecture, a Back-to-Back >User Agent (B2BUA) is any SIP device in the logical path between two User >Agents performing a role beyond that of a Proxy as defined in RFC 3261. >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA >in order to terminate dead sessions by generating BYEs; or it may be a >3PCC-style agent only modifying SDP; or it may be a Session Border >Controller performing such functions as in RFC 5853; or it may be an >Enterprise PBX terminating REFERs and such; or it may be a complete UAS >and UAC implementation with a PRI loopback in-between. > >In its most extreme form, the scope of the SIP protocol ends at the UAS >of the B2BUA, and a new SIP protocol scope begins on its UAC side. In >practice, however, users expect some SIP protocol aspects to go beyond >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as >if the B2BUA was not an end unto itself; this is similar to the >expectation that emails work when they cross from POP and IMAP to/from >SMTP. > >It is impossible to normatively define all the behaviors of B2BUAs in >general, or even subsets of them such as SBCs or PBXs. Unlike consumer >NATs, B2BUAs perform widely varying functions for purposes which may be >unique to their environment, unique to their architecture, or unique to >the wishes of their administrator. Instead of defining all things a >given type of B2BUA must do, a more practical objective would be to >define what very few things any B2BUA must do to make a specific SIP >mechanism work, and let the market decide whether to do those things. > >The name of this working group reflects that practical objective: if >there were a thin straw between the SIP UAS and UAC of a B2BUA, what must >be passed through that straw and used on each side. Or viewed another >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback >circuit, and if we could extend ISDN, what information would we carry in >ISDN across the PRI for a specific SIP mechanism to work end-to-end. > >For example, the WG could produce a document which specifies that the >Max-Forwards header field value should be copied and decremented across >the B2BUA, if the B2BUA wishes to prevent infinite loops. Administrators >could then tell their B2BUA vendors to comply with the document, if the >administrator so wishes. > > >Objectives: >The objectives of the STRAW Working Group are to publish normative >documents which define which SIP header fields, parameters, MIME bodies, >body content fields/information, or media-plane characteristics are >required to traverse between the User Agent "sides" of a B2BUA for >specific functions to work. > >The specific functions covered are expected to relate to >already-published RFCs or existing RAI area work, as opposed to all >future IETF work. In other words, the Working Group is not meant to be a >never-ending source for B2BUA requirements in the RAI area. > >Deliverables would indicate which types of B2BUAs would apply or not. >For example, a document defining the requirements for end-to-end >DTLS-SRTP would not apply to B2BUAs which terminate media, such as >transcoders or recorders. > > >Initial Deliverables: >1) A taxonomy document defining role-types of B2BUAs, as a reference for >other deliverables. >2) A framework document for defining requirements and considerations for >traversing B2BUAs. >3) A document defining the requirements for B2BUAs with respect to loop >detection/prevention. >4) A document defining the requirements for B2BUAs to support end-to-end >and hop-by-hop media-loopback test calls. >5) A document defining the requirements for B2BUAs to support DTLS-SRTP >(RFC 5764) end-to-end. >6) A document defining the requirements for B2BUAs to support STUN >message transactions end-to-end. >7) A document defining the requirements for B2BUAs to support RTCP >end-to-end. > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org<mailto:dispatch@ietf.org> >https://www.ietf.org/mailman/listinfo/dispatch >_______________________________________________ >dispatch mailing list >dispatch@ietf.org<mailto:dispatch@ietf.org> >https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch --_000_CB9A431CDC38dmalascablelabscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:= space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-si= ze: 14px; font-family: Calibri, sans-serif; "><div>Michael,</div><div><br><= /div><div>I do not view it this way.  If someone develops a requiremen= ts document based on the framework, it would still need to be approved by a= directorate (only used as an example, may not really apply) or something s= imilar.  The mailing list could also be kept open for these.  The= re are existing examples of processes for this.  </div><div><br></div>= <div>With regards to the considerations, the document would provide details= of variables to include in a considerations section.  Again, the cons= iderations section, part of an Internet Draft, would still need to be revie= wed and processed by the working group, AD's, IESG, etc.</div><div><br></di= v><div>--Daryl</div><div><br></div><span id=3D"OLK_SRC_BODY_SECTION"><div s= tyle=3D"font-family:Calibri; font-size:11pt; text-align:left; color:black; = BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; = PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDE= R-RIGHT: medium none; PADDING-TOP: 3pt"><span style=3D"font-weight:bold">Fr= om: </span> Michael Hammer <<a href=3D"mailto:mphmmr@gmail.com">mphmmr@g= mail.com</a>><br><span style=3D"font-weight:bold">Date: </span> Thu, 29 = Mar 2012 08:43:11 -0600<br><span style=3D"font-weight:bold">To: </span> Dar= yl Malas <<a href=3D"mailto:d.malas@cablelabs.com">d.malas@cablelabs.com= </a>><br><span style=3D"font-weight:bold">Cc: </span> Christer Holmberg = <<a href=3D"mailto:christer.holmberg@ericsson.com">christer.holmberg@eri= csson.com</a>>, Hadriel Kaplan <<a href=3D"mailto:HKaplan@acmepacket.= com">HKaplan@acmepacket.com</a>>, "<a href=3D"mailto:dispatch@ietf.org">= dispatch@ietf.org</a> list" <<a href=3D"mailto:dispatch@ietf.org">dispat= ch@ietf.org</a>><br><span style=3D"font-weight:bold">Subject: </span> Re= : [dispatch] Updated STRAW Charter v2<br></div><div><br></div>Daryl,<div><b= r></div><div>That sounds like signing a blank check.  </div><div>Will = certain implementations be declared non-compliant to the RFC for some unkno= wn future feature?</div><div><br></div><div>Would this also require future = SIP features to add a section, say just prior to the Security section,</div= ><div>that would need to declare handling by B2BUAs?</div><div><br></div><d= iv>Mike</div><div><br><br><div class=3D"gmail_quote">On Thu, Mar 29, 2012 a= t 9:43 AM, Daryl Malas <span dir=3D"ltr"><<a href=3D"mailto:D.Malas@cabl= elabs.com">D.Malas@cablelabs.com</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex">Christer,<br><br> Deliverable "2" will be used to create documents defining the requirements<= br> for B2BUAs to support future/undefined "specific features." It allows the<b= r> working group to not persist indefinitely.<br><br> I am assuming the deliverables are not listed as a prioritized list.  = I<br> would expect the framework to be completed towards the end, based on<br> previous experience.<br><br> Framework Examples:<br><br><a href=3D"http://tools.ietf.org/html/rfc6117" t= arget=3D"_blank">http://tools.ietf.org/html/rfc6117</a><br><br><a href=3D"h= ttp://tools.ietf.org/html/rfc6390" target=3D"_blank">http://tools.ietf.org/= html/rfc6390</a><br><br> --Daryl<br><br> On 3/29/12 1:20 PM, "Christer Holmberg" <<a href=3D"mailto:christer.holm= berg@ericsson.com">christer.holmberg@ericsson.com</a>><br> wrote:<br><div class=3D"HOEnZb"><div class=3D"h5"><br> ><br> >Hi,<br> ><br> >I support this work, and after a quick look the proposed charter looks<= br> >good, but I have a question for clarification regarding the suggested<b= r> >deliverable 2).<br> ><br> >A question for clarification (my appologies if it has already been<br> >clarified).<br> ><br> >"2) A framework document for defining requirements and considerations f= or<br> >traversing B2BUAs."<br> ><br> >Deliverables 3) - 7) talk about requirements in order for specific<br> >features to "survive" a B2BUA, but I am not sure what requirements 2) i= s<br> >talking about?<br> ><br> >Regards,<br> ><br> >Christer<br> ><br> ><br> ><br> ><br> >-----Original Message-----<br> >From: <a href=3D"mailto:dispatch-bounces@ietf.org">dispatch-bounces@iet= f.org</a> [mailto:<a href=3D"mailto:dispatch-bounces@ietf.org">dispatch-bou= nces@ietf.org</a>] On<br> >Behalf Of Hadriel Kaplan<br> >Sent: 29. maaliskuuta 2012 10:33<br> >To: <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a> list<br> >Subject: [dispatch] Updated STRAW Charter v2<br> ><br> >Howdy,<br> >Updated charter below...<br> ><br> ><br> >Description of STRAW Working Group<br> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> >Name: Sip Traversal Required for Applications to Work (STRAW)<br> ><br> >Problem Statement:<br> >Within the context of the SIP protocol and architecture, a Back-to-Back= <br> >User Agent (B2BUA) is any SIP device in the logical path between two Us= er<br> >Agents performing a role beyond that of a Proxy as defined in RFC 3261.= <br> >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA= <br> >in order to terminate dead sessions by generating BYEs; or it may be a<= br> >3PCC-style agent only modifying SDP; or it may be a Session Border<br> >Controller performing such functions as in RFC 5853; or it may be an<br= > >Enterprise PBX terminating REFERs and such; or it may be a complete UAS= <br> >and UAC implementation with a PRI loopback in-between.<br> ><br> >In its most extreme form, the scope of the SIP protocol ends at the UAS= <br> >of the B2BUA, and a new SIP protocol scope begins on its UAC side. &nbs= p;In<br> >practice, however, users expect some SIP protocol aspects to go beyond<= br> >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, = as<br> >if the B2BUA was not an end unto itself; this is similar to the<br> >expectation that emails work when they cross from POP and IMAP to/from<= br> >SMTP.<br> ><br> >It is impossible to normatively define all the behaviors of B2BUAs in<b= r> >general, or even subsets of them such as SBCs or PBXs. Unlike consumer<= br> >NATs, B2BUAs perform widely varying functions for purposes which may be= <br> >unique to their environment, unique to their architecture, or unique to= <br> >the wishes of their administrator.  Instead of defining all things= a<br> >given type of B2BUA must do, a more practical objective would be to<br>= >define what very few things any B2BUA must do to make a specific SIP<br= > >mechanism work, and let the market decide whether to do those things.<b= r> ><br> >The name of this working group reflects that practical objective: if<br= > >there were a thin straw between the SIP UAS and UAC of a B2BUA, what mu= st<br> >be passed through that straw and used on each side.  Or viewed ano= ther<br> >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopbac= k<br> >circuit, and if we could extend ISDN, what information would we carry i= n<br> >ISDN across the PRI for a specific SIP mechanism to work end-to-end.<br= > ><br> >For example, the WG could produce a document which specifies that the<b= r> >Max-Forwards header field value should be copied and decremented across= <br> >the B2BUA, if the B2BUA wishes to prevent infinite loops.  Adminis= trators<br> >could then tell their B2BUA vendors to comply with the document, if the= <br> >administrator so wishes.<br> ><br> ><br> >Objectives:<br> >The objectives of the STRAW Working Group are to publish normative<br> >documents which define which SIP header fields, parameters, MIME bodies= ,<br> >body content fields/information, or media-plane characteristics are<br>= >required to traverse between the User Agent "sides" of a B2BUA for<br> >specific functions to work.<br> ><br> >The specific functions covered are expected to relate to<br> >already-published RFCs or existing RAI area work, as opposed to all<br>= >future IETF work.  In other words, the Working Group is not meant = to be a<br> >never-ending source for B2BUA requirements in the RAI area.<br> ><br> >Deliverables would indicate which types of B2BUAs would apply or not.<b= r> >For example, a document defining the requirements for end-to-end<br> >DTLS-SRTP would not apply to B2BUAs which terminate media, such as<br> >transcoders or recorders.<br> ><br> ><br> >Initial Deliverables:<br> >1) A taxonomy document defining role-types of B2BUAs, as a reference fo= r<br> >other deliverables.<br> >2) A framework document for defining requirements and considerations fo= r<br> >traversing B2BUAs.<br> >3) A document defining the requirements for B2BUAs with respect to loop= <br> >detection/prevention.<br> >4) A document defining the requirements for B2BUAs to support end-to-en= d<br> >and hop-by-hop media-loopback test calls.<br> >5) A document defining the requirements for B2BUAs to support DTLS-SRTP= <br> >(RFC 5764) end-to-end.<br> >6) A document defining the requirements for B2BUAs to support STUN<br> >message transactions end-to-end.<br> >7) A document defining the requirements for B2BUAs to support RTCP<br> >end-to-end.<br> ><br> ><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br><br> _______________________________________________<br> dispatch mailing list<br><a href=3D"mailto:dispatch@ietf.org">dispatch@ietf= .org</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" targ= et=3D"_blank">https://www.ietf.org/mailman/listinfo/dispatch</a><br></div><= /div></blockquote></div><br></div></span></body></html> --_000_CB9A431CDC38dmalascablelabscom_-- From pkyzivat@alum.mit.edu Thu Mar 29 07:59:51 2012 Return-Path: <pkyzivat@alum.mit.edu> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E349621E81C7 for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 07:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg-Wn-NODyf2 for <dispatch@ietfa.amsl.com>; Thu, 29 Mar 2012 07:59:51 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id B402021E809C for <dispatch@ietf.org>; Thu, 29 Mar 2012 07:59:50 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta07.westchester.pa.mail.comcast.net with comcast id rSxL1i00617dt5G57SzrvG; Thu, 29 Mar 2012 14:59:51 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta13.westchester.pa.mail.comcast.net with comcast id rSzi1i0065EhBnE3ZSzkd8; Thu, 29 Mar 2012 14:59:49 +0000 Message-ID: <4F7478DB.3050508@alum.mit.edu> Date: Thu, 29 Mar 2012 16:59:39 +0200 From: Paul Kyzivat <pkyzivat@alum.mit.edu> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852C429F5D8F@ESESSCMS0356.eemea.ericsson.se> <CB9A3140.DBF1%d.malas@cablelabs.com> <CAA3wLqWXufOGXnbsQ8hwWwLHvjLQjTBQtTkC3fF2RmpQ_Nn7OA@mail.gmail.com> In-Reply-To: <CAA3wLqWXufOGXnbsQ8hwWwLHvjLQjTBQtTkC3fF2RmpQ_Nn7OA@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Updated STRAW Charter v2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 29 Mar 2012 14:59:52 -0000 On 3/29/12 4:43 PM, Michael Hammer wrote: > Would this also require future SIP features to add a section, say just > prior to the Security section, > that would need to declare handling by B2BUAs? That seems like the only sustainable approach I can envision. Thanks, Paul > Mike > > > On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <D.Malas@cablelabs.com > <mailto:D.Malas@cablelabs.com>> wrote: > > Christer, > > Deliverable "2" will be used to create documents defining the > requirements > for B2BUAs to support future/undefined "specific features." It > allows the > working group to not persist indefinitely. > > I am assuming the deliverables are not listed as a prioritized list. I > would expect the framework to be completed towards the end, based on > previous experience. > > Framework Examples: > > http://tools.ietf.org/html/rfc6117 > > http://tools.ietf.org/html/rfc6390 > > --Daryl > > On 3/29/12 1:20 PM, "Christer Holmberg" > <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>> > wrote: > > > > >Hi, > > > >I support this work, and after a quick look the proposed charter looks > >good, but I have a question for clarification regarding the suggested > >deliverable 2). > > > >A question for clarification (my appologies if it has already been > >clarified). > > > >"2) A framework document for defining requirements and > considerations for > >traversing B2BUAs." > > > >Deliverables 3) - 7) talk about requirements in order for specific > >features to "survive" a B2BUA, but I am not sure what requirements > 2) is > >talking about? > > > >Regards, > > > >Christer > > > > > > > > > >-----Original Message----- > >From: dispatch-bounces@ietf.org <mailto:dispatch-bounces@ietf.org> > [mailto:dispatch-bounces@ietf.org <mailto:dispatch-bounces@ietf.org>] On > >Behalf Of Hadriel Kaplan > >Sent: 29. maaliskuuta 2012 10:33 > >To: dispatch@ietf.org <mailto:dispatch@ietf.org> list > >Subject: [dispatch] Updated STRAW Charter v2 > > > >Howdy, > >Updated charter below... > > > > > >Description of STRAW Working Group > >==================================== > >Name: Sip Traversal Required for Applications to Work (STRAW) > > > >Problem Statement: > >Within the context of the SIP protocol and architecture, a > Back-to-Back > >User Agent (B2BUA) is any SIP device in the logical path between > two User > >Agents performing a role beyond that of a Proxy as defined in RFC > 3261. > >The B2BUA may be as simple as a session-stateful Proxy becoming a > B2BUA > >in order to terminate dead sessions by generating BYEs; or it may be a > >3PCC-style agent only modifying SDP; or it may be a Session Border > >Controller performing such functions as in RFC 5853; or it may be an > >Enterprise PBX terminating REFERs and such; or it may be a > complete UAS > >and UAC implementation with a PRI loopback in-between. > > > >In its most extreme form, the scope of the SIP protocol ends at > the UAS > >of the B2BUA, and a new SIP protocol scope begins on its UAC side. In > >practice, however, users expect some SIP protocol aspects to go beyond > >the scope of the B2BUA's UAS side, and be traversed onto its UAC > side, as > >if the B2BUA was not an end unto itself; this is similar to the > >expectation that emails work when they cross from POP and IMAP to/from > >SMTP. > > > >It is impossible to normatively define all the behaviors of B2BUAs in > >general, or even subsets of them such as SBCs or PBXs. Unlike consumer > >NATs, B2BUAs perform widely varying functions for purposes which > may be > >unique to their environment, unique to their architecture, or > unique to > >the wishes of their administrator. Instead of defining all things a > >given type of B2BUA must do, a more practical objective would be to > >define what very few things any B2BUA must do to make a specific SIP > >mechanism work, and let the market decide whether to do those things. > > > >The name of this working group reflects that practical objective: if > >there were a thin straw between the SIP UAS and UAC of a B2BUA, > what must > >be passed through that straw and used on each side. Or viewed another > >way, if a B2BUA were in fact a UAS and UAC connected with a PRI > loopback > >circuit, and if we could extend ISDN, what information would we > carry in > >ISDN across the PRI for a specific SIP mechanism to work end-to-end. > > > >For example, the WG could produce a document which specifies that the > >Max-Forwards header field value should be copied and decremented > across > >the B2BUA, if the B2BUA wishes to prevent infinite loops. > Administrators > >could then tell their B2BUA vendors to comply with the document, > if the > >administrator so wishes. > > > > > >Objectives: > >The objectives of the STRAW Working Group are to publish normative > >documents which define which SIP header fields, parameters, MIME > bodies, > >body content fields/information, or media-plane characteristics are > >required to traverse between the User Agent "sides" of a B2BUA for > >specific functions to work. > > > >The specific functions covered are expected to relate to > >already-published RFCs or existing RAI area work, as opposed to all > >future IETF work. In other words, the Working Group is not meant > to be a > >never-ending source for B2BUA requirements in the RAI area. > > > >Deliverables would indicate which types of B2BUAs would apply or not. > >For example, a document defining the requirements for end-to-end > >DTLS-SRTP would not apply to B2BUAs which terminate media, such as > >transcoders or recorders. > > > > > >Initial Deliverables: > >1) A taxonomy document defining role-types of B2BUAs, as a > reference for > >other deliverables. > >2) A framework document for defining requirements and > considerations for > >traversing B2BUAs. > >3) A document defining the requirements for B2BUAs with respect to > loop > >detection/prevention. > >4) A document defining the requirements for B2BUAs to support > end-to-end > >and hop-by-hop media-loopback test calls. > >5) A document defining the requirements for B2BUAs to support > DTLS-SRTP > >(RFC 5764) end-to-end. > >6) A document defining the requirements for B2BUAs to support STUN > >message transactions end-to-end. > >7) A document defining the requirements for B2BUAs to support RTCP > >end-to-end. > > > > > >_______________________________________________ > >dispatch mailing list > >dispatch@ietf.org <mailto:dispatch@ietf.org> > >https://www.ietf.org/mailman/listinfo/dispatch > >_______________________________________________ > >dispatch mailing list > >dispatch@ietf.org <mailto:dispatch@ietf.org> > >https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org <mailto: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 Mar 30 09:22:23 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35BF21F8533 for <dispatch@ietfa.amsl.com>; Fri, 30 Mar 2012 09:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqNqyURshTqy for <dispatch@ietfa.amsl.com>; Fri, 30 Mar 2012 09:22:23 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id C4FFE21F852A for <dispatch@ietf.org>; Fri, 30 Mar 2012 09:22:22 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 30 Mar 2012 12:22:20 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.64]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Fri, 30 Mar 2012 12:22:19 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: Michael Hammer <mphmmr@gmail.com> Thread-Topic: [dispatch] Updated STRAW Charter v2 Thread-Index: AQHNDpFH8k7IxO2lTQK9hZw77JEqwg== Date: Fri, 30 Mar 2012 16:22:19 +0000 Message-ID: <5154BBCD-26E7-4884-B981-F6F51EE05F5B@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C429F5D8F@ESESSCMS0356.eemea.ericsson.se> <CB9A3140.DBF1%d.malas@cablelabs.com> <CAA3wLqWXufOGXnbsQ8hwWwLHvjLQjTBQtTkC3fF2RmpQ_Nn7OA@mail.gmail.com> In-Reply-To: <CAA3wLqWXufOGXnbsQ8hwWwLHvjLQjTBQtTkC3fF2RmpQ_Nn7OA@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="Windows-1252" Content-ID: <589C6BB4CF29D64A96F33FE91CF68082@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] Updated STRAW Charter v2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 30 Mar 2012 16:22:23 -0000 Hey Mike, comments inline=85 On Mar 29, 2012, at 4:43 PM, Michael Hammer wrote: > That sounds like signing a blank check. =20 > Will certain implementations be declared non-compliant to the RFC for som= e unknown future feature? I'm not quite sure in what way you meant that - which RFC your above senten= ce refers to. =20 Do you mean: "Assume we publish this Framework as RFC X, would a B2BUA that= is not compliant to RFC X also not be compliant to future SIP features/ext= ensions in other future RFCs?" If you meant that, I certainly don't expect= that to be the case. First, I don't even think it would be possible to de= fine a Framework that stipulated how B2BUAs should behave for any given fut= ure SIP extension. To me a "Framework" in this case is more of a guideline= s and recommendations for future RFCs to consider how their new extension m= ight be impacted by B2BUAs, and how they could/should address it in the fut= ure RFCs. Or did you mean: "assume we publish this Framework as RFC X, and some futur= e IETF RFC Y includes a B2BUA considerations section based on RFC X's guide= lines, then would a B2BUA not following those considerations in RFC Y be no= n-compliant to RFC Y?" If you meant that, then yes that's likely. I mean = if a future RFC Y defined for a B2BUA to behave a certain way to support so= me extension working, and a B2BUA didn't do it, then by definition the B2BU= A wouldn't be compliant to RFC Y. > Would this also require future SIP features to add a section, say just pr= ior to the Security section, > that would need to declare handling by B2BUAs? I don't believe it would "require" it, at least not in the same sense that = the Security section is required. Personally I'd rather it be a guidelines= type thing, and that individual RAI-area RFCs get to ignore it. For examp= le if it's just not relevant to RTCWeb nor VIPR. But it's up to the A-D's = or RAI area to decide how applicable it would be, presumably. -hadriel From HKaplan@acmepacket.com Fri Mar 30 09:29:15 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701A421F8527 for <dispatch@ietfa.amsl.com>; Fri, 30 Mar 2012 09:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aayK89l1-Qvo for <dispatch@ietfa.amsl.com>; Fri, 30 Mar 2012 09:29:14 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B4BB421F84DD for <dispatch@ietf.org>; Fri, 30 Mar 2012 09:29:13 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 30 Mar 2012 12:29:12 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.64]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Fri, 30 Mar 2012 12:29:12 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: Daryl Malas <D.Malas@cablelabs.com> Thread-Topic: [dispatch] Updated STRAW Charter v2 Thread-Index: AQHNDpI98k7IxO2lTQK9hZw77JEqwg== Date: Fri, 30 Mar 2012 16:29:12 +0000 Message-ID: <40B778D0-8451-44FA-A822-D816F0CAB750@acmepacket.com> References: <CB9A431C.DC38%d.malas@cablelabs.com> In-Reply-To: <CB9A431C.DC38%d.malas@cablelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: multipart/alternative; boundary="_000_40B778D0845144FAA822D816F0CAB750acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] Updated STRAW Charter v2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 30 Mar 2012 16:29:15 -0000 --_000_40B778D0845144FAA822D816F0CAB750acmepacketcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Daryl, Do you mind if I remove that deliverable from the Charter? The STRAW Worki= ng Group can always add it back in, once the WG's established and there's a= candidate draft to look at and think about. I think I understand what you= 're looking for and I like the idea, but I too am not sure if we're all on = the same page, or if we can actually produce such a document. So I'd prefe= r to just delay that one until we have such a draft written up, and so we c= an get STRAW created sooner. As you said it would be timed toward the end = anyway, so there's no urgency. -hadriel On Mar 29, 2012, at 4:55 PM, Daryl Malas wrote: Michael, I do not view it this way. If someone develops a requirements document bas= ed on the framework, it would still need to be approved by a directorate (o= nly used as an example, may not really apply) or something similar. The ma= iling list could also be kept open for these. There are existing examples = of processes for this. With regards to the considerations, the document would provide details of v= ariables to include in a considerations section. Again, the considerations= section, part of an Internet Draft, would still need to be reviewed and pr= ocessed by the working group, AD's, IESG, etc. --Daryl From: Michael Hammer <mphmmr@gmail.com<mailto:mphmmr@gmail.com>> Date: Thu, 29 Mar 2012 08:43:11 -0600 To: Daryl Malas <d.malas@cablelabs.com<mailto:d.malas@cablelabs.com>> Cc: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmb= erg@ericsson.com>>, Hadriel Kaplan <HKaplan@acmepacket.com<mailto:HKaplan@a= cmepacket.com>>, "dispatch@ietf.org<mailto:dispatch@ietf.org> list" <dispat= ch@ietf.org<mailto:dispatch@ietf.org>> Subject: Re: [dispatch] Updated STRAW Charter v2 Daryl, That sounds like signing a blank check. Will certain implementations be declared non-compliant to the RFC for some = unknown future feature? Would this also require future SIP features to add a section, say just prio= r to the Security section, that would need to declare handling by B2BUAs? Mike On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <D.Malas@cablelabs.com<mailto:= D.Malas@cablelabs.com>> wrote: Christer, Deliverable "2" will be used to create documents defining the requirements for B2BUAs to support future/undefined "specific features." It allows the working group to not persist indefinitely. I am assuming the deliverables are not listed as a prioritized list. I would expect the framework to be completed towards the end, based on previous experience. Framework Examples: http://tools.ietf.org/html/rfc6117 http://tools.ietf.org/html/rfc6390 --Daryl On 3/29/12 1:20 PM, "Christer Holmberg" <christer.holmberg@ericsson.com<mai= lto:christer.holmberg@ericsson.com>> wrote: > >Hi, > >I support this work, and after a quick look the proposed charter looks >good, but I have a question for clarification regarding the suggested >deliverable 2). > >A question for clarification (my appologies if it has already been >clarified). > >"2) A framework document for defining requirements and considerations for >traversing B2BUAs." > >Deliverables 3) - 7) talk about requirements in order for specific >features to "survive" a B2BUA, but I am not sure what requirements 2) is >talking about? > >Regards, > >Christer > > > > >-----Original Message----- >From: dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org> [mailto:= dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org>] On >Behalf Of Hadriel Kaplan >Sent: 29. maaliskuuta 2012 10:33 >To: dispatch@ietf.org<mailto:dispatch@ietf.org> list >Subject: [dispatch] Updated STRAW Charter v2 > >Howdy, >Updated charter below... > > >Description of STRAW Working Group >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Name: Sip Traversal Required for Applications to Work (STRAW) > >Problem Statement: >Within the context of the SIP protocol and architecture, a Back-to-Back >User Agent (B2BUA) is any SIP device in the logical path between two User >Agents performing a role beyond that of a Proxy as defined in RFC 3261. >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA >in order to terminate dead sessions by generating BYEs; or it may be a >3PCC-style agent only modifying SDP; or it may be a Session Border >Controller performing such functions as in RFC 5853; or it may be an >Enterprise PBX terminating REFERs and such; or it may be a complete UAS >and UAC implementation with a PRI loopback in-between. > >In its most extreme form, the scope of the SIP protocol ends at the UAS >of the B2BUA, and a new SIP protocol scope begins on its UAC side. In >practice, however, users expect some SIP protocol aspects to go beyond >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as >if the B2BUA was not an end unto itself; this is similar to the >expectation that emails work when they cross from POP and IMAP to/from >SMTP. > >It is impossible to normatively define all the behaviors of B2BUAs in >general, or even subsets of them such as SBCs or PBXs. Unlike consumer >NATs, B2BUAs perform widely varying functions for purposes which may be >unique to their environment, unique to their architecture, or unique to >the wishes of their administrator. Instead of defining all things a >given type of B2BUA must do, a more practical objective would be to >define what very few things any B2BUA must do to make a specific SIP >mechanism work, and let the market decide whether to do those things. > >The name of this working group reflects that practical objective: if >there were a thin straw between the SIP UAS and UAC of a B2BUA, what must >be passed through that straw and used on each side. Or viewed another >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback >circuit, and if we could extend ISDN, what information would we carry in >ISDN across the PRI for a specific SIP mechanism to work end-to-end. > >For example, the WG could produce a document which specifies that the >Max-Forwards header field value should be copied and decremented across >the B2BUA, if the B2BUA wishes to prevent infinite loops. Administrators >could then tell their B2BUA vendors to comply with the document, if the >administrator so wishes. > > >Objectives: >The objectives of the STRAW Working Group are to publish normative >documents which define which SIP header fields, parameters, MIME bodies, >body content fields/information, or media-plane characteristics are >required to traverse between the User Agent "sides" of a B2BUA for >specific functions to work. > >The specific functions covered are expected to relate to >already-published RFCs or existing RAI area work, as opposed to all >future IETF work. In other words, the Working Group is not meant to be a >never-ending source for B2BUA requirements in the RAI area. > >Deliverables would indicate which types of B2BUAs would apply or not. >For example, a document defining the requirements for end-to-end >DTLS-SRTP would not apply to B2BUAs which terminate media, such as >transcoders or recorders. > > >Initial Deliverables: >1) A taxonomy document defining role-types of B2BUAs, as a reference for >other deliverables. >2) A framework document for defining requirements and considerations for >traversing B2BUAs. >3) A document defining the requirements for B2BUAs with respect to loop >detection/prevention. >4) A document defining the requirements for B2BUAs to support end-to-end >and hop-by-hop media-loopback test calls. >5) A document defining the requirements for B2BUAs to support DTLS-SRTP >(RFC 5764) end-to-end. >6) A document defining the requirements for B2BUAs to support STUN >message transactions end-to-end. >7) A document defining the requirements for B2BUAs to support RTCP >end-to-end. > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org<mailto:dispatch@ietf.org> >https://www.ietf.org/mailman/listinfo/dispatch >_______________________________________________ >dispatch mailing list >dispatch@ietf.org<mailto:dispatch@ietf.org> >https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch --_000_40B778D0845144FAA822D816F0CAB750acmepacketcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <ABA00BE01F729A449E425467CE31C8D8@acmepacket.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; "> <div><br> </div> <div>Daryl,</div> <div>Do you mind if I remove that deliverable from the Charter?  The S= TRAW Working Group can always add it back in, once the WG's established and= there's a candidate draft to look at and think about.  I think I unde= rstand what you're looking for and I like the idea, but I too am not sure if we're all on the same page, or if we ca= n actually produce such a document.  So I'd prefer to just delay that = one until we have such a draft written up, and so we can get STRAW created = sooner.  As you said it would be timed toward the end anyway, so there's no urgency.</div> <div><br> </div> <div>-hadriel</div> <div><br> </div> <br> <div> <div>On Mar 29, 2012, at 4:55 PM, Daryl Malas wrote:</div> <br class=3D"Apple-interchange-newline"> <blockquote type=3D"cite"> <div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line= -break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-famil= y: Calibri, sans-serif; "> <div>Michael,</div> <div><br> </div> <div>I do not view it this way.  If someone develops a requirements do= cument based on the framework, it would still need to be approved by a dire= ctorate (only used as an example, may not really apply) or something simila= r.  The mailing list could also be kept open for these.  There are existing examples of processes for this. &= nbsp;</div> <div><br> </div> <div>With regards to the considerations, the document would provide details= of variables to include in a considerations section.  Again, the cons= iderations section, part of an Internet Draft, would still need to be revie= wed and processed by the working group, AD's, IESG, etc.</div> <div><br> </div> <div>--Daryl</div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span style=3D"font-weight:bold">From: </span>Michael Hammer <<a href=3D= "mailto:mphmmr@gmail.com">mphmmr@gmail.com</a>><br> <span style=3D"font-weight:bold">Date: </span>Thu, 29 Mar 2012 08:43:11 -06= 00<br> <span style=3D"font-weight:bold">To: </span>Daryl Malas <<a href=3D"mail= to:d.malas@cablelabs.com">d.malas@cablelabs.com</a>><br> <span style=3D"font-weight:bold">Cc: </span>Christer Holmberg <<a href= =3D"mailto:christer.holmberg@ericsson.com">christer.holmberg@ericsson.com</= a>>, Hadriel Kaplan <<a href=3D"mailto:HKaplan@acmepacket.com">HKapla= n@acmepacket.com</a>>, "<a href=3D"mailto:dispatch@ietf.org">dispat= ch@ietf.org</a> list" <<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a>&= gt;<br> <span style=3D"font-weight:bold">Subject: </span>Re: [dispatch] Updated STR= AW Charter v2<br> </div> <div><br> </div> Daryl, <div><br> </div> <div>That sounds like signing a blank check.  </div> <div>Will certain implementations be declared non-compliant to the RFC for = some unknown future feature?</div> <div><br> </div> <div>Would this also require future SIP features to add a section, say just= prior to the Security section,</div> <div>that would need to declare handling by B2BUAs?</div> <div><br> </div> <div>Mike</div> <div><br> <br> <div class=3D"gmail_quote">On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <sp= an dir=3D"ltr"> <<a href=3D"mailto:D.Malas@cablelabs.com">D.Malas@cablelabs.com</a>><= /span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex" type=3D"cite"> Christer,<br> <br> Deliverable "2" will be used to create documents defining the req= uirements<br> for B2BUAs to support future/undefined "specific features." It al= lows the<br> working group to not persist indefinitely.<br> <br> I am assuming the deliverables are not listed as a prioritized list.  = I<br> would expect the framework to be completed towards the end, based on<br> previous experience.<br> <br> Framework Examples:<br> <br> <a href=3D"http://tools.ietf.org/html/rfc6117" target=3D"_blank">http://too= ls.ietf.org/html/rfc6117</a><br> <br> <a href=3D"http://tools.ietf.org/html/rfc6390" target=3D"_blank">http://too= ls.ietf.org/html/rfc6390</a><br> <br> --Daryl<br> <br> On 3/29/12 1:20 PM, "Christer Holmberg" <<a href=3D"mailto:chr= ister.holmberg@ericsson.com">christer.holmberg@ericsson.com</a>><br> wrote:<br> <div class=3D"HOEnZb"> <div class=3D"h5"><br> ><br> >Hi,<br> ><br> >I support this work, and after a quick look the proposed charter looks<= br> >good, but I have a question for clarification regarding the suggested<b= r> >deliverable 2).<br> ><br> >A question for clarification (my appologies if it has already been<br> >clarified).<br> ><br> >"2) A framework document for defining requirements and considerati= ons for<br> >traversing B2BUAs."<br> ><br> >Deliverables 3) - 7) talk about requirements in order for specific<br> >features to "survive" a B2BUA, but I am not sure what require= ments 2) is<br> >talking about?<br> ><br> >Regards,<br> ><br> >Christer<br> ><br> ><br> ><br> ><br> >-----Original Message-----<br> >From: <a href=3D"mailto:dispatch-bounces@ietf.org">dispatch-bounces@iet= f.org</a> [mailto:<a href=3D"mailto:dispatch-bounces@ietf.org">dispatch-bou= nces@ietf.org</a>] On<br> >Behalf Of Hadriel Kaplan<br> >Sent: 29. maaliskuuta 2012 10:33<br> >To: <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a> list<br> >Subject: [dispatch] Updated STRAW Charter v2<br> ><br> >Howdy,<br> >Updated charter below...<br> ><br> ><br> >Description of STRAW Working Group<br> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> >Name: Sip Traversal Required for Applications to Work (STRAW)<br> ><br> >Problem Statement:<br> >Within the context of the SIP protocol and architecture, a Back-to-Back= <br> >User Agent (B2BUA) is any SIP device in the logical path between two Us= er<br> >Agents performing a role beyond that of a Proxy as defined in RFC 3261.= <br> >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA= <br> >in order to terminate dead sessions by generating BYEs; or it may be a<= br> >3PCC-style agent only modifying SDP; or it may be a Session Border<br> >Controller performing such functions as in RFC 5853; or it may be an<br= > >Enterprise PBX terminating REFERs and such; or it may be a complete UAS= <br> >and UAC implementation with a PRI loopback in-between.<br> ><br> >In its most extreme form, the scope of the SIP protocol ends at the UAS= <br> >of the B2BUA, and a new SIP protocol scope begins on its UAC side. &nbs= p;In<br> >practice, however, users expect some SIP protocol aspects to go beyond<= br> >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, = as<br> >if the B2BUA was not an end unto itself; this is similar to the<br> >expectation that emails work when they cross from POP and IMAP to/from<= br> >SMTP.<br> ><br> >It is impossible to normatively define all the behaviors of B2BUAs in<b= r> >general, or even subsets of them such as SBCs or PBXs. Unlike consumer<= br> >NATs, B2BUAs perform widely varying functions for purposes which may be= <br> >unique to their environment, unique to their architecture, or unique to= <br> >the wishes of their administrator.  Instead of defining all things= a<br> >given type of B2BUA must do, a more practical objective would be to<br> >define what very few things any B2BUA must do to make a specific SIP<br= > >mechanism work, and let the market decide whether to do those things.<b= r> ><br> >The name of this working group reflects that practical objective: if<br= > >there were a thin straw between the SIP UAS and UAC of a B2BUA, what mu= st<br> >be passed through that straw and used on each side.  Or viewed ano= ther<br> >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopbac= k<br> >circuit, and if we could extend ISDN, what information would we carry i= n<br> >ISDN across the PRI for a specific SIP mechanism to work end-to-end.<br= > ><br> >For example, the WG could produce a document which specifies that the<b= r> >Max-Forwards header field value should be copied and decremented across= <br> >the B2BUA, if the B2BUA wishes to prevent infinite loops.  Adminis= trators<br> >could then tell their B2BUA vendors to comply with the document, if the= <br> >administrator so wishes.<br> ><br> ><br> >Objectives:<br> >The objectives of the STRAW Working Group are to publish normative<br> >documents which define which SIP header fields, parameters, MIME bodies= ,<br> >body content fields/information, or media-plane characteristics are<br> >required to traverse between the User Agent "sides" of a B2BU= A for<br> >specific functions to work.<br> ><br> >The specific functions covered are expected to relate to<br> >already-published RFCs or existing RAI area work, as opposed to all<br> >future IETF work.  In other words, the Working Group is not meant = to be a<br> >never-ending source for B2BUA requirements in the RAI area.<br> ><br> >Deliverables would indicate which types of B2BUAs would apply or not.<b= r> >For example, a document defining the requirements for end-to-end<br> >DTLS-SRTP would not apply to B2BUAs which terminate media, such as<br> >transcoders or recorders.<br> ><br> ><br> >Initial Deliverables:<br> >1) A taxonomy document defining role-types of B2BUAs, as a reference fo= r<br> >other deliverables.<br> >2) A framework document for defining requirements and considerations fo= r<br> >traversing B2BUAs.<br> >3) A document defining the requirements for B2BUAs with respect to loop= <br> >detection/prevention.<br> >4) A document defining the requirements for B2BUAs to support end-to-en= d<br> >and hop-by-hop media-loopback test calls.<br> >5) A document defining the requirements for B2BUAs to support DTLS-SRTP= <br> >(RFC 5764) end-to-end.<br> >6) A document defining the requirements for B2BUAs to support STUN<br> >message transactions end-to-end.<br> >7) A document defining the requirements for B2BUAs to support RTCP<br> >end-to-end.<br> ><br> ><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br> <br> _______________________________________________<br> dispatch mailing list<br> <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/dispatch</a><br> </div> </div> </blockquote> </div> <br> </div> </span></div> </blockquote> </div> <br> </body> </html> --_000_40B778D0845144FAA822D816F0CAB750acmepacketcom_-- From D.Malas@cablelabs.com Fri Mar 30 10:00:26 2012 Return-Path: <D.Malas@cablelabs.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF6221F869F for <dispatch@ietfa.amsl.com>; Fri, 30 Mar 2012 10:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.389 X-Spam-Level: X-Spam-Status: No, score=-100.389 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1+IdzpoZfmv for <dispatch@ietfa.amsl.com>; Fri, 30 Mar 2012 10:00:24 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 90F2521F869C for <dispatch@ietf.org>; Fri, 30 Mar 2012 10:00:24 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2UH0H11000417; Fri, 30 Mar 2012 11:00:17 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 30 Mar 2012 11:00:17 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 30 Mar 2012 11:00:17 -0600 From: Daryl Malas <D.Malas@cablelabs.com> To: Hadriel Kaplan <HKaplan@acmepacket.com> Date: Fri, 30 Mar 2012 11:00:16 -0600 Thread-Topic: [dispatch] Updated STRAW Charter v2 Thread-Index: Ac0OlpSAZHdVGNx9RueUVcWN6x6ISw== Message-ID: <CB9BB1BD.DF92%d.malas@cablelabs.com> In-Reply-To: <40B778D0-8451-44FA-A822-D816F0CAB750@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB9BB1BDDF92dmalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] Updated STRAW Charter v2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 30 Mar 2012 17:00:26 -0000 --_000_CB9BB1BDDF92dmalascablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hadriel, I guess in the end it doesn't matter; however, I would argue that working g= roup deliverable intentions does not mean the work is not scrapped at a lat= er point either. In fact, working group drafts and working groups have bee= n scrapped due to a number of different reasons=85some you have described b= elow. The reason I am a proponent of keeping it in the list, is that it pr= ovides a reminder to attempt putting this together towards the end. I admi= t that I'm not 100% sure it is a feasible deliverable, but I think it helps= avoid the potential situation of continuously dealing with "features" for = many years to come. All of this being said, if it is the only remaining co= ntroversial item, then I am not that bent on having it in there now. The o= verall work is more valuable that quibbling over this one deliverable. --Daryl From: Hadriel Kaplan <HKaplan@acmepacket.com<mailto:HKaplan@acmepacket.com>= > Date: Fri, 30 Mar 2012 10:29:12 -0600 To: Daryl Malas <d.malas@cablelabs.com<mailto:d.malas@cablelabs.com>> Cc: Michael Hammer <mphmmr@gmail.com<mailto:mphmmr@gmail.com>>, Christer Ho= lmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.co= m>>, "dispatch@ietf.org<mailto:dispatch@ietf.org> list" <dispatch@ietf.org<= mailto:dispatch@ietf.org>> Subject: Re: [dispatch] Updated STRAW Charter v2 Daryl, Do you mind if I remove that deliverable from the Charter? The STRAW Worki= ng Group can always add it back in, once the WG's established and there's a= candidate draft to look at and think about. I think I understand what you= 're looking for and I like the idea, but I too am not sure if we're all on = the same page, or if we can actually produce such a document. So I'd prefe= r to just delay that one until we have such a draft written up, and so we c= an get STRAW created sooner. As you said it would be timed toward the end = anyway, so there's no urgency. -hadriel On Mar 29, 2012, at 4:55 PM, Daryl Malas wrote: Michael, I do not view it this way. If someone develops a requirements document bas= ed on the framework, it would still need to be approved by a directorate (o= nly used as an example, may not really apply) or something similar. The ma= iling list could also be kept open for these. There are existing examples = of processes for this. With regards to the considerations, the document would provide details of v= ariables to include in a considerations section. Again, the considerations= section, part of an Internet Draft, would still need to be reviewed and pr= ocessed by the working group, AD's, IESG, etc. --Daryl From: Michael Hammer <mphmmr@gmail.com<mailto:mphmmr@gmail.com>> Date: Thu, 29 Mar 2012 08:43:11 -0600 To: Daryl Malas <d.malas@cablelabs.com<mailto:d.malas@cablelabs.com>> Cc: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmb= erg@ericsson.com>>, Hadriel Kaplan <HKaplan@acmepacket.com<mailto:HKaplan@a= cmepacket.com>>, "dispatch@ietf.org<mailto:dispatch@ietf.org> list" <dispat= ch@ietf.org<mailto:dispatch@ietf.org>> Subject: Re: [dispatch] Updated STRAW Charter v2 Daryl, That sounds like signing a blank check. Will certain implementations be declared non-compliant to the RFC for some = unknown future feature? Would this also require future SIP features to add a section, say just prio= r to the Security section, that would need to declare handling by B2BUAs? Mike On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <D.Malas@cablelabs.com<mailto:= D.Malas@cablelabs.com>> wrote: Christer, Deliverable "2" will be used to create documents defining the requirements for B2BUAs to support future/undefined "specific features." It allows the working group to not persist indefinitely. I am assuming the deliverables are not listed as a prioritized list. I would expect the framework to be completed towards the end, based on previous experience. Framework Examples: http://tools.ietf.org/html/rfc6117 http://tools.ietf.org/html/rfc6390 --Daryl On 3/29/12 1:20 PM, "Christer Holmberg" <christer.holmberg@ericsson.com<mai= lto:christer.holmberg@ericsson.com>> wrote: > >Hi, > >I support this work, and after a quick look the proposed charter looks >good, but I have a question for clarification regarding the suggested >deliverable 2). > >A question for clarification (my appologies if it has already been >clarified). > >"2) A framework document for defining requirements and considerations for >traversing B2BUAs." > >Deliverables 3) - 7) talk about requirements in order for specific >features to "survive" a B2BUA, but I am not sure what requirements 2) is >talking about? > >Regards, > >Christer > > > > >-----Original Message----- >From: dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org> [mailto:= dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org>] On >Behalf Of Hadriel Kaplan >Sent: 29. maaliskuuta 2012 10:33 >To: dispatch@ietf.org<mailto:dispatch@ietf.org> list >Subject: [dispatch] Updated STRAW Charter v2 > >Howdy, >Updated charter below... > > >Description of STRAW Working Group >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Name: Sip Traversal Required for Applications to Work (STRAW) > >Problem Statement: >Within the context of the SIP protocol and architecture, a Back-to-Back >User Agent (B2BUA) is any SIP device in the logical path between two User >Agents performing a role beyond that of a Proxy as defined in RFC 3261. >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA >in order to terminate dead sessions by generating BYEs; or it may be a >3PCC-style agent only modifying SDP; or it may be a Session Border >Controller performing such functions as in RFC 5853; or it may be an >Enterprise PBX terminating REFERs and such; or it may be a complete UAS >and UAC implementation with a PRI loopback in-between. > >In its most extreme form, the scope of the SIP protocol ends at the UAS >of the B2BUA, and a new SIP protocol scope begins on its UAC side. In >practice, however, users expect some SIP protocol aspects to go beyond >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as >if the B2BUA was not an end unto itself; this is similar to the >expectation that emails work when they cross from POP and IMAP to/from >SMTP. > >It is impossible to normatively define all the behaviors of B2BUAs in >general, or even subsets of them such as SBCs or PBXs. Unlike consumer >NATs, B2BUAs perform widely varying functions for purposes which may be >unique to their environment, unique to their architecture, or unique to >the wishes of their administrator. Instead of defining all things a >given type of B2BUA must do, a more practical objective would be to >define what very few things any B2BUA must do to make a specific SIP >mechanism work, and let the market decide whether to do those things. > >The name of this working group reflects that practical objective: if >there were a thin straw between the SIP UAS and UAC of a B2BUA, what must >be passed through that straw and used on each side. Or viewed another >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback >circuit, and if we could extend ISDN, what information would we carry in >ISDN across the PRI for a specific SIP mechanism to work end-to-end. > >For example, the WG could produce a document which specifies that the >Max-Forwards header field value should be copied and decremented across >the B2BUA, if the B2BUA wishes to prevent infinite loops. Administrators >could then tell their B2BUA vendors to comply with the document, if the >administrator so wishes. > > >Objectives: >The objectives of the STRAW Working Group are to publish normative >documents which define which SIP header fields, parameters, MIME bodies, >body content fields/information, or media-plane characteristics are >required to traverse between the User Agent "sides" of a B2BUA for >specific functions to work. > >The specific functions covered are expected to relate to >already-published RFCs or existing RAI area work, as opposed to all >future IETF work. In other words, the Working Group is not meant to be a >never-ending source for B2BUA requirements in the RAI area. > >Deliverables would indicate which types of B2BUAs would apply or not. >For example, a document defining the requirements for end-to-end >DTLS-SRTP would not apply to B2BUAs which terminate media, such as >transcoders or recorders. > > >Initial Deliverables: >1) A taxonomy document defining role-types of B2BUAs, as a reference for >other deliverables. >2) A framework document for defining requirements and considerations for >traversing B2BUAs. >3) A document defining the requirements for B2BUAs with respect to loop >detection/prevention. >4) A document defining the requirements for B2BUAs to support end-to-end >and hop-by-hop media-loopback test calls. >5) A document defining the requirements for B2BUAs to support DTLS-SRTP >(RFC 5764) end-to-end. >6) A document defining the requirements for B2BUAs to support STUN >message transactions end-to-end. >7) A document defining the requirements for B2BUAs to support RTCP >end-to-end. > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org<mailto:dispatch@ietf.org> >https://www.ietf.org/mailman/listinfo/dispatch >_______________________________________________ >dispatch mailing list >dispatch@ietf.org<mailto:dispatch@ietf.org> >https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch --_000_CB9BB1BDDF92dmalascablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html><head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space;= -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14p= x; font-family: Calibri, sans-serif; "><div>Hadriel,</div><div><br></div><d= iv>I guess in the end it doesn't matter; however, I would argue that workin= g group deliverable intentions does not mean the work is not scrapped at a = later point either.  In fact, working group drafts and working groups = have been scrapped due to a number of different reasons=85some you have des= cribed below.  The reason I am a proponent of keeping it in the list, = is that it provides a reminder to attempt putting this together towards the= end.  I admit that I'm not 100% sure it is a feasible deliverable, bu= t I think it helps avoid the potential situation of continuously dealing wi= th "features" for many years to come.  All of this being sai= d, if it is the only remaining controversial item, then I am not that bent = on having it in there now.  The overall work is more valuable that qui= bbling over this one deliverable.</div><div><br></div><div>--Daryl</div><di= v><br></div><span id=3D"OLK_SRC_BODY_SECTION"><div style=3D"font-family:Cal= ibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium n= one; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADD= ING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; P= ADDING-TOP: 3pt"><span style=3D"font-weight:bold">From: </span> Hadriel Kap= lan <<a href=3D"mailto:HKaplan@acmepacket.com">HKaplan@acmepacket.com</a= >><br><span style=3D"font-weight:bold">Date: </span> Fri, 30 Mar 2012 10= :29:12 -0600<br><span style=3D"font-weight:bold">To: </span> Daryl Malas &l= t;<a href=3D"mailto:d.malas@cablelabs.com">d.malas@cablelabs.com</a>><br= ><span style=3D"font-weight:bold">Cc: </span> Michael Hammer <<a href=3D= "mailto:mphmmr@gmail.com">mphmmr@gmail.com</a>>, Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com">christer.holmberg@ericsson= .com</a>>, "<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org<= /a> list" <<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</= a>><br><span style=3D"font-weight:bold">Subject: </span> Re: [dispatch] = Updated STRAW Charter v2<br></div><div><br></div><div><div style=3D"word-wr= ap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-s= pace; "><div><br></div><div>Daryl,</div><div>Do you mind if I remove that d= eliverable from the Charter?  The STRAW Working Group can always add i= t back in, once the WG's established and there's a candidate draft to look = at and think about.  I think I understand what you're looking for and = I like the idea, but I too am not sure if we're all on the same page, or if we ca= n actually produce such a document.  So I'd prefer to just delay that = one until we have such a draft written up, and so we can get STRAW created = sooner.  As you said it would be timed toward the end anyway, so there's no urgency.</div><div><br></div><div>-ha= driel</div><div><br></div><br><div><div>On Mar 29, 2012, at 4:55 PM, Daryl = Malas wrote:</div><br class=3D"Apple-interchange-newline"><blockquote type= =3D"cite"><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -w= ebkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; = font-family: Calibri, sans-serif; "><div>Michael,</div><div><br></div><div>= I do not view it this way.  If someone develops a requirements documen= t based on the framework, it would still need to be approved by a directora= te (only used as an example, may not really apply) or something similar. &n= bsp;The mailing list could also be kept open for these.  There are existing examples of processes for this. &= nbsp;</div><div><br></div><div>With regards to the considerations, the docu= ment would provide details of variables to include in a considerations sect= ion.  Again, the considerations section, part of an Internet Draft, wo= uld still need to be reviewed and processed by the working group, AD's, IESG, etc.</div><div><br></div><div>--Daryl</div><div><br></div><spa= n id=3D"OLK_SRC_BODY_SECTION"><div style=3D"font-family:Calibri; font-size:= 11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT= : medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; = BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"= ><span style=3D"font-weight:bold">From: </span>Michael Hammer <<a href= =3D"mailto:mphmmr@gmail.com">mphmmr@gmail.com</a>><br><span style=3D"fon= t-weight:bold">Date: </span>Thu, 29 Mar 2012 08:43:11 -0600<br><span style= =3D"font-weight:bold">To: </span>Daryl Malas <<a href=3D"mailto:d.malas@= cablelabs.com">d.malas@cablelabs.com</a>><br><span style=3D"font-weight:= bold">Cc: </span>Christer Holmberg <<a href=3D"mailto:christer.holmberg@= ericsson.com">christer.holmberg@ericsson.com</a>>, Hadriel Kaplan <<a= href=3D"mailto:HKaplan@acmepacket.com">HKaplan@acmepacket.com</a>>, &qu= ot;<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a> list" <<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a>&= gt;<br><span style=3D"font-weight:bold">Subject: </span>Re: [dispatch] Upda= ted STRAW Charter v2<br></div><div><br></div> Daryl, <div><br></div><div>That sounds like signing a blank check.  </div><di= v>Will certain implementations be declared non-compliant to the RFC for som= e unknown future feature?</div><div><br></div><div>Would this also require = future SIP features to add a section, say just prior to the Security sectio= n,</div><div>that would need to declare handling by B2BUAs?</div><div><br><= /div><div>Mike</div><div><br><br><div class=3D"gmail_quote">On Thu, Mar 29,= 2012 at 9:43 AM, Daryl Malas <span dir=3D"ltr"> <<a href=3D"mailto:D.Malas@cablelabs.com">D.Malas@cablelabs.com</a>><= /span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex" type=3D"cite"> Christer,<br><br> Deliverable "2" will be used to create documents defining the req= uirements<br> for B2BUAs to support future/undefined "specific features." It al= lows the<br> working group to not persist indefinitely.<br><br> I am assuming the deliverables are not listed as a prioritized list.  = I<br> would expect the framework to be completed towards the end, based on<br> previous experience.<br><br> Framework Examples:<br><br><a href=3D"http://tools.ietf.org/html/rfc6117" t= arget=3D"_blank">http://tools.ietf.org/html/rfc6117</a><br><br><a href=3D"h= ttp://tools.ietf.org/html/rfc6390" target=3D"_blank">http://tools.ietf.org/= html/rfc6390</a><br><br> --Daryl<br><br> On 3/29/12 1:20 PM, "Christer Holmberg" <<a href=3D"mailto:chr= ister.holmberg@ericsson.com">christer.holmberg@ericsson.com</a>><br> wrote:<br><div class=3D"HOEnZb"><div class=3D"h5"><br> ><br> >Hi,<br> ><br> >I support this work, and after a quick look the proposed charter looks<= br> >good, but I have a question for clarification regarding the suggested<b= r> >deliverable 2).<br> ><br> >A question for clarification (my appologies if it has already been<br> >clarified).<br> ><br> >"2) A framework document for defining requirements and considerati= ons for<br> >traversing B2BUAs."<br> ><br> >Deliverables 3) - 7) talk about requirements in order for specific<br> >features to "survive" a B2BUA, but I am not sure what require= ments 2) is<br> >talking about?<br> ><br> >Regards,<br> ><br> >Christer<br> ><br> ><br> ><br> ><br> >-----Original Message-----<br> >From: <a href=3D"mailto:dispatch-bounces@ietf.org">dispatch-bounces@iet= f.org</a> [mailto:<a href=3D"mailto:dispatch-bounces@ietf.org">dispatch-bou= nces@ietf.org</a>] On<br> >Behalf Of Hadriel Kaplan<br> >Sent: 29. maaliskuuta 2012 10:33<br> >To: <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a> list<br> >Subject: [dispatch] Updated STRAW Charter v2<br> ><br> >Howdy,<br> >Updated charter below...<br> ><br> ><br> >Description of STRAW Working Group<br> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> >Name: Sip Traversal Required for Applications to Work (STRAW)<br> ><br> >Problem Statement:<br> >Within the context of the SIP protocol and architecture, a Back-to-Back= <br> >User Agent (B2BUA) is any SIP device in the logical path between two Us= er<br> >Agents performing a role beyond that of a Proxy as defined in RFC 3261.= <br> >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA= <br> >in order to terminate dead sessions by generating BYEs; or it may be a<= br> >3PCC-style agent only modifying SDP; or it may be a Session Border<br> >Controller performing such functions as in RFC 5853; or it may be an<br= > >Enterprise PBX terminating REFERs and such; or it may be a complete UAS= <br> >and UAC implementation with a PRI loopback in-between.<br> ><br> >In its most extreme form, the scope of the SIP protocol ends at the UAS= <br> >of the B2BUA, and a new SIP protocol scope begins on its UAC side. &nbs= p;In<br> >practice, however, users expect some SIP protocol aspects to go beyond<= br> >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, = as<br> >if the B2BUA was not an end unto itself; this is similar to the<br> >expectation that emails work when they cross from POP and IMAP to/from<= br> >SMTP.<br> ><br> >It is impossible to normatively define all the behaviors of B2BUAs in<b= r> >general, or even subsets of them such as SBCs or PBXs. Unlike consumer<= br> >NATs, B2BUAs perform widely varying functions for purposes which may be= <br> >unique to their environment, unique to their architecture, or unique to= <br> >the wishes of their administrator.  Instead of defining all things= a<br> >given type of B2BUA must do, a more practical objective would be to<br>= >define what very few things any B2BUA must do to make a specific SIP<br= > >mechanism work, and let the market decide whether to do those things.<b= r> ><br> >The name of this working group reflects that practical objective: if<br= > >there were a thin straw between the SIP UAS and UAC of a B2BUA, what mu= st<br> >be passed through that straw and used on each side.  Or viewed ano= ther<br> >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopbac= k<br> >circuit, and if we could extend ISDN, what information would we carry i= n<br> >ISDN across the PRI for a specific SIP mechanism to work end-to-end.<br= > ><br> >For example, the WG could produce a document which specifies that the<b= r> >Max-Forwards header field value should be copied and decremented across= <br> >the B2BUA, if the B2BUA wishes to prevent infinite loops.  Adminis= trators<br> >could then tell their B2BUA vendors to comply with the document, if the= <br> >administrator so wishes.<br> ><br> ><br> >Objectives:<br> >The objectives of the STRAW Working Group are to publish normative<br> >documents which define which SIP header fields, parameters, MIME bodies= ,<br> >body content fields/information, or media-plane characteristics are<br>= >required to traverse between the User Agent "sides" of a B2BU= A for<br> >specific functions to work.<br> ><br> >The specific functions covered are expected to relate to<br> >already-published RFCs or existing RAI area work, as opposed to all<br>= >future IETF work.  In other words, the Working Group is not meant = to be a<br> >never-ending source for B2BUA requirements in the RAI area.<br> ><br> >Deliverables would indicate which types of B2BUAs would apply or not.<b= r> >For example, a document defining the requirements for end-to-end<br> >DTLS-SRTP would not apply to B2BUAs which terminate media, such as<br> >transcoders or recorders.<br> ><br> ><br> >Initial Deliverables:<br> >1) A taxonomy document defining role-types of B2BUAs, as a reference fo= r<br> >other deliverables.<br> >2) A framework document for defining requirements and considerations fo= r<br> >traversing B2BUAs.<br> >3) A document defining the requirements for B2BUAs with respect to loop= <br> >detection/prevention.<br> >4) A document defining the requirements for B2BUAs to support end-to-en= d<br> >and hop-by-hop media-loopback test calls.<br> >5) A document defining the requirements for B2BUAs to support DTLS-SRTP= <br> >(RFC 5764) end-to-end.<br> >6) A document defining the requirements for B2BUAs to support STUN<br> >message transactions end-to-end.<br> >7) A document defining the requirements for B2BUAs to support RTCP<br> >end-to-end.<br> ><br> ><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br><br> _______________________________________________<br> dispatch mailing list<br><a href=3D"mailto:dispatch@ietf.org">dispatch@ietf= .org</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" targ= et=3D"_blank">https://www.ietf.org/mailman/listinfo/dispatch</a><br></div><= /div></blockquote></div><br></div></span></div></blockquote></div><br></div= ></div></span></body></html> --_000_CB9BB1BDDF92dmalascablelabscom_-- From HKaplan@acmepacket.com Fri Mar 30 10:25:37 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD34821F8673 for <dispatch@ietfa.amsl.com>; Fri, 30 Mar 2012 10:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGlDShUZGoia for <dispatch@ietfa.amsl.com>; Fri, 30 Mar 2012 10:25:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7555121F865D for <dispatch@ietf.org>; Fri, 30 Mar 2012 10:25:35 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 30 Mar 2012 13:25:28 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.64]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Fri, 30 Mar 2012 13:25:27 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: Daryl Malas <D.Malas@cablelabs.com> Thread-Topic: [dispatch] Updated STRAW Charter v2 Thread-Index: AQHNDpoZ8k7IxO2lTQK9hZw77JEqwg== Date: Fri, 30 Mar 2012 17:25:27 +0000 Message-ID: <3E5EA8D9-7147-4F6C-86DB-DCBBF36760F3@acmepacket.com> References: <CB9BB1BD.DF92%d.malas@cablelabs.com> In-Reply-To: <CB9BB1BD.DF92%d.malas@cablelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: multipart/alternative; boundary="_000_3E5EA8D971474F6C86DBDCBBF36760F3acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] Updated STRAW Charter v2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 30 Mar 2012 17:25:37 -0000 --_000_3E5EA8D971474F6C86DBDCBBF36760F3acmepacketcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Cool, thanks! I am sure you will be happy to remind us and the eventual chairs about it, = at every opportunity. :) I too want such a draft written, as I said during the DISPATCH presentation= that it's my personal belief we have to get future RFCs to do their own B2= BUA considerations/requirements, and having a document to point to would be= the only way to get that. -hadriel On Mar 30, 2012, at 7:00 PM, Daryl Malas wrote: Hadriel, I guess in the end it doesn't matter; however, I would argue that working g= roup deliverable intentions does not mean the work is not scrapped at a lat= er point either. In fact, working group drafts and working groups have bee= n scrapped due to a number of different reasons=85some you have described b= elow. The reason I am a proponent of keeping it in the list, is that it pr= ovides a reminder to attempt putting this together towards the end. I admi= t that I'm not 100% sure it is a feasible deliverable, but I think it helps= avoid the potential situation of continuously dealing with "features" for = many years to come. All of this being said, if it is the only remaining co= ntroversial item, then I am not that bent on having it in there now. The o= verall work is more valuable that quibbling over this one deliverable. --Daryl From: Hadriel Kaplan <HKaplan@acmepacket.com<mailto:HKaplan@acmepacket.com>= > Date: Fri, 30 Mar 2012 10:29:12 -0600 To: Daryl Malas <d.malas@cablelabs.com<mailto:d.malas@cablelabs.com>> Cc: Michael Hammer <mphmmr@gmail.com<mailto:mphmmr@gmail.com>>, Christer Ho= lmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.co= m>>, "dispatch@ietf.org<mailto:dispatch@ietf.org> list" <dispatch@ietf.org<= mailto:dispatch@ietf.org>> Subject: Re: [dispatch] Updated STRAW Charter v2 Daryl, Do you mind if I remove that deliverable from the Charter? The STRAW Worki= ng Group can always add it back in, once the WG's established and there's a= candidate draft to look at and think about. I think I understand what you= 're looking for and I like the idea, but I too am not sure if we're all on = the same page, or if we can actually produce such a document. So I'd prefe= r to just delay that one until we have such a draft written up, and so we c= an get STRAW created sooner. As you said it would be timed toward the end = anyway, so there's no urgency. -hadriel On Mar 29, 2012, at 4:55 PM, Daryl Malas wrote: Michael, I do not view it this way. If someone develops a requirements document bas= ed on the framework, it would still need to be approved by a directorate (o= nly used as an example, may not really apply) or something similar. The ma= iling list could also be kept open for these. There are existing examples = of processes for this. With regards to the considerations, the document would provide details of v= ariables to include in a considerations section. Again, the considerations= section, part of an Internet Draft, would still need to be reviewed and pr= ocessed by the working group, AD's, IESG, etc. --Daryl From: Michael Hammer <mphmmr@gmail.com<mailto:mphmmr@gmail.com>> Date: Thu, 29 Mar 2012 08:43:11 -0600 To: Daryl Malas <d.malas@cablelabs.com<mailto:d.malas@cablelabs.com>> Cc: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmb= erg@ericsson.com>>, Hadriel Kaplan <HKaplan@acmepacket.com<mailto:HKaplan@a= cmepacket.com>>, "dispatch@ietf.org<mailto:dispatch@ietf.org> list" <dispat= ch@ietf.org<mailto:dispatch@ietf.org>> Subject: Re: [dispatch] Updated STRAW Charter v2 Daryl, That sounds like signing a blank check. Will certain implementations be declared non-compliant to the RFC for some = unknown future feature? Would this also require future SIP features to add a section, say just prio= r to the Security section, that would need to declare handling by B2BUAs? Mike On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <D.Malas@cablelabs.com<mailto:= D.Malas@cablelabs.com>> wrote: Christer, Deliverable "2" will be used to create documents defining the requirements for B2BUAs to support future/undefined "specific features." It allows the working group to not persist indefinitely. I am assuming the deliverables are not listed as a prioritized list. I would expect the framework to be completed towards the end, based on previous experience. Framework Examples: http://tools.ietf.org/html/rfc6117 http://tools.ietf.org/html/rfc6390 --Daryl On 3/29/12 1:20 PM, "Christer Holmberg" <christer.holmberg@ericsson.com<mai= lto:christer.holmberg@ericsson.com>> wrote: > >Hi, > >I support this work, and after a quick look the proposed charter looks >good, but I have a question for clarification regarding the suggested >deliverable 2). > >A question for clarification (my appologies if it has already been >clarified). > >"2) A framework document for defining requirements and considerations for >traversing B2BUAs." > >Deliverables 3) - 7) talk about requirements in order for specific >features to "survive" a B2BUA, but I am not sure what requirements 2) is >talking about? > >Regards, > >Christer > > > > >-----Original Message----- >From: dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org> [mailto:= dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org>] On >Behalf Of Hadriel Kaplan >Sent: 29. maaliskuuta 2012 10:33 >To: dispatch@ietf.org<mailto:dispatch@ietf.org> list >Subject: [dispatch] Updated STRAW Charter v2 > >Howdy, >Updated charter below... > > >Description of STRAW Working Group >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Name: Sip Traversal Required for Applications to Work (STRAW) > >Problem Statement: >Within the context of the SIP protocol and architecture, a Back-to-Back >User Agent (B2BUA) is any SIP device in the logical path between two User >Agents performing a role beyond that of a Proxy as defined in RFC 3261. >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA >in order to terminate dead sessions by generating BYEs; or it may be a >3PCC-style agent only modifying SDP; or it may be a Session Border >Controller performing such functions as in RFC 5853; or it may be an >Enterprise PBX terminating REFERs and such; or it may be a complete UAS >and UAC implementation with a PRI loopback in-between. > >In its most extreme form, the scope of the SIP protocol ends at the UAS >of the B2BUA, and a new SIP protocol scope begins on its UAC side. In >practice, however, users expect some SIP protocol aspects to go beyond >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as >if the B2BUA was not an end unto itself; this is similar to the >expectation that emails work when they cross from POP and IMAP to/from >SMTP. > >It is impossible to normatively define all the behaviors of B2BUAs in >general, or even subsets of them such as SBCs or PBXs. Unlike consumer >NATs, B2BUAs perform widely varying functions for purposes which may be >unique to their environment, unique to their architecture, or unique to >the wishes of their administrator. Instead of defining all things a >given type of B2BUA must do, a more practical objective would be to >define what very few things any B2BUA must do to make a specific SIP >mechanism work, and let the market decide whether to do those things. > >The name of this working group reflects that practical objective: if >there were a thin straw between the SIP UAS and UAC of a B2BUA, what must >be passed through that straw and used on each side. Or viewed another >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback >circuit, and if we could extend ISDN, what information would we carry in >ISDN across the PRI for a specific SIP mechanism to work end-to-end. > >For example, the WG could produce a document which specifies that the >Max-Forwards header field value should be copied and decremented across >the B2BUA, if the B2BUA wishes to prevent infinite loops. Administrators >could then tell their B2BUA vendors to comply with the document, if the >administrator so wishes. > > >Objectives: >The objectives of the STRAW Working Group are to publish normative >documents which define which SIP header fields, parameters, MIME bodies, >body content fields/information, or media-plane characteristics are >required to traverse between the User Agent "sides" of a B2BUA for >specific functions to work. > >The specific functions covered are expected to relate to >already-published RFCs or existing RAI area work, as opposed to all >future IETF work. In other words, the Working Group is not meant to be a >never-ending source for B2BUA requirements in the RAI area. > >Deliverables would indicate which types of B2BUAs would apply or not. >For example, a document defining the requirements for end-to-end >DTLS-SRTP would not apply to B2BUAs which terminate media, such as >transcoders or recorders. > > >Initial Deliverables: >1) A taxonomy document defining role-types of B2BUAs, as a reference for >other deliverables. >2) A framework document for defining requirements and considerations for >traversing B2BUAs. >3) A document defining the requirements for B2BUAs with respect to loop >detection/prevention. >4) A document defining the requirements for B2BUAs to support end-to-end >and hop-by-hop media-loopback test calls. >5) A document defining the requirements for B2BUAs to support DTLS-SRTP >(RFC 5764) end-to-end. >6) A document defining the requirements for B2BUAs to support STUN >message transactions end-to-end. >7) A document defining the requirements for B2BUAs to support RTCP >end-to-end. > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org<mailto:dispatch@ietf.org> >https://www.ietf.org/mailman/listinfo/dispatch >_______________________________________________ >dispatch mailing list >dispatch@ietf.org<mailto:dispatch@ietf.org> >https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch --_000_3E5EA8D971474F6C86DBDCBBF36760F3acmepacketcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <F9B8E70C00BF254FA15D0BBFAF8D8535@acmepacket.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; "> <div><br> </div> <div>Cool, thanks!</div> <div>I am sure you will be happy to remind us and the eventual chairs about= it, at every opportunity. :)</div> <div>I too want such a draft written, as I said during the DISPATCH present= ation that it's my personal belief we have to get future RFCs to do their o= wn B2BUA considerations/requirements, and having a document to point to wou= ld be the only way to get that.</div> <div><br> </div> <div>-hadriel</div> <br> <div> <div>On Mar 30, 2012, at 7:00 PM, Daryl Malas wrote:</div> <br class=3D"Apple-interchange-newline"> <blockquote type=3D"cite"> <div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line= -break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-famil= y: Calibri, sans-serif; "> <div>Hadriel,</div> <div><br> </div> <div>I guess in the end it doesn't matter; however, I would argue that work= ing group deliverable intentions does not mean the work is not scrapped at = a later point either.  In fact, working group drafts and working group= s have been scrapped due to a number of different reasons=85some you have described below.  The reason I a= m a proponent of keeping it in the list, is that it provides a reminder to = attempt putting this together towards the end.  I admit that I'm not 1= 00% sure it is a feasible deliverable, but I think it helps avoid the potential situation of continuously dealing with = "features" for many years to come.  All of this being said, = if it is the only remaining controversial item, then I am not that bent on = having it in there now.  The overall work is more valuable that quibbling over this one deliverable.</div> <div><br> </div> <div>--Daryl</div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span style=3D"font-weight:bold">From: </span>Hadriel Kaplan <<a href=3D= "mailto:HKaplan@acmepacket.com">HKaplan@acmepacket.com</a>><br> <span style=3D"font-weight:bold">Date: </span>Fri, 30 Mar 2012 10:29:12 -06= 00<br> <span style=3D"font-weight:bold">To: </span>Daryl Malas <<a href=3D"mail= to:d.malas@cablelabs.com">d.malas@cablelabs.com</a>><br> <span style=3D"font-weight:bold">Cc: </span>Michael Hammer <<a href=3D"m= ailto:mphmmr@gmail.com">mphmmr@gmail.com</a>>, Christer Holmberg <<a = href=3D"mailto:christer.holmberg@ericsson.com">christer.holmberg@ericsson.c= om</a>>, "<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a= > list" <<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a>&= gt;<br> <span style=3D"font-weight:bold">Subject: </span>Re: [dispatch] Updated STR= AW Charter v2<br> </div> <div><br> </div> <div> <div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line= -break: after-white-space; "> <div><br> </div> <div>Daryl,</div> <div>Do you mind if I remove that deliverable from the Charter?  The S= TRAW Working Group can always add it back in, once the WG's established and= there's a candidate draft to look at and think about.  I think I unde= rstand what you're looking for and I like the idea, but I too am not sure if we're all on the same page, or if we ca= n actually produce such a document.  So I'd prefer to just delay that = one until we have such a draft written up, and so we can get STRAW created = sooner.  As you said it would be timed toward the end anyway, so there's no urgency.</div> <div><br> </div> <div>-hadriel</div> <div><br> </div> <br> <div> <div>On Mar 29, 2012, at 4:55 PM, Daryl Malas wrote:</div> <br class=3D"Apple-interchange-newline"> <blockquote type=3D"cite"> <div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line= -break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-famil= y: Calibri, sans-serif; "> <div>Michael,</div> <div><br> </div> <div>I do not view it this way.  If someone develops a requirements do= cument based on the framework, it would still need to be approved by a dire= ctorate (only used as an example, may not really apply) or something simila= r.  The mailing list could also be kept open for these.  There are existing examples of processes for this. &= nbsp;</div> <div><br> </div> <div>With regards to the considerations, the document would provide details= of variables to include in a considerations section.  Again, the cons= iderations section, part of an Internet Draft, would still need to be revie= wed and processed by the working group, AD's, IESG, etc.</div> <div><br> </div> <div>--Daryl</div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span style=3D"font-weight:bold">From: </span>Michael Hammer <<a href=3D= "mailto:mphmmr@gmail.com">mphmmr@gmail.com</a>><br> <span style=3D"font-weight:bold">Date: </span>Thu, 29 Mar 2012 08:43:11 -06= 00<br> <span style=3D"font-weight:bold">To: </span>Daryl Malas <<a href=3D"mail= to:d.malas@cablelabs.com">d.malas@cablelabs.com</a>><br> <span style=3D"font-weight:bold">Cc: </span>Christer Holmberg <<a href= =3D"mailto:christer.holmberg@ericsson.com">christer.holmberg@ericsson.com</= a>>, Hadriel Kaplan <<a href=3D"mailto:HKaplan@acmepacket.com">HKapla= n@acmepacket.com</a>>, "<a href=3D"mailto:dispatch@ietf.org">dispat= ch@ietf.org</a> list" <<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a>&= gt;<br> <span style=3D"font-weight:bold">Subject: </span>Re: [dispatch] Updated STR= AW Charter v2<br> </div> <div><br> </div> Daryl, <div><br> </div> <div>That sounds like signing a blank check.  </div> <div>Will certain implementations be declared non-compliant to the RFC for = some unknown future feature?</div> <div><br> </div> <div>Would this also require future SIP features to add a section, say just= prior to the Security section,</div> <div>that would need to declare handling by B2BUAs?</div> <div><br> </div> <div>Mike</div> <div><br> <br> <div class=3D"gmail_quote">On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <sp= an dir=3D"ltr"> <<a href=3D"mailto:D.Malas@cablelabs.com">D.Malas@cablelabs.com</a>><= /span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex" type=3D"cite"> Christer,<br> <br> Deliverable "2" will be used to create documents defining the req= uirements<br> for B2BUAs to support future/undefined "specific features." It al= lows the<br> working group to not persist indefinitely.<br> <br> I am assuming the deliverables are not listed as a prioritized list.  = I<br> would expect the framework to be completed towards the end, based on<br> previous experience.<br> <br> Framework Examples:<br> <br> <a href=3D"http://tools.ietf.org/html/rfc6117" target=3D"_blank">http://too= ls.ietf.org/html/rfc6117</a><br> <br> <a href=3D"http://tools.ietf.org/html/rfc6390" target=3D"_blank">http://too= ls.ietf.org/html/rfc6390</a><br> <br> --Daryl<br> <br> On 3/29/12 1:20 PM, "Christer Holmberg" <<a href=3D"mailto:chr= ister.holmberg@ericsson.com">christer.holmberg@ericsson.com</a>><br> wrote:<br> <div class=3D"HOEnZb"> <div class=3D"h5"><br> ><br> >Hi,<br> ><br> >I support this work, and after a quick look the proposed charter looks<= br> >good, but I have a question for clarification regarding the suggested<b= r> >deliverable 2).<br> ><br> >A question for clarification (my appologies if it has already been<br> >clarified).<br> ><br> >"2) A framework document for defining requirements and considerati= ons for<br> >traversing B2BUAs."<br> ><br> >Deliverables 3) - 7) talk about requirements in order for specific<br> >features to "survive" a B2BUA, but I am not sure what require= ments 2) is<br> >talking about?<br> ><br> >Regards,<br> ><br> >Christer<br> ><br> ><br> ><br> ><br> >-----Original Message-----<br> >From: <a href=3D"mailto:dispatch-bounces@ietf.org">dispatch-bounces@iet= f.org</a> [mailto:<a href=3D"mailto:dispatch-bounces@ietf.org">dispatch-bou= nces@ietf.org</a>] On<br> >Behalf Of Hadriel Kaplan<br> >Sent: 29. maaliskuuta 2012 10:33<br> >To: <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a> list<br> >Subject: [dispatch] Updated STRAW Charter v2<br> ><br> >Howdy,<br> >Updated charter below...<br> ><br> ><br> >Description of STRAW Working Group<br> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> >Name: Sip Traversal Required for Applications to Work (STRAW)<br> ><br> >Problem Statement:<br> >Within the context of the SIP protocol and architecture, a Back-to-Back= <br> >User Agent (B2BUA) is any SIP device in the logical path between two Us= er<br> >Agents performing a role beyond that of a Proxy as defined in RFC 3261.= <br> >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA= <br> >in order to terminate dead sessions by generating BYEs; or it may be a<= br> >3PCC-style agent only modifying SDP; or it may be a Session Border<br> >Controller performing such functions as in RFC 5853; or it may be an<br= > >Enterprise PBX terminating REFERs and such; or it may be a complete UAS= <br> >and UAC implementation with a PRI loopback in-between.<br> ><br> >In its most extreme form, the scope of the SIP protocol ends at the UAS= <br> >of the B2BUA, and a new SIP protocol scope begins on its UAC side. &nbs= p;In<br> >practice, however, users expect some SIP protocol aspects to go beyond<= br> >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, = as<br> >if the B2BUA was not an end unto itself; this is similar to the<br> >expectation that emails work when they cross from POP and IMAP to/from<= br> >SMTP.<br> ><br> >It is impossible to normatively define all the behaviors of B2BUAs in<b= r> >general, or even subsets of them such as SBCs or PBXs. Unlike consumer<= br> >NATs, B2BUAs perform widely varying functions for purposes which may be= <br> >unique to their environment, unique to their architecture, or unique to= <br> >the wishes of their administrator.  Instead of defining all things= a<br> >given type of B2BUA must do, a more practical objective would be to<br> >define what very few things any B2BUA must do to make a specific SIP<br= > >mechanism work, and let the market decide whether to do those things.<b= r> ><br> >The name of this working group reflects that practical objective: if<br= > >there were a thin straw between the SIP UAS and UAC of a B2BUA, what mu= st<br> >be passed through that straw and used on each side.  Or viewed ano= ther<br> >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopbac= k<br> >circuit, and if we could extend ISDN, what information would we carry i= n<br> >ISDN across the PRI for a specific SIP mechanism to work end-to-end.<br= > ><br> >For example, the WG could produce a document which specifies that the<b= r> >Max-Forwards header field value should be copied and decremented across= <br> >the B2BUA, if the B2BUA wishes to prevent infinite loops.  Adminis= trators<br> >could then tell their B2BUA vendors to comply with the document, if the= <br> >administrator so wishes.<br> ><br> ><br> >Objectives:<br> >The objectives of the STRAW Working Group are to publish normative<br> >documents which define which SIP header fields, parameters, MIME bodies= ,<br> >body content fields/information, or media-plane characteristics are<br> >required to traverse between the User Agent "sides" of a B2BU= A for<br> >specific functions to work.<br> ><br> >The specific functions covered are expected to relate to<br> >already-published RFCs or existing RAI area work, as opposed to all<br> >future IETF work.  In other words, the Working Group is not meant = to be a<br> >never-ending source for B2BUA requirements in the RAI area.<br> ><br> >Deliverables would indicate which types of B2BUAs would apply or not.<b= r> >For example, a document defining the requirements for end-to-end<br> >DTLS-SRTP would not apply to B2BUAs which terminate media, such as<br> >transcoders or recorders.<br> ><br> ><br> >Initial Deliverables:<br> >1) A taxonomy document defining role-types of B2BUAs, as a reference fo= r<br> >other deliverables.<br> >2) A framework document for defining requirements and considerations fo= r<br> >traversing B2BUAs.<br> >3) A document defining the requirements for B2BUAs with respect to loop= <br> >detection/prevention.<br> >4) A document defining the requirements for B2BUAs to support end-to-en= d<br> >and hop-by-hop media-loopback test calls.<br> >5) A document defining the requirements for B2BUAs to support DTLS-SRTP= <br> >(RFC 5764) end-to-end.<br> >6) A document defining the requirements for B2BUAs to support STUN<br> >message transactions end-to-end.<br> >7) A document defining the requirements for B2BUAs to support RTCP<br> >end-to-end.<br> ><br> ><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br> <br> _______________________________________________<br> dispatch mailing list<br> <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/dispatch</a><br> </div> </div> </blockquote> </div> <br> </div> </span></div> </blockquote> </div> <br> </div> </div> </span></div> </blockquote> </div> <br> </body> </html> --_000_3E5EA8D971474F6C86DBDCBBF36760F3acmepacketcom_-- From HKaplan@acmepacket.com Fri Mar 30 10:27:43 2012 Return-Path: <HKaplan@acmepacket.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E462021F84DA for <dispatch@ietfa.amsl.com>; Fri, 30 Mar 2012 10:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PElBCeKsUtXP for <dispatch@ietfa.amsl.com>; Fri, 30 Mar 2012 10:27:43 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBA221F84D6 for <dispatch@ietf.org>; Fri, 30 Mar 2012 10:27:43 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 30 Mar 2012 13:27:41 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.64]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Fri, 30 Mar 2012 13:27:41 -0400 From: Hadriel Kaplan <HKaplan@acmepacket.com> To: "dispatch@ietf.org list" <dispatch@ietf.org> Thread-Topic: Updated STRAW Charter v3 Thread-Index: AQHNDppowHITO/msdUGIrQePJgpN3w== Date: Fri, 30 Mar 2012 17:27:40 +0000 Message-ID: <F8D7E876-1B35-4AF2-9F53-EBDF3D012ED3@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <BB5456C77429F44D8828E97E373B36C1@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [dispatch] Updated STRAW Charter v3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 30 Mar 2012 17:27:44 -0000 Updated charter v3 below... Description of STRAW Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Name: Sip Traversal Required for Applications to Work (STRAW) Problem Statement:=20 Within the context of the SIP protocol and architecture, a Back-to-Back Use= r Agent (B2BUA) is any SIP device in the logical path between two User Agen= ts performing a role beyond that of a Proxy as defined in RFC 3261. The B2= BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order = to terminate dead sessions by generating BYEs; or it may be a 3PCC-style ag= ent only modifying SDP; or it may be a Session Border Controller performing= such functions as in RFC 5853; or it may be an Enterprise PBX terminating = REFERs and such; or it may be a complete UAS and UAC implementation with a = PRI loopback in-between.=20 In its most extreme form, the scope of the SIP protocol ends at the UAS of = the B2BUA, and a new SIP protocol scope begins on its UAC side. In practic= e, however, users expect some SIP protocol aspects to go beyond the scope o= f the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA= was not an end unto itself; this is similar to the expectation that emails= work when they cross from POP and IMAP to/from SMTP. It is impossible to normatively define all the behaviors of B2BUAs in gener= al, or even subsets of them such as SBCs or PBXs. Unlike consumer NATs, B2B= UAs perform widely varying functions for purposes which may be unique to th= eir environment, unique to their architecture, or unique to the wishes of t= heir administrator. Instead of defining all things a given type of B2BUA m= ust do, a more practical objective would be to define what very few things = any B2BUA must do to make a specific SIP mechanism work, and let the market= decide whether to do those things. The name of this working group reflects that practical objective: if there = were a thin straw between the SIP UAS and UAC of a B2BUA, what must be pass= ed through that straw and used on each side. Or viewed another way, if a B= 2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and = if we could extend ISDN, what information would we carry in ISDN across the= PRI for a specific SIP mechanism to work end-to-end. For example, the WG could produce a document which specifies that the Max-F= orwards header field value should be copied and decremented across the B2BU= A, if the B2BUA wishes to prevent infinite loops. Administrators could then= tell their B2BUA vendors to comply with the document, if the administrator= so wishes. Objectives: The objectives of the STRAW Working Group are to publish normative document= s which define which SIP header fields, parameters, MIME bodies, body conte= nt fields/information, or media-plane characteristics are required to trave= rse between the User Agent "sides" of a B2BUA for specific functions to wor= k. =20 The specific functions covered are expected to relate to already-published = RFCs or existing RAI area work, as opposed to all future IETF work. In oth= er words, the Working Group is not meant to be a never-ending source for B2= BUA requirements in the RAI area. Deliverables would indicate which types of B2BUAs would apply or not. For = example, a document defining the requirements for end-to-end DTLS-SRTP woul= d not apply to B2BUAs which terminate media, such as transcoders or recorde= rs. Initial Deliverables: 1) A taxonomy document defining role-types of B2BUAs, as a reference for ot= her deliverables. 2) A document defining the requirements for B2BUAs with respect to loop det= ection/prevention. 3) A document defining the requirements for B2BUAs to support end-to-end an= d hop-by-hop media-loopback test calls. 4) A document defining the requirements for B2BUAs to support DTLS-SRTP (RF= C 5764) end-to-end. 5) A document defining the requirements for B2BUAs to support STUN message = transactions end-to-end. 6) A document defining the requirements for B2BUAs to support RTCP end-to-e= nd. From mphmmr@gmail.com Fri Mar 30 13:34:52 2012 Return-Path: <mphmmr@gmail.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774C721F86B3 for <dispatch@ietfa.amsl.com>; Fri, 30 Mar 2012 13:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0upBiec8BoD for <dispatch@ietfa.amsl.com>; Fri, 30 Mar 2012 13:34:50 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 262C121F86B5 for <dispatch@ietf.org>; Fri, 30 Mar 2012 13:34:49 -0700 (PDT) Received: by lagj5 with SMTP id j5so1393802lag.31 for <dispatch@ietf.org>; Fri, 30 Mar 2012 13:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QIfxqzm6mSvSD7YAdlvQI7W/wMYADmvab/1PJeF/TdI=; b=db8SW1HU441r1B4gVJhJA2DjySKPfhUHCAf1GkOz9Z47RgS/11XSIkc28E2kBd9Hns LjoBTfjZIR7KED6zUu4U+8BZwLnQb3+Ovnt4NZiamRPV+wQ3rftyG93lATF8nwpvyxbx LMLTeYoAJUNRTI2rTly+AjvBOtELzm8mjq4lpkjsQ0yBV9NO1Wpj476XBCbvjEmwDwT5 1SEHJ+Bu6uH6FT8KDgsJcnSHgf7OvvuEup2JhNdpj0V4MDTjqIXiFfUA+TIUFZt6ZkI9 NlV9b6CaiOSuJni7RIdf15gXGZsxqYLp+B4RYcp3+Gdl+f1SF0GZ38NxushZOhnlU6Xs PxMw== MIME-Version: 1.0 Received: by 10.152.108.171 with SMTP id hl11mr3884836lab.29.1333139689026; Fri, 30 Mar 2012 13:34:49 -0700 (PDT) Received: by 10.112.76.196 with HTTP; Fri, 30 Mar 2012 13:34:48 -0700 (PDT) In-Reply-To: <3E5EA8D9-7147-4F6C-86DB-DCBBF36760F3@acmepacket.com> References: <CB9BB1BD.DF92%d.malas@cablelabs.com> <3E5EA8D9-7147-4F6C-86DB-DCBBF36760F3@acmepacket.com> Date: Fri, 30 Mar 2012 16:34:48 -0400 Message-ID: <CAA3wLqXGN9=xfevu2=gfJqiT0x_fhaU+A5tQjJ69HW7X8+FSiA@mail.gmail.com> From: Michael Hammer <mphmmr@gmail.com> To: Hadriel Kaplan <HKaplan@acmepacket.com> Content-Type: multipart/alternative; boundary=bcaec54fbd3c99b69e04bc7bc5f4 Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] Updated STRAW Charter v2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 30 Mar 2012 20:34:52 -0000 --bcaec54fbd3c99b69e04bc7bc5f4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My concern was generally around the practicality of predicting future events, i.e. new SIP headers in new RFCs, and the tendency to include mandatory RFCs in RFPs. So, just trying to contemplate how future compatibility is handled. I am happy if this is more the nature of guidelines and suggested guidance on text addressing B2BUAs in future RFCs. Mike On Fri, Mar 30, 2012 at 1:25 PM, Hadriel Kaplan <HKaplan@acmepacket.com>wro= te: > > Cool, thanks! > I am sure you will be happy to remind us and the eventual chairs about it= , > at every opportunity. :) > I too want such a draft written, as I said during the DISPATCH > presentation that it's my personal belief we have to get future RFCs to d= o > their own B2BUA considerations/requirements, and having a document to poi= nt > to would be the only way to get that. > > -hadriel > > On Mar 30, 2012, at 7:00 PM, Daryl Malas wrote: > > Hadriel, > > I guess in the end it doesn't matter; however, I would argue that > working group deliverable intentions does not mean the work is not scrapp= ed > at a later point either. In fact, working group drafts and working group= s > have been scrapped due to a number of different reasons=85some you have > described below. The reason I am a proponent of keeping it in the list, = is > that it provides a reminder to attempt putting this together towards the > end. I admit that I'm not 100% sure it is a feasible deliverable, but I > think it helps avoid the potential situation of continuously dealing with > "features" for many years to come. All of this being said, if it is the > only remaining controversial item, then I am not that bent on having it i= n > there now. The overall work is more valuable that quibbling over this on= e > deliverable. > > --Daryl > > From: Hadriel Kaplan <HKaplan@acmepacket.com> > Date: Fri, 30 Mar 2012 10:29:12 -0600 > To: Daryl Malas <d.malas@cablelabs.com> > Cc: Michael Hammer <mphmmr@gmail.com>, Christer Holmberg < > christer.holmberg@ericsson.com>, "dispatch@ietf.org list" < > dispatch@ietf.org> > Subject: Re: [dispatch] Updated STRAW Charter v2 > > > Daryl, > Do you mind if I remove that deliverable from the Charter? The STRAW > Working Group can always add it back in, once the WG's established and > there's a candidate draft to look at and think about. I think I understa= nd > what you're looking for and I like the idea, but I too am not sure if we'= re > all on the same page, or if we can actually produce such a document. So > I'd prefer to just delay that one until we have such a draft written up, > and so we can get STRAW created sooner. As you said it would be timed > toward the end anyway, so there's no urgency. > > -hadriel > > > On Mar 29, 2012, at 4:55 PM, Daryl Malas wrote: > > Michael, > > I do not view it this way. If someone develops a requirements document > based on the framework, it would still need to be approved by a directora= te > (only used as an example, may not really apply) or something similar. Th= e > mailing list could also be kept open for these. There are existing > examples of processes for this. > > With regards to the considerations, the document would provide details > of variables to include in a considerations section. Again, the > considerations section, part of an Internet Draft, would still need to be > reviewed and processed by the working group, AD's, IESG, etc. > > --Daryl > > From: Michael Hammer <mphmmr@gmail.com> > Date: Thu, 29 Mar 2012 08:43:11 -0600 > To: Daryl Malas <d.malas@cablelabs.com> > Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Hadriel Kaplan < > HKaplan@acmepacket.com>, "dispatch@ietf.org list" <dispatch@ietf.org> > Subject: Re: [dispatch] Updated STRAW Charter v2 > > Daryl, > > That sounds like signing a blank check. > Will certain implementations be declared non-compliant to the RFC for som= e > unknown future feature? > > Would this also require future SIP features to add a section, say just > prior to the Security section, > that would need to declare handling by B2BUAs? > > Mike > > > On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <D.Malas@cablelabs.com>wrote= : > >> Christer, >> >> Deliverable "2" will be used to create documents defining the requiremen= ts >> for B2BUAs to support future/undefined "specific features." It allows th= e >> working group to not persist indefinitely. >> >> I am assuming the deliverables are not listed as a prioritized list. I >> would expect the framework to be completed towards the end, based on >> previous experience. >> >> Framework Examples: >> >> http://tools.ietf.org/html/rfc6117 >> >> http://tools.ietf.org/html/rfc6390 >> >> --Daryl >> >> On 3/29/12 1:20 PM, "Christer Holmberg" <christer.holmberg@ericsson.com> >> wrote: >> >> > >> >Hi, >> > >> >I support this work, and after a quick look the proposed charter looks >> >good, but I have a question for clarification regarding the suggested >> >deliverable 2). >> > >> >A question for clarification (my appologies if it has already been >> >clarified). >> > >> >"2) A framework document for defining requirements and considerations f= or >> >traversing B2BUAs." >> > >> >Deliverables 3) - 7) talk about requirements in order for specific >> >features to "survive" a B2BUA, but I am not sure what requirements 2) i= s >> >talking about? >> > >> >Regards, >> > >> >Christer >> > >> > >> > >> > >> >-----Original Message----- >> >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> >Behalf Of Hadriel Kaplan >> >Sent: 29. maaliskuuta 2012 10:33 >> >To: dispatch@ietf.org list >> >Subject: [dispatch] Updated STRAW Charter v2 >> > >> >Howdy, >> >Updated charter below... >> > >> > >> >Description of STRAW Working Group >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >Name: Sip Traversal Required for Applications to Work (STRAW) >> > >> >Problem Statement: >> >Within the context of the SIP protocol and architecture, a Back-to-Back >> >User Agent (B2BUA) is any SIP device in the logical path between two Us= er >> >Agents performing a role beyond that of a Proxy as defined in RFC 3261. >> >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA >> >in order to terminate dead sessions by generating BYEs; or it may be a >> >3PCC-style agent only modifying SDP; or it may be a Session Border >> >Controller performing such functions as in RFC 5853; or it may be an >> >Enterprise PBX terminating REFERs and such; or it may be a complete UAS >> >and UAC implementation with a PRI loopback in-between. >> > >> >In its most extreme form, the scope of the SIP protocol ends at the UAS >> >of the B2BUA, and a new SIP protocol scope begins on its UAC side. In >> >practice, however, users expect some SIP protocol aspects to go beyond >> >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, = as >> >if the B2BUA was not an end unto itself; this is similar to the >> >expectation that emails work when they cross from POP and IMAP to/from >> >SMTP. >> > >> >It is impossible to normatively define all the behaviors of B2BUAs in >> >general, or even subsets of them such as SBCs or PBXs. Unlike consumer >> >NATs, B2BUAs perform widely varying functions for purposes which may be >> >unique to their environment, unique to their architecture, or unique to >> >the wishes of their administrator. Instead of defining all things a >> >given type of B2BUA must do, a more practical objective would be to >> >define what very few things any B2BUA must do to make a specific SIP >> >mechanism work, and let the market decide whether to do those things. >> > >> >The name of this working group reflects that practical objective: if >> >there were a thin straw between the SIP UAS and UAC of a B2BUA, what mu= st >> >be passed through that straw and used on each side. Or viewed another >> >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopbac= k >> >circuit, and if we could extend ISDN, what information would we carry i= n >> >ISDN across the PRI for a specific SIP mechanism to work end-to-end. >> > >> >For example, the WG could produce a document which specifies that the >> >Max-Forwards header field value should be copied and decremented across >> >the B2BUA, if the B2BUA wishes to prevent infinite loops. Administrato= rs >> >could then tell their B2BUA vendors to comply with the document, if the >> >administrator so wishes. >> > >> > >> >Objectives: >> >The objectives of the STRAW Working Group are to publish normative >> >documents which define which SIP header fields, parameters, MIME bodies= , >> >body content fields/information, or media-plane characteristics are >> >required to traverse between the User Agent "sides" of a B2BUA for >> >specific functions to work. >> > >> >The specific functions covered are expected to relate to >> >already-published RFCs or existing RAI area work, as opposed to all >> >future IETF work. In other words, the Working Group is not meant to be= a >> >never-ending source for B2BUA requirements in the RAI area. >> > >> >Deliverables would indicate which types of B2BUAs would apply or not. >> >For example, a document defining the requirements for end-to-end >> >DTLS-SRTP would not apply to B2BUAs which terminate media, such as >> >transcoders or recorders. >> > >> > >> >Initial Deliverables: >> >1) A taxonomy document defining role-types of B2BUAs, as a reference fo= r >> >other deliverables. >> >2) A framework document for defining requirements and considerations fo= r >> >traversing B2BUAs. >> >3) A document defining the requirements for B2BUAs with respect to loop >> >detection/prevention. >> >4) A document defining the requirements for B2BUAs to support end-to-en= d >> >and hop-by-hop media-loopback test calls. >> >5) A document defining the requirements for B2BUAs to support DTLS-SRTP >> >(RFC 5764) end-to-end. >> >6) A document defining the requirements for B2BUAs to support STUN >> >message transactions end-to-end. >> >7) A document defining the requirements for B2BUAs to support RTCP >> >end-to-end. >> > >> > >> >_______________________________________________ >> >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 >> > > > > --bcaec54fbd3c99b69e04bc7bc5f4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My concern was generally around the practicality of predicting future event= s, i.e. new SIP headers in new RFCs,<div>and the tendency to include mandat= ory RFCs in RFPs. =A0So, just trying to contemplate how future compatibilit= y is handled.</div> <div><br></div><div>I am happy if this is more the nature of guidelines and= suggested guidance on text addressing B2BUAs in future RFCs.</div><div><br= ></div><div>Mike</div><div><br></div><div><br><div class=3D"gmail_quote"> On Fri, Mar 30, 2012 at 1:25 PM, Hadriel Kaplan <span dir=3D"ltr"><<a hr= ef=3D"mailto:HKaplan@acmepacket.com">HKaplan@acmepacket.com</a>></span> = wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"> <div style=3D"word-wrap:break-word"> <div><br> </div> <div>Cool, thanks!</div> <div>I am sure you will be happy to remind us and the eventual chairs about= it, at every opportunity. :)</div> <div>I too want such a draft written, as I said during the DISPATCH present= ation that it's my personal belief we have to get future RFCs to do the= ir own B2BUA considerations/requirements, and having a document to point to= would be the only way to get that.</div> <span class=3D"HOEnZb"><font color=3D"#888888"> <div><br> </div> <div>-hadriel</div></font></span><div><div class=3D"h5"> <br> <div> <div>On Mar 30, 2012, at 7:00 PM, Daryl Malas wrote:</div> <br> <blockquote type=3D"cite"> <div style=3D"font-size:14px;font-family:Calibri,sans-serif;word-wrap:break= -word"> <div>Hadriel,</div> <div><br> </div> <div>I guess in the end it doesn't matter; however, I would argue that = working group deliverable intentions does not mean the work is not scrapped= at a later point either. =A0In fact, working group drafts and working grou= ps have been scrapped due to a number of different reasons=85some you have described below. =A0The reason I am a= proponent of keeping it in the list, is that it provides a reminder to att= empt putting this together towards the end. =A0I admit that I'm not 100= % sure it is a feasible deliverable, but I think it helps avoid the potential situation of continuously dealing with = "features" for many years to come. =A0All of this being said, if = it is the only remaining controversial item, then I am not that bent on hav= ing it in there now. =A0The overall work is more valuable that quibbling over this one deliverable.</div> <div><br> </div> <div>--Daryl</div> <div><br> </div> <span> <div style=3D"border-right:medium none;padding-right:0in;padding-left:0in;p= adding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;fon= t-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-lef= t:medium none"> <span style=3D"font-weight:bold">From: </span>Hadriel Kaplan <<a href=3D= "mailto:HKaplan@acmepacket.com" target=3D"_blank">HKaplan@acmepacket.com</a= >><br> <span style=3D"font-weight:bold">Date: </span>Fri, 30 Mar 2012 10:29:12 -06= 00<br> <span style=3D"font-weight:bold">To: </span>Daryl Malas <<a href=3D"mail= to:d.malas@cablelabs.com" target=3D"_blank">d.malas@cablelabs.com</a>><b= r> <span style=3D"font-weight:bold">Cc: </span>Michael Hammer <<a href=3D"m= ailto:mphmmr@gmail.com" target=3D"_blank">mphmmr@gmail.com</a>>, Christe= r Holmberg <<a href=3D"mailto:christer.holmberg@ericsson.com" target=3D"= _blank">christer.holmberg@ericsson.com</a>>, "<a href=3D"mailto:dis= patch@ietf.org" target=3D"_blank">dispatch@ietf.org</a> list" <<a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">disp= atch@ietf.org</a>><br> <span style=3D"font-weight:bold">Subject: </span>Re: [dispatch] Updated STR= AW Charter v2<br> </div> <div><br> </div> <div> <div style=3D"word-wrap:break-word"> <div><br> </div> <div>Daryl,</div> <div>Do you mind if I remove that deliverable from the Charter? =A0The STRA= W Working Group can always add it back in, once the WG's established an= d there's a candidate draft to look at and think about. =A0I think I un= derstand what you're looking for and I like the idea, but I too am not sure if we're all on the same page, or if w= e can actually produce such a document. =A0So I'd prefer to just delay = that one until we have such a draft written up, and so we can get STRAW cre= ated sooner. =A0As you said it would be timed toward the end anyway, so there's no urgency.</div> <div><br> </div> <div>-hadriel</div> <div><br> </div> <br> <div> <div>On Mar 29, 2012, at 4:55 PM, Daryl Malas wrote:</div> <br> <blockquote type=3D"cite"> <div style=3D"font-size:14px;font-family:Calibri,sans-serif;word-wrap:break= -word"> <div>Michael,</div> <div><br> </div> <div>I do not view it this way. =A0If someone develops a requirements docum= ent based on the framework, it would still need to be approved by a directo= rate (only used as an example, may not really apply) or something similar. = =A0The mailing list could also be kept open for these. =A0There are existing examples of processes for this. =A0<= /div> <div><br> </div> <div>With regards to the considerations, the document would provide details= of variables to include in a considerations section. =A0Again, the conside= rations section, part of an Internet Draft, would still need to be reviewed= and processed by the working group, AD's, IESG, etc.</div> <div><br> </div> <div>--Daryl</div> <div><br> </div> <span> <div style=3D"border-right:medium none;padding-right:0in;padding-left:0in;p= adding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;fon= t-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-lef= t:medium none"> <span style=3D"font-weight:bold">From: </span>Michael Hammer <<a href=3D= "mailto:mphmmr@gmail.com" target=3D"_blank">mphmmr@gmail.com</a>><br> <span style=3D"font-weight:bold">Date: </span>Thu, 29 Mar 2012 08:43:11 -06= 00<br> <span style=3D"font-weight:bold">To: </span>Daryl Malas <<a href=3D"mail= to:d.malas@cablelabs.com" target=3D"_blank">d.malas@cablelabs.com</a>><b= r> <span style=3D"font-weight:bold">Cc: </span>Christer Holmberg <<a href= =3D"mailto:christer.holmberg@ericsson.com" target=3D"_blank">christer.holmb= erg@ericsson.com</a>>, Hadriel Kaplan <<a href=3D"mailto:HKaplan@acme= packet.com" target=3D"_blank">HKaplan@acmepacket.com</a>>, "<a href= =3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@ietf.org</a> list" <<a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">disp= atch@ietf.org</a>><br> <span style=3D"font-weight:bold">Subject: </span>Re: [dispatch] Updated STR= AW Charter v2<br> </div> <div><br> </div> Daryl, <div><br> </div> <div>That sounds like signing a blank check. =A0</div> <div>Will certain implementations be declared non-compliant to the RFC for = some unknown future feature?</div> <div><br> </div> <div>Would this also require future SIP features to add a section, say just= prior to the Security section,</div> <div>that would need to declare handling by B2BUAs?</div> <div><br> </div> <div>Mike</div> <div><br> <br> <div class=3D"gmail_quote">On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <sp= an dir=3D"ltr"> <<a href=3D"mailto:D.Malas@cablelabs.com" target=3D"_blank">D.Malas@cabl= elabs.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex" type=3D"cite"> Christer,<br> <br> Deliverable "2" will be used to create documents defining the req= uirements<br> for B2BUAs to support future/undefined "specific features." It al= lows the<br> working group to not persist indefinitely.<br> <br> I am assuming the deliverables are not listed as a prioritized list. =A0I<b= r> would expect the framework to be completed towards the end, based on<br> previous experience.<br> <br> Framework Examples:<br> <br> <a href=3D"http://tools.ietf.org/html/rfc6117" target=3D"_blank">http://too= ls.ietf.org/html/rfc6117</a><br> <br> <a href=3D"http://tools.ietf.org/html/rfc6390" target=3D"_blank">http://too= ls.ietf.org/html/rfc6390</a><br> <br> --Daryl<br> <br> On 3/29/12 1:20 PM, "Christer Holmberg" <<a href=3D"mailto:chr= ister.holmberg@ericsson.com" target=3D"_blank">christer.holmberg@ericsson.c= om</a>><br> wrote:<br> <div> <div><br> ><br> >Hi,<br> ><br> >I support this work, and after a quick look the proposed charter looks<= br> >good, but I have a question for clarification regarding the suggested<b= r> >deliverable 2).<br> ><br> >A question for clarification (my appologies if it has already been<br> >clarified).<br> ><br> >"2) A framework document for defining requirements and considerati= ons for<br> >traversing B2BUAs."<br> ><br> >Deliverables 3) - 7) talk about requirements in order for specific<br> >features to "survive" a B2BUA, but I am not sure what require= ments 2) is<br> >talking about?<br> ><br> >Regards,<br> ><br> >Christer<br> ><br> ><br> ><br> ><br> >-----Original Message-----<br> >From: <a href=3D"mailto:dispatch-bounces@ietf.org" target=3D"_blank">di= spatch-bounces@ietf.org</a> [mailto:<a href=3D"mailto:dispatch-bounces@ietf= .org" target=3D"_blank">dispatch-bounces@ietf.org</a>] On<br> >Behalf Of Hadriel Kaplan<br> >Sent: 29. maaliskuuta 2012 10:33<br> >To: <a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@iet= f.org</a> list<br> >Subject: [dispatch] Updated STRAW Charter v2<br> ><br> >Howdy,<br> >Updated charter below...<br> ><br> ><br> >Description of STRAW Working Group<br> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> >Name: Sip Traversal Required for Applications to Work (STRAW)<br> ><br> >Problem Statement:<br> >Within the context of the SIP protocol and architecture, a Back-to-Back= <br> >User Agent (B2BUA) is any SIP device in the logical path between two Us= er<br> >Agents performing a role beyond that of a Proxy as defined in RFC 3261.= <br> >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA= <br> >in order to terminate dead sessions by generating BYEs; or it may be a<= br> >3PCC-style agent only modifying SDP; or it may be a Session Border<br> >Controller performing such functions as in RFC 5853; or it may be an<br= > >Enterprise PBX terminating REFERs and such; or it may be a complete UAS= <br> >and UAC implementation with a PRI loopback in-between.<br> ><br> >In its most extreme form, the scope of the SIP protocol ends at the UAS= <br> >of the B2BUA, and a new SIP protocol scope begins on its UAC side. =A0I= n<br> >practice, however, users expect some SIP protocol aspects to go beyond<= br> >the scope of the B2BUA's UAS side, and be traversed onto its UAC si= de, as<br> >if the B2BUA was not an end unto itself; this is similar to the<br> >expectation that emails work when they cross from POP and IMAP to/from<= br> >SMTP.<br> ><br> >It is impossible to normatively define all the behaviors of B2BUAs in<b= r> >general, or even subsets of them such as SBCs or PBXs. Unlike consumer<= br> >NATs, B2BUAs perform widely varying functions for purposes which may be= <br> >unique to their environment, unique to their architecture, or unique to= <br> >the wishes of their administrator. =A0Instead of defining all things a<= br> >given type of B2BUA must do, a more practical objective would be to<br> >define what very few things any B2BUA must do to make a specific SIP<br= > >mechanism work, and let the market decide whether to do those things.<b= r> ><br> >The name of this working group reflects that practical objective: if<br= > >there were a thin straw between the SIP UAS and UAC of a B2BUA, what mu= st<br> >be passed through that straw and used on each side. =A0Or viewed anothe= r<br> >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopbac= k<br> >circuit, and if we could extend ISDN, what information would we carry i= n<br> >ISDN across the PRI for a specific SIP mechanism to work end-to-end.<br= > ><br> >For example, the WG could produce a document which specifies that the<b= r> >Max-Forwards header field value should be copied and decremented across= <br> >the B2BUA, if the B2BUA wishes to prevent infinite loops. =A0Administra= tors<br> >could then tell their B2BUA vendors to comply with the document, if the= <br> >administrator so wishes.<br> ><br> ><br> >Objectives:<br> >The objectives of the STRAW Working Group are to publish normative<br> >documents which define which SIP header fields, parameters, MIME bodies= ,<br> >body content fields/information, or media-plane characteristics are<br> >required to traverse between the User Agent "sides" of a B2BU= A for<br> >specific functions to work.<br> ><br> >The specific functions covered are expected to relate to<br> >already-published RFCs or existing RAI area work, as opposed to all<br> >future IETF work. =A0In other words, the Working Group is not meant to = be a<br> >never-ending source for B2BUA requirements in the RAI area.<br> ><br> >Deliverables would indicate which types of B2BUAs would apply or not.<b= r> >For example, a document defining the requirements for end-to-end<br> >DTLS-SRTP would not apply to B2BUAs which terminate media, such as<br> >transcoders or recorders.<br> ><br> ><br> >Initial Deliverables:<br> >1) A taxonomy document defining role-types of B2BUAs, as a reference fo= r<br> >other deliverables.<br> >2) A framework document for defining requirements and considerations fo= r<br> >traversing B2BUAs.<br> >3) A document defining the requirements for B2BUAs with respect to loop= <br> >detection/prevention.<br> >4) A document defining the requirements for B2BUAs to support end-to-en= d<br> >and hop-by-hop media-loopback test calls.<br> >5) A document defining the requirements for B2BUAs to support DTLS-SRTP= <br> >(RFC 5764) end-to-end.<br> >6) A document defining the requirements for B2BUAs to support STUN<br> >message transactions end-to-end.<br> >7) A document defining the requirements for B2BUAs to support RTCP<br> >end-to-end.<br> ><br> ><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@ietf.or= g</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@ietf.or= g</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br> <br> _______________________________________________<br> dispatch mailing list<br> <a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@ietf.org</a= ><br> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/dispatch</a><br> </div> </div> </blockquote> </div> <br> </div> </span></div> </blockquote> </div> <br> </div> </div> </span></div> </blockquote> </div> <br> </div></div></div> </blockquote></div><br></div> --bcaec54fbd3c99b69e04bc7bc5f4-- From pravindran@sonusnet.com Sat Mar 31 02:56:17 2012 Return-Path: <pravindran@sonusnet.com> X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1350A21F870F for <dispatch@ietfa.amsl.com>; Sat, 31 Mar 2012 02:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.241 X-Spam-Level: X-Spam-Status: No, score=-5.241 tagged_above=-999 required=5 tests=[AWL=1.357, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c-liOrVfREA for <dispatch@ietfa.amsl.com>; Sat, 31 Mar 2012 02:56:12 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0E021F8566 for <dispatch@ietf.org>; Sat, 31 Mar 2012 02:56:11 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKT3bUurXTnk9DflVxJjZM7AhJsgEqy2mR@postini.com; Sat, 31 Mar 2012 02:56:11 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 31 Mar 2012 05:56:31 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Sat, 31 Mar 2012 15:25:59 +0530 From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com> To: Michael Hammer <mphmmr@gmail.com>, Hadriel Kaplan <HKaplan@acmepacket.com> Thread-Topic: [dispatch] Updated STRAW Charter v2 Thread-Index: AQHNDZ4E5UOS+/abbECWQipL2YK6ppaA7EqAgAAQzYCAAAOMgIABrGgAgAAIrgCAAAcJgIAANOcAgAE4jsA= Date: Sat, 31 Mar 2012 09:56:20 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E222F1A@inba-mail01.sonusnet.com> References: <CB9BB1BD.DF92%d.malas@cablelabs.com> <3E5EA8D9-7147-4F6C-86DB-DCBBF36760F3@acmepacket.com> <CAA3wLqXGN9=xfevu2=gfJqiT0x_fhaU+A5tQjJ69HW7X8+FSiA@mail.gmail.com> In-Reply-To: <CAA3wLqXGN9=xfevu2=gfJqiT0x_fhaU+A5tQjJ69HW7X8+FSiA@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E222F1Ainbamail01sonus_" MIME-Version: 1.0 Cc: "dispatch@ietf.org list" <dispatch@ietf.org> Subject: Re: [dispatch] Updated STRAW Charter v2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 31 Mar 2012 09:56:17 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E222F1Ainbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As I mentioned in IETF-83 Dispatch meeting, the draft has to be written for= B2BUA considerations for new SIP/SDP headers. I understand Hadriel concer= n about the timeline for the closure of STRAW charter with existing undefin= ed RFC's and so, let the initial draft of B2BUA consideration be in Dispatc= h. I will volunteer to write the initial draft for B2BUA consideration. I noti= ced that lot of folks shows interest during STRAW charter discussion. So, I= 'm interested in hearing other folks opinion for this activity. Thanks Partha From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Michael Hammer Sent: Saturday, March 31, 2012 2:05 AM To: Hadriel Kaplan Cc: dispatch@ietf.org list Subject: Re: [dispatch] Updated STRAW Charter v2 My concern was generally around the practicality of predicting future event= s, i.e. new SIP headers in new RFCs, and the tendency to include mandatory RFCs in RFPs. So, just trying to con= template how future compatibility is handled. I am happy if this is more the nature of guidelines and suggested guidance = on text addressing B2BUAs in future RFCs. Mike On Fri, Mar 30, 2012 at 1:25 PM, Hadriel Kaplan <HKaplan@acmepacket.com<mai= lto:HKaplan@acmepacket.com>> wrote: Cool, thanks! I am sure you will be happy to remind us and the eventual chairs about it, = at every opportunity. :) I too want such a draft written, as I said during the DISPATCH presentation= that it's my personal belief we have to get future RFCs to do their own B2= BUA considerations/requirements, and having a document to point to would be= the only way to get that. -hadriel On Mar 30, 2012, at 7:00 PM, Daryl Malas wrote: Hadriel, I guess in the end it doesn't matter; however, I would argue that working g= roup deliverable intentions does not mean the work is not scrapped at a lat= er point either. In fact, working group drafts and working groups have bee= n scrapped due to a number of different reasons...some you have described b= elow. The reason I am a proponent of keeping it in the list, is that it pr= ovides a reminder to attempt putting this together towards the end. I admi= t that I'm not 100% sure it is a feasible deliverable, but I think it helps= avoid the potential situation of continuously dealing with "features" for = many years to come. All of this being said, if it is the only remaining co= ntroversial item, then I am not that bent on having it in there now. The o= verall work is more valuable that quibbling over this one deliverable. --Daryl From: Hadriel Kaplan <HKaplan@acmepacket.com<mailto:HKaplan@acmepacket.com>= > Date: Fri, 30 Mar 2012 10:29:12 -0600 To: Daryl Malas <d.malas@cablelabs.com<mailto:d.malas@cablelabs.com>> Cc: Michael Hammer <mphmmr@gmail.com<mailto:mphmmr@gmail.com>>, Christer Ho= lmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.co= m>>, "dispatch@ietf.org<mailto:dispatch@ietf.org> list" <dispatch@ietf.org<= mailto:dispatch@ietf.org>> Subject: Re: [dispatch] Updated STRAW Charter v2 Daryl, Do you mind if I remove that deliverable from the Charter? The STRAW Worki= ng Group can always add it back in, once the WG's established and there's a= candidate draft to look at and think about. I think I understand what you= 're looking for and I like the idea, but I too am not sure if we're all on = the same page, or if we can actually produce such a document. So I'd prefe= r to just delay that one until we have such a draft written up, and so we c= an get STRAW created sooner. As you said it would be timed toward the end = anyway, so there's no urgency. -hadriel On Mar 29, 2012, at 4:55 PM, Daryl Malas wrote: Michael, I do not view it this way. If someone develops a requirements document bas= ed on the framework, it would still need to be approved by a directorate (o= nly used as an example, may not really apply) or something similar. The ma= iling list could also be kept open for these. There are existing examples = of processes for this. With regards to the considerations, the document would provide details of v= ariables to include in a considerations section. Again, the considerations= section, part of an Internet Draft, would still need to be reviewed and pr= ocessed by the working group, AD's, IESG, etc. --Daryl From: Michael Hammer <mphmmr@gmail.com<mailto:mphmmr@gmail.com>> Date: Thu, 29 Mar 2012 08:43:11 -0600 To: Daryl Malas <d.malas@cablelabs.com<mailto:d.malas@cablelabs.com>> Cc: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmb= erg@ericsson.com>>, Hadriel Kaplan <HKaplan@acmepacket.com<mailto:HKaplan@a= cmepacket.com>>, "dispatch@ietf.org<mailto:dispatch@ietf.org> list" <dispat= ch@ietf.org<mailto:dispatch@ietf.org>> Subject: Re: [dispatch] Updated STRAW Charter v2 Daryl, That sounds like signing a blank check. Will certain implementations be declared non-compliant to the RFC for some = unknown future feature? Would this also require future SIP features to add a section, say just prio= r to the Security section, that would need to declare handling by B2BUAs? Mike On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <D.Malas@cablelabs.com<mailto:= D.Malas@cablelabs.com>> wrote: Christer, Deliverable "2" will be used to create documents defining the requirements for B2BUAs to support future/undefined "specific features." It allows the working group to not persist indefinitely. I am assuming the deliverables are not listed as a prioritized list. I would expect the framework to be completed towards the end, based on previous experience. Framework Examples: http://tools.ietf.org/html/rfc6117 http://tools.ietf.org/html/rfc6390 --Daryl On 3/29/12 1:20 PM, "Christer Holmberg" <christer.holmberg@ericsson.com<mai= lto:christer.holmberg@ericsson.com>> wrote: > >Hi, > >I support this work, and after a quick look the proposed charter looks >good, but I have a question for clarification regarding the suggested >deliverable 2). > >A question for clarification (my appologies if it has already been >clarified). > >"2) A framework document for defining requirements and considerations for >traversing B2BUAs." > >Deliverables 3) - 7) talk about requirements in order for specific >features to "survive" a B2BUA, but I am not sure what requirements 2) is >talking about? > >Regards, > >Christer > > > > >-----Original Message----- >From: dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org> [mailto:= dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org>] On >Behalf Of Hadriel Kaplan >Sent: 29. maaliskuuta 2012 10:33 >To: dispatch@ietf.org<mailto:dispatch@ietf.org> list >Subject: [dispatch] Updated STRAW Charter v2 > >Howdy, >Updated charter below... > > >Description of STRAW Working Group >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Name: Sip Traversal Required for Applications to Work (STRAW) > >Problem Statement: >Within the context of the SIP protocol and architecture, a Back-to-Back >User Agent (B2BUA) is any SIP device in the logical path between two User >Agents performing a role beyond that of a Proxy as defined in RFC 3261. >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA >in order to terminate dead sessions by generating BYEs; or it may be a >3PCC-style agent only modifying SDP; or it may be a Session Border >Controller performing such functions as in RFC 5853; or it may be an >Enterprise PBX terminating REFERs and such; or it may be a complete UAS >and UAC implementation with a PRI loopback in-between. > >In its most extreme form, the scope of the SIP protocol ends at the UAS >of the B2BUA, and a new SIP protocol scope begins on its UAC side. In >practice, however, users expect some SIP protocol aspects to go beyond >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as >if the B2BUA was not an end unto itself; this is similar to the >expectation that emails work when they cross from POP and IMAP to/from >SMTP. > >It is impossible to normatively define all the behaviors of B2BUAs in >general, or even subsets of them such as SBCs or PBXs. Unlike consumer >NATs, B2BUAs perform widely varying functions for purposes which may be >unique to their environment, unique to their architecture, or unique to >the wishes of their administrator. Instead of defining all things a >given type of B2BUA must do, a more practical objective would be to >define what very few things any B2BUA must do to make a specific SIP >mechanism work, and let the market decide whether to do those things. > >The name of this working group reflects that practical objective: if >there were a thin straw between the SIP UAS and UAC of a B2BUA, what must >be passed through that straw and used on each side. Or viewed another >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback >circuit, and if we could extend ISDN, what information would we carry in >ISDN across the PRI for a specific SIP mechanism to work end-to-end. > >For example, the WG could produce a document which specifies that the >Max-Forwards header field value should be copied and decremented across >the B2BUA, if the B2BUA wishes to prevent infinite loops. Administrators >could then tell their B2BUA vendors to comply with the document, if the >administrator so wishes. > > >Objectives: >The objectives of the STRAW Working Group are to publish normative >documents which define which SIP header fields, parameters, MIME bodies, >body content fields/information, or media-plane characteristics are >required to traverse between the User Agent "sides" of a B2BUA for >specific functions to work. > >The specific functions covered are expected to relate to >already-published RFCs or existing RAI area work, as opposed to all >future IETF work. In other words, the Working Group is not meant to be a >never-ending source for B2BUA requirements in the RAI area. > >Deliverables would indicate which types of B2BUAs would apply or not. >For example, a document defining the requirements for end-to-end >DTLS-SRTP would not apply to B2BUAs which terminate media, such as >transcoders or recorders. > > >Initial Deliverables: >1) A taxonomy document defining role-types of B2BUAs, as a reference for >other deliverables. >2) A framework document for defining requirements and considerations for >traversing B2BUAs. >3) A document defining the requirements for B2BUAs with respect to loop >detection/prevention. >4) A document defining the requirements for B2BUAs to support end-to-end >and hop-by-hop media-loopback test calls. >5) A document defining the requirements for B2BUAs to support DTLS-SRTP >(RFC 5764) end-to-end. >6) A document defining the requirements for B2BUAs to support STUN >message transactions end-to-end. >7) A document defining the requirements for B2BUAs to support RTCP >end-to-end. > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org<mailto:dispatch@ietf.org> >https://www.ietf.org/mailman/listinfo/dispatch >_______________________________________________ >dispatch mailing list >dispatch@ietf.org<mailto:dispatch@ietf.org> >https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch --_000_387F9047F55E8C42850AD6B3A7A03C6C0E222F1Ainbamail01sonus_ 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: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=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @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;} /* 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.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.hoenzb {mso-style-name:hoenzb;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .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;} --></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=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">As I mentioned in IETF-83= Dispatch meeting, the draft has to be written for B2BUA considerations for= new SIP/SDP headers.  I understand Hadriel concern about the timeline for the closure of STRAW charter with existing undefined RFC&= #8217;s and so, let the initial draft of B2BUA consideration be in Dispatch= .<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I will volunteer to write= the initial draft for B2BUA consideration. I noticed that lot of folks sho= ws interest during STRAW charter discussion. So, I’m interested in hearing other folks opinion for this activity. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks<o:p></o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Partha<o:p></o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><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 style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> dispatch= -bounces@ietf.org [mailto:dispatch-bounces@ietf.org] <b>On Behalf Of </b>Michael Hammer<br> <b>Sent:</b> Saturday, March 31, 2012 2:05 AM<br> <b>To:</b> Hadriel Kaplan<br> <b>Cc:</b> dispatch@ietf.org list<br> <b>Subject:</b> Re: [dispatch] Updated STRAW Charter v2<o:p></o:p></span></= p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">My concern was generally around the practicality of = predicting future events, i.e. new SIP headers in new RFCs,<o:p></o:p></p> <div> <p class=3D"MsoNormal">and the tendency to include mandatory RFCs in RFPs. =  So, just trying to contemplate how future compatibility is handled.<o= :p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">I am happy if this is more the nature of guidelines = and suggested guidance on text addressing B2BUAs in future RFCs.<o:p></o:p>= </p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Mike<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal">On Fri, Mar 30, 2012 at 1:25 PM, Hadriel Kaplan <= <a href=3D"mailto:HKaplan@acmepacket.com">HKaplan@acmepacket.com</a>> wr= ote:<o:p></o:p></p> <div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Cool, thanks!<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">I am sure you will be happy to remind us and the eve= ntual chairs about it, at every opportunity. :)<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">I too want such a draft written, as I said during th= e DISPATCH presentation that it's my personal belief we have to get future = RFCs to do their own B2BUA considerations/requirements, and having a docume= nt to point to would be the only way to get that.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p> </o:p></spa= n></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:#888888">-hadriel<o:p></o:p></s= pan></p> </div> <div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <div> <p class=3D"MsoNormal">On Mar 30, 2012, at 7:00 PM, Daryl Malas wrote:<o:p>= </o:p></p> </div> <p class=3D"MsoNormal"><br> <br> <o:p></o:p></p> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">Hadriel,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">I guess in the end it doesn't matter; h= owever, I would argue that working group deliverable intentions does not me= an the work is not scrapped at a later point either.  In fact, working group drafts and working groups have been scrapped due to a = number of different reasons…some you have described below.  The = reason I am a proponent of keeping it in the list, is that it provides a re= minder to attempt putting this together towards the end.  I admit that I'm not 100% sure it is a feasible deliverable= , but I think it helps avoid the potential situation of continuously dealin= g with "features" for many years to come.  All of this being= said, if it is the only remaining controversial item, then I am not that bent on having it in there now.  The overall work = is more valuable that quibbling over this one deliverable.<o:p></o:p></span= ></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">--Daryl<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><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=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From: </span></b><span style=3D"font-size:11.0pt;font-family:"Calibri",= "sans-serif"">Hadriel Kaplan <<a href=3D"mailto:HKaplan@acmepa= cket.com" target=3D"_blank">HKaplan@acmepacket.com</a>><br> <b>Date: </b>Fri, 30 Mar 2012 10:29:12 -0600<br> <b>To: </b>Daryl Malas <<a href=3D"mailto:d.malas@cablelabs.com" target= =3D"_blank">d.malas@cablelabs.com</a>><br> <b>Cc: </b>Michael Hammer <<a href=3D"mailto:mphmmr@gmail.com" target=3D= "_blank">mphmmr@gmail.com</a>>, Christer Holmberg <<a href=3D"mailto:= christer.holmberg@ericsson.com" target=3D"_blank">christer.holmberg@ericsso= n.com</a>>, "<a href=3D"mailto:dispatch@ietf.org" target=3D"_blank"= >dispatch@ietf.org</a> list" <<a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">disp= atch@ietf.org</a>><br> <b>Subject: </b>Re: [dispatch] Updated STRAW Charter v2<o:p></o:p></span></= p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <div> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">Daryl,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">Do you mind if I remove that deliverabl= e from the Charter?  The STRAW Working Group can always add it back in= , once the WG's established and there's a candidate draft to look at and think about.  I think I understand what you're looking fo= r and I like the idea, but I too am not sure if we're all on the same page,= or if we can actually produce such a document.  So I'd prefer to just= delay that one until we have such a draft written up, and so we can get STRAW created sooner.  As you said it w= ould be timed toward the end anyway, so there's no urgency.<o:p></o:p></spa= n></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">-hadriel<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">On Mar 29, 2012, at 4:55 PM, Daryl Mala= s wrote:<o:p></o:p></span></p> </div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><br> <br> <o:p></o:p></span></p> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">Michael,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">I do not view it this way.  If som= eone develops a requirements document based on the framework, it would stil= l need to be approved by a directorate (only used as an example, may not really apply) or something similar.  The mailing list could a= lso be kept open for these.  There are existing examples of processes = for this.  <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">With regards to the considerations, the= document would provide details of variables to include in a considerations= section.  Again, the considerations section, part of an Internet Draft, would still need to be reviewed and processed by the worki= ng group, AD's, IESG, etc.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">--Daryl<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><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=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From: </span></b><span style=3D"font-size:11.0pt;font-family:"Calibri",= "sans-serif"">Michael Hammer <<a href=3D"mailto:mphmmr@gmail.c= om" target=3D"_blank">mphmmr@gmail.com</a>><br> <b>Date: </b>Thu, 29 Mar 2012 08:43:11 -0600<br> <b>To: </b>Daryl Malas <<a href=3D"mailto:d.malas@cablelabs.com" target= =3D"_blank">d.malas@cablelabs.com</a>><br> <b>Cc: </b>Christer Holmberg <<a href=3D"mailto:christer.holmberg@ericss= on.com" target=3D"_blank">christer.holmberg@ericsson.com</a>>, Hadriel K= aplan <<a href=3D"mailto:HKaplan@acmepacket.com" target=3D"_blank">HKapl= an@acmepacket.com</a>>, "<a href=3D"mailto:dispatch@ietf.org" targe= t=3D"_blank">dispatch@ietf.org</a> list" <<a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">disp= atch@ietf.org</a>><br> <b>Subject: </b>Re: [dispatch] Updated STRAW Charter v2<o:p></o:p></span></= p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">Daryl, <o:p></o:p></span></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">That sounds like signing a blank check.=  <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">Will certain implementations be declare= d non-compliant to the RFC for some unknown future feature?<o:p></o:p></spa= n></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">Would this also require future SIP feat= ures to add a section, say just prior to the Security section,<o:p></o:p></= span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">that would need to declare handling by = B2BUAs?<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">Mike<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s= ize:10.5pt;font-family:"Calibri","sans-serif""><o:p>&nb= sp;</o:p></span></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">On Thu, Mar 29, 2012 at 9:43 AM, Daryl = Malas <<a href=3D"mailto:D.Malas@cablelabs.com" target=3D"_blank">D.Mala= s@cablelabs.com</a>> wrote:<br> <br> <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif"">Christer,<br> <br> Deliverable "2" will be used to create documents defining the req= uirements<br> for B2BUAs to support future/undefined "specific features." It al= lows the<br> working group to not persist indefinitely.<br> <br> I am assuming the deliverables are not listed as a prioritized list.  = I<br> would expect the framework to be completed towards the end, based on<br> previous experience.<br> <br> Framework Examples:<br> <br> <a href=3D"http://tools.ietf.org/html/rfc6117" target=3D"_blank">http://too= ls.ietf.org/html/rfc6117</a><br> <br> <a href=3D"http://tools.ietf.org/html/rfc6390" target=3D"_blank">http://too= ls.ietf.org/html/rfc6390</a><br> <br> --Daryl<br> <br> On 3/29/12 1:20 PM, "Christer Holmberg" <<a href=3D"mailto:chr= ister.holmberg@ericsson.com" target=3D"_blank">christer.holmberg@ericsson.c= om</a>><br> wrote:<o:p></o:p></span></p> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><br> ><br> >Hi,<br> ><br> >I support this work, and after a quick look the proposed charter looks<= br> >good, but I have a question for clarification regarding the suggested<b= r> >deliverable 2).<br> ><br> >A question for clarification (my appologies if it has already been<br> >clarified).<br> ><br> >"2) A framework document for defining requirements and considerati= ons for<br> >traversing B2BUAs."<br> ><br> >Deliverables 3) - 7) talk about requirements in order for specific<br> >features to "survive" a B2BUA, but I am not sure what require= ments 2) is<br> >talking about?<br> ><br> >Regards,<br> ><br> >Christer<br> ><br> ><br> ><br> ><br> >-----Original Message-----<br> >From: <a href=3D"mailto:dispatch-bounces@ietf.org" target=3D"_blank">di= spatch-bounces@ietf.org</a> [mailto:<a href=3D"mailto:dispatch-bounces@ietf= .org" target=3D"_blank">dispatch-bounces@ietf.org</a>] On<br> >Behalf Of Hadriel Kaplan<br> >Sent: 29. maaliskuuta 2012 10:33<br> >To: <a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@iet= f.org</a> list<br> >Subject: [dispatch] Updated STRAW Charter v2<br> ><br> >Howdy,<br> >Updated charter below...<br> ><br> ><br> >Description of STRAW Working Group<br> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> >Name: Sip Traversal Required for Applications to Work (STRAW)<br> ><br> >Problem Statement:<br> >Within the context of the SIP protocol and architecture, a Back-to-Back= <br> >User Agent (B2BUA) is any SIP device in the logical path between two Us= er<br> >Agents performing a role beyond that of a Proxy as defined in RFC 3261.= <br> >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA= <br> >in order to terminate dead sessions by generating BYEs; or it may be a<= br> >3PCC-style agent only modifying SDP; or it may be a Session Border<br> >Controller performing such functions as in RFC 5853; or it may be an<br= > >Enterprise PBX terminating REFERs and such; or it may be a complete UAS= <br> >and UAC implementation with a PRI loopback in-between.<br> ><br> >In its most extreme form, the scope of the SIP protocol ends at the UAS= <br> >of the B2BUA, and a new SIP protocol scope begins on its UAC side. &nbs= p;In<br> >practice, however, users expect some SIP protocol aspects to go beyond<= br> >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, = as<br> >if the B2BUA was not an end unto itself; this is similar to the<br> >expectation that emails work when they cross from POP and IMAP to/from<= br> >SMTP.<br> ><br> >It is impossible to normatively define all the behaviors of B2BUAs in<b= r> >general, or even subsets of them such as SBCs or PBXs. Unlike consumer<= br> >NATs, B2BUAs perform widely varying functions for purposes which may be= <br> >unique to their environment, unique to their architecture, or unique to= <br> >the wishes of their administrator.  Instead of defining all things= a<br> >given type of B2BUA must do, a more practical objective would be to<br> >define what very few things any B2BUA must do to make a specific SIP<br= > >mechanism work, and let the market decide whether to do those things.<b= r> ><br> >The name of this working group reflects that practical objective: if<br= > >there were a thin straw between the SIP UAS and UAC of a B2BUA, what mu= st<br> >be passed through that straw and used on each side.  Or viewed ano= ther<br> >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopbac= k<br> >circuit, and if we could extend ISDN, what information would we carry i= n<br> >ISDN across the PRI for a specific SIP mechanism to work end-to-end.<br= > ><br> >For example, the WG could produce a document which specifies that the<b= r> >Max-Forwards header field value should be copied and decremented across= <br> >the B2BUA, if the B2BUA wishes to prevent infinite loops.  Adminis= trators<br> >could then tell their B2BUA vendors to comply with the document, if the= <br> >administrator so wishes.<br> ><br> ><br> >Objectives:<br> >The objectives of the STRAW Working Group are to publish normative<br> >documents which define which SIP header fields, parameters, MIME bodies= ,<br> >body content fields/information, or media-plane characteristics are<br> >required to traverse between the User Agent "sides" of a B2BU= A for<br> >specific functions to work.<br> ><br> >The specific functions covered are expected to relate to<br> >already-published RFCs or existing RAI area work, as opposed to all<br> >future IETF work.  In other words, the Working Group is not meant = to be a<br> >never-ending source for B2BUA requirements in the RAI area.<br> ><br> >Deliverables would indicate which types of B2BUAs would apply or not.<b= r> >For example, a document defining the requirements for end-to-end<br> >DTLS-SRTP would not apply to B2BUAs which terminate media, such as<br> >transcoders or recorders.<br> ><br> ><br> >Initial Deliverables:<br> >1) A taxonomy document defining role-types of B2BUAs, as a reference fo= r<br> >other deliverables.<br> >2) A framework document for defining requirements and considerations fo= r<br> >traversing B2BUAs.<br> >3) A document defining the requirements for B2BUAs with respect to loop= <br> >detection/prevention.<br> >4) A document defining the requirements for B2BUAs to support end-to-en= d<br> >and hop-by-hop media-loopback test calls.<br> >5) A document defining the requirements for B2BUAs to support DTLS-SRTP= <br> >(RFC 5764) end-to-end.<br> >6) A document defining the requirements for B2BUAs to support STUN<br> >message transactions end-to-end.<br> >7) A document defining the requirements for B2BUAs to support RTCP<br> >end-to-end.<br> ><br> ><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@ietf.or= g</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br> >_______________________________________________<br> >dispatch mailing list<br> ><a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@ietf.or= g</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/dispatch</a><br> <br> _______________________________________________<br> dispatch mailing list<br> <a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@ietf.org</a= ><br> <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/dispatch</a><o:p></o:p></span></p> </div> </div> </div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> </div> </div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif""><o:p> </o:p></span></p> </div> </div> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </div> </body> </html> --_000_387F9047F55E8C42850AD6B3A7A03C6C0E222F1Ainbamail01sonus_--