From HKaplan@acmepacket.com Sat May 1 00:11:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4EEC3A6A64 for ; Sat, 1 May 2010 00:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.08 X-Spam-Level: X-Spam-Status: No, score=-1.08 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APyT64aunkHI for ; Sat, 1 May 2010 00:11:36 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D81E03A6783 for ; Sat, 1 May 2010 00:11:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 1 May 2010 03:11:18 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 1 May 2010 03:11:16 -0400 From: Hadriel Kaplan To: Cullen Jennings , Dean Willis Date: Sat, 1 May 2010 03:11:08 -0400 Thread-Topic: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) Thread-Index: Acrom6UgYbDig5oJQFGGFvw6/zE1kQAYCRgA Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F19B2@mail> References: <85FD2EC8-311C-44E8-A699-0E7B577463D4@softarmor.com> <1AF232C1-9025-4C5E-9F52-DC3BD9CDDE68@cisco.com> In-Reply-To: <1AF232C1-9025-4C5E-9F52-DC3BD9CDDE68@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 07:11:37 -0000 Not a single customer I have ever talked to about TRIP ever expressed conce= rn over authorization of identities. Not one. They may well have if it ha= d been deployed, but that was not the reason it failed to get deployed, afa= ict. There were a bunch of factors, including only two vendors implemented= it (Acme and Cisco), it uses BGP which scared voice people, and numbers di= dn't aggregate as well anymore. But really the number one reason by far wa= s that there was no problem to solve back then. SIP was in its infancy rea= lly, and the number of systems was small enough and un-changing enough that= they could just handle it using static configuration tables and PSTN datab= ases. Without a real problem to solve, TRIP was dead at the starting gate. -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Friday, April 30, 2010 3:30 PM >=20 > There probably any number of reasons that TRIP and others were never > deployed but I think one of the largest reasons is the questions about > authorization of identities. There are any number of protocols where > organization A can tell organization B that calls to phone number X shoul= d > be routed to server Y. Some examples are TRIP, DUNI, flavors of ENUM, VIP= R, > and so on. The issue is you need a reason that B should trust what A told > them. >=20 > Without a good answer that question, it's hard to see how one would use > the resulting solution. >=20 > Cullen From hannes.tschofenig@nsn.com Sun May 2 07:53:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9933A6929 for ; Sun, 2 May 2010 07:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.31 X-Spam-Level: X-Spam-Status: No, score=0.31 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2i31MfMsdog for ; Sun, 2 May 2010 07:52:59 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id F1B413A6823 for ; Sun, 2 May 2010 07:52:55 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o42EqckK024587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 May 2010 16:52:38 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o42EqaQC029915; Sun, 2 May 2010 16:52:38 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 2 May 2010 16:52:37 +0200 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_01CAEA07.1AA8EDCB" Date: Sun, 2 May 2010 17:52:36 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45028697BE@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Open talk and investigation about HIP and SIP/IMS thread-index: AcroGU7wm2Vk9ekHTkS5tLn3jRSbIQB6Rg7w References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , X-OriginalArrivalTime: 02 May 2010 14:52:37.0174 (UTC) FILETIME=[1AF9F560:01CAEA07] Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 14:53:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAEA07.1AA8EDCB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gao,=20 =20 I read through your mail a couple of times but I was not quite sure that I understood your line of thought.=20 When someone does not want to use SIP (but HTTP instead) then let them do. There shouldn't be any problem with that.=20 =20 The RADIUS and Diameter based Authentication, Authorization, and Accounting (AAA) infrastructure is not application independent. RADIUS and Diameter have largely been utilized for network access authentication and for a few selected applications but have not found widespread usage for web applications. There you find other protocols being used. Also not a problem as such either.=20 =20 Having said that I am not sure how you draw the conclusion that HIP might be the right protocol given that it is not a AAA protocol in the first place nor particularly well aligned with any of the mentioned protocols.=20 =20 I personally prefer to start with a problem statement first and then to figure out whether people agree with it. Subsequently, one can brainstorm about the appropriate protocol that addresses the gaps. =20 Ciao Hannes =20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext gao.yang2@zte.com.cn Sent: Friday, April 30, 2010 6:55 AM To: dispatch@ietf.org Subject: [dispatch] Open talk and investigation about HIP and SIP/IMS =09 =09 Hi,=20 =09 For people caring about SIP/IMS's network management level, I think one application independency AAA infrastructure is future direction for SIP/IMS. I'd like to know how many people have the same interest? If you have any comments/feeling/suggestion for this topic, feel free to go on.=20 =09 Telecom Core Network=20 =09 IMS(IP Multimedia Subsystem) is aimed for unified user management, unified authentication, unified policy/charging and unified service control, but it is tightly coupled with SIP. While the telecom core network operators want to deploy any non-sip application, they find that the unified platform(IMS) would not be suitable. =20 =09 We may conclude from the situation that, if telecom (core network) operators want to make one infrastructure(unified user management, unified authentication, unified policy/charging and unified service control) suitable for any application(sip and non-sip), they need make an sip decoupling AAA infrastructure at first.=20 =09 Making IMS's AAA based on HIP and IMS's multimedia level still on sip, would make IMS's infrastructure open for any other protocol and application. And if the telecom (core network) operators want to embrace more and more non-sip application, HIP may be the only way.=20 =09 Meanwhile, Could Computing and even M2M network also can get benefit from such application independency AAA infrastructure:=20 =09 Clouding Computing=20 =09 Some standard cloud/grid computing technology is based on Web. On the web platform, it is easy to bulid one AAA infrastructure and open for appliaction such as SOA. But if we want to build web and non-web(such as RAI) application on the same platform, there's the same problem IMS has.=20 So, if IT industry's could computing want to embrace non-web application, HIP may be the same way again.=20 =09 M2M Network=20 Machine to machine network is hot now. But it also need one application independency AAA infrastructure as platform for all the conceivable application protocols. HIP is still a good choice for it.=20 =09 Thanks,=20 =09 Gao=20 =09 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. ------_=_NextPart_001_01CAEA07.1AA8EDCB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Gao,
 
I read=20 through your mail a couple of times but I was not quite sure that I = understood=20 your line of thought.
When=20 someone does not want to use SIP (but HTTP instead) then let them do. = There=20 shouldn't be any problem with that.
 
The=20 RADIUS and Diameter based Authentication, Authorization, and Accounting = (AAA)=20 infrastructure is not application independent. RADIUS and Diameter have = largely=20 been utilized for network access authentication and for a few selected=20 applications but have not found widespread usage for web applications. = There you=20 find other protocols being used. Also not a problem as such either.=20
 
Having=20 said that I am not sure how you draw the conclusion that HIP might be = the right=20 protocol given that it is not a AAA protocol in the first place nor = particularly=20 well aligned with any of the mentioned protocols.
 
I=20 personally prefer to start with a problem statement first and then to = figure out=20 whether people agree with it. Subsequently, one can brainstorm about the = appropriate protocol that addresses the gaps.
 
Ciao
Hannes
 

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of ext=20 gao.yang2@zte.com.cn
Sent: Friday, April 30, 2010 6:55=20 AM
To: dispatch@ietf.org
Subject: [dispatch] Open = talk and=20 investigation about HIP and SIP/IMS


Hi, =

For people caring about SIP/IMS's network = management=20 level, I think one application independency AAA infrastructure is = future=20 direction for SIP/IMS. I'd like to know how many people have the same=20 interest? If you have any comments/feeling/suggestion for this topic, = feel=20 free to go on.

Telecom = Core=20 Network

IMS(IP = Multimedia=20 Subsystem) is aimed for unified user management, unified = authentication,=20 unified policy/charging and unified service control, but it is tightly = coupled=20 with SIP. While the telecom core network operators want to deploy any = non-sip=20 application, they find that the unified platform(IMS) would not be = suitable.=20  

We may conclude = from the=20 situation that, if telecom (core network) operators want to make one=20 infrastructure(unified user management, unified authentication, = unified=20 policy/charging and unified service control) suitable for any = application(sip=20 and non-sip), they need make an sip decoupling AAA infrastructure at = first.=20

Making IMS's AAA based = on HIP and=20 IMS's multimedia level still on sip, would make IMS's infrastructure = open for=20 any other protocol and application. And if the telecom (core network)=20 operators want to embrace more and more non-sip application, HIP may = be the=20 only way.

Meanwhile, Could=20 Computing and even M2M network also can get benefit from such = application=20 independency AAA infrastructure:

Clouding Computing

Some=20 standard cloud/grid computing technology is based on Web. On the web = platform,=20 it is easy to bulid one AAA infrastructure and open for appliaction = such as=20 SOA. But if we want to build web and non-web(such as RAI) application = on the=20 same platform, there's the same problem IMS has.
So, if IT industry's could computing want = to embrace=20 non-web application, HIP may be the same way again. =

M2M Network
Machine to machine network is hot now. But it also need one = application=20 independency AAA infrastructure as platform for all the conceivable=20 application protocols. HIP is still a good choice for it. =

Thanks,

Gao

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zip    : = 210012
Tel=20    : 87211
Tel2   :(+86)-025-52877211
e_mail :=20 = gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
---=
-----------------------------------------------------
ZTE Information Security Notice: The information=
 contained in this mail is solely prop=
erty of the sender's organization. This mai=
l communication is confidential. Recipients name=
d above are obligated to maintain secrecy&n=
bsp;and are not permitted to disclose the&n=
bsp;contents of this communication to others.
This email and any files transmitted with&n=
bsp;it are confidential and intended solely =
;for the use of the individual or enti=
ty to whom they are addressed. If you&=
nbsp;have received this email in error plea=
se notify the originator of the message.&nb=
sp;Any views expressed in this message are&=
nbsp;those of the individual sender.
This message has been scanned for viruses&n=
bsp;and Spam by ZTE Anti-Spam system.
------_=_NextPart_001_01CAEA07.1AA8EDCB-- From peter.leis@nsn.com Mon May 3 06:32:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8210328C198 for ; Mon, 3 May 2010 06:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgb3JfyqTNp8 for ; Mon, 3 May 2010 06:32:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 6E3EA28C17B for ; Mon, 3 May 2010 06:32:39 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o43DWLkl021010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 May 2010 15:32:21 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o43DWKSb010494; Mon, 3 May 2010 15:32:20 +0200 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 May 2010 15:32:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 May 2010 15:32:19 +0200 Message-ID: In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sA== References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail> <430FC6BDED356B4C8498F634416644A91A8A5F1711@mail> <430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> From: "Leis, Peter (NSN - DE/Munich)" To: "ext Hadriel Kaplan" , "Dawes, Peter, VF-Group" , X-OriginalArrivalTime: 03 May 2010 13:32:20.0737 (UTC) FILETIME=[0E91BF10:01CAEAC5] Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 13:32:49 -0000 comments inline=20 > -----Original Message----- > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Friday, April 30, 2010 5:47 PM > To: Leis, Peter (NSN - DE/Munich); Dawes, Peter, VF-Group;=20 > dispatch@ietf.org > Subject: RE: [dispatch] New I-D:=20 > draft-dawes-dispatch-mediasec-parameter-01 >=20 >=20 >=20 > > -----Original Message----- > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > > Sent: Friday, April 30, 2010 4:17 AM > > To: Hadriel Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org > >=20 > > > -----Original Message----- > > > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Thursday, April 29, 2010 6:59 PM > > > > > > Right, but I'm trying to figure out why that is. I mean > > > what's the reason the UA needs to know at Registration time > > > that it's next-hop b2bua can do srtp, instead of letting SDP > > > handle it? > > > > > > I *think* the answer is so that it can later send an INVITE > > > with an SDP offer without failing the request - is that=20 > the reason? > >=20 > > Right > =20 > OK, and I also agree that's a real problem. That issue was=20 > raised in the IETF in 2006/2007. There was a very simple=20 > proposal to avoid that, in=20 > draft-kaplan-mmusic-best-effort-srtp, but the decision of the=20 > MMUSIC WG was to instead use=20 > draft-ietf-mmusic-sdp-capability-negotiation to accomplish=20 > it. That draft is now in the RFC editor's queue. I know=20 > it's a lot of processing overhead, but that was the decision.=20 > And I think 3gpp has put support for that into some release or other. >=20 The requirement in 3GPP is, that the UE has to know whether or not the network (P-CSCF) will support SDES-SRTP before the session takes place, if it wants to employ End2AccessEdge media plane security. This will ensure that the IMS UE shares the media keys only with the P-CSCF and not with some other entity. In addition, in 3GPP there is a requirement that the UE knows whether media plane security is established between itself and the network (i.e. End2AccessEdge), or whether media plane security is established between itself and the far end.=20 As you said, CapNeg has a lot of processing overhead, and in addition, it does not solve the requirements I have listed. >=20 > > > > RFC 3840 does only cover UA indicating support, but not SBC > > > indicating > > > > support. > > > > > > Actually, in a way it does. An SBC is a B2BUA. As a UA, it > > > can indicate feature tags. What it *can't* do is indicate it > > > in the REGISTER response it sends to the UA. But the UA > > > could send an OPTIONS to the B2BUA and get it in a feature > > > tag of the response to the OPTIONS. I know it sucks to send > > > more SIP messages, but I don't see how to avoid that and be > > > consistent with the SIP architecture. It's really weird for > > > a REGISTER response to indicate media capabilities of the=20 > Registrar. > >=20 > > use of OPTIONS was discussed, but due to the additional=20 > signalling, it > > was discarded. >=20 > Considering all of the other signaling already required=20 > (subscription to reg-event, subscription to presence, xcap,=20 > possibly subscription to Config server) isn't an OPTIONS just=20 > a nit at this point? And that way this could be a general=20 > solution, instead of a 3gpp-specific one. >=20 >=20 > > The indication of network support for SDES-SRTP in response=20 > to REGISTER > > is not included by the registrar, but by the network=20 > element placed at > > the edge (the SBC/B2BUA) >=20 > I know, but from the UA's perspective the REGISTER response=20 > is coming from the Registrar, possibly through proxies. =20 > There's no logical/conceptual model in the IETF for a=20 > REGISTER response to indicate media capabilities of some=20 > middle hop of the REGISTER. >=20 > -hadriel >=20 From Martin.Huelsemann@telekom.de Mon May 3 08:19:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0F43A6864 for ; Mon, 3 May 2010 08:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwGKpYcJZQWK for ; Mon, 3 May 2010 08:19:36 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 454B93A67F6 for ; Mon, 3 May 2010 08:19:35 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 03 May 2010 17:19:16 +0200 Received: from S4DE9JSAAIL.ost.t-com.de ([10.125.177.200]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 May 2010 17:19:15 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 3 May 2010 17:19:14 +0200 Message-ID: In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F1281@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Using session-id for dialog correlation Thread-Index: AcrmNuwi6qvbpieVQEqOL1XxIRQ97QEm38Ag References: <430FC6BDED356B4C8498F634416644A91A8A5F1281@mail> From: To: , X-OriginalArrivalTime: 03 May 2010 15:19:15.0826 (UTC) FILETIME=[FE42A520:01CAEAD3] Subject: Re: [dispatch] Using session-id for dialog correlation X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 15:19:38 -0000 =20 =20 > -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] Im Auftrag von Hadriel Kaplan > Gesendet: Dienstag, 27. April 2010 20:25 > An: dispatch@ietf.org > Betreff: [dispatch] Using session-id for dialog correlation >=20 > [sorry for the long email, but it's a complicated topic] >=20 > A few people have mentioned that the session-id draft should=20 > not only be for troubleshooting, but for dialog correlation as well. =20 >=20 > Specifically to handle this type of scenario, based on 3GPP=20 > 24.605 annex A.2.2 >=20 > +----+ +-----+ +----+ +-----+ +----+ > |UA-A| |B2BUA| | AS | |B2BUA| |UA-B| > +----+ +-----+ +----+ +-----+ +----+ > | | | | | > |INVITE | | | | > |callid:1a |callid:1b |callid:1c |callid:1d | > |----------->|----------->|---------->|----------->| > |sessid:1 |sessid:1 |sessid:1 |sessid:1 | > | | | | | > |INVITE | | | | > |callid:2a |callid:2b | | | > |----------->|----------->| | | > |sessid:2 |sessid:2 |re-INVITE | | > |RL|RL|callid:1c |callid:1d | > | | |---------->|----------->| > | | |sessid:1 |sessid:1 | > | | | | | >=20 > [note: this is a simplified drawing from 3gpp's - in 3gpp it=20 > has two called parties: UA-B and UA-C, but it doesn't really=20 > matter with regards to the problem] >=20 > Explanation of drawing: > UA-A has a call with UA-B through multiple B2BUA's and an=20 > Application Server. The dialogs of that call all have the=20 > same session-id, but unique call-id/tags. >=20 > UA-A wants to invoke a 3rd party conference facility in the=20 > AS, and reference the call with UA-B for that. In this=20 > particular 3gpp scenario, to do that UA-A sends a new INVITE=20 > to the AS with a resource-list body (a la RFC 5366)=20 > containing the call information for the original call. This=20 > is the "RL" piece in the diagram. It has the=20 > calli-d/tags as well, but they'll be wrong when received at the AS. >=20 > The AS processes that list, can't match the callid/tags in=20 > the resource-lit but does match the session-id, and sends a=20 > re-INVITE to party B within the original call's dialog. >=20 > Do I have that right? Hi Hadriel, thanks for checking it. You are right, that's the idea behind it. >=20 > I think there are problems doing that. :( >=20 > 1) The Session-ID only provides a single value which is the=20 > same on both "sides" of a B2BUA. The AS *is* a B2BUA, so=20 > when it gets the resource-list with a Session-ID, how does it=20 > know which side of session-id 1 to re-INVITE? I.e., how does=20 > it know to send a re-INVITE to call-id 1c vs. 1b? The tags=20 > were there to do that, but they no longer match. We could=20 > define a flag/param for Session-ID to indicate uac vs. uas,=20 > if you think that would help (I was prepared to do that in=20 > the draft at one point, to avoid this problem). The AS has more capabilities than a normal B2BUA, it also looks at the = URI in the ressource list, which is UA-B, so it sends the re-INVITE to = the call-id 1c side. >=20 > 2) What if the AS has multiple dialogs for that same=20 > Session-ID? It could have - for example in a "normal" ad-hoc=20 > rfc5366 conference scenario the AS could have invited=20 > multiple participants to the same initial conference call,=20 > and could arguably use the same session-id for all legs. So=20 > if another invite referred to that conference call, it would=20 > be ambiguous which leg it meant. A dialog initiator, UAs or AS, should not use the same Session-ID for 2 = different dialogs. Maybe you remember the discussion we had on the ML = with Salvatore on "session-id" for disagregated media, where we came to = the conclusion that we should not use the same id. >=20 > 3) Let's say this call-flow actually worked, and the AS sent=20 > the re-INVITE to UA-B. At that point, the B2BUA(s) on the=20 > left-hand side of the AS are no longer in synch with regards=20 > to the call or media state. For example, some B2BUA's will=20 > tear-down the call if media stops flowing through them for=20 > too long. In this specific 3gpp spec it says the call was=20 > put on hold before-hand, so that won't happen, but you get=20 > the idea: "bypassing" b2bua's is brittle. It's true, this is a potential source of problems. We took this into = account for the 3GPP use cases (e.g. the communications are in the HOLD = state from the perspective of the left B2BUA). >=20 > 4) In this *particular* scenario the solution is easier: make=20 > the B2BUA's understand resource-lists, and make them change=20 > the callid/tags in them correctly. After all, that's what's=20 > causing the mismatch at the AS. But isn't this a rather=20 > unlikely/rare scenario? I mean do you really intend every=20 > call to go through an AS, just in case it ends up becoming a=20 > 3pcc conf call? If the AS checks the body with the resource list this would be the ideal = solution. But most B2BUAs today do not understand RL.. So we had to look = for an e2e dialog correlator. Unfortunately indeed every call has to be an AS call. But this is also = the case for a number of other IMS services, caused by the IMS = architecture where the AS hosts a number of services, so it won't be = only the 3PTY conference which causes the AS call. It's more like that = it's routed via the AS anyway, so let's use it to send the re-INVITEs = (see below). >=20 > But I also don't understand why 3gpp has this call flow this=20 > way. I'm not an expert on conference call models by any=20 > stretch, and I'm not trying to second-guess 3gpp, but it=20 > seems to me that this isn't what should happen in this call=20 > case. From a logical perspective, the AS getting the=20 > resource-list should try to match the URI's in it. When it=20 > doesn't find them, it should act *exactly* as it would if it=20 > were not by coincidence the same AS which was in the original=20 > call flows - in other words, it should generate new INVITEs=20 > with a Replaces header for the callid/tags in the=20 > resource-list. Those would go to the URI's in the=20 > resource-list, which would be the B2BUA that UA-A made the=20 > original call to. The AS will eventually get that INVITE=20 > with Replaces back again, through that b2bua, things match=20 > up, and all is good.=20 The problem is it is not predictable if the invited UAs really accept = the INVITE from the conference focus, even if there is a Replaces = header. Many of them simply answer with 486, because they are already in = a dialog with the conference initiator. This is even more the case if = the UA is in the PSTN, a usecase we always have to consider at 3gpp. = When you send a re-INVITE in the existing dialog it's very likely the = invited UA accepts. And you are able to restore the original = communications from before the conference rather quickly, which is also = quite important for a 3PTY conference. Regards, Martin =20 >=20 > It's more signaling, but really this call scenario is rare to=20 > begin with and you need the call signaling to avoid the=20 > issues raised earlier. And it will actually replace the=20 > original call dialogs, which is a good thing. And it will=20 > work the same way as cases where the conference AS is not by=20 > coincidence the same as the original calls. (I think) >=20 > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From pkyzivat@cisco.com Mon May 3 09:11:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613653A696B for ; Mon, 3 May 2010 09:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.56 X-Spam-Level: X-Spam-Status: No, score=-9.56 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBt1G5uxggMh for ; Mon, 3 May 2010 09:11:47 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1D99B3A6A09 for ; Mon, 3 May 2010 09:11:36 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugFALqS3ktAZnwN/2dsb2JhbACRAIwicaQDmQuCX4IzBA X-IronPort-AV: E=Sophos;i="4.52,320,1270425600"; d="scan'208";a="107447852" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 03 May 2010 16:11:21 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o43GBLmY000252; Mon, 3 May 2010 16:11:21 GMT Message-ID: <4BDEF5A8.9000305@cisco.com> Date: Mon, 03 May 2010 12:11:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Martin.Huelsemann@telekom.de References: <430FC6BDED356B4C8498F634416644A91A8A5F1281@mail> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, HKaplan@acmepacket.com Subject: Re: [dispatch] Using session-id for dialog correlation X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 16:11:52 -0000 Martin.Huelsemann@telekom.de wrote: > If the AS checks the body with the resource list this would be the ideal solution. But most B2BUAs today do not understand RL.. So we had to look for an e2e dialog correlator. > Unfortunately indeed every call has to be an AS call. But this is also the case for a number of other IMS services, caused by the IMS architecture where the AS hosts a number of services, so it won't be only the 3PTY conference which causes the AS call. It's more like that it's routed via the AS anyway, so let's use it to send the re-INVITEs (see below). Even in the simplest case, where a new INVITE is not forked, and goes to a single UAS that responds with 200? I understand why the AS would be included in the initial routing of the call, but I would think in such a case it would not R-R, and so would be out of the call once the dialog was established. Of course it would then not be present for mid-call actions, like transfers. But its a very specialized architecture that has such a thing in *every* call. IMS *is* such a specialized architecture. But then we perhaps don't want to be devising a session-id mechanism that is only useful in that environment. Thanks, Paul From HKaplan@acmepacket.com Mon May 3 12:52:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6945228C17B for ; Mon, 3 May 2010 12:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viwIbBZOYcM3 for ; Mon, 3 May 2010 12:52:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 40D6B3A6990 for ; Mon, 3 May 2010 12:52:29 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 3 May 2010 15:52:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 3 May 2010 15:52:14 -0400 From: Hadriel Kaplan To: "Martin.Huelsemann@telekom.de" , "dispatch@ietf.org" Date: Mon, 3 May 2010 15:52:12 -0400 Thread-Topic: [dispatch] Using session-id for dialog correlation Thread-Index: AcrmNuwi6qvbpieVQEqOL1XxIRQ97QEm38AgAAletzA= Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1BE4@mail> References: <430FC6BDED356B4C8498F634416644A91A8A5F1281@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Using session-id for dialog correlation X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 19:52:30 -0000 > -----Original Message----- > From: Martin.Huelsemann@telekom.de [mailto:Martin.Huelsemann@telekom.de] > Sent: Monday, May 03, 2010 11:19 AM > To: Hadriel Kaplan; dispatch@ietf.org > Subject: AW: [dispatch] Using session-id for dialog correlation >=20 > > From Hadriel: > > 1) The Session-ID only provides a single value which is the > > same on both "sides" of a B2BUA. The AS *is* a B2BUA, so > > when it gets the resource-list with a Session-ID, how does it > > know which side of session-id 1 to re-INVITE? I.e., how does > > it know to send a re-INVITE to call-id 1c vs. 1b? The tags > > were there to do that, but they no longer match. We could > > define a flag/param for Session-ID to indicate uac vs. uas, > > if you think that would help (I was prepared to do that in > > the draft at one point, to avoid this problem). >=20 > The AS has more capabilities than a normal B2BUA, it also looks at the UR= I > in the ressource list, which is UA-B, so it sends the re-INVITE to the > call-id 1c side. I think that's brittle - by "brittle" I mean makes assumptions about the ne= twork that will not be true in all cases and cause it to fail. (maybe) For example, assume the following call-flow: +----+ +-----+ +-----+ +-----+ +----+ |UA-A| | AS | |B2BUA| | AS | |UA-B| +----+ +-----+ +-----+ +-----+ +----+ | | | | | |INVITE | | | | |callid:1a |callid:1b |callid:1c |callid:1d | |----------->|----------->|---------->|----------->| |sessid:1 |sessid:1 |sessid:1 |sessid:1 | | | | | | |INVITE |re-INVITE | | | |callid:2a |callid:1b | | | |----------->|----------->| | | |sessid:2 |sessid:1 |re-INVITE | | |RL| |callid:1c |callid:1d | | | |---------->|----------->| | | |sessid:1 |sessid:1 | | | | | | Note that now there are *two* AS's in the path. This is like the original = drawing, but the call got routed by the first AS to a stateful-Proxy or B2B= UA, which sent it to a second AS. Now imagine that the AS on the left and the one on the right are the *same*= AS. (That's not as unlikely as one would think, especially in 3gpp) So the AS gets a RL with wrong info, but a matching session-id and a RL-ent= ry for UA-B. Would it bypass the B2BUA in the middle for the re-INVITE, be= cause it finds UA-B in its local table? > > 2) What if the AS has multiple dialogs for that same > > Session-ID? It could have - for example in a "normal" ad-hoc > > rfc5366 conference scenario the AS could have invited > > multiple participants to the same initial conference call, > > and could arguably use the same session-id for all legs. So > > if another invite referred to that conference call, it would > > be ambiguous which leg it meant. >=20 > A dialog initiator, UAs or AS, should not use the same Session-ID for 2 > different dialogs. Maybe you remember the discussion we had on the ML wit= h > Salvatore on "session-id" for disagregated media, where we came to the > conclusion that we should not use the same id. I don't remember it, but I'm not sure it matters: take the example above. = The call comes into the AS, goes to a next-hop B2BUA without forking, gets = routed back to the same AS, and voil=E0: 2 dialogs on the AS with the same = session-id. > > 4) In this *particular* scenario the solution is easier: make > > the B2BUA's understand resource-lists, and make them change > > the callid/tags in them correctly. After all, that's what's > > causing the mismatch at the AS. But isn't this a rather > > unlikely/rare scenario? I mean do you really intend every > > call to go through an AS, just in case it ends up becoming a > > 3pcc conf call? >=20 > If the AS checks the body with the resource list this would be the ideal > solution. But most B2BUAs today do not understand RL.. So we had to look > for an e2e dialog correlator. But you can make them do so. They are under the same administrative contro= l, and subject to 3GPP specs, no? -hadriel From gao.yang2@zte.com.cn Mon May 3 18:44:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2B63A6B6F for ; Mon, 3 May 2010 18:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.266 X-Spam-Level: X-Spam-Status: No, score=-96.266 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4suokykYY2F for ; Mon, 3 May 2010 18:44:54 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id E63D53A6B6C for ; Mon, 3 May 2010 18:44:53 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 36887992332426; Tue, 4 May 2010 09:40:08 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 43572.2898723675; Tue, 4 May 2010 09:40:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o441i7sm004350; Tue, 4 May 2010 09:44:07 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Peter Musgrave MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 4 May 2010 09:41:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-04 09:44:04, Serialize complete at 2010-05-04 09:44:04 Content-Type: multipart/alternative; boundary="=_alternative 00097FFC48257719_=" X-MAIL: mse2.zte.com.cn o441i7sm004350 Cc: dispatch@ietf.org Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 01:44:55 -0000 This is a multipart message in MIME format. --=_alternative 00097FFC48257719_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGV0ZXIgTXVzZ3JhdmUsDQoNClllcywgSElUIHdvdWxkIGJlIGluIFVSTCBhbmQgU0RQLiBB bmQgSSBndWVzcywgSVAgYWRkcmVzcyBpbiBhcHBsaWNhdGlvbiANCmxldmVsIHByb3RvY2FsLCBl c3BlY2lhbGx5IGZvciB0ZXh0IGJhc2VkIHByb3RvY2FsLCB3b3VsZCBiZSByZXBsYWNlZCBieSAN CkhJVC4NCg0KQW5kIGFib3V0IElNUywgaXQgaXMgYmFmZmxpbmcsIGJ5IG9wZXJhdG9ycyBhbmQg bWFudWZhY3R1cmVyIHBvaW50cyBvZiANCnZpZXcuIE9wZXJhdG9ycyByZWFsbHkgbmVlZCBhIENv cmUgTmV0d29yayB0byBkZXBsb3kgYXR0cmFjdGl2ZSANCmFwcGxpY2F0aW9ucyBiZXlvbmQgU0lQ LiBCdXQgSU1TIGNhbiBub3QgYWZmb3JkIGl0LiBBbmQgdGhpcyBpcyB0aGUgcmVhc29uIA0Kd2h5 IEkgdGhpbmsgcGVvcGxlIHdvdWxkIG5lZWQgSElQIGFzIHRoZSBiYXNlIG9mIHRlbGVjb20gY29y ZSBuZXR3b3JrLg0KDQpUaGFua3MgZm9yIHlvdSByZXNwb25zZSBhbmQgd2FpdGluZyBmb3IgeW91 ciBtb3JlIHBvaW50cy4NCg0KR2FvDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAy NS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KUGV0ZXIgTXVzZ3JhdmUgPHBldGVyLm11c2dy YXZlQG1hZ29yY29ycC5jb20+IA0KMjAxMC0wNC0zMCAxODozNA0KDQrK1bz+yMsNCmdhby55YW5n MkB6dGUuY29tLmNuDQqzrcvNDQpkaXNwYXRjaEBpZXRmLm9yZw0K1vfM4g0KUmU6IFtkaXNwYXRj aF0gT3BlbiB0YWxrIGFuZCBpbnZlc3RpZ2F0aW9uIGFib3V0IEhJUCBhbmQgU0lQL0lNUw0KDQoN Cg0KDQoNCg0KSGkgR2FvLA0KDQpJIGFtIGludGVyZXN0ZWQgaW4gdGhlIHBvc3NpYmlsaXRpZXMg b2YgSElQIGFuZCBTSVAuIChJIGNhbid0IHNwZWFrIHRvDQpJTVMgc2luY2UgSSBkb24ndCB3b3Jr IGluIHRoYXQgYXJlYSAtIGFuZCBmcmFua2x5IGZpbmQgaXQgYWxsIHZlcnkNCmJhZmZsaW5nKS4N Cg0KVGhlcmUgaXMgYSBwYXNzaW5nIHJlZmVyZW5jZSB0byBISVAgaW4gdGhlIHAycHNpcCB3b3Jr Lg0KDQpIb3cgZGVlcGx5IHRvIHlvdSBzZWUgdGhlIGludGVyd29ya2luZz8gSWRlYWxseSBpbiBh ICJmdXR1cmUgcGVyZmVjdCINCndvcmxkIEkgd291bGQgbGlrZSB0byB1c2UgSElUcyBpbiBVUkxz IGFuZCBTRFBzIGFuZCB0aGVuIGhhdmUgdGhlDQpzb2NrZXQgZG8gdGhlIE5BVCB0cmF2ZXJzYWwg Zm9yIG1lIGFzIHBhcnQgb2YgZXN0YWJsaXNoaW5nIHRoZSBISVANCmNvbm5lY3Rpb24uIFRoZW4g TkFUIHRyYXZlcnNhbCBjYW4gbGl2ZSBpbiB0aGUgSVAgc3RhY2sgYW5kIG5vdCBpbiBteQ0KbWVk aWEvc2lnbmFsbGluZyBjb2RlLg0KDQpSZWdhcmRzLA0KDQpQZXRlciBNdXNncmF2ZQ0KDQoNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5 c3RlbS4NCg== --=_alternative 00097FFC48257719_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIDwvZm9udD48dHQ+PGZvbnQg c2l6ZT0yPlBldGVyIE11c2dyYXZlPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlllcywgSElUIHdvdWxkIGJlIGluIFVSTCBhbmQgU0RQLiBBbmQNCkkgZ3Vlc3MsIElQIGFkZHJl c3MgaW4gYXBwbGljYXRpb24gbGV2ZWwgcHJvdG9jYWwsIGVzcGVjaWFsbHkgZm9yIHRleHQNCmJh c2VkIHByb3RvY2FsLCB3b3VsZCBiZSByZXBsYWNlZCBieSBISVQuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgYWJvdXQgSU1TLCBpdCBpcyA8L2Zv bnQ+PHR0Pjxmb250IHNpemU9Mj5iYWZmbGluZzwvZm9udD48L3R0Pjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4sDQpieSBvcGVyYXRvcnMgYW5kIG1hbnVmYWN0dXJlciBwb2ludHMgb2Yg dmlldy4gT3BlcmF0b3JzIHJlYWxseSBuZWVkIGEgQ29yZQ0KTmV0d29yayB0byBkZXBsb3kgYXR0 cmFjdGl2ZSBhcHBsaWNhdGlvbnMgYmV5b25kIFNJUC4gQnV0IElNUyBjYW4gbm90IGFmZm9yZA0K aXQuIEFuZCB0aGlzIGlzIHRoZSByZWFzb24gd2h5IEkgdGhpbmsgcGVvcGxlIHdvdWxkIG5lZWQg SElQIGFzIHRoZSBiYXNlDQpvZiB0ZWxlY29tIGNvcmUgbmV0d29yay48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91IHJlc3BvbnNl IGFuZCB3YWl0aW5nDQpmb3IgeW91ciBtb3JlIHBvaW50cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNw OzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21h aWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPlBldGVyIE11c2dyYXZlICZsdDtwZXRlci5tdXNncmF2ZUBtYWdvcmNvcnAuY29tJmd0 OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA0 LTMwIDE4OjM0PC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPmdhby55YW5nMkB6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvN PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5kaXNwYXRj aEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtkaXNwYXRjaF0gT3BlbiB0YWxrIGFu ZCBpbnZlc3RpZ2F0aW9uDQphYm91dCBISVAgYW5kIFNJUC9JTVM8L2ZvbnQ+PC90YWJsZT4NCjxi cj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90 YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkhpIEdhbyw8YnI+DQo8YnI+ DQpJIGFtIGludGVyZXN0ZWQgaW4gdGhlIHBvc3NpYmlsaXRpZXMgb2YgSElQIGFuZCBTSVAuIChJ IGNhbid0IHNwZWFrIHRvPGJyPg0KSU1TIHNpbmNlIEkgZG9uJ3Qgd29yayBpbiB0aGF0IGFyZWEg LSBhbmQgZnJhbmtseSBmaW5kIGl0IGFsbCB2ZXJ5PGJyPg0KYmFmZmxpbmcpLjxicj4NCjxicj4N ClRoZXJlIGlzIGEgcGFzc2luZyByZWZlcmVuY2UgdG8gSElQIGluIHRoZSBwMnBzaXAgd29yay48 YnI+DQo8YnI+DQpIb3cgZGVlcGx5IHRvIHlvdSBzZWUgdGhlIGludGVyd29ya2luZz8gSWRlYWxs eSBpbiBhICZxdW90O2Z1dHVyZSBwZXJmZWN0JnF1b3Q7PGJyPg0Kd29ybGQgSSB3b3VsZCBsaWtl IHRvIHVzZSBISVRzIGluIFVSTHMgYW5kIFNEUHMgYW5kIHRoZW4gaGF2ZSB0aGU8YnI+DQpzb2Nr ZXQgZG8gdGhlIE5BVCB0cmF2ZXJzYWwgZm9yIG1lIGFzIHBhcnQgb2YgZXN0YWJsaXNoaW5nIHRo ZSBISVA8YnI+DQpjb25uZWN0aW9uLiBUaGVuIE5BVCB0cmF2ZXJzYWwgY2FuIGxpdmUgaW4gdGhl IElQIHN0YWNrIGFuZCBub3QgaW4gbXk8YnI+DQptZWRpYS9zaWduYWxsaW5nIGNvZGUuPGJyPg0K PGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpQZXRlciBNdXNncmF2ZTxicj4NCjxicj4NCjwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1 cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5l ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3By b3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4m bmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZp ZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZu YnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5k Jm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZu YnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55 Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZu YnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7 Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5i c3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5i c3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25v dGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3Nh Z2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2lu ZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2Jl ZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0m bmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 00097FFC48257719_=-- From gao.yang2@zte.com.cn Mon May 3 19:28:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E363B28C36B for ; Mon, 3 May 2010 19:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.771 X-Spam-Level: X-Spam-Status: No, score=-95.771 tagged_above=-999 required=5 tests=[AWL=-1.336, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgux6+hUkByP for ; Mon, 3 May 2010 19:28:41 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id B2CAB28C369 for ; Mon, 3 May 2010 19:28:39 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 58071992332426; Tue, 4 May 2010 10:24:31 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 43572.1908261391; Tue, 4 May 2010 10:24:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o442Rwjc086156; Tue, 4 May 2010 10:27:58 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45028697BE@FIESEXC015.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 4 May 2010 10:25:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-04 10:27:54, Serialize complete at 2010-05-04 10:27:54 Content-Type: multipart/alternative; boundary="=_alternative 000D83B848257719_=" X-MAIL: mse2.zte.com.cn o442Rwjc086156 Cc: dispatch@ietf.org Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 02:28:43 -0000 This is a multipart message in MIME format. --=_alternative 000D83B848257719_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSGFubmVzLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2Ugc2luY2VyZWx5IGZpcnN0Lg0K DQpBQUEncyBrZXJuZWwgaXMgaWRlbnRpdHkuIE15IHByb3Bvc2FsIGlzIHRoYXQgdXNpbmcgSElQ J3MgaWRlbnRpdHkoc3VjaCBhcyANCkhJVCkgYXMgdGhlIGtlcm5lbCBvZiBBQUEuIFdoaWxlIEhJ UCBjYW4gYmUgdXNlZCBmb3IgYWxsIGtpbmRzIG9mIA0KYXBwbGljYXRpb24gbGV2ZWwgcHJvdG9j b2wsIHN1Y2ggYXMgU0lQLCBIVFRQIGFuZCBzbyBvbiwgdGhlbiB0aGUgQUFBIGNhbiANCmJlIHVz ZWQgZm9yIG1vcmUgdGhhbiBvbmUgYXBwbGljYXRpb24gbGV2ZWwgcHJvdG9jb2wuIEFuZCBpZiBv cGVyYXRvcnMgDQpkZXBsb3kgdGhpcyBraW5kIG9mIG5ldHdvcmssIHRoZXkgY2FuIHVzaW5nIG9u ZSBpbmZyYXN0cnVjdHVyZSBmb3IgbW9yZSANCnRoYW4gb25lIGFwcGxpY2F0aW9uLg0KDQpVc2lu ZyBTSVAvSU1TIGFzIGV4YW1wbGUsIHVzZXIgbWFuYWdlbWVudCwgcmVnaXN0cmF0aW9uLCBhdXRo ZW50aWNhdGlvbiANCmFuZCBQQ0MoQXV0aG9yaXphdGlvbiwgYW5kIEFjY291bnRpbmcpIGNhbiBi ZSBpbXBsZW1lbnRlZCBpbiB0aGUgDQppbmZyYXN0cnVjdHVyZS4gQW5kIFNJUCBhcHBsaWNhdGlv biBjYW4gb25seSBmb2N1cyBvbiBzZXNzaW9uL2NhbGwgDQpjb250cm9sLiBGdXJ0aGVyLCBpZiB0 aGUgb3BlcmF0b3JzIHdhbnQgdG8gZGVwbG95IGEgbmV3IGFwcGxpY2F0aW9uIGJleW9uZCANClNJ UCwgdGhlIGluZnJhc3RydWN0dXJlIHdvdWxkIGJlIHJldXNhYmxlLg0KDQpUaGlzIGNvbmNlcHQg aXMgcmF3IG5vdywgc28gSSdkIGxpa2UgdG8gaGVhciBtb3JlIG9mIHlvdXIgY29tbWVudHMvZmVl bGluZyANCnRvIGxpZ2h0IGl0IHVwLg0KDQpSZWdhcmRzLA0KDQpHYW8NCg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIx MQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5j b20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQoiVHNjaG9m ZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykiIDxoYW5uZXMudHNjaG9mZW5pZ0Buc24uY29t PiANCjIwMTAtMDUtMDIgMjI6NTINCg0KytW8/sjLDQo8Z2FvLnlhbmcyQHp0ZS5jb20uY24+LCA8 ZGlzcGF0Y2hAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINClJFOiBbZGlzcGF0Y2hdIE9wZW4gdGFs ayBhbmQgaW52ZXN0aWdhdGlvbiBhYm91dCBISVAgYW5kIFNJUC9JTVMNCg0KDQoNCg0KDQoNCkhp IEdhbywgDQogDQpJIHJlYWQgdGhyb3VnaCB5b3VyIG1haWwgYSBjb3VwbGUgb2YgdGltZXMgYnV0 IEkgd2FzIG5vdCBxdWl0ZSBzdXJlIHRoYXQgSSANCnVuZGVyc3Rvb2QgeW91ciBsaW5lIG9mIHRo b3VnaHQuIA0KV2hlbiBzb21lb25lIGRvZXMgbm90IHdhbnQgdG8gdXNlIFNJUCAoYnV0IEhUVFAg aW5zdGVhZCkgdGhlbiBsZXQgdGhlbSBkby4gDQpUaGVyZSBzaG91bGRuJ3QgYmUgYW55IHByb2Js ZW0gd2l0aCB0aGF0LiANCg0KVGhlIFJBRElVUyBhbmQgRGlhbWV0ZXIgYmFzZWQgQXV0aGVudGlj YXRpb24sIEF1dGhvcml6YXRpb24sIGFuZCANCkFjY291bnRpbmcgKEFBQSkgaW5mcmFzdHJ1Y3R1 cmUgaXMgbm90IGFwcGxpY2F0aW9uIGluZGVwZW5kZW50LiBSQURJVVMgYW5kIA0KRGlhbWV0ZXIg aGF2ZSBsYXJnZWx5IGJlZW4gdXRpbGl6ZWQgZm9yIG5ldHdvcmsgYWNjZXNzIGF1dGhlbnRpY2F0 aW9uIGFuZCANCmZvciBhIGZldyBzZWxlY3RlZCBhcHBsaWNhdGlvbnMgYnV0IGhhdmUgbm90IGZv dW5kIHdpZGVzcHJlYWQgdXNhZ2UgZm9yIA0Kd2ViIGFwcGxpY2F0aW9ucy4gVGhlcmUgeW91IGZp bmQgb3RoZXIgcHJvdG9jb2xzIGJlaW5nIHVzZWQuIEFsc28gbm90IGEgDQpwcm9ibGVtIGFzIHN1 Y2ggZWl0aGVyLiANCg0KSGF2aW5nIHNhaWQgdGhhdCBJIGFtIG5vdCBzdXJlIGhvdyB5b3UgZHJh dyB0aGUgY29uY2x1c2lvbiB0aGF0IEhJUCBtaWdodCANCmJlIHRoZSByaWdodCBwcm90b2NvbCBn aXZlbiB0aGF0IGl0IGlzIG5vdCBhIEFBQSBwcm90b2NvbCBpbiB0aGUgZmlyc3QgDQpwbGFjZSBu b3IgcGFydGljdWxhcmx5IHdlbGwgYWxpZ25lZCB3aXRoIGFueSBvZiB0aGUgbWVudGlvbmVkIHBy b3RvY29scy4gDQoNCkkgcGVyc29uYWxseSBwcmVmZXIgdG8gc3RhcnQgd2l0aCBhIHByb2JsZW0g c3RhdGVtZW50IGZpcnN0IGFuZCB0aGVuIHRvIA0KZmlndXJlIG91dCB3aGV0aGVyIHBlb3BsZSBh Z3JlZSB3aXRoIGl0LiBTdWJzZXF1ZW50bHksIG9uZSBjYW4gYnJhaW5zdG9ybSANCmFib3V0IHRo ZSBhcHByb3ByaWF0ZSBwcm90b2NvbCB0aGF0IGFkZHJlc3NlcyB0aGUgZ2Fwcy4NCg0KQ2lhbw0K SGFubmVzDQogDQoNCkZyb206IGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaXNw YXRjaC1ib3VuY2VzQGlldGYub3JnXSBPbiANCkJlaGFsZiBPZiBleHQgZ2FvLnlhbmcyQHp0ZS5j b20uY24NClNlbnQ6IEZyaWRheSwgQXByaWwgMzAsIDIwMTAgNjo1NSBBTQ0KVG86IGRpc3BhdGNo QGlldGYub3JnDQpTdWJqZWN0OiBbZGlzcGF0Y2hdIE9wZW4gdGFsayBhbmQgaW52ZXN0aWdhdGlv biBhYm91dCBISVAgYW5kIFNJUC9JTVMNCg0KDQpIaSwgDQoNCkZvciBwZW9wbGUgY2FyaW5nIGFi b3V0IFNJUC9JTVMncyBuZXR3b3JrIG1hbmFnZW1lbnQgbGV2ZWwsIEkgdGhpbmsgb25lIA0KYXBw bGljYXRpb24gaW5kZXBlbmRlbmN5IEFBQSBpbmZyYXN0cnVjdHVyZSBpcyBmdXR1cmUgZGlyZWN0 aW9uIGZvciANClNJUC9JTVMuIEknZCBsaWtlIHRvIGtub3cgaG93IG1hbnkgcGVvcGxlIGhhdmUg dGhlIHNhbWUgaW50ZXJlc3Q/IElmIHlvdSANCmhhdmUgYW55IGNvbW1lbnRzL2ZlZWxpbmcvc3Vn Z2VzdGlvbiBmb3IgdGhpcyB0b3BpYywgZmVlbCBmcmVlIHRvIGdvIG9uLiANCg0KVGVsZWNvbSBD b3JlIE5ldHdvcmsgDQoNCklNUyhJUCBNdWx0aW1lZGlhIFN1YnN5c3RlbSkgaXMgYWltZWQgZm9y IHVuaWZpZWQgdXNlciBtYW5hZ2VtZW50LCB1bmlmaWVkIA0KYXV0aGVudGljYXRpb24sIHVuaWZp ZWQgcG9saWN5L2NoYXJnaW5nIGFuZCB1bmlmaWVkIHNlcnZpY2UgY29udHJvbCwgYnV0IA0KaXQg aXMgdGlnaHRseSBjb3VwbGVkIHdpdGggU0lQLiBXaGlsZSB0aGUgdGVsZWNvbSBjb3JlIG5ldHdv cmsgb3BlcmF0b3JzIA0Kd2FudCB0byBkZXBsb3kgYW55IG5vbi1zaXAgYXBwbGljYXRpb24sIHRo ZXkgZmluZCB0aGF0IHRoZSB1bmlmaWVkIA0KcGxhdGZvcm0oSU1TKSB3b3VsZCBub3QgYmUgc3Vp dGFibGUuICAgDQoNCldlIG1heSBjb25jbHVkZSBmcm9tIHRoZSBzaXR1YXRpb24gdGhhdCwgaWYg dGVsZWNvbSAoY29yZSBuZXR3b3JrKSANCm9wZXJhdG9ycyB3YW50IHRvIG1ha2Ugb25lIGluZnJh c3RydWN0dXJlKHVuaWZpZWQgdXNlciBtYW5hZ2VtZW50LCB1bmlmaWVkIA0KYXV0aGVudGljYXRp b24sIHVuaWZpZWQgcG9saWN5L2NoYXJnaW5nIGFuZCB1bmlmaWVkIHNlcnZpY2UgY29udHJvbCkg DQpzdWl0YWJsZSBmb3IgYW55IGFwcGxpY2F0aW9uKHNpcCBhbmQgbm9uLXNpcCksIHRoZXkgbmVl ZCBtYWtlIGFuIHNpcCANCmRlY291cGxpbmcgQUFBIGluZnJhc3RydWN0dXJlIGF0IGZpcnN0LiAN Cg0KTWFraW5nIElNUydzIEFBQSBiYXNlZCBvbiBISVAgYW5kIElNUydzIG11bHRpbWVkaWEgbGV2 ZWwgc3RpbGwgb24gc2lwLCANCndvdWxkIG1ha2UgSU1TJ3MgaW5mcmFzdHJ1Y3R1cmUgb3BlbiBm b3IgYW55IG90aGVyIHByb3RvY29sIGFuZCANCmFwcGxpY2F0aW9uLiBBbmQgaWYgdGhlIHRlbGVj b20gKGNvcmUgbmV0d29yaykgb3BlcmF0b3JzIHdhbnQgdG8gZW1icmFjZSANCm1vcmUgYW5kIG1v cmUgbm9uLXNpcCBhcHBsaWNhdGlvbiwgSElQIG1heSBiZSB0aGUgb25seSB3YXkuIA0KDQpNZWFu d2hpbGUsIENvdWxkIENvbXB1dGluZyBhbmQgZXZlbiBNMk0gbmV0d29yayBhbHNvIGNhbiBnZXQg YmVuZWZpdCBmcm9tIA0Kc3VjaCBhcHBsaWNhdGlvbiBpbmRlcGVuZGVuY3kgQUFBIGluZnJhc3Ry dWN0dXJlOiANCg0KQ2xvdWRpbmcgQ29tcHV0aW5nIA0KDQpTb21lIHN0YW5kYXJkIGNsb3VkL2dy aWQgY29tcHV0aW5nIHRlY2hub2xvZ3kgaXMgYmFzZWQgb24gV2ViLiBPbiB0aGUgd2ViIA0KcGxh dGZvcm0sIGl0IGlzIGVhc3kgdG8gYnVsaWQgb25lIEFBQSBpbmZyYXN0cnVjdHVyZSBhbmQgb3Bl biBmb3IgDQphcHBsaWFjdGlvbiBzdWNoIGFzIFNPQS4gQnV0IGlmIHdlIHdhbnQgdG8gYnVpbGQg d2ViIGFuZCBub24td2ViKHN1Y2ggYXMgDQpSQUkpIGFwcGxpY2F0aW9uIG9uIHRoZSBzYW1lIHBs YXRmb3JtLCB0aGVyZSdzIHRoZSBzYW1lIHByb2JsZW0gSU1TIGhhcy4gDQpTbywgaWYgSVQgaW5k dXN0cnkncyBjb3VsZCBjb21wdXRpbmcgd2FudCB0byBlbWJyYWNlIG5vbi13ZWIgYXBwbGljYXRp b24sIA0KSElQIG1heSBiZSB0aGUgc2FtZSB3YXkgYWdhaW4uIA0KDQpNMk0gTmV0d29yayANCk1h Y2hpbmUgdG8gbWFjaGluZSBuZXR3b3JrIGlzIGhvdCBub3cuIEJ1dCBpdCBhbHNvIG5lZWQgb25l IGFwcGxpY2F0aW9uIA0KaW5kZXBlbmRlbmN5IEFBQSBpbmZyYXN0cnVjdHVyZSBhcyBwbGF0Zm9y bSBmb3IgYWxsIHRoZSBjb25jZWl2YWJsZSANCmFwcGxpY2F0aW9uIHByb3RvY29scy4gSElQIGlz IHN0aWxsIGEgZ29vZCBjaG9pY2UgZm9yIGl0LiANCg0KVGhhbmtzLCANCg0KR2FvIA0KDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KWmlwICAgIDogMjEwMDEyDQpUZWwgICAg OiA4NzIxMQ0KVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCmVfbWFpbCA6IGdhby55YW5nMkB6 dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtYWlsIGlzIA0Kc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24u IFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0KY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5h bWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgDQphcmUgbm90 IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9u IHRvIA0Kb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGgg aXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiANCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBvZiANCnRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMg bWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIA0KaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IA0Kc3lzdGVtLg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNv bmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50 YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50 cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZp bGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBw bGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhw cmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVy Lg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkg WlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 000D83B848257719_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEhhbm5lcyw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciBy ZXNwb25zZSBzaW5jZXJlbHkgZmlyc3QuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5BQUEncyBrZXJuZWwgaXMgaWRlbnRpdHkuIE15IHByb3Bvc2FsDQpp cyB0aGF0IHVzaW5nIEhJUCdzIGlkZW50aXR5KHN1Y2ggYXMgSElUKSBhcyB0aGUga2VybmVsIG9m IEFBQS4gV2hpbGUgSElQDQpjYW4gYmUgdXNlZCBmb3IgYWxsIGtpbmRzIG9mIGFwcGxpY2F0aW9u IGxldmVsIHByb3RvY29sLCBzdWNoIGFzIFNJUCwgSFRUUA0KYW5kIHNvIG9uLCB0aGVuIHRoZSBB QUEgY2FuIGJlIHVzZWQgZm9yIG1vcmUgdGhhbiBvbmUgYXBwbGljYXRpb24gbGV2ZWwNCnByb3Rv Y29sLiBBbmQgaWYgb3BlcmF0b3JzIGRlcGxveSB0aGlzIGtpbmQgb2YgbmV0d29yaywgdGhleSBj YW4gdXNpbmcNCm9uZSBpbmZyYXN0cnVjdHVyZSBmb3IgbW9yZSB0aGFuIG9uZSBhcHBsaWNhdGlv bi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlVzaW5n IFNJUC9JTVMgYXMgZXhhbXBsZSwgdXNlciBtYW5hZ2VtZW50LA0KcmVnaXN0cmF0aW9uLCBhdXRo ZW50aWNhdGlvbiBhbmQgUENDKEF1dGhvcml6YXRpb24sIGFuZCBBY2NvdW50aW5nKSBjYW4NCmJl IGltcGxlbWVudGVkIGluIHRoZSBpbmZyYXN0cnVjdHVyZS4gQW5kIFNJUCBhcHBsaWNhdGlvbiBj YW4gb25seSBmb2N1cw0Kb24gc2Vzc2lvbi9jYWxsIGNvbnRyb2wuIEZ1cnRoZXIsIGlmIHRoZSBv cGVyYXRvcnMgd2FudCB0byBkZXBsb3kgYSBuZXcNCmFwcGxpY2F0aW9uIGJleW9uZCBTSVAsIHRo ZSBpbmZyYXN0cnVjdHVyZSB3b3VsZCBiZSByZXVzYWJsZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoaXMgY29uY2VwdCBpcyByYXcgbm93LCBzbyBJ J2QgbGlrZQ0KdG8gaGVhciBtb3JlIG9mIHlvdXIgY29tbWVudHMvZmVlbGluZyB0byBsaWdodCBp dCB1cC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJl Z2FyZHMsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5H YW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAy MTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDoo Kzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+ DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYl Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtUc2Nob2ZlbmlnLCBIYW5u ZXMNCihOU04gLSBGSS9Fc3BvbykmcXVvdDsgJmx0O2hhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb20m Z3Q7PC9iPiA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0w NS0wMiAyMjo1MjwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4mbHQ7Z2FvLnlhbmcyQHp0ZS5jb20uY24mZ3Q7LCAmbHQ7ZGlzcGF0Y2hAaWV0 Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5SRTogW2Rpc3BhdGNoXSBPcGVuIHRhbGsgYW5kIGludmVzdGlnYXRpb24NCmFi b3V0IEhJUCBhbmQgU0lQL0lNUzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5IaSBHYW8sIDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IkFyaWFsIj5JIHJlYWQgdGhyb3VnaCB5b3VyIG1haWwgYSBjb3VwbGUNCm9mIHRp bWVzIGJ1dCBJIHdhcyBub3QgcXVpdGUgc3VyZSB0aGF0IEkgdW5kZXJzdG9vZCB5b3VyIGxpbmUg b2YgdGhvdWdodC4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJB cmlhbCI+V2hlbiBzb21lb25lIGRvZXMgbm90IHdhbnQgdG8NCnVzZSBTSVAgKGJ1dCBIVFRQIGlu c3RlYWQpIHRoZW4gbGV0IHRoZW0gZG8uIFRoZXJlIHNob3VsZG4ndCBiZSBhbnkgcHJvYmxlbQ0K d2l0aCB0aGF0LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iQXJpYWwiPlRoZSBSQURJVVMgYW5kIERpYW1ldGVyIGJhc2VkDQpBdXRoZW50aWNhdGlvbiwg QXV0aG9yaXphdGlvbiwgYW5kIEFjY291bnRpbmcgKEFBQSkgaW5mcmFzdHJ1Y3R1cmUgaXMgbm90 DQphcHBsaWNhdGlvbiBpbmRlcGVuZGVudC4gUkFESVVTIGFuZCBEaWFtZXRlciBoYXZlIGxhcmdl bHkgYmVlbiB1dGlsaXplZA0KZm9yIG5ldHdvcmsgYWNjZXNzIGF1dGhlbnRpY2F0aW9uIGFuZCBm b3IgYSBmZXcgc2VsZWN0ZWQgYXBwbGljYXRpb25zIGJ1dA0KaGF2ZSBub3QgZm91bmQgd2lkZXNw cmVhZCB1c2FnZSBmb3Igd2ViIGFwcGxpY2F0aW9ucy4gVGhlcmUgeW91IGZpbmQgb3RoZXINCnBy b3RvY29scyBiZWluZyB1c2VkLiBBbHNvIG5vdCBhIHByb2JsZW0gYXMgc3VjaCBlaXRoZXIuIDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+SGF2 aW5nIHNhaWQgdGhhdCBJIGFtIG5vdCBzdXJlDQpob3cgeW91IGRyYXcgdGhlIGNvbmNsdXNpb24g dGhhdCBISVAgbWlnaHQgYmUgdGhlIHJpZ2h0IHByb3RvY29sIGdpdmVuDQp0aGF0IGl0IGlzIG5v dCBhIEFBQSBwcm90b2NvbCBpbiB0aGUgZmlyc3QgcGxhY2Ugbm9yIHBhcnRpY3VsYXJseSB3ZWxs DQphbGlnbmVkIHdpdGggYW55IG9mIHRoZSBtZW50aW9uZWQgcHJvdG9jb2xzLiA8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPkkgcGVyc29uYWxs eSBwcmVmZXIgdG8gc3RhcnQgd2l0aA0KYSBwcm9ibGVtIHN0YXRlbWVudCBmaXJzdCBhbmQgdGhl biB0byBmaWd1cmUgb3V0IHdoZXRoZXIgcGVvcGxlIGFncmVlIHdpdGgNCml0LiBTdWJzZXF1ZW50 bHksIG9uZSBjYW4gYnJhaW5zdG9ybSBhYm91dCB0aGUgYXBwcm9wcmlhdGUgcHJvdG9jb2wgdGhh dA0KYWRkcmVzc2VzIHRoZSBnYXBzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJBcmlhbCI+Q2lhbzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJBcmlhbCI+SGFubmVzPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8 L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8aHI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJv bTo8L2I+IGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaXNwYXRjaC1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5leHQgZ2FvLnlhbmcyQHp0ZS5jb20uY248 Yj48YnI+DQpTZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAzMCwgMjAxMCA2OjU1IEFNPGI+PGJyPg0K VG86PC9iPiBkaXNwYXRjaEBpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBbZGlzcGF0Y2hd IE9wZW4gdGFsayBhbmQgaW52ZXN0aWdhdGlvbiBhYm91dCBISVAgYW5kIFNJUC9JTVM8L2ZvbnQ+ PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+PGJyPg0KSGksPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpGb3IgcGVvcGxlIGNhcmluZyBhYm91dCBTSVAv SU1TJ3MgbmV0d29yayBtYW5hZ2VtZW50IGxldmVsLCBJIHRoaW5rIG9uZQ0KYXBwbGljYXRpb24g aW5kZXBlbmRlbmN5IEFBQSBpbmZyYXN0cnVjdHVyZSBpcyBmdXR1cmUgZGlyZWN0aW9uIGZvciBT SVAvSU1TLg0KSSdkIGxpa2UgdG8ga25vdyBob3cgbWFueSBwZW9wbGUgaGF2ZSB0aGUgc2FtZSBp bnRlcmVzdD8gSWYgeW91IGhhdmUgYW55DQpjb21tZW50cy9mZWVsaW5nL3N1Z2dlc3Rpb24gZm9y IHRoaXMgdG9waWMsIGZlZWwgZnJlZSB0byBnbyBvbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUZWxlY29tIENv cmUgTmV0d29yayA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KSU1TKElQIE11bHRpbWVkaWEgU3Vic3lzdGVtKSBpcyBh aW1lZCBmb3IgdW5pZmllZCB1c2VyIG1hbmFnZW1lbnQsIHVuaWZpZWQNCmF1dGhlbnRpY2F0aW9u LCB1bmlmaWVkIHBvbGljeS9jaGFyZ2luZyBhbmQgdW5pZmllZCBzZXJ2aWNlIGNvbnRyb2wsIGJ1 dA0KaXQgaXMgdGlnaHRseSBjb3VwbGVkIHdpdGggU0lQLiBXaGlsZSB0aGUgdGVsZWNvbSBjb3Jl IG5ldHdvcmsgb3BlcmF0b3JzDQp3YW50IHRvIGRlcGxveSBhbnkgbm9uLXNpcCBhcHBsaWNhdGlv biwgdGhleSBmaW5kIHRoYXQgdGhlIHVuaWZpZWQgcGxhdGZvcm0oSU1TKQ0Kd291bGQgbm90IGJl IHN1aXRhYmxlLiAmbmJzcDsgPC9mb250Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCldlIG1heSBjb25jbHVkZSBmcm9tIHRoZSBz aXR1YXRpb24gdGhhdCwgaWYgdGVsZWNvbSAoY29yZSBuZXR3b3JrKSBvcGVyYXRvcnMNCndhbnQg dG8gbWFrZSBvbmUgaW5mcmFzdHJ1Y3R1cmUodW5pZmllZCB1c2VyIG1hbmFnZW1lbnQsIHVuaWZp ZWQgYXV0aGVudGljYXRpb24sDQp1bmlmaWVkIHBvbGljeS9jaGFyZ2luZyBhbmQgdW5pZmllZCBz ZXJ2aWNlIGNvbnRyb2wpIHN1aXRhYmxlIGZvciBhbnkgYXBwbGljYXRpb24oc2lwDQphbmQgbm9u LXNpcCksIHRoZXkgbmVlZCBtYWtlIGFuIHNpcCBkZWNvdXBsaW5nIEFBQSBpbmZyYXN0cnVjdHVy ZSBhdCBmaXJzdC4NCjwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpNYWtpbmcgSU1TJ3MgQUFBIGJhc2VkIG9uIEhJUCBh bmQgSU1TJ3MgbXVsdGltZWRpYSBsZXZlbCBzdGlsbCBvbiBzaXAsDQp3b3VsZCBtYWtlIElNUydz IGluZnJhc3RydWN0dXJlIG9wZW4gZm9yIGFueSBvdGhlciBwcm90b2NvbCBhbmQgYXBwbGljYXRp b24uDQpBbmQgaWYgdGhlIHRlbGVjb20gKGNvcmUgbmV0d29yaykgb3BlcmF0b3JzIHdhbnQgdG8g ZW1icmFjZSBtb3JlIGFuZCBtb3JlDQpub24tc2lwIGFwcGxpY2F0aW9uLCBISVAgbWF5IGJlIHRo ZSBvbmx5IHdheS4gPC9mb250Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPjxiPjxicj4NCk1lYW53aGlsZSwgQ291bGQgQ29tcHV0aW5nIGFu ZCBldmVuIE0yTSBuZXR3b3JrIGFsc28gY2FuIGdldCBiZW5lZml0IGZyb20NCnN1Y2ggYXBwbGlj YXRpb24gaW5kZXBlbmRlbmN5IEFBQSBpbmZyYXN0cnVjdHVyZTo8L2I+PC9mb250Pjxmb250IHNp emU9Mz4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K Q2xvdWRpbmcgQ29tcHV0aW5nIDwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpTb21lIHN0YW5kYXJkIGNsb3VkL2dyaWQg Y29tcHV0aW5nIHRlY2hub2xvZ3kgaXMgYmFzZWQgb24gV2ViLiBPbiB0aGUgd2ViDQpwbGF0Zm9y bSwgaXQgaXMgZWFzeSB0byBidWxpZCBvbmUgQUFBIGluZnJhc3RydWN0dXJlIGFuZCBvcGVuIGZv ciBhcHBsaWFjdGlvbg0Kc3VjaCBhcyBTT0EuIEJ1dCBpZiB3ZSB3YW50IHRvIGJ1aWxkIHdlYiBh bmQgbm9uLXdlYihzdWNoIGFzIFJBSSkgYXBwbGljYXRpb24NCm9uIHRoZSBzYW1lIHBsYXRmb3Jt LCB0aGVyZSdzIHRoZSBzYW1lIHByb2JsZW0gSU1TIGhhcy4gPGJyPg0KU28sIGlmIElUIGluZHVz dHJ5J3MgY291bGQgY29tcHV0aW5nIHdhbnQgdG8gZW1icmFjZSBub24td2ViIGFwcGxpY2F0aW9u LA0KSElQIG1heSBiZSB0aGUgc2FtZSB3YXkgYWdhaW4uPC9mb250Pjxmb250IHNpemU9Mz4gPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpNMk0gTmV0d29y azwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KTWFjaGluZSB0byBtYWNoaW5lIG5ldHdvcmsgaXMgaG90IG5vdy4gQnV0IGl0IGFs c28gbmVlZCBvbmUgYXBwbGljYXRpb24NCmluZGVwZW5kZW5jeSBBQUEgaW5mcmFzdHJ1Y3R1cmUg YXMgcGxhdGZvcm0gZm9yIGFsbCB0aGUgY29uY2VpdmFibGUgYXBwbGljYXRpb24NCnByb3RvY29s cy4gSElQIGlzIHN0aWxsIGEgZ29vZCBjaG9pY2UgZm9yIGl0LjwvZm9udD48Zm9udCBzaXplPTM+ IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KVGhhbmtz LDwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KR2FvPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PTxicj4NClppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQpUZWwgJm5ic3A7 ICZuYnNwOzogODcyMTE8YnI+DQpUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0K ZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PTwvZm9udD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0zPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWlRFIEluZm9y bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IG1haWwNCmlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBU aGlzIG1haWwgY29tbXVuaWNhdGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVk IGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVy bWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8N Cm90aGVycy48YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBp dCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBvZg0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNz YWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NClRoaXMgbWVzc2Fn ZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0g c3lzdGVtLjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5m b3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1h dGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZu YnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZu YnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24m bmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJz cDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJz cDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7 dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlz Jm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWls Jm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgm bmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVk Jm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJz cDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2 ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZu YnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZu YnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQm bmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2Fn ZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZu YnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5 c3RlbS4NCjwvcHJlPg== --=_alternative 000D83B848257719_=-- From tom111.taylor@bell.net Mon May 3 19:58:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824583A6B9F for ; Mon, 3 May 2010 19:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.104 X-Spam-Level: * X-Spam-Status: No, score=1.104 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_84=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-1PvT2vu-aI for ; Mon, 3 May 2010 19:58:47 -0700 (PDT) Received: from blu0-omc4-s32.blu0.hotmail.com (blu0-omc4-s32.blu0.hotmail.com [65.55.111.171]) by core3.amsl.com (Postfix) with ESMTP id B22303A68CC for ; Mon, 3 May 2010 19:58:47 -0700 (PDT) Received: from BLU0-SMTP65 ([65.55.111.136]) by blu0-omc4-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 May 2010 19:58:33 -0700 X-Originating-IP: [70.26.23.183] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.23.183]) by BLU0-SMTP65.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 May 2010 19:58:33 -0700 Date: Mon, 03 May 2010 22:58:30 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2010 02:58:33.0300 (UTC) FILETIME=[AEDD1940:01CAEB35] Cc: dispatch@ietf.org Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 02:58:48 -0000 By using HIT, you are equating the subscription with the device rather than the user. How well would that work if the user transferred a SIM card from one device to another? gao.yang2@zte.com.cn wrote: > Hi Hannes, > > Thanks for your response sincerely first. > > AAA's kernel is identity. My proposal is that using HIP's identity(such as > HIT) as the kernel of AAA. While HIP can be used for all kinds of > application level protocol, such as SIP, HTTP and so on, then the AAA can > be used for more than one application level protocol. And if operators > deploy this kind of network, they can using one infrastructure for more > than one application. > > Using SIP/IMS as example, user management, registration, authentication > and PCC(Authorization, and Accounting) can be implemented in the > infrastructure. And SIP application can only focus on session/call > control. Further, if the operators want to deploy a new application beyond > SIP, the infrastructure would be reusable. > > This concept is raw now, so I'd like to hear more of your comments/feeling > to light it up. > > Regards, > > Gao > ... From gao.yang2@zte.com.cn Mon May 3 20:22:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6026C3A6851 for ; Mon, 3 May 2010 20:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.687 X-Spam-Level: X-Spam-Status: No, score=-95.687 tagged_above=-999 required=5 tests=[AWL=-1.252, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YIYnAWb6uhW for ; Mon, 3 May 2010 20:22:20 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 599763A6B83 for ; Mon, 3 May 2010 20:22:18 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 58071992332426; Tue, 4 May 2010 11:18:14 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 6793.2222905167; Tue, 4 May 2010 11:21:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o443Lsp3077081; Tue, 4 May 2010 11:21:54 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Tom Taylor MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 4 May 2010 11:19:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-04 11:21:49, Serialize complete at 2010-05-04 11:21:49 Content-Type: multipart/alternative; boundary="=_alternative 0012729F48257719_=" X-MAIL: mse2.zte.com.cn o443Lsp3077081 Cc: dispatch@ietf.org Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 03:22:23 -0000 This is a multipart message in MIME format. --=_alternative 0012729F48257719_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgVG9tLA0KDQpDb25zaWRlcmluZyBTSU0gY2FyZCwgSSBzdWdnZXN0IFNJTSBjYXJkIGl0c2Vs ZiBoYXMgSElULCB3aGlsZSBub3QgdGhlIA0KcGhvbmUuDQoNCkFuZCBmdXJ0aGVyLCB1c2UgSElQ L0hJVCBhcyBWUE4tbGlrZSB0aGluZy4gVXNlciByZWdpc3RlciBieSBzb2Z0d2FyZSwgYW5kIA0K dGhlbiBnZXQgYSB2aXJ0dWFsIG5ldHdvcmsgZXN0YWJsaXNoZWQgYnkgSElQLiBBbmQgdXBvbiB0 aGlzIHZpcnR1YWwgDQpuZXR3b3JrLCBhbnkgYXBwbGljYXRpb24gcnVuIG9uIGl0IGlzIHNlY3Vy ZSBhbmQgbW9iaWxpdHksIGFuZCANCm1hbmFnZWFibGUoZnJvbSBvcGVyYXRvcnMnIHBlcnNwZWN0 aXZlKS4gVGhpcyB3b3VsZCBiZSBtb3JlIGNvbnZlbmllbmNlIA0KZm9yIHVzZXJzLiBBbmQgb3Bl cmF0b3JzIGNhbiB1c2UgVVNCIGRpZ2l0YWwgY3JlZGVudGlhbCBhcyBISVQgdG8gaW1wcm92ZSAN CnNlY3VyaXR5LiANCg0KVGVjaG5pY2FsbHksIEkgcHJvcG9zZSB1c2luZyBISVQgYXMgYW4gYXBw bGljYXRpb24taW5kZXBlbmRlbnQgaWRlbnRpdHkuIA0KQW5kIHRoZSBISVQgY2FuIGJpbmRpbmcg d2l0aCB2aXJ0dWFsIGhvc3QvbWFjaGluZS90aGluZy4NCg0KVGhhbmtzLA0KDQpHYW8NCiANCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVs ICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55 YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoN Cg0KVG9tIFRheWxvciA8dG9tMTExLnRheWxvckBiZWxsLm5ldD4gDQoyMDEwLTA1LTA0IDEwOjU4 DQoNCsrVvP7Iyw0KZ2FvLnlhbmcyQHp0ZS5jb20uY24NCrOty80NCiJUc2Nob2ZlbmlnLCBIYW5u ZXMgKE5TTiAtIEZJL0VzcG9vKSIgPGhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb20+LCANCmRpc3Bh dGNoQGlldGYub3JnDQrW98ziDQpSZTogW2Rpc3BhdGNoXSBPcGVuIHRhbGsgYW5kIGludmVzdGln YXRpb24gYWJvdXQgSElQIGFuZCBTSVAvSU1TDQoNCg0KDQoNCg0KDQpCeSB1c2luZyBISVQsIHlv dSBhcmUgZXF1YXRpbmcgdGhlIHN1YnNjcmlwdGlvbiB3aXRoIHRoZSBkZXZpY2UgcmF0aGVyIA0K dGhhbiB0aGUNCnVzZXIuIEhvdyB3ZWxsIHdvdWxkIHRoYXQgd29yayBpZiB0aGUgdXNlciB0cmFu c2ZlcnJlZCBhIFNJTSBjYXJkIGZyb20gb25lDQpkZXZpY2UgdG8gYW5vdGhlcj8NCg0KZ2FvLnlh bmcyQHp0ZS5jb20uY24gd3JvdGU6DQo+IEhpIEhhbm5lcywNCj4gDQo+IFRoYW5rcyBmb3IgeW91 ciByZXNwb25zZSBzaW5jZXJlbHkgZmlyc3QuDQo+IA0KPiBBQUEncyBrZXJuZWwgaXMgaWRlbnRp dHkuIE15IHByb3Bvc2FsIGlzIHRoYXQgdXNpbmcgSElQJ3MgaWRlbnRpdHkoc3VjaCANCmFzIA0K PiBISVQpIGFzIHRoZSBrZXJuZWwgb2YgQUFBLiBXaGlsZSBISVAgY2FuIGJlIHVzZWQgZm9yIGFs bCBraW5kcyBvZiANCj4gYXBwbGljYXRpb24gbGV2ZWwgcHJvdG9jb2wsIHN1Y2ggYXMgU0lQLCBI VFRQIGFuZCBzbyBvbiwgdGhlbiB0aGUgQUFBIA0KY2FuIA0KPiBiZSB1c2VkIGZvciBtb3JlIHRo YW4gb25lIGFwcGxpY2F0aW9uIGxldmVsIHByb3RvY29sLiBBbmQgaWYgb3BlcmF0b3JzIA0KPiBk ZXBsb3kgdGhpcyBraW5kIG9mIG5ldHdvcmssIHRoZXkgY2FuIHVzaW5nIG9uZSBpbmZyYXN0cnVj dHVyZSBmb3IgbW9yZSANCj4gdGhhbiBvbmUgYXBwbGljYXRpb24uDQo+IA0KPiBVc2luZyBTSVAv SU1TIGFzIGV4YW1wbGUsIHVzZXIgbWFuYWdlbWVudCwgcmVnaXN0cmF0aW9uLCBhdXRoZW50aWNh dGlvbiANCj4gYW5kIFBDQyhBdXRob3JpemF0aW9uLCBhbmQgQWNjb3VudGluZykgY2FuIGJlIGlt cGxlbWVudGVkIGluIHRoZSANCj4gaW5mcmFzdHJ1Y3R1cmUuIEFuZCBTSVAgYXBwbGljYXRpb24g Y2FuIG9ubHkgZm9jdXMgb24gc2Vzc2lvbi9jYWxsIA0KPiBjb250cm9sLiBGdXJ0aGVyLCBpZiB0 aGUgb3BlcmF0b3JzIHdhbnQgdG8gZGVwbG95IGEgbmV3IGFwcGxpY2F0aW9uIA0KYmV5b25kIA0K PiBTSVAsIHRoZSBpbmZyYXN0cnVjdHVyZSB3b3VsZCBiZSByZXVzYWJsZS4NCj4gDQo+IFRoaXMg Y29uY2VwdCBpcyByYXcgbm93LCBzbyBJJ2QgbGlrZSB0byBoZWFyIG1vcmUgb2YgeW91ciANCmNv bW1lbnRzL2ZlZWxpbmcgDQo+IHRvIGxpZ2h0IGl0IHVwLg0KPiANCj4gUmVnYXJkcywNCj4gDQo+ IEdhbw0KPiANCi4uLg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24g aXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8g bWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNv bnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBh bnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20g dGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3 cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBz ZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3Bh bSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0012729F48257719_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFRvbSw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNvbnNpZGVyaW5nIFNJTSBjYXJk LCBJIHN1Z2dlc3QgU0lNDQpjYXJkIGl0c2VsZiBoYXMgSElULCB3aGlsZSBub3QgdGhlIHBob25l LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW5kIGZ1 cnRoZXIsIHVzZSBISVAvSElUIGFzIFZQTi1saWtlDQp0aGluZy4gVXNlciByZWdpc3RlciBieSBz b2Z0d2FyZSwgYW5kIHRoZW4gZ2V0IGEgdmlydHVhbCBuZXR3b3JrIGVzdGFibGlzaGVkDQpieSBI SVAuIEFuZCB1cG9uIHRoaXMgdmlydHVhbCBuZXR3b3JrLCBhbnkgYXBwbGljYXRpb24gcnVuIG9u IGl0IGlzIHNlY3VyZQ0KYW5kIG1vYmlsaXR5LCBhbmQgbWFuYWdlYWJsZShmcm9tIG9wZXJhdG9y cycgcGVyc3BlY3RpdmUpLiBUaGlzIHdvdWxkIGJlDQptb3JlIGNvbnZlbmllbmNlIGZvciB1c2Vy cy4gQW5kIG9wZXJhdG9ycyBjYW4gdXNlIFVTQiBkaWdpdGFsIGNyZWRlbnRpYWwNCmFzIEhJVCB0 byBpbXByb3ZlIHNlY3VyaXR5LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlRlY2huaWNhbGx5LCBJIHByb3Bvc2UgdXNpbmcgSElUIGFzDQphbiBhcHBs aWNhdGlvbi1pbmRlcGVuZGVudCBpZGVudGl0eS4gQW5kIHRoZSBISVQgY2FuIGJpbmRpbmcgd2l0 aCB2aXJ0dWFsDQpob3N0L21hY2hpbmUvdGhpbmcuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQogWmlwICZuYnNw OyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQogVGVs MiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21haWwgOiBnYW8ueWFuZzJAenRl LmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlRvbSBUYXlsb3Ig Jmx0O3RvbTExMS50YXlsb3JAYmVsbC5uZXQmZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDUtMDQgMTA6NTg8L2ZvbnQ+DQo8dGQgd2lkdGg9 NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Z2FvLnlhbmcyQHp0ZS5jb20u Y248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O1RzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkv RXNwb28pJnF1b3Q7DQombHQ7aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbSZndDssIGRpc3BhdGNo QGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW2Rpc3BhdGNoXSBPcGVuIHRhbGsgYW5k IGludmVzdGlnYXRpb24NCmFib3V0IEhJUCBhbmQgU0lQL0lNUzwvZm9udD48L3RhYmxlPg0KPGJy Pg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3Rh YmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QnkgdXNpbmcgSElULCB5b3Ug YXJlIGVxdWF0aW5nIHRoZSBzdWJzY3JpcHRpb24gd2l0aA0KdGhlIGRldmljZSByYXRoZXIgdGhh biB0aGU8YnI+DQp1c2VyLiBIb3cgd2VsbCB3b3VsZCB0aGF0IHdvcmsgaWYgdGhlIHVzZXIgdHJh bnNmZXJyZWQgYSBTSU0gY2FyZCBmcm9tDQpvbmU8YnI+DQpkZXZpY2UgdG8gYW5vdGhlcj88YnI+ DQo8YnI+DQpnYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7IEhpIEhhbm5lcyw8 YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlIHNpbmNlcmVseSBm aXJzdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgQUFBJ3Mga2VybmVsIGlzIGlkZW50aXR5LiBNeSBw cm9wb3NhbCBpcyB0aGF0IHVzaW5nIEhJUCdzIGlkZW50aXR5KHN1Y2gNCmFzIDxicj4NCiZndDsg SElUKSBhcyB0aGUga2VybmVsIG9mIEFBQS4gV2hpbGUgSElQIGNhbiBiZSB1c2VkIGZvciBhbGwg a2luZHMgb2YNCjxicj4NCiZndDsgYXBwbGljYXRpb24gbGV2ZWwgcHJvdG9jb2wsIHN1Y2ggYXMg U0lQLCBIVFRQIGFuZCBzbyBvbiwgdGhlbiB0aGUNCkFBQSBjYW4gPGJyPg0KJmd0OyBiZSB1c2Vk IGZvciBtb3JlIHRoYW4gb25lIGFwcGxpY2F0aW9uIGxldmVsIHByb3RvY29sLiBBbmQgaWYgb3Bl cmF0b3JzDQo8YnI+DQomZ3Q7IGRlcGxveSB0aGlzIGtpbmQgb2YgbmV0d29yaywgdGhleSBjYW4g dXNpbmcgb25lIGluZnJhc3RydWN0dXJlIGZvcg0KbW9yZSA8YnI+DQomZ3Q7IHRoYW4gb25lIGFw cGxpY2F0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBVc2luZyBTSVAvSU1TIGFzIGV4YW1wbGUs IHVzZXIgbWFuYWdlbWVudCwgcmVnaXN0cmF0aW9uLCBhdXRoZW50aWNhdGlvbg0KPGJyPg0KJmd0 OyBhbmQgUENDKEF1dGhvcml6YXRpb24sIGFuZCBBY2NvdW50aW5nKSBjYW4gYmUgaW1wbGVtZW50 ZWQgaW4gdGhlIDxicj4NCiZndDsgaW5mcmFzdHJ1Y3R1cmUuIEFuZCBTSVAgYXBwbGljYXRpb24g Y2FuIG9ubHkgZm9jdXMgb24gc2Vzc2lvbi9jYWxsDQo8YnI+DQomZ3Q7IGNvbnRyb2wuIEZ1cnRo ZXIsIGlmIHRoZSBvcGVyYXRvcnMgd2FudCB0byBkZXBsb3kgYSBuZXcgYXBwbGljYXRpb24NCmJl eW9uZCA8YnI+DQomZ3Q7IFNJUCwgdGhlIGluZnJhc3RydWN0dXJlIHdvdWxkIGJlIHJldXNhYmxl Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIGNvbmNlcHQgaXMgcmF3IG5vdywgc28gSSdkIGxp a2UgdG8gaGVhciBtb3JlIG9mIHlvdXIgY29tbWVudHMvZmVlbGluZw0KPGJyPg0KJmd0OyB0byBs aWdodCBpdCB1cC48YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7IDxicj4N CiZndDsgR2FvPGJyPg0KJmd0OyA8YnI+DQouLi48YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxi cj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtO b3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZu YnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5i c3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0 ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZu YnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJz cDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZu YnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVz Jm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRl bnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3Ro ZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7 ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3Nl ZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJz cDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0 aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0Fu eSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2Fn ZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nh bm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJz cDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0012729F48257719_=-- From gao.yang2@zte.com.cn Mon May 3 20:30:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91183A68CD for ; Mon, 3 May 2010 20:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.927 X-Spam-Level: X-Spam-Status: No, score=-95.927 tagged_above=-999 required=5 tests=[AWL=-1.492, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE85TuVAlF3x for ; Mon, 3 May 2010 20:30:32 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id A7D2C3A67FC for ; Mon, 3 May 2010 20:30:31 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 36887992332426; Tue, 4 May 2010 11:25:40 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 43572.2222905167; Tue, 4 May 2010 11:25:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o443TpRo090518; Tue, 4 May 2010 11:29:51 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: Tom Taylor MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 4 May 2010 11:27:34 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-04 11:29:45, Serialize complete at 2010-05-04 11:29:45 Content-Type: multipart/alternative; boundary="=_alternative 00132D0848257719_=" X-MAIL: mse2.zte.com.cn o443TpRo090518 Cc: dispatch@ietf.org Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 03:30:35 -0000 This is a multipart message in MIME format. --=_alternative 00132D0848257719_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgVG9tLA0KDQpUaGlzIGlzIGp1c3QgbXkgZmVlbGluZy4gQW5kIHRoZSB3aG9sZSBwcm9wb3Nh bCBpcyByYXcgbm93LCBhbmQgSSBhbSBub3QgDQpnb2luZyB0byBkZXNpZ24gYWxsIGFzcGVjdCBv ZiB0aGUgcHJvcG9zYWwgYWxvbmUuIFNvLCBhbnkgDQpyZWZpbmluZy9zdWdnZXN0aW9uIGZvciBh bnkgYXNwZWN0IGlzIHdlbGNvbWUuDQoNClRoYW5rcyBmb3IgeW91ciByZXNwb25zZSwgYWdhaW4u DQoNCkdhbw0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6 IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBl X21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCi0tLS0tINeqt6LIyyBHYW9ZYW5nMTQwMTk3L3VzZXIvenRlX2x0ZCDKsbzkIDIw MTAtMDUtMDQgMTE6MjMgLS0tLS0NCg0KR2FvWWFuZzE0MDE5Ny91c2VyL3p0ZV9sdGQNCjIwMTAt MDUtMDQgMTE6MTkNCg0KytW8/sjLDQpUb20gVGF5bG9yIDx0b20xMTEudGF5bG9yQGJlbGwubmV0 Pg0Ks63LzQ0KZGlzcGF0Y2hAaWV0Zi5vcmcsICJUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJ L0VzcG9vKSIgDQo8aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbT4NCtb3zOINClJlOiBbZGlzcGF0 Y2hdIE9wZW4gdGFsayBhbmQgaW52ZXN0aWdhdGlvbiBhYm91dCBISVAgYW5kIFNJUC9JTVMNCg0K DQoNCg0KDQoNCkhpIFRvbSwNCg0KQ29uc2lkZXJpbmcgU0lNIGNhcmQsIEkgc3VnZ2VzdCBTSU0g Y2FyZCBpdHNlbGYgaGFzIEhJVCwgd2hpbGUgbm90IHRoZSANCnBob25lLg0KDQpBbmQgZnVydGhl ciwgdXNlIEhJUC9ISVQgYXMgVlBOLWxpa2UgdGhpbmcuIFVzZXIgcmVnaXN0ZXIgYnkgc29mdHdh cmUsIGFuZCANCnRoZW4gZ2V0IGEgdmlydHVhbCBuZXR3b3JrIGVzdGFibGlzaGVkIGJ5IEhJUC4g QW5kIHVwb24gdGhpcyB2aXJ0dWFsIA0KbmV0d29yaywgYW55IGFwcGxpY2F0aW9uIHJ1biBvbiBp dCBpcyBzZWN1cmUgYW5kIG1vYmlsaXR5LCBhbmQgDQptYW5hZ2VhYmxlKGZyb20gb3BlcmF0b3Jz JyBwZXJzcGVjdGl2ZSkuIFRoaXMgd291bGQgYmUgbW9yZSBjb252ZW5pZW5jZSANCmZvciB1c2Vy cy4gQW5kIG9wZXJhdG9ycyBjYW4gdXNlIFVTQiBkaWdpdGFsIGNyZWRlbnRpYWwgYXMgSElUIHRv IGltcHJvdmUgDQpzZWN1cml0eS4gDQoNClRlY2huaWNhbGx5LCBJIHByb3Bvc2UgdXNpbmcgSElU IGFzIGFuIGFwcGxpY2F0aW9uLWluZGVwZW5kZW50IGlkZW50aXR5LiANCkFuZCB0aGUgSElUIGNh biBiaW5kaW5nIHdpdGggdmlydHVhbCBob3N0L21hY2hpbmUvdGhpbmcuDQoNClRoYW5rcywNCg0K R2FvDQogDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIx MDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21h aWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCg0KDQoNClRvbSBUYXlsb3IgPHRvbTExMS50YXlsb3JAYmVsbC5uZXQ+IA0KMjAxMC0w NS0wNCAxMDo1OA0KDQrK1bz+yMsNCmdhby55YW5nMkB6dGUuY29tLmNuDQqzrcvNDQoiVHNjaG9m ZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykiIDxoYW5uZXMudHNjaG9mZW5pZ0Buc24uY29t PiwgDQpkaXNwYXRjaEBpZXRmLm9yZw0K1vfM4g0KUmU6IFtkaXNwYXRjaF0gT3BlbiB0YWxrIGFu ZCBpbnZlc3RpZ2F0aW9uIGFib3V0IEhJUCBhbmQgU0lQL0lNUw0KDQoNCg0KDQoNCg0KQnkgdXNp bmcgSElULCB5b3UgYXJlIGVxdWF0aW5nIHRoZSBzdWJzY3JpcHRpb24gd2l0aCB0aGUgZGV2aWNl IHJhdGhlciANCnRoYW4gdGhlDQp1c2VyLiBIb3cgd2VsbCB3b3VsZCB0aGF0IHdvcmsgaWYgdGhl IHVzZXIgdHJhbnNmZXJyZWQgYSBTSU0gY2FyZCBmcm9tIG9uZQ0KZGV2aWNlIHRvIGFub3RoZXI/ DQoNCmdhby55YW5nMkB6dGUuY29tLmNuIHdyb3RlOg0KPiBIaSBIYW5uZXMsDQo+IA0KPiBUaGFu a3MgZm9yIHlvdXIgcmVzcG9uc2Ugc2luY2VyZWx5IGZpcnN0Lg0KPiANCj4gQUFBJ3Mga2VybmVs IGlzIGlkZW50aXR5LiBNeSBwcm9wb3NhbCBpcyB0aGF0IHVzaW5nIEhJUCdzIGlkZW50aXR5KHN1 Y2ggDQphcyANCj4gSElUKSBhcyB0aGUga2VybmVsIG9mIEFBQS4gV2hpbGUgSElQIGNhbiBiZSB1 c2VkIGZvciBhbGwga2luZHMgb2YgDQo+IGFwcGxpY2F0aW9uIGxldmVsIHByb3RvY29sLCBzdWNo IGFzIFNJUCwgSFRUUCBhbmQgc28gb24sIHRoZW4gdGhlIEFBQSANCmNhbiANCj4gYmUgdXNlZCBm b3IgbW9yZSB0aGFuIG9uZSBhcHBsaWNhdGlvbiBsZXZlbCBwcm90b2NvbC4gQW5kIGlmIG9wZXJh dG9ycyANCj4gZGVwbG95IHRoaXMga2luZCBvZiBuZXR3b3JrLCB0aGV5IGNhbiB1c2luZyBvbmUg aW5mcmFzdHJ1Y3R1cmUgZm9yIG1vcmUgDQo+IHRoYW4gb25lIGFwcGxpY2F0aW9uLg0KPiANCj4g VXNpbmcgU0lQL0lNUyBhcyBleGFtcGxlLCB1c2VyIG1hbmFnZW1lbnQsIHJlZ2lzdHJhdGlvbiwg YXV0aGVudGljYXRpb24gDQo+IGFuZCBQQ0MoQXV0aG9yaXphdGlvbiwgYW5kIEFjY291bnRpbmcp IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiB0aGUgDQo+IGluZnJhc3RydWN0dXJlLiBBbmQgU0lQIGFw cGxpY2F0aW9uIGNhbiBvbmx5IGZvY3VzIG9uIHNlc3Npb24vY2FsbCANCj4gY29udHJvbC4gRnVy dGhlciwgaWYgdGhlIG9wZXJhdG9ycyB3YW50IHRvIGRlcGxveSBhIG5ldyBhcHBsaWNhdGlvbiAN CmJleW9uZCANCj4gU0lQLCB0aGUgaW5mcmFzdHJ1Y3R1cmUgd291bGQgYmUgcmV1c2FibGUuDQo+ IA0KPiBUaGlzIGNvbmNlcHQgaXMgcmF3IG5vdywgc28gSSdkIGxpa2UgdG8gaGVhciBtb3JlIG9m IHlvdXIgDQpjb21tZW50cy9mZWVsaW5nIA0KPiB0byBsaWdodCBpdCB1cC4NCj4gDQo+IFJlZ2Fy ZHMsDQo+IA0KPiBHYW8NCj4gDQouLi4NCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29s ZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21t dW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2Js aWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Ns b3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBl bWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBh bmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0 eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdl LiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGlu ZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVz ZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 00132D0848257719_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFRvbSw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoaXMgaXMganVzdCBteSBmZWVs aW5nLiBBbmQgdGhlIHdob2xlDQpwcm9wb3NhbCBpcyByYXcgbm93LCBhbmQgSSBhbSBub3QgZ29p bmcgdG8gZGVzaWduIGFsbCBhc3BlY3Qgb2YgdGhlIHByb3Bvc2FsDQphbG9uZS4gU28sIGFueSBy ZWZpbmluZy9zdWdnZXN0aW9uIGZvciBhbnkgYXNwZWN0IGlzIHdlbGNvbWUuPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHlvdXIgcmVz cG9uc2UsIGFnYWluLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZu YnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZu YnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29t LmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM4MDAwODAgZmFjZT0ic2Fucy1zZXJpZiI+LS0tLS0g16q3osjL IEdhb1lhbmcxNDAxOTcvdXNlci96dGVfbHRkDQrKsbzkIDIwMTAtMDUtMDQgMTE6MjMgLS0tLS08 L2ZvbnQ+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTQwJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+R2FvWWFuZzE0MDE5Ny91 c2VyL3p0ZV9sdGQ8L2I+PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PjIwMTAtMDUtMDQgMTE6MTk8L2ZvbnQ+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+VG9tIFRheWxvciAmbHQ7dG9tMTExLnRheWxvckBiZWxsLm5ldCZn dDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmRpc3BhdGNoQGlldGYub3JnLCAmcXVvdDtUc2Nob2Zlbmln LA0KSGFubmVzIChOU04gLSBGSS9Fc3BvbykmcXVvdDsgJmx0O2hhbm5lcy50c2Nob2ZlbmlnQG5z bi5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW2Rpc3BhdGNoXSBPcGVuIHRhbGsgYW5k IGludmVzdGlnYXRpb24NCmFib3V0IEhJUCBhbmQgU0lQL0lNUzwvZm9udD48YSBocmVmPU5vdGVz Oi8vTkpNQUlMMDEvNDgyNTcxNjkwMDJERjhFRS9EQUJBOTc1QjlGQjExM0VCODUyNTY0QjUwMDEy ODNFQS8yRjIxMEM0MDc0NTRGQzlCNDgyNTc3MTkwMDEwMkFDOD7BtL3TPC9hPjwvdGFibGU+DQo8 YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhp IFRvbSw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNv bnNpZGVyaW5nIFNJTSBjYXJkLCBJIHN1Z2dlc3QgU0lNDQpjYXJkIGl0c2VsZiBoYXMgSElULCB3 aGlsZSBub3QgdGhlIHBob25lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+QW5kIGZ1cnRoZXIsIHVzZSBISVAvSElUIGFzIFZQTi1saWtlDQp0aGluZy4g VXNlciByZWdpc3RlciBieSBzb2Z0d2FyZSwgYW5kIHRoZW4gZ2V0IGEgdmlydHVhbCBuZXR3b3Jr IGVzdGFibGlzaGVkDQpieSBISVAuIEFuZCB1cG9uIHRoaXMgdmlydHVhbCBuZXR3b3JrLCBhbnkg YXBwbGljYXRpb24gcnVuIG9uIGl0IGlzIHNlY3VyZQ0KYW5kIG1vYmlsaXR5LCBhbmQgbWFuYWdl YWJsZShmcm9tIG9wZXJhdG9ycycgcGVyc3BlY3RpdmUpLiBUaGlzIHdvdWxkIGJlDQptb3JlIGNv bnZlbmllbmNlIGZvciB1c2Vycy4gQW5kIG9wZXJhdG9ycyBjYW4gdXNlIFVTQiBkaWdpdGFsIGNy ZWRlbnRpYWwNCmFzIEhJVCB0byBpbXByb3ZlIHNlY3VyaXR5LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRlY2huaWNhbGx5LCBJIHByb3Bvc2UgdXNp bmcgSElUIGFzDQphbiBhcHBsaWNhdGlvbi1pbmRlcGVuZGVudCBpZGVudGl0eS4gQW5kIHRoZSBI SVQgY2FuIGJpbmRpbmcgd2l0aCB2aXJ0dWFsDQpob3N0L21hY2hpbmUvdGhpbmcuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNw OzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21h aWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPlRvbSBUYXlsb3IgJmx0O3RvbTExMS50YXlsb3JAYmVsbC5uZXQmZ3Q7PC9iPg0KPC9m b250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDUtMDQgMTA6NTg8 L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ Z2FvLnlhbmcyQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O1RzY2hvZmVuaWcs IEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pJnF1b3Q7DQombHQ7aGFubmVzLnRzY2hvZmVuaWdAbnNu LmNvbSZndDssIGRpc3BhdGNoQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW2Rpc3Bh dGNoXSBPcGVuIHRhbGsgYW5kIGludmVzdGlnYXRpb24NCmFib3V0IEhJUCBhbmQgU0lQL0lNUzwv Zm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+ PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ QnkgdXNpbmcgSElULCB5b3UgYXJlIGVxdWF0aW5nIHRoZSBzdWJzY3JpcHRpb24gd2l0aA0KdGhl IGRldmljZSByYXRoZXIgdGhhbiB0aGU8YnI+DQp1c2VyLiBIb3cgd2VsbCB3b3VsZCB0aGF0IHdv cmsgaWYgdGhlIHVzZXIgdHJhbnNmZXJyZWQgYSBTSU0gY2FyZCBmcm9tDQpvbmU8YnI+DQpkZXZp Y2UgdG8gYW5vdGhlcj88YnI+DQo8YnI+DQpnYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZTo8YnI+ DQomZ3Q7IEhpIEhhbm5lcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzIGZvciB5b3VyIHJl c3BvbnNlIHNpbmNlcmVseSBmaXJzdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgQUFBJ3Mga2VybmVs IGlzIGlkZW50aXR5LiBNeSBwcm9wb3NhbCBpcyB0aGF0IHVzaW5nIEhJUCdzIGlkZW50aXR5KHN1 Y2gNCmFzIDxicj4NCiZndDsgSElUKSBhcyB0aGUga2VybmVsIG9mIEFBQS4gV2hpbGUgSElQIGNh biBiZSB1c2VkIGZvciBhbGwga2luZHMgb2YNCjxicj4NCiZndDsgYXBwbGljYXRpb24gbGV2ZWwg cHJvdG9jb2wsIHN1Y2ggYXMgU0lQLCBIVFRQIGFuZCBzbyBvbiwgdGhlbiB0aGUNCkFBQSBjYW4g PGJyPg0KJmd0OyBiZSB1c2VkIGZvciBtb3JlIHRoYW4gb25lIGFwcGxpY2F0aW9uIGxldmVsIHBy b3RvY29sLiBBbmQgaWYgb3BlcmF0b3JzDQo8YnI+DQomZ3Q7IGRlcGxveSB0aGlzIGtpbmQgb2Yg bmV0d29yaywgdGhleSBjYW4gdXNpbmcgb25lIGluZnJhc3RydWN0dXJlIGZvcg0KbW9yZSA8YnI+ DQomZ3Q7IHRoYW4gb25lIGFwcGxpY2F0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBVc2luZyBT SVAvSU1TIGFzIGV4YW1wbGUsIHVzZXIgbWFuYWdlbWVudCwgcmVnaXN0cmF0aW9uLCBhdXRoZW50 aWNhdGlvbg0KPGJyPg0KJmd0OyBhbmQgUENDKEF1dGhvcml6YXRpb24sIGFuZCBBY2NvdW50aW5n KSBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gdGhlIDxicj4NCiZndDsgaW5mcmFzdHJ1Y3R1cmUuIEFu ZCBTSVAgYXBwbGljYXRpb24gY2FuIG9ubHkgZm9jdXMgb24gc2Vzc2lvbi9jYWxsDQo8YnI+DQom Z3Q7IGNvbnRyb2wuIEZ1cnRoZXIsIGlmIHRoZSBvcGVyYXRvcnMgd2FudCB0byBkZXBsb3kgYSBu ZXcgYXBwbGljYXRpb24NCmJleW9uZCA8YnI+DQomZ3Q7IFNJUCwgdGhlIGluZnJhc3RydWN0dXJl IHdvdWxkIGJlIHJldXNhYmxlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIGNvbmNlcHQgaXMg cmF3IG5vdywgc28gSSdkIGxpa2UgdG8gaGVhciBtb3JlIG9mIHlvdXIgY29tbWVudHMvZmVlbGlu Zw0KPGJyPg0KJmd0OyB0byBsaWdodCBpdCB1cC48YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJk cyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgR2FvPGJyPg0KJmd0OyA8YnI+DQouLi48YnI+DQo8YnI+ DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5i c3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtj b250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkm bmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6 YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJz cDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJz cDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZu YnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlz Y2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZu YnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJz cDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVs eSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNw O2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNl aXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2Um bmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMm bmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJz cDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3By ZT4= --=_alternative 00132D0848257719_=-- From peter.musgrave@magorcorp.com Tue May 4 05:03:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71B13A6914 for ; Tue, 4 May 2010 05:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.107 X-Spam-Level: X-Spam-Status: No, score=0.107 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVhLZCZ7n43n for ; Tue, 4 May 2010 05:03:07 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id 90B843A6B5B for ; Tue, 4 May 2010 05:03:06 -0700 (PDT) Received: by yxe9 with SMTP id 9so1271537yxe.29 for ; Tue, 04 May 2010 05:02:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.118.3 with SMTP id q3mr11809734ybc.211.1272974565088; Tue, 04 May 2010 05:02:45 -0700 (PDT) Received: by 10.150.92.9 with HTTP; Tue, 4 May 2010 05:02:44 -0700 (PDT) Date: Tue, 4 May 2010 08:02:44 -0400 Message-ID: From: Peter Musgrave To: "gao.yang2" , dispatch mailing list Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] HITs in SIP/SDP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 12:03:08 -0000 Hi Gao/Dispatch, I though I would separate Gao's question about HIP in SIP into a thread specific to the protocol issues. Has this topic been raised before? Do people see benefits in using HITs (built in NAT traversal, handling of multi-homed and mobility issues etc.)? Is the use of HITs in SIP/SDP protocols largely a matter of adding conventions for URLs and SDP c= lines etc. or is it "deep"? I suspect that the later is true (especially in mixed HIP/non-HIP calls since they would e.g. still need ICE and perhaps the HITs become candidates in an SDP offer)? The multi-homed and address mobility issue may also cause deeper issues. Peter Musgrave From gao.yang2@zte.com.cn Tue May 4 05:23:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426F93A6B88 for ; Tue, 4 May 2010 05:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.9 X-Spam-Level: X-Spam-Status: No, score=-95.9 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld5i01Xy1oST for ; Tue, 4 May 2010 05:23:51 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 32FDF3A6BE0 for ; Tue, 4 May 2010 05:22:21 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 58071992332426; Tue, 4 May 2010 20:18:15 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 43572.2898723675; Tue, 4 May 2010 20:17:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o44CMA03041829; Tue, 4 May 2010 20:22:10 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Peter Musgrave MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 4 May 2010 20:19:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-04 20:21:56, Serialize complete at 2010-05-04 20:21:56 Content-Type: multipart/alternative; boundary="=_alternative 0043E54448257719_=" X-MAIL: mse2.zte.com.cn o44CMA03041829 Cc: dispatch mailing list Subject: Re: [dispatch] HITs in SIP/SDP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 12:23:52 -0000 This is a multipart message in MIME format. --=_alternative 0043E54448257719_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGV0ZXIgTXVzZ3JhdmUsDQoNCkkgb25jZSBzZWUgc2VjdGlvbiAxNS4yLjQgb2YgdGhlIGJv b2sgb2YgDQoiSG9zdC5JZGVudGl0eS5Qcm90b2NvbC5ISVAuVG93YXJkcy50aGUuU2VjdXJlLk1v YmlsZS5JbnRlcm5ldCIgaGFzIHN1Y2ggDQpkaXNjdXNzaW9uLg0KDQpUaGFua3MsDQoNCkdhbw0K DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0K IFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBn YW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cg0KDQoNClBldGVyIE11c2dyYXZlIDxwZXRlci5tdXNncmF2ZUBtYWdvcmNvcnAuY29tPiANCjIw MTAtMDUtMDQgMjA6MDINCg0KytW8/sjLDQoiZ2FvLnlhbmcyIiA8Z2FvLnlhbmcyQHp0ZS5jb20u Y24+LCBkaXNwYXRjaCBtYWlsaW5nIGxpc3QgDQo8ZGlzcGF0Y2hAaWV0Zi5vcmc+DQqzrcvNDQoN Ctb3zOINCkhJVHMgaW4gU0lQL1NEUA0KDQoNCg0KDQoNCg0KSGkgR2FvL0Rpc3BhdGNoLA0KDQpJ IHRob3VnaCBJIHdvdWxkIHNlcGFyYXRlIEdhbydzIHF1ZXN0aW9uIGFib3V0IEhJUCBpbiBTSVAg aW50byBhDQp0aHJlYWQgc3BlY2lmaWMgdG8gdGhlIHByb3RvY29sIGlzc3Vlcy4NCg0KSGFzIHRo aXMgdG9waWMgYmVlbiByYWlzZWQgYmVmb3JlPw0KDQpEbyBwZW9wbGUgc2VlIGJlbmVmaXRzIGlu IHVzaW5nIEhJVHMgKGJ1aWx0IGluIE5BVCB0cmF2ZXJzYWwsIGhhbmRsaW5nDQpvZiBtdWx0aS1o b21lZCBhbmQgbW9iaWxpdHkgaXNzdWVzIGV0Yy4pPw0KDQpJcyB0aGUgdXNlIG9mIEhJVHMgaW4g U0lQL1NEUCBwcm90b2NvbHMgbGFyZ2VseSBhIG1hdHRlciBvZiBhZGRpbmcNCmNvbnZlbnRpb25z IGZvciBVUkxzIGFuZCBTRFAgYz0gbGluZXMgZXRjLiBvciBpcyBpdCAiZGVlcCI/DQoNCkkgc3Vz cGVjdCB0aGF0IHRoZSBsYXRlciBpcyB0cnVlIChlc3BlY2lhbGx5IGluIG1peGVkIEhJUC9ub24t SElQDQpjYWxscyBzaW5jZSB0aGV5IHdvdWxkIGUuZy4gc3RpbGwgbmVlZCBJQ0UgYW5kIHBlcmhh cHMgdGhlIEhJVHMgYmVjb21lDQpjYW5kaWRhdGVzIGluIGFuIFNEUCBvZmZlcik/IFRoZSBtdWx0 aS1ob21lZCBhbmQgYWRkcmVzcyBtb2JpbGl0eQ0KaXNzdWUgbWF5IGFsc28gY2F1c2UgZGVlcGVy IGlzc3Vlcy4NCg0KDQpQZXRlciBNdXNncmF2ZQ0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBp cyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFy ZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8g ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpU aGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50 aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0 aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Ig dmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0043E54448257719_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIDwvZm9udD48dHQ+PGZvbnQg c2l6ZT0yPlBldGVyIE11c2dyYXZlPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pkkgb25jZSBzZWUgc2VjdGlvbiAxNS4yLjQgb2YgdGhlIGJvb2sNCm9mICZxdW90O0hvc3QuSWRl bnRpdHkuUHJvdG9jb2wuSElQLlRvd2FyZHMudGhlLlNlY3VyZS5Nb2JpbGUuSW50ZXJuZXQmcXVv dDsNCmhhcyBzdWNoIGRpc2N1c3Npb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFpp cCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJy Pg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlh bmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwv Zm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5QZXRl ciBNdXNncmF2ZSAmbHQ7cGV0ZXIubXVzZ3JhdmVAbWFnb3Jjb3JwLmNvbSZndDs8L2I+DQo8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0wNS0wNCAyMDowMjwv Zm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4m cXVvdDtnYW8ueWFuZzImcXVvdDsgJmx0O2dhby55YW5nMkB6dGUuY29tLmNuJmd0OywNCmRpc3Bh dGNoIG1haWxpbmcgbGlzdCAmbHQ7ZGlzcGF0Y2hAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5ISVRzIGluIFNJUC9T RFA8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPkhpIEdhby9EaXNwYXRjaCw8YnI+DQo8YnI+DQpJIHRob3VnaCBJIHdvdWxkIHNlcGFyYXRl IEdhbydzIHF1ZXN0aW9uIGFib3V0IEhJUCBpbiBTSVAgaW50byBhPGJyPg0KdGhyZWFkIHNwZWNp ZmljIHRvIHRoZSBwcm90b2NvbCBpc3N1ZXMuPGJyPg0KPGJyPg0KSGFzIHRoaXMgdG9waWMgYmVl biByYWlzZWQgYmVmb3JlPzxicj4NCjxicj4NCkRvIHBlb3BsZSBzZWUgYmVuZWZpdHMgaW4gdXNp bmcgSElUcyAoYnVpbHQgaW4gTkFUIHRyYXZlcnNhbCwgaGFuZGxpbmc8YnI+DQpvZiBtdWx0aS1o b21lZCBhbmQgbW9iaWxpdHkgaXNzdWVzIGV0Yy4pPzxicj4NCjxicj4NCklzIHRoZSB1c2Ugb2Yg SElUcyBpbiBTSVAvU0RQIHByb3RvY29scyBsYXJnZWx5IGEgbWF0dGVyIG9mIGFkZGluZzxicj4N CmNvbnZlbnRpb25zIGZvciBVUkxzIGFuZCBTRFAgYz0gbGluZXMgZXRjLiBvciBpcyBpdCAmcXVv dDtkZWVwJnF1b3Q7Pzxicj4NCjxicj4NCkkgc3VzcGVjdCB0aGF0IHRoZSBsYXRlciBpcyB0cnVl IChlc3BlY2lhbGx5IGluIG1peGVkIEhJUC9ub24tSElQPGJyPg0KY2FsbHMgc2luY2UgdGhleSB3 b3VsZCBlLmcuIHN0aWxsIG5lZWQgSUNFIGFuZCBwZXJoYXBzIHRoZSBISVRzIGJlY29tZTxicj4N CmNhbmRpZGF0ZXMgaW4gYW4gU0RQIG9mZmVyKT8gVGhlIG11bHRpLWhvbWVkIGFuZCBhZGRyZXNz IG1vYmlsaXR5PGJyPg0KaXNzdWUgbWF5IGFsc28gY2F1c2UgZGVlcGVyIGlzc3Vlcy48YnI+DQo8 YnI+DQo8YnI+DQpQZXRlciBNdXNncmF2ZTxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K PGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGlj ZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7 dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7 bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtS ZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZu YnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7 bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2Nv bnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7 b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJz cDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlh bCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5i c3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRp dHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZu YnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2Vt YWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZu YnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5i c3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5i c3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtz ZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVk Jm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pU RSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0043E54448257719_=-- From gonzalo.camarillo@ericsson.com Tue May 4 06:07:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245B73A67F8 for ; Tue, 4 May 2010 06:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.127 X-Spam-Level: X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=-2.128, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jONPsHAqVIKZ for ; Tue, 4 May 2010 06:07:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 94B313A6BFE for ; Tue, 4 May 2010 06:07:24 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-68-4be01bfd2cae Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E2.41.21861.DFB10EB4; Tue, 4 May 2010 15:07:09 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 May 2010 15:07:09 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 May 2010 15:07:09 +0200 Received: from [131.160.126.205] (rvi2-126-205.lmf.ericsson.se [131.160.126.205]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0BC272549 for ; Tue, 4 May 2010 16:07:08 +0300 (EEST) Message-ID: <4BE01BFC.2060902@ericsson.com> Date: Tue, 04 May 2010 16:07:08 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------030608010404000600070806" X-OriginalArrivalTime: 04 May 2010 13:07:09.0350 (UTC) FILETIME=[B4202460:01CAEB8A] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Disaggregated media - charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 13:07:39 -0000 This is a multi-part message in MIME format. --------------030608010404000600070806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks, after discussing the Disaggregated Media charter proposal with a few IESG members, I have clarified and narrowed the scope of this WG-to-be. Some people have concerns that the original proposal was too vague. This proposal should be more specific. Comments are welcome. I would like to get the whole IESG to review this proposal pretty soon. Also, we still do not have an acronym for this. Thanks, Gonzalo --------------030608010404000600070806 Content-Type: text/plain; name="Disaggregated Media Charter Proposal.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Disaggregated Media Charter Proposal.txt" Disaggregated Media WG Charter ------------------------------ Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams coming from different devices under his or her control so that they are treated by the far end of the session as a single media session. Generally, a given participant uses a single device to establish (or participate in) a given multimedia session. Consequently, the SIP signaling to manage the multimedia session and the actual media streams are typically co-located in the same device. In scenarios involving disaggregated media, a user wants to establish a single multimedia session combining different media streams coming from different devices under his or her control. This creates a need to coordinate the exchange of the those media streams within the multimedia session. There are a number of existing mechanisms that can be used to coordinate different devices under user's control and to involve them in the call (e.g. Message Bus (Mbus) [RFC3259], Megaco [ITU-T H.248.1] and SIP 3pcc [RFC3725]). However, these mechanisms are intended to be used in "tightly coupled" scenarios. The use of all those mechanisms requires the presence of a "master" device. That is, at least one among the different devices under the control of the same user must support the control mechanism and be able to become a controller for the other devices in the call. Moreover, the "master" device is supposed to remain involved in the user's session for its entire duration given that performing a handover of the master role is typically cumbersome and sometimes impossible. The objective of this working group is to develop a framework for Disaggregated Media in "loosely-coupled" scenarios, where no single device needs to remain in the session for its entire duration and no single device needs to act as a master. Coordination among devices in this type of scenario is less tight than in the scenarios described above since they do not assume central elements with complete knowledge of the whole media session. While the framework may describe how to use existing mechanism (e.g., the SIP REFER method) to coordinate devices, the working group will not develop new device coordination mechanisms. In addition to the framework, the working group will work on a mechanism to label SIP dialogs as relating to the same media session. Specifically, the proposed working group will develop the following deliverables: 1. A framework document describing key considerations for the exchange of disaggregated media in SIP. The document will include use cases and examples. 2. Specification of a mechanism to label SIP dialogs as relating to the same media session. --------------030608010404000600070806-- From mary.ietf.barnes@gmail.com Tue May 4 06:12:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552A128C117 for ; Tue, 4 May 2010 06:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.672 X-Spam-Level: X-Spam-Status: No, score=-0.672 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FLEiiRwoM3O for ; Tue, 4 May 2010 06:12:12 -0700 (PDT) Received: from mail-iw0-f187.google.com (mail-iw0-f187.google.com [209.85.223.187]) by core3.amsl.com (Postfix) with ESMTP id C09233A6C1E for ; Tue, 4 May 2010 06:10:08 -0700 (PDT) Received: by iwn17 with SMTP id 17so1088265iwn.19 for ; Tue, 04 May 2010 06:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=ncg8JY57lO1YPwhW4fb0JRasHaC90lkRC2dglxLzpMA=; b=dlNOcANL4ohgs7RhmBEg/KReaVGk/T05+AjxevGWaojjgmS9EnXBE2nXwxfTCF7URI 3TOqntjtXCpNIHcIVArDoHjP7No/WYHgCU9LQIroSPoa0zF+lzkhiUJMYe8Q2R2enHhO UAGtPmsPY3o7gTfWA0rbPal6vtJbf1p0rkrx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=gd4yO4zWPr4BJoTVBPsZhYAky5wcw62tJe7V8LhKoez6foVAUQGsHKREeijPH0fRyS w/RbM5efqw2EoMkWW0aL+LoZavY9wx9iDw2esJKS8r/Za86sv5F8gYW2eme9dn7uvtxr UWVAkjiYlmXSD8lMacZ5MLXdgIrt+rJjJ2XKI= MIME-Version: 1.0 Received: by 10.231.85.205 with SMTP id p13mr3043706ibl.8.1272978590424; Tue, 04 May 2010 06:09:50 -0700 (PDT) Received: by 10.231.147.148 with HTTP; Tue, 4 May 2010 06:09:50 -0700 (PDT) Date: Tue, 4 May 2010 08:09:50 -0500 Message-ID: From: Mary Barnes To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] Reminder: DISPATCH WG deadlines for IETF-78 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 13:12:17 -0000 Hi folks, Here's a reminder of the deadlines for DISPATCH for IETF-78 timeframe. The first one is coming up in less than two weeks. * May 17th, 2010. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. [Two weeks prior to BoF proposal deadline] * May 31st, 2010. Cutoff for charter proposals for topics. [One day prior to BoF proposal deadline] * June 7th, 2010. Topics that are to be the focus of IETF-78 are announced. [One week before AD BoF approval and deadline to request WG slot] * July 5th, 2010. -00 draft deadline. * July 12th, 2010. Draft deadline. These dates have also been posted on the DISPATCH WG wiki page: http://trac.tools.ietf.org/wg/dispatch/trac/wiki The wiki has also been updated to capture the latest status of the already dispatched items. Regards, Mary DISPATCH WG co-chair From gonzalo.camarillo@ericsson.com Tue May 4 06:32:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331BC3A68F7 for ; Tue, 4 May 2010 06:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bkSJ-H4z9rD for ; Tue, 4 May 2010 06:32:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E0F4528C105 for ; Tue, 4 May 2010 06:32:10 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-6d-4be021cb1147 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AC.64.21861.BC120EB4; Tue, 4 May 2010 15:31:55 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 May 2010 15:31:55 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 May 2010 15:31:54 +0200 Received: from [131.160.126.205] (rvi2-126-205.lmf.ericsson.se [131.160.126.205]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A8CBE2549; Tue, 4 May 2010 16:31:54 +0300 (EEST) Message-ID: <4BE021CA.5060807@ericsson.com> Date: Tue, 04 May 2010 16:31:54 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF Dispatch References: <4B670809.2010903@nostrum.com> In-Reply-To: <4B670809.2010903@nostrum.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 May 2010 13:31:55.0096 (UTC) FILETIME=[29B2FD80:01CAEB8E] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] draft-mdolly-dispatch-oma-push X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 13:32:35 -0000 Hi, I have not seen any activity on this for a relatively long time. Note also that we received the LS below some time ago: https://datatracker.ietf.org/documents/LIAISON/file726.doc Where are we with this? Thanks, Gonzalo On 01/02/2010 6:57 PM, Adam Roach wrote: > The area directors for RAI asked me to review > draft-mdolly-dispatch-oma-push, specifically as they relate to the > ongoing revisions to RFCs 3265 and 3427. > > While there are some relatively minor issues with some of the 3265 > concepts used in this document, there is an overarching structural issue > that needs to be addressed. > > By my reading, what this document seeks to do is open a door for OMA to > create new event packages without requiring any IETF review (and, even > if such is not the intent, it would certainly be the outcome). This is > achieved by using an event package type of "oma-push," and then using a > new "Event" header field parameter of "event-app-id" to indicate the > actual event package. In the language of object-oriented programming, > this draft seeks to define an event package that is little more than a > façade to wrap RFC 3265, with the only substantive difference being > whether IETF review is required. > > The nature of this proposed "event package" as a framework (as opposed > to an actual event package as RFC 3265 defines that term) is revealed > substantially by the contents of two of its sections: section 10 and > section 12. In section 10, the draft tacitly indicates that it is to be > applied to a broad range of events: > > The durations of push event subscriptions, and in general the > conditions under which they are terminated, vary widely with the > nature of the applications as they are assumed to be application- > specific criteria. > > > Even more tellingly, section 12 simply indicates that the notification > bodies can be carried either inline or via indirection, and gives no > actual definition of body type or of body syntax. By contrast, consider > the body of published event packages: > > * RFC4575 defines a new application/conference-info+xml for NOTIFY > * RFC5362 defines a new application/resource-lists+xml for NOTIFY > * RFC4235 defines a new application/dialog-info+xml for NOTIFY > * RFC4730 defined a new application/kpml-request+xml for NOTIFY > * RFC3842 defines a new appcliation/simple-message-summary for NOTIFY > * RFC4354 defines a new application/poc-settings+xml for NOTIFY > * RFC3856 uses application/pidf+xml (which was designed for this > purpose) for NOTIFY > * RFC3680 defines a new application/reginfo+xml for NOTIFY > * RFC3515 uses message/sipfrag to convey the state of the indicated > resource in a NOTIFY > * RFC3910 defines a new application/spirits-event+xml for NOTIFY > * RFC3857 defines a new application/watcherinfo+xml for NOTIFY > > > A legitimate event package would indicate specifically and completely > what state is to be conveyed. It will also define or normatively > reference a formally-defined syntax for conveying the state. The fact > that the draft cannot provide such a description of state and a syntax > for conveying the state is a good indication that it is not an event > package, but actually an attempt to wrap RFC3265 in a parallel framework. > > If the overall mechanism proposed by the current document is approved as > an IETF-sanctioned event package, the net result will be a loophole that > effectively eliminates section 4.1 of rfc3427bis entirely. > > By my reading of subject matter covered by this document -- and with the > caveat that I am not familiar with any of the OMA applications that the > mechanism is intended to enable -- the only path forward that both > achieves the goals stated in this document's problem statement and > conforms to the restrictions put forth in RFC 3427 (and its draft > successor) is to define each of the applications as a new event package. > Unless I misunderstand the mechanism defined in OMA-TS-SIP_PUSH, there > appear to be approximately 23 such applications presently defined [1]. > For the sake of expediency, it may be sensible to have a single document > that defines the RFC3265 event packages for all of them -- that is, a > single draft with 23 distinct copies of the sections required by section > 4.4 of RFC3265. > > /a > > [1] A (partial?) list of defined applications appears to be published > here: http://www.wapforum.org/wina/push-app-id.htm From pkyzivat@cisco.com Tue May 4 06:52:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58B43A6BFD for ; Tue, 4 May 2010 06:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.703 X-Spam-Level: X-Spam-Status: No, score=-8.703 tagged_above=-999 required=5 tests=[AWL=-1.304, BAYES_50=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2NeDsoz2J-R for ; Tue, 4 May 2010 06:52:48 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 892C93A6B06 for ; Tue, 4 May 2010 06:52:48 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF7D30tAZnwM/2dsb2JhbACdMXGiIZl1hRME X-IronPort-AV: E=Sophos;i="4.52,327,1270425600"; d="scan'208";a="107781969" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 04 May 2010 13:52:34 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o44DqYe9025842; Tue, 4 May 2010 13:52:34 GMT Message-ID: <4BE026A2.9070909@cisco.com> Date: Tue, 04 May 2010 09:52:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4BE01BFC.2060902@ericsson.com> In-Reply-To: <4BE01BFC.2060902@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Disaggregated media - charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 13:52:52 -0000 Gonzalo, Gonzalo Camarillo wrote: > Folks, > > after discussing the Disaggregated Media charter proposal with a few > IESG members, I have clarified and narrowed the scope of this WG-to-be. > Some people have concerns that the original proposal was too vague. This > proposal should be more specific. > > Comments are welcome. I would like to get the whole IESG to review this > proposal pretty soon. I continue to disagree with some of the assumptions implicit in how this is worded, though the current phrasing is less objectionable than before. My main concerns are: - the distinction between "loosely coupled" and "tightly coupled": There is an explicit assertion that tightly coupled, with a "master", is more difficult and expensive than "loosely coupled". But the only suggestions I have seen for how to do "loosely coupled" really just shift some of the burden from the end that wants to use disaggregated media to the device(s?) at the other end. And this also increases the difficulty of implementing various "features", such as transfer, hold, etc. - deliverable number 2 (labeling multiple dialogs) presumes a particular outcome to deliverable number 1. I can live with the introductory material even though I don't fully agree with it. But I would like to see deliverable number 1 produced before deciding what solution mechanisms are required. The act of coming up with that first deliverable will provide a context for exploring the pros and cons of differing implementation approaches. To be specific, how about the following deliverables, to be sequenced: 1) a disaggregated media use cases document 2) a framework for realization of the use cases, including requirements for new mechanisms 3) specification for any new mechanisms required by (2). Thanks, Paul > Also, we still do not have an acronym for this. > > Thanks, > > Gonzalo > > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Hannes.Tschofenig@gmx.net Tue May 4 09:01:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007023A6CA4 for ; Tue, 4 May 2010 09:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7PhHL5rhIz9 for ; Tue, 4 May 2010 09:01:08 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9AE9A3A6940 for ; Tue, 4 May 2010 09:01:07 -0700 (PDT) Received: (qmail invoked by alias); 04 May 2010 16:00:50 -0000 Received: from wsip-24-120-240-250.lv.lv.cox.net (EHLO [10.186.94.68]) [24.120.240.250] by mail.gmx.net (mp013) with SMTP; 04 May 2010 18:00:50 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/xPXNxuXHxiXEkbf/eHv4o0QJnrHYr8cGcYK3BPE JZitNqEKuZxgC9 Message-ID: <4BE044AE.7020405@gmx.net> Date: Tue, 04 May 2010 09:00:46 -0700 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Musgrave References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59999999999999998 Cc: dispatch mailing list Subject: Re: [dispatch] HITs in SIP/SDP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 16:01:09 -0000 Some time ago we worked on a draft about the interaction between HIP and SIP: http://tools.ietf.org/html/draft-tschofenig-hiprg-host-identities-06 But the problem statement there was very different. It essentially simplified HIP deployment with the help of SIP. I believe that Gao has a different goal. I have not fully understood why he believes that HIP is the solution since I don't understand the problem. Ciao Hannes Peter Musgrave wrote: > Hi Gao/Dispatch, > > I though I would separate Gao's question about HIP in SIP into a > thread specific to the protocol issues. > > Has this topic been raised before? > > Do people see benefits in using HITs (built in NAT traversal, handling > of multi-homed and mobility issues etc.)? > > Is the use of HITs in SIP/SDP protocols largely a matter of adding > conventions for URLs and SDP c= lines etc. or is it "deep"? > > I suspect that the later is true (especially in mixed HIP/non-HIP > calls since they would e.g. still need ICE and perhaps the HITs become > candidates in an SDP offer)? The multi-homed and address mobility > issue may also cause deeper issues. > > > Peter Musgrave > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From Hannes.Tschofenig@gmx.net Tue May 4 09:05:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7C93A6C96 for ; Tue, 4 May 2010 09:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.826 X-Spam-Level: * X-Spam-Status: No, score=1.826 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_50=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_84=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EdedJIuIyXh for ; Tue, 4 May 2010 09:05:52 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E24913A6C89 for ; Tue, 4 May 2010 09:05:47 -0700 (PDT) Received: (qmail invoked by alias); 04 May 2010 16:05:32 -0000 Received: from wsip-24-120-240-250.lv.lv.cox.net (EHLO [10.186.94.68]) [24.120.240.250] by mail.gmx.net (mp054) with SMTP; 04 May 2010 18:05:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ztK84G1FzFJDW5A5Yb2xf/MjEN4pCOegu+Z7+6K UjB1rK6p7WdWeB Message-ID: <4BE045C7.60004@gmx.net> Date: Tue, 04 May 2010 09:05:27 -0700 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53000000000000003 Cc: dispatch@ietf.org Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 16:05:54 -0000 Hi Gao, gao.yang2@zte.com.cn wrote: > > Hi Hannes, > > Thanks for your response sincerely first. > > AAA's kernel is identity. My proposal is that using HIP's > identity(such as HIT) as the kernel of AAA. While HIP can be used for > all kinds of application level protocol, such as SIP, HTTP and so on, > then the AAA can be used for more than one application level protocol. > And if operators deploy this kind of network, they can using one > infrastructure for more than one application. What's wrong with SIP URIs? > > Using SIP/IMS as example, user management, registration, > authentication and PCC(Authorization, and Accounting) can be > implemented in the infrastructure. And SIP application can only focus > on session/call control. Further, if the operators want to deploy a > new application beyond SIP, the infrastructure would be reusable. When you say that the infrastructure is reusable what infrastructure are you talking about? Backend authentication servers (like HLR, AAA server, ..)? > > This concept is raw now, so I'd like to hear more of your > comments/feeling to light it up. Ciao Hannes > > Regards, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *"Tschofenig, Hannes (NSN - FI/Espoo)" * > > 2010-05-02 22:52 > > > ÊÕ¼þÈË > , > ³­ËÍ > > Ö÷Ìâ > RE: [dispatch] Open talk and investigation about HIP and SIP/IMS > > > > > > > > > > Hi Gao, > > I read through your mail a couple of times but I was not quite sure > that I understood your line of thought. > When someone does not want to use SIP (but HTTP instead) then let them > do. There shouldn't be any problem with that. > > The RADIUS and Diameter based Authentication, Authorization, and > Accounting (AAA) infrastructure is not application independent. RADIUS > and Diameter have largely been utilized for network access > authentication and for a few selected applications but have not found > widespread usage for web applications. There you find other protocols > being used. Also not a problem as such either. > > Having said that I am not sure how you draw the conclusion that HIP > might be the right protocol given that it is not a AAA protocol in the > first place nor particularly well aligned with any of the mentioned > protocols. > > I personally prefer to start with a problem statement first and then > to figure out whether people agree with it. Subsequently, one can > brainstorm about the appropriate protocol that addresses the gaps. > > Ciao > Hannes > > > ------------------------------------------------------------------------ > *From:* dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > *On Behalf Of *ext gao.yang2@zte.com.cn* > Sent:* Friday, April 30, 2010 6:55 AM* > To:* dispatch@ietf.org* > Subject:* [dispatch] Open talk and investigation about HIP and SIP/IMS > > > Hi, > > For people caring about SIP/IMS's network management level, I think > one application independency AAA infrastructure is future direction > for SIP/IMS. I'd like to know how many people have the same interest? > If you have any comments/feeling/suggestion for this topic, feel free > to go on. > > Telecom Core Network > > IMS(IP Multimedia Subsystem) is aimed for unified user management, > unified authentication, unified policy/charging and unified service > control, but it is tightly coupled with SIP. While the telecom core > network operators want to deploy any non-sip application, they find > that the unified platform(IMS) would not be suitable. > > We may conclude from the situation that, if telecom (core network) > operators want to make one infrastructure(unified user management, > unified authentication, unified policy/charging and unified service > control) suitable for any application(sip and non-sip), they need make > an sip decoupling AAA infrastructure at first. > > Making IMS's AAA based on HIP and IMS's multimedia level still on sip, > would make IMS's infrastructure open for any other protocol and > application. And if the telecom (core network) operators want to > embrace more and more non-sip application, HIP may be the only way. > * > Meanwhile, Could Computing and even M2M network also can get benefit > from such application independency AAA infrastructure:* > > Clouding Computing > > Some standard cloud/grid computing technology is based on Web. On the > web platform, it is easy to bulid one AAA infrastructure and open for > appliaction such as SOA. But if we want to build web and non-web(such > as RAI) application on the same platform, there's the same problem IMS > has. > So, if IT industry's could computing want to embrace non-web > application, HIP may be the same way again. > > M2M Network > Machine to machine network is hot now. But it also need one > application independency AAA infrastructure as platform for all the > conceivable application protocols. HIP is still a good choice for it. > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated to > maintain secrecy and are not permitted to disclose the contents of > this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the originator of the message. Any views expressed in this message are > those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dworley@avaya.com Tue May 4 10:37:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7A13A67A1 for ; Tue, 4 May 2010 10:37:32 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODuSfCaKq3OI for ; Tue, 4 May 2010 10:37:27 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id AD03A3A6A06 for ; Tue, 4 May 2010 10:37:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,328,1270440000"; d="scan'208";a="187146592" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 May 2010 13:36:57 -0400 X-IronPort-AV: E=Sophos;i="4.52,328,1270440000"; d="scan'208";a="470370812" 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; 04 May 2010 13:36:56 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 4 May 2010 13:36:56 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , Gonzalo Camarillo Date: Tue, 4 May 2010 13:34:08 -0400 Thread-Topic: [dispatch] Disaggregated media - charter proposal Thread-Index: AcrrkRuJkD7cWJwaTBeex8/IpImwuQAHuS+9 Message-ID: References: <4BE01BFC.2060902@ericsson.com>,<4BE026A2.9070909@cisco.com> In-Reply-To: <4BE026A2.9070909@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Disaggregated media - charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 17:37:32 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat [pkyzivat@cisco.com] - deliverable number 2 (labeling multiple dialogs) presumes a particular outcome to deliverable number 1. _______________________________________________ To be more clear, "deliverable number 2" is a specific implementation techn= ique, and it is the #1 feature of the current proposals that people object = to. So approving this charter proposal as it stands would beg the question= regarding the most significant design choice. Dale From fluffy@cisco.com Tue May 4 11:54:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E2A3A6CD9 for ; Tue, 4 May 2010 11:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.346 X-Spam-Level: X-Spam-Status: No, score=-107.346 tagged_above=-999 required=5 tests=[AWL=-2.441, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_84=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPO9v2h9R9S4 for ; Tue, 4 May 2010 11:54:32 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 58F373A687C for ; Tue, 4 May 2010 11:45:36 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMFAM4H4EurRN+K/2dsb2JhbAAtgmqaGXGkWIhoCJB/gSKBOIFHcgSDKA X-IronPort-AV: E=Sophos;i="4.52,328,1270425600"; d="scan'208";a="221357851" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 04 May 2010 18:45:22 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o44IjJO6026448; Tue, 4 May 2010 18:45:22 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=GB2312 From: Cullen Jennings In-Reply-To: Date: Tue, 4 May 2010 10:24:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: gao.yang2@zte.com.cn X-Mailer: Apple Mail (2.1078) Cc: dispatch@ietf.org Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 18:54:34 -0000 Given this sounds like a fundamental change to the IMS architecture, I = suspect that 3GPP would be a better place to discuss it than IETF.=20 On May 3, 2010, at 23:27 , gao.yang2@zte.com.cn wrote: >=20 > Hi Tom,=20 >=20 > This is just my feeling. And the whole proposal is raw now, and I am = not going to design all aspect of the proposal alone. So, any = refining/suggestion for any aspect is welcome.=20 >=20 > Thanks for your response, again.=20 >=20 > Gao=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > ----- =D7=AA=B7=A2=C8=CB GaoYang140197/user/zte_ltd =CA=B1=BC=E4 = 2010-05-04 11:23 -----=20 > GaoYang140197/user/zte_ltd > 2010-05-04 11:19 >=20 > =CA=D5=BC=FE=C8=CB > Tom Taylor > =B3=AD=CB=CD > dispatch@ietf.org, "Tschofenig, Hannes (NSN - FI/Espoo)" = > =D6=F7=CC=E2 > Re: [dispatch] Open talk and investigation about HIP and SIP/IMS=C1=B4=BD= =D3 >=20 >=20 >=20 >=20 >=20 > Hi Tom,=20 >=20 > Considering SIM card, I suggest SIM card itself has HIT, while not the = phone.=20 >=20 > And further, use HIP/HIT as VPN-like thing. User register by software, = and then get a virtual network established by HIP. And upon this virtual = network, any application run on it is secure and mobility, and = manageable(from operators' perspective). This would be more convenience = for users. And operators can use USB digital credential as HIT to = improve security.=20 >=20 > Technically, I propose using HIT as an application-independent = identity. And the HIT can binding with virtual host/machine/thing.=20 >=20 > Thanks,=20 >=20 > Gao=20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >=20 >=20 > Tom Taylor =20 > 2010-05-04 10:58 >=20 > =CA=D5=BC=FE=C8=CB > gao.yang2@zte.com.cn > =B3=AD=CB=CD > "Tschofenig, Hannes (NSN - FI/Espoo)" , = dispatch@ietf.org > =D6=F7=CC=E2 > Re: [dispatch] Open talk and investigation about HIP and SIP/IMS >=20 >=20 >=20 >=20 >=20 > By using HIT, you are equating the subscription with the device rather = than the > user. How well would that work if the user transferred a SIM card from = one > device to another? >=20 > gao.yang2@zte.com.cn wrote: > > Hi Hannes, > >=20 > > Thanks for your response sincerely first. > >=20 > > AAA's kernel is identity. My proposal is that using HIP's = identity(such as=20 > > HIT) as the kernel of AAA. While HIP can be used for all kinds of=20 > > application level protocol, such as SIP, HTTP and so on, then the = AAA can=20 > > be used for more than one application level protocol. And if = operators=20 > > deploy this kind of network, they can using one infrastructure for = more=20 > > than one application. > >=20 > > Using SIP/IMS as example, user management, registration, = authentication=20 > > and PCC(Authorization, and Accounting) can be implemented in the=20 > > infrastructure. And SIP application can only focus on session/call=20= > > control. Further, if the operators want to deploy a new application = beyond=20 > > SIP, the infrastructure would be reusable. > >=20 > > This concept is raw now, so I'd like to hear more of your = comments/feeling=20 > > to light it up. > >=20 > > Regards, > >=20 > > Gao > >=20 > ... >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From hannes.tschofenig@nsn.com Tue May 4 12:27:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E7128C39B for ; Tue, 4 May 2010 12:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.284 X-Spam-Level: X-Spam-Status: No, score=0.284 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG2mPPdpaZ58 for ; Tue, 4 May 2010 12:27:46 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 38D1128C3A1 for ; Tue, 4 May 2010 11:58:10 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o44Iv3o7021018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 May 2010 20:57:03 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o44Iv3WR014837; Tue, 4 May 2010 20:57:03 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 May 2010 20:57:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 May 2010 21:56:59 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502891543@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Open talk and investigation about HIP and SIP/IMS thread-index: Acrruzgc+iwD0YkSTeSSsldxv7wxTAAAEETg References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Cullen Jennings" , X-OriginalArrivalTime: 04 May 2010 18:57:03.0468 (UTC) FILETIME=[959852C0:01CAEBBB] Cc: dispatch@ietf.org Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 19:27:51 -0000 Cullen,=20 that's a very good point.=20 =20 Ciao Hannes >-----Original Message----- >From: dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] On Behalf Of ext Cullen Jennings >Sent: 04 May, 2010 07:25 >To: gao.yang2@zte.com.cn >Cc: dispatch@ietf.org >Subject: Re: [dispatch] Open talk and investigation about HIP=20 >and SIP/IMS > > >Given this sounds like a fundamental change to the IMS=20 >architecture, I suspect that 3GPP would be a better place to=20 >discuss it than IETF.=20 > >On May 3, 2010, at 23:27 , gao.yang2@zte.com.cn wrote: > >>=20 >> Hi Tom, >>=20 >> This is just my feeling. And the whole proposal is raw now,=20 >and I am not going to design all aspect of the proposal alone.=20 >So, any refining/suggestion for any aspect is welcome.=20 >>=20 >> Thanks for your response, again.=20 >>=20 >> Gao >>=20 >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Zip : 210012 >> Tel : 87211 >> Tel2 :(+86)-025-52877211 >> e_mail : gao.yang2@zte.com.cn >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> ----- =D7=AA=B7=A2=C8=CB GaoYang140197/user/zte_ltd =CA=B1=BC=E4 = 2010-05-04 11:23 -----=20 >> GaoYang140197/user/zte_ltd >> 2010-05-04 11:19 >>=20 >> =CA=D5=BC=FE=C8=CB >> Tom Taylor >> =B3=AD=CB=CD >> dispatch@ietf.org, "Tschofenig, Hannes (NSN - FI/Espoo)"=20 >> >> =D6=F7=CC=E2 >> Re: [dispatch] Open talk and investigation about HIP and = SIP/IMS=C1=B4=BD=D3 >>=20 >>=20 >>=20 >>=20 >>=20 >> Hi Tom, >>=20 >> Considering SIM card, I suggest SIM card itself has HIT,=20 >while not the phone.=20 >>=20 >> And further, use HIP/HIT as VPN-like thing. User register by=20 >software, and then get a virtual network established by HIP.=20 >And upon this virtual network, any application run on it is=20 >secure and mobility, and manageable(from operators'=20 >perspective). This would be more convenience for users. And=20 >operators can use USB digital credential as HIT to improve security.=20 >>=20 >> Technically, I propose using HIT as an=20 >application-independent identity. And the HIT can binding with=20 >virtual host/machine/thing.=20 >>=20 >> Thanks, >>=20 >> Gao >> =20 >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Zip : 210012 >> Tel : 87211 >> Tel2 :(+86)-025-52877211 >> e_mail : gao.yang2@zte.com.cn >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >> Tom Taylor >> 2010-05-04 10:58 >>=20 >> =CA=D5=BC=FE=C8=CB >> gao.yang2@zte.com.cn >> =B3=AD=CB=CD >> "Tschofenig, Hannes (NSN - FI/Espoo)" ,=20 >> dispatch@ietf.org >> =D6=F7=CC=E2 >> Re: [dispatch] Open talk and investigation about HIP and SIP/IMS >>=20 >>=20 >>=20 >>=20 >>=20 >> By using HIT, you are equating the subscription with the=20 >device rather=20 >> than the user. How well would that work if the user=20 >transferred a SIM=20 >> card from one device to another? >>=20 >> gao.yang2@zte.com.cn wrote: >> > Hi Hannes, >> >=20 >> > Thanks for your response sincerely first. >> >=20 >> > AAA's kernel is identity. My proposal is that using HIP's=20 >> > identity(such as >> > HIT) as the kernel of AAA. While HIP can be used for all kinds of=20 >> > application level protocol, such as SIP, HTTP and so on, then the=20 >> > AAA can be used for more than one application level=20 >protocol. And if=20 >> > operators deploy this kind of network, they can using one=20 >> > infrastructure for more than one application. >> >=20 >> > Using SIP/IMS as example, user management, registration,=20 >> > authentication and PCC(Authorization, and Accounting) can be=20 >> > implemented in the infrastructure. And SIP application can only=20 >> > focus on session/call control. Further, if the operators want to=20 >> > deploy a new application beyond SIP, the infrastructure=20 >would be reusable. >> >=20 >> > This concept is raw now, so I'd like to hear more of your=20 >> > comments/feeling to light it up. >> >=20 >> > Regards, >> >=20 >> > Gao >> >=20 >> ... >>=20 >>=20 >>=20 >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained=20 >in this mail is solely property of the sender's organization.=20 >This mail communication is confidential. Recipients named=20 >above are obligated to maintain secrecy and are not permitted=20 >to disclose the contents of this communication to others. >> This email and any files transmitted with it are=20 >confidential and intended solely for the use of the individual=20 >or entity to whom they are addressed. If you have received=20 >this email in error please notify the originator of the=20 >message. Any views expressed in this message are those of the=20 >individual sender. >> This message has been scanned for viruses and Spam by ZTE=20 >Anti-Spam system. >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > >Cullen Jennings >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch > From gao.yang2@zte.com.cn Tue May 4 18:11:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562F33A6899 for ; Tue, 4 May 2010 18:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.627 X-Spam-Level: X-Spam-Status: No, score=-95.627 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAOznfB7vJGR for ; Tue, 4 May 2010 18:11:35 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id E92A03A67D7 for ; Tue, 4 May 2010 18:11:34 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 58071992332426; Wed, 5 May 2010 09:07:25 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 6793.3072420325; Wed, 5 May 2010 09:11:14 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o451BA9O068320; Wed, 5 May 2010 09:11:10 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4BE045C7.60004@gmx.net> To: Hannes Tschofenig MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 5 May 2010 09:08:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-05 09:11:09, Serialize complete at 2010-05-05 09:11:09 Content-Type: multipart/alternative; boundary="=_alternative 00067C014825771A_=" X-MAIL: mse2.zte.com.cn o451BA9O068320 Cc: dispatch@ietf.org Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 01:11:37 -0000 This is a multipart message in MIME format. --=_alternative 00067C014825771A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSGFubmVzLA0KDQpIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5l dD4g0LTT2iAyMDEwLTA1LTA1IDAwOjA1OjI3Og0KDQo+IEhpIEdhbywNCj4gDQo+IGdhby55YW5n MkB6dGUuY29tLmNuIHdyb3RlOg0KPiA+DQo+ID4gSGkgSGFubmVzLA0KPiA+DQo+ID4gVGhhbmtz IGZvciB5b3VyIHJlc3BvbnNlIHNpbmNlcmVseSBmaXJzdC4NCj4gPg0KPiA+IEFBQSdzIGtlcm5l bCBpcyBpZGVudGl0eS4gTXkgcHJvcG9zYWwgaXMgdGhhdCB1c2luZyBISVAncw0KPiA+IGlkZW50 aXR5KHN1Y2ggYXMgSElUKSBhcyB0aGUga2VybmVsIG9mIEFBQS4gV2hpbGUgSElQIGNhbiBiZSB1 c2VkIGZvcg0KPiA+IGFsbCBraW5kcyBvZiBhcHBsaWNhdGlvbiBsZXZlbCBwcm90b2NvbCwgc3Vj aCBhcyBTSVAsIEhUVFAgYW5kIHNvIG9uLA0KPiA+IHRoZW4gdGhlIEFBQSBjYW4gYmUgdXNlZCBm b3IgbW9yZSB0aGFuIG9uZSBhcHBsaWNhdGlvbiBsZXZlbCBwcm90b2NvbC4NCj4gPiBBbmQgaWYg b3BlcmF0b3JzIGRlcGxveSB0aGlzIGtpbmQgb2YgbmV0d29yaywgdGhleSBjYW4gdXNpbmcgb25l DQo+ID4gaW5mcmFzdHJ1Y3R1cmUgZm9yIG1vcmUgdGhhbiBvbmUgYXBwbGljYXRpb24uIA0KPiBX aGF0J3Mgd3Jvbmcgd2l0aCBTSVAgVVJJcz8NCg0KRnJvbSBTSVAgcGVzcGVjdGl2ZSwgdGhlcmUn cyBubyB3cm9uZyB3aXRoIGl0LiBCdXQgaWYgc29tZW9uZS9vcmdhbml6YXRpb24gDQpjaG9vc2Ug U0lQJ3MgaWRlbnRpdHkgYXMgdGhlIGtlcm5lbCBvZiBpdCdzIEFBQSBpbmZyYXN0cnVjdHVyZSwg dGhpcyANCmluZnJhc3RydWN0dXJlIHdvdWxkIGJlIGxpbWl0ZWQgZm9yIFNJUCB1c2FnZS4gT25l IGV4YW1wbGUgaXMgM0dQUCdzIElNUy4gDQo+IA0KPiA+DQo+ID4gVXNpbmcgU0lQL0lNUyBhcyBl eGFtcGxlLCB1c2VyIG1hbmFnZW1lbnQsIHJlZ2lzdHJhdGlvbiwNCj4gPiBhdXRoZW50aWNhdGlv biBhbmQgUENDKEF1dGhvcml6YXRpb24sIGFuZCBBY2NvdW50aW5nKSBjYW4gYmUNCj4gPiBpbXBs ZW1lbnRlZCBpbiB0aGUgaW5mcmFzdHJ1Y3R1cmUuIEFuZCBTSVAgYXBwbGljYXRpb24gY2FuIG9u bHkgZm9jdXMNCj4gPiBvbiBzZXNzaW9uL2NhbGwgY29udHJvbC4gRnVydGhlciwgaWYgdGhlIG9w ZXJhdG9ycyB3YW50IHRvIGRlcGxveSBhDQo+ID4gbmV3IGFwcGxpY2F0aW9uIGJleW9uZCBTSVAs IHRoZSBpbmZyYXN0cnVjdHVyZSB3b3VsZCBiZSByZXVzYWJsZS4NCj4gDQo+IFdoZW4geW91IHNh eSB0aGF0IHRoZSBpbmZyYXN0cnVjdHVyZSBpcyByZXVzYWJsZSB3aGF0IGluZnJhc3RydWN0dXJl IGFyZQ0KPiB5b3UgdGFsa2luZyBhYm91dD8gQmFja2VuZCBhdXRoZW50aWNhdGlvbiBzZXJ2ZXJz IChsaWtlIEhMUiwgQUFBIHNlcnZlciwNCj4gLi4pPw0KDQpZZXMsIHN1Y2ggZXF1aXBtZW50IGlz IGluY2x1ZGVkIGluIHRoZSByZXVzYWJsZSBpbmZyYXN0cnVjdHVyZS4gQW5kIA0KUENDKHBvbGlj eSBhbmQgY2hhcmdpbmcpIGlzIGFsc28gaW5jbHVkZWQuDQpGdXJ0aGVyLCBDU0NGIGNhbiBiZSBl bmhhbmNlZCBhcyBISVAgcmVnaXN0cmF0aW9uL3JlbmRlenZvdXMgc2VydmVyLg0KDQpUaGUgZmlu YWwgYmVuZWZpdCBvZiB0aGllIGVuaGFuY2VtZW50IGlzIHRoaXMgaW5mcmFzdHJ1Y3R1cmUgY2Fu IGJlIG9wZW4gDQpmb3IgYW55IGFwcGxpY2F0aW9uIHByb3RvY29sLCBpbmNsdWRpbmcgU0lQLiBB bmQgdGhlIG1lYW53aGlsZSwgYXMgdGhlIA0KaW5mcmFzdHJ1Y3R1cmUgbGV2ZWwgbWVjaGFuaXNt LCBzdWNoIGFzIHJlZ2lzdHJhdGlvbiwgQUFBLCBQQ0MsIGFuZCANCm1vYmlsaXR5LCBoYXMgYmVl biBpbXBsZW1lbnRlZCBpbiB0aGUgaW5mcmFzdHJ1Y3R1cmUsIHNlc3Npb24gYXBwbGljYXRpb24g DQpsZXZlbChTSVApIGNhbiBjdXQgZG93biBzdWNoIG1lY2hhbmlzbS4NCg0KUmVnYXJkcywNCg0K R2FvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5k ZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlh bC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3Jl Y3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlz IGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5z bWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0 aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJl c3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90 aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGlu IHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBt ZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGkt U3BhbSBzeXN0ZW0uDQo= --=_alternative 00067C014825771A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEhhbm5lcyw8L2Zv bnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IYW5uZXMgVHNjaG9mZW5pZyAmbHQ7SGFu bmVzLlRzY2hvZmVuaWdAZ214Lm5ldCZndDsNCtC009ogMjAxMC0wNS0wNSAwMDowNToyNzo8YnI+ DQo8YnI+DQomZ3Q7IEhpIEdhbyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgZ2FvLnlhbmcyQHp0ZS5j b20uY24gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEhpIEhhbm5lcyw8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlIHNpbmNl cmVseSBmaXJzdC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQUFBJ3Mga2VybmVsIGlz IGlkZW50aXR5LiBNeSBwcm9wb3NhbCBpcyB0aGF0IHVzaW5nIEhJUCdzPGJyPg0KJmd0OyAmZ3Q7 IGlkZW50aXR5KHN1Y2ggYXMgSElUKSBhcyB0aGUga2VybmVsIG9mIEFBQS4gV2hpbGUgSElQIGNh biBiZQ0KdXNlZCBmb3I8YnI+DQomZ3Q7ICZndDsgYWxsIGtpbmRzIG9mIGFwcGxpY2F0aW9uIGxl dmVsIHByb3RvY29sLCBzdWNoIGFzIFNJUCwgSFRUUCBhbmQNCnNvIG9uLDxicj4NCiZndDsgJmd0 OyB0aGVuIHRoZSBBQUEgY2FuIGJlIHVzZWQgZm9yIG1vcmUgdGhhbiBvbmUgYXBwbGljYXRpb24g bGV2ZWwNCnByb3RvY29sLjxicj4NCiZndDsgJmd0OyBBbmQgaWYgb3BlcmF0b3JzIGRlcGxveSB0 aGlzIGtpbmQgb2YgbmV0d29yaywgdGhleSBjYW4gdXNpbmcNCm9uZTxicj4NCiZndDsgJmd0OyBp bmZyYXN0cnVjdHVyZSBmb3IgbW9yZSB0aGFuIG9uZSBhcHBsaWNhdGlvbi4gPGJyPg0KJmd0OyBX aGF0J3Mgd3Jvbmcgd2l0aCBTSVAgVVJJcz88L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPkZyb20gU0lQIHBlc3BlY3RpdmUsIHRoZXJlJ3Mgbm8gd3Jvbmcgd2l0aCBpdC4g QnV0DQppZiBzb21lb25lL29yZ2FuaXphdGlvbiBjaG9vc2UgU0lQJ3MgaWRlbnRpdHkgYXMgdGhl IGtlcm5lbCBvZiBpdCdzIEFBQQ0KaW5mcmFzdHJ1Y3R1cmUsIHRoaXMgaW5mcmFzdHJ1Y3R1cmUg d291bGQgYmUgbGltaXRlZCBmb3IgU0lQIHVzYWdlLiBPbmUNCmV4YW1wbGUgaXMgM0dQUCdzIElN Uy4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVXNpbmcgU0lQL0lN UyBhcyBleGFtcGxlLCB1c2VyIG1hbmFnZW1lbnQsIHJlZ2lzdHJhdGlvbiw8YnI+DQomZ3Q7ICZn dDsgYXV0aGVudGljYXRpb24gYW5kIFBDQyhBdXRob3JpemF0aW9uLCBhbmQgQWNjb3VudGluZykg Y2FuIGJlPGJyPg0KJmd0OyAmZ3Q7IGltcGxlbWVudGVkIGluIHRoZSBpbmZyYXN0cnVjdHVyZS4g QW5kIFNJUCBhcHBsaWNhdGlvbiBjYW4gb25seQ0KZm9jdXM8YnI+DQomZ3Q7ICZndDsgb24gc2Vz c2lvbi9jYWxsIGNvbnRyb2wuIEZ1cnRoZXIsIGlmIHRoZSBvcGVyYXRvcnMgd2FudCB0byBkZXBs b3kNCmE8YnI+DQomZ3Q7ICZndDsgbmV3IGFwcGxpY2F0aW9uIGJleW9uZCBTSVAsIHRoZSBpbmZy YXN0cnVjdHVyZSB3b3VsZCBiZSByZXVzYWJsZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2hlbiB5 b3Ugc2F5IHRoYXQgdGhlIGluZnJhc3RydWN0dXJlIGlzIHJldXNhYmxlIHdoYXQgaW5mcmFzdHJ1 Y3R1cmUNCmFyZTxicj4NCiZndDsgeW91IHRhbGtpbmcgYWJvdXQ/IEJhY2tlbmQgYXV0aGVudGlj YXRpb24gc2VydmVycyAobGlrZSBITFIsIEFBQSBzZXJ2ZXIsPGJyPg0KJmd0OyAuLik/PC9mb250 PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5ZZXMsIHN1Y2ggZXF1aXBtZW50IGlz IGluY2x1ZGVkIGluIHRoZSByZXVzYWJsZSBpbmZyYXN0cnVjdHVyZS4NCkFuZCBQQ0MocG9saWN5 IGFuZCBjaGFyZ2luZykgaXMgYWxzbyBpbmNsdWRlZC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPkZ1cnRoZXIsIENTQ0YgY2FuIGJlIGVuaGFuY2VkIGFzIEhJUCByZWdpc3RyYXRp b24vcmVuZGV6dm91cw0Kc2VydmVyLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+VGhlIGZpbmFsIGJlbmVmaXQgb2YgdGhpZSBlbmhhbmNlbWVudCBpcyB0aGlzIGluZnJh c3RydWN0dXJlDQpjYW4gYmUgb3BlbiBmb3IgYW55IGFwcGxpY2F0aW9uIHByb3RvY29sLCBpbmNs dWRpbmcgU0lQLiBBbmQgdGhlIG1lYW53aGlsZSwNCmFzIHRoZSBpbmZyYXN0cnVjdHVyZSBsZXZl bCBtZWNoYW5pc20sIHN1Y2ggYXMgcmVnaXN0cmF0aW9uLCBBQUEsIFBDQywNCmFuZCBtb2JpbGl0 eSwgaGFzIGJlZW4gaW1wbGVtZW50ZWQgaW4gdGhlIGluZnJhc3RydWN0dXJlLCBzZXNzaW9uIGFw cGxpY2F0aW9uDQpsZXZlbChTSVApIGNhbiBjdXQgZG93biBzdWNoIG1lY2hhbmlzbS48L2ZvbnQ+ PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlJlZ2FyZHMsPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5HYW88L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJl Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7 VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJz cDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJz cDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50 cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZu YnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNw O3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZu YnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4N ClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNt aXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDth bmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7 dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZu YnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNw O2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmln aW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdz Jm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZu YnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0K VGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2Zv ciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtB bnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00067C014825771A_=-- From gao.yang2@zte.com.cn Tue May 4 18:22:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C5EB3A6954 for ; Tue, 4 May 2010 18:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.807 X-Spam-Level: X-Spam-Status: No, score=-96.807 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OsKw4u98+Fk for ; Tue, 4 May 2010 18:22:18 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id E5D0D3A6995 for ; Tue, 4 May 2010 18:22:14 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 58071992332426; Wed, 5 May 2010 09:16:23 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 43572.1212601940; Wed, 5 May 2010 09:16:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o451KXFZ079077; Wed, 5 May 2010 09:20:33 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Cullen Jennings MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 5 May 2010 09:18:15 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-05 09:20:32, Serialize complete at 2010-05-05 09:20:32 Content-Type: multipart/alternative; boundary="=_alternative 0007576F4825771A_=" X-MAIL: mse2.zte.com.cn o451KXFZ079077 Cc: dispatch@ietf.org Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 01:22:21 -0000 This is a multipart message in MIME format. --=_alternative 0007576F4825771A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQ3VsbGVuLA0KDQpJIGFncmVlIHdpdGggeW91LiAzR1BQJ3MgU0ExIGlzIGEgbW9yZSBwcm9w ZXIgZm9yIHRoaXMgY29uY2VwdCBhdCBsYXJnZS4NCg0KQnV0IGFzIG1ha2luZyBzb21lIGluZnJh c3RydWN0dXJlIGxldmVsIG1lY2hhbmlzbShpbmNsdWRpbmcgYnV0IG5vdCANCnJlc3RyaWN0ZWQg YXM6IHJlZ2lzdHJhdGlvbiwgQUFBLCBQQ0MsIGFuZCBtb2JpbGl0eSkgYXQgaW5mcmFzdHJ1Y3R1 cmUgDQpsZXZlbCwgd2UgbWlnaHQgbmVlZCBhIGN1dHRlZCBkb3duIHZlcnNpb24gb2YgU0lQLiBN YXliZSB0aGlzIGFzcGVjdCBpcyANCnByb3BlciBoZXJlLg0KDQpBbmQgYWxvbmcgc3VnZ2VzdGlv biwgdG8gc3BsaXQgdGhpcyBiaWcgY29uY2VwdCBpbnRvIHNhbWxsZXIgYmFzaWMgDQpwcm90b2Nv bCBsZXZlbCBpc3N1ZSBtaWdodCBiZSBPSz8NCg0KVGhhbmtzLA0KDQpHYW8gDQoNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDog ODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6 dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KQ3Vs bGVuIEplbm5pbmdzIDxmbHVmZnlAY2lzY28uY29tPiANCjIwMTAtMDUtMDQgMjI6MjQNCg0KytW8 /sjLDQpnYW8ueWFuZzJAenRlLmNvbS5jbg0Ks63LzQ0KZGlzcGF0Y2hAaWV0Zi5vcmcNCtb3zOIN ClJlOiBbZGlzcGF0Y2hdIE9wZW4gdGFsayBhbmQgaW52ZXN0aWdhdGlvbiBhYm91dCBISVAgYW5k IFNJUC9JTVMNCg0KDQoNCg0KDQoNCg0KR2l2ZW4gdGhpcyBzb3VuZHMgbGlrZSBhIGZ1bmRhbWVu dGFsIGNoYW5nZSB0byB0aGUgSU1TIGFyY2hpdGVjdHVyZSwgSSANCnN1c3BlY3QgdGhhdCAzR1BQ IHdvdWxkIGJlIGEgYmV0dGVyIHBsYWNlIHRvIGRpc2N1c3MgaXQgdGhhbiBJRVRGLiANCg0KT24g TWF5IDMsIDIwMTAsIGF0IDIzOjI3ICwgZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3JvdGU6DQoNCj4g DQo+IEhpIFRvbSwgDQo+IA0KPiBUaGlzIGlzIGp1c3QgbXkgZmVlbGluZy4gQW5kIHRoZSB3aG9s ZSBwcm9wb3NhbCBpcyByYXcgbm93LCBhbmQgSSBhbSBub3QgDQpnb2luZyB0byBkZXNpZ24gYWxs IGFzcGVjdCBvZiB0aGUgcHJvcG9zYWwgYWxvbmUuIFNvLCBhbnkgDQpyZWZpbmluZy9zdWdnZXN0 aW9uIGZvciBhbnkgYXNwZWN0IGlzIHdlbGNvbWUuIA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIHJl c3BvbnNlLCBhZ2Fpbi4gDQo+IA0KPiBHYW8gDQo+IA0KPiA9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KPiBaaXAgICAgOiAyMTAwMTINCj4gVGVsICAgIDogODcyMTENCj4gVGVs MiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCj4gZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24N Cj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gDQo+IC0tLS0tINeqt6LIyyBH YW9ZYW5nMTQwMTk3L3VzZXIvenRlX2x0ZCDKsbzkIDIwMTAtMDUtMDQgMTE6MjMgLS0tLS0gDQo+ IEdhb1lhbmcxNDAxOTcvdXNlci96dGVfbHRkDQo+IDIwMTAtMDUtMDQgMTE6MTkNCj4gDQo+IMrV vP7Iyw0KPiBUb20gVGF5bG9yIDx0b20xMTEudGF5bG9yQGJlbGwubmV0Pg0KPiCzrcvNDQo+IGRp c3BhdGNoQGlldGYub3JnLCAiVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykiIA0K PGhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb20+DQo+INb3zOINCj4gUmU6IFtkaXNwYXRjaF0gT3Bl biB0YWxrIGFuZCBpbnZlc3RpZ2F0aW9uIGFib3V0IEhJUCBhbmQgU0lQL0lNU8G0vdMNCj4gDQo+ IA0KPiANCj4gDQo+IA0KPiBIaSBUb20sIA0KPiANCj4gQ29uc2lkZXJpbmcgU0lNIGNhcmQsIEkg c3VnZ2VzdCBTSU0gY2FyZCBpdHNlbGYgaGFzIEhJVCwgd2hpbGUgbm90IHRoZSANCnBob25lLiAN Cj4gDQo+IEFuZCBmdXJ0aGVyLCB1c2UgSElQL0hJVCBhcyBWUE4tbGlrZSB0aGluZy4gVXNlciBy ZWdpc3RlciBieSBzb2Z0d2FyZSwgDQphbmQgdGhlbiBnZXQgYSB2aXJ0dWFsIG5ldHdvcmsgZXN0 YWJsaXNoZWQgYnkgSElQLiBBbmQgdXBvbiB0aGlzIHZpcnR1YWwgDQpuZXR3b3JrLCBhbnkgYXBw bGljYXRpb24gcnVuIG9uIGl0IGlzIHNlY3VyZSBhbmQgbW9iaWxpdHksIGFuZCANCm1hbmFnZWFi bGUoZnJvbSBvcGVyYXRvcnMnIHBlcnNwZWN0aXZlKS4gVGhpcyB3b3VsZCBiZSBtb3JlIGNvbnZl bmllbmNlIA0KZm9yIHVzZXJzLiBBbmQgb3BlcmF0b3JzIGNhbiB1c2UgVVNCIGRpZ2l0YWwgY3Jl ZGVudGlhbCBhcyBISVQgdG8gaW1wcm92ZSANCnNlY3VyaXR5LiANCj4gDQo+IFRlY2huaWNhbGx5 LCBJIHByb3Bvc2UgdXNpbmcgSElUIGFzIGFuIGFwcGxpY2F0aW9uLWluZGVwZW5kZW50IGlkZW50 aXR5LiANCkFuZCB0aGUgSElUIGNhbiBiaW5kaW5nIHdpdGggdmlydHVhbCBob3N0L21hY2hpbmUv dGhpbmcuIA0KPiANCj4gVGhhbmtzLCANCj4gDQo+IEdhbyANCj4gDQo+ID09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQo+IFppcCAgICA6IDIxMDAxMg0KPiBUZWwgICAgOiA4NzIx MQ0KPiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KPiBlX21haWwgOiBnYW8ueWFuZzJAenRl LmNvbS5jbg0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSANCj4gDQo+IA0K PiBUb20gVGF5bG9yIDx0b20xMTEudGF5bG9yQGJlbGwubmV0PiANCj4gMjAxMC0wNS0wNCAxMDo1 OA0KPiANCj4gytW8/sjLDQo+IGdhby55YW5nMkB6dGUuY29tLmNuDQo+ILOty80NCj4gIlRzY2hv ZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pIiA8aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNv bT4sIA0KZGlzcGF0Y2hAaWV0Zi5vcmcNCj4g1vfM4g0KPiBSZTogW2Rpc3BhdGNoXSBPcGVuIHRh bGsgYW5kIGludmVzdGlnYXRpb24gYWJvdXQgSElQIGFuZCBTSVAvSU1TDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gQnkgdXNpbmcgSElULCB5b3UgYXJlIGVxdWF0aW5nIHRoZSBzdWJzY3JpcHRpb24g d2l0aCB0aGUgZGV2aWNlIHJhdGhlciANCnRoYW4gdGhlDQo+IHVzZXIuIEhvdyB3ZWxsIHdvdWxk IHRoYXQgd29yayBpZiB0aGUgdXNlciB0cmFuc2ZlcnJlZCBhIFNJTSBjYXJkIGZyb20gDQpvbmUN Cj4gZGV2aWNlIHRvIGFub3RoZXI/DQo+IA0KPiBnYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZToN Cj4gPiBIaSBIYW5uZXMsDQo+ID4gDQo+ID4gVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlIHNpbmNl cmVseSBmaXJzdC4NCj4gPiANCj4gPiBBQUEncyBrZXJuZWwgaXMgaWRlbnRpdHkuIE15IHByb3Bv c2FsIGlzIHRoYXQgdXNpbmcgSElQJ3MgDQppZGVudGl0eShzdWNoIGFzIA0KPiA+IEhJVCkgYXMg dGhlIGtlcm5lbCBvZiBBQUEuIFdoaWxlIEhJUCBjYW4gYmUgdXNlZCBmb3IgYWxsIGtpbmRzIG9m IA0KPiA+IGFwcGxpY2F0aW9uIGxldmVsIHByb3RvY29sLCBzdWNoIGFzIFNJUCwgSFRUUCBhbmQg c28gb24sIHRoZW4gdGhlIEFBQSANCmNhbiANCj4gPiBiZSB1c2VkIGZvciBtb3JlIHRoYW4gb25l IGFwcGxpY2F0aW9uIGxldmVsIHByb3RvY29sLiBBbmQgaWYgb3BlcmF0b3JzIA0KDQo+ID4gZGVw bG95IHRoaXMga2luZCBvZiBuZXR3b3JrLCB0aGV5IGNhbiB1c2luZyBvbmUgaW5mcmFzdHJ1Y3R1 cmUgZm9yIA0KbW9yZSANCj4gPiB0aGFuIG9uZSBhcHBsaWNhdGlvbi4NCj4gPiANCj4gPiBVc2lu ZyBTSVAvSU1TIGFzIGV4YW1wbGUsIHVzZXIgbWFuYWdlbWVudCwgcmVnaXN0cmF0aW9uLCANCmF1 dGhlbnRpY2F0aW9uIA0KPiA+IGFuZCBQQ0MoQXV0aG9yaXphdGlvbiwgYW5kIEFjY291bnRpbmcp IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiB0aGUgDQo+ID4gaW5mcmFzdHJ1Y3R1cmUuIEFuZCBTSVAg YXBwbGljYXRpb24gY2FuIG9ubHkgZm9jdXMgb24gc2Vzc2lvbi9jYWxsIA0KPiA+IGNvbnRyb2wu IEZ1cnRoZXIsIGlmIHRoZSBvcGVyYXRvcnMgd2FudCB0byBkZXBsb3kgYSBuZXcgYXBwbGljYXRp b24gDQpiZXlvbmQgDQo+ID4gU0lQLCB0aGUgaW5mcmFzdHJ1Y3R1cmUgd291bGQgYmUgcmV1c2Fi bGUuDQo+ID4gDQo+ID4gVGhpcyBjb25jZXB0IGlzIHJhdyBub3csIHNvIEknZCBsaWtlIHRvIGhl YXIgbW9yZSBvZiB5b3VyIA0KY29tbWVudHMvZmVlbGluZyANCj4gPiB0byBsaWdodCBpdCB1cC4N Cj4gPiANCj4gPiBSZWdhcmRzLA0KPiA+IA0KPiA+IEdhbw0KPiA+IA0KPiAuLi4NCj4gDQo+IA0K PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgDQppcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRl cidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gDQppcyBjb25maWRlbnRp YWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNy ZWN5IA0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0 aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMuDQo+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIA0KaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIA0KYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y IHBsZWFzZSBub3RpZnkgdGhlIA0Kb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIA0Kb2YgdGhlIGluZGl2aWR1YWwg c2VuZGVyLg0KPiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQg U3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+ IGRpc3BhdGNoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGlzcGF0Y2gNCg0KDQpDdWxsZW4gSmVubmluZ3MNCkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5m b3JtYXRpb24gZ28gdG86DQpodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVz aW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwNCg0KDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1h aWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0 byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4N ClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRl bnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUg bWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZv ciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0007576F4825771A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEN1bGxlbiw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYWdyZWUgd2l0aCB5b3Uu IDNHUFAncyBTQTEgaXMgYSBtb3JlDQpwcm9wZXIgZm9yIHRoaXMgY29uY2VwdCBhdCBsYXJnZS48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJ1dCBhcyBt YWtpbmcgc29tZSA8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5pbmZyYXN0cnVjdHVyZQ0KbGV2ZWwg bWVjaGFuaXNtKGluY2x1ZGluZyBidXQgbm90IHJlc3RyaWN0ZWQgYXM6IHJlZ2lzdHJhdGlvbiwg QUFBLCBQQ0MsDQphbmQgbW9iaWxpdHkpIGF0IGluZnJhc3RydWN0dXJlIGxldmVsLCB3ZSBtaWdo dCBuZWVkIGEgY3V0dGVkIGRvd24gdmVyc2lvbg0Kb2YgU0lQLiBNYXliZSB0aGlzIGFzcGVjdCBp cyBwcm9wZXIgaGVyZS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkFu ZCBhbG9uZyBzdWdnZXN0aW9uLCB0byBzcGxpdCB0aGlzIGJpZyBjb25jZXB0IGludG8NCnNhbWxs ZXIgYmFzaWMgcHJvdG9jb2wgbGV2ZWwgaXNzdWUgbWlnaHQgYmUgT0s/PC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGFua3MsPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5HYW8gPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJy Pg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3 MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDog Z2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj5DdWxsZW4gSmVubmluZ3MgJmx0O2ZsdWZmeUBjaXNjby5jb20mZ3Q7PC9iPg0KPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDUtMDQgMjI6MjQ8L2ZvbnQ+ DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7I yzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Z2FvLnlh bmcyQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmRpc3BhdGNoQGlldGYub3JnPC9mb250 Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5SZTogW2Rpc3BhdGNoXSBPcGVuIHRhbGsgYW5kIGludmVzdGlnYXRpb24N CmFib3V0IEhJUCBhbmQgU0lQL0lNUzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJy Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KR2l2ZW4gdGhpcyBzb3VuZHMgbGlrZSBhIGZ1 bmRhbWVudGFsIGNoYW5nZSB0byB0aGUgSU1TIGFyY2hpdGVjdHVyZSwgSQ0Kc3VzcGVjdCB0aGF0 IDNHUFAgd291bGQgYmUgYSBiZXR0ZXIgcGxhY2UgdG8gZGlzY3VzcyBpdCB0aGFuIElFVEYuIDxi cj4NCjxicj4NCk9uIE1heSAzLCAyMDEwLCBhdCAyMzoyNyAsIGdhby55YW5nMkB6dGUuY29tLmNu IHdyb3RlOjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBUb20sIDxicj4NCiZndDsgPGJy Pg0KJmd0OyBUaGlzIGlzIGp1c3QgbXkgZmVlbGluZy4gQW5kIHRoZSB3aG9sZSBwcm9wb3NhbCBp cyByYXcgbm93LCBhbmQgSQ0KYW0gbm90IGdvaW5nIHRvIGRlc2lnbiBhbGwgYXNwZWN0IG9mIHRo ZSBwcm9wb3NhbCBhbG9uZS4gU28sIGFueSByZWZpbmluZy9zdWdnZXN0aW9uDQpmb3IgYW55IGFz cGVjdCBpcyB3ZWxjb21lLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzIGZvciB5b3VyIHJl c3BvbnNlLCBhZ2Fpbi4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEdhbyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IFppcCAm bmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQomZ3Q7IFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxi cj4NCiZndDsgVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiZndDsgZV9tYWls IDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09IDxicj4NCiZndDsgLS0tLS0g16q3osjLIEdhb1lhbmcxNDAxOTcvdXNlci96 dGVfbHRkIMqxvOQgMjAxMC0wNS0wNCAxMToyMw0KLS0tLS0gPGJyPg0KJmd0OyBHYW9ZYW5nMTQw MTk3L3VzZXIvenRlX2x0ZDxicj4NCiZndDsgMjAxMC0wNS0wNCAxMToxOTxicj4NCiZndDsgPGJy Pg0KJmd0OyDK1bz+yMs8YnI+DQomZ3Q7IFRvbSBUYXlsb3IgJmx0O3RvbTExMS50YXlsb3JAYmVs bC5uZXQmZ3Q7PGJyPg0KJmd0OyCzrcvNPGJyPg0KJmd0OyBkaXNwYXRjaEBpZXRmLm9yZywgJnF1 b3Q7VHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykmcXVvdDsNCiZsdDtoYW5uZXMu dHNjaG9mZW5pZ0Buc24uY29tJmd0Ozxicj4NCiZndDsg1vfM4jxicj4NCiZndDsgUmU6IFtkaXNw YXRjaF0gT3BlbiB0YWxrIGFuZCBpbnZlc3RpZ2F0aW9uIGFib3V0IEhJUCBhbmQgU0lQL0lNU8G0 vdM8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyBIaSBUb20sIDxicj4NCiZndDsgPGJyPg0KJmd0OyBDb25zaWRlcmluZyBTSU0g Y2FyZCwgSSBzdWdnZXN0IFNJTSBjYXJkIGl0c2VsZiBoYXMgSElULCB3aGlsZSBub3QNCnRoZSBw aG9uZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFuZCBmdXJ0aGVyLCB1c2UgSElQL0hJVCBhcyBW UE4tbGlrZSB0aGluZy4gVXNlciByZWdpc3RlciBieSBzb2Z0d2FyZSwNCmFuZCB0aGVuIGdldCBh IHZpcnR1YWwgbmV0d29yayBlc3RhYmxpc2hlZCBieSBISVAuIEFuZCB1cG9uIHRoaXMgdmlydHVh bA0KbmV0d29yaywgYW55IGFwcGxpY2F0aW9uIHJ1biBvbiBpdCBpcyBzZWN1cmUgYW5kIG1vYmls aXR5LCBhbmQgbWFuYWdlYWJsZShmcm9tDQpvcGVyYXRvcnMnIHBlcnNwZWN0aXZlKS4gVGhpcyB3 b3VsZCBiZSBtb3JlIGNvbnZlbmllbmNlIGZvciB1c2Vycy4gQW5kDQpvcGVyYXRvcnMgY2FuIHVz ZSBVU0IgZGlnaXRhbCBjcmVkZW50aWFsIGFzIEhJVCB0byBpbXByb3ZlIHNlY3VyaXR5LiA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgVGVjaG5pY2FsbHksIEkgcHJvcG9zZSB1c2luZyBISVQgYXMgYW4g YXBwbGljYXRpb24taW5kZXBlbmRlbnQgaWRlbnRpdHkuDQpBbmQgdGhlIEhJVCBjYW4gYmluZGlu ZyB3aXRoIHZpcnR1YWwgaG9zdC9tYWNoaW5lL3RoaW5nLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsg VGhhbmtzLCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgR2FvIDxicj4NCiZndDsgJm5ic3A7IDxicj4N CiZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IFppcCAm bmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQomZ3Q7IFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxi cj4NCiZndDsgVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiZndDsgZV9tYWls IDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRvbSBUYXlsb3Ig Jmx0O3RvbTExMS50YXlsb3JAYmVsbC5uZXQmZ3Q7IDxicj4NCiZndDsgMjAxMC0wNS0wNCAxMDo1 ODxicj4NCiZndDsgPGJyPg0KJmd0OyDK1bz+yMs8YnI+DQomZ3Q7IGdhby55YW5nMkB6dGUuY29t LmNuPGJyPg0KJmd0OyCzrcvNPGJyPg0KJmd0OyAmcXVvdDtUc2Nob2ZlbmlnLCBIYW5uZXMgKE5T TiAtIEZJL0VzcG9vKSZxdW90OyAmbHQ7aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbSZndDssDQpk aXNwYXRjaEBpZXRmLm9yZzxicj4NCiZndDsg1vfM4jxicj4NCiZndDsgUmU6IFtkaXNwYXRjaF0g T3BlbiB0YWxrIGFuZCBpbnZlc3RpZ2F0aW9uIGFib3V0IEhJUCBhbmQgU0lQL0lNUzxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEJ5IHVzaW5nIEhJVCwgeW91IGFyZSBlcXVhdGluZyB0aGUgc3Vic2NyaXB0aW9uIHdpdGggdGhl IGRldmljZSByYXRoZXINCnRoYW4gdGhlPGJyPg0KJmd0OyB1c2VyLiBIb3cgd2VsbCB3b3VsZCB0 aGF0IHdvcmsgaWYgdGhlIHVzZXIgdHJhbnNmZXJyZWQgYSBTSU0gY2FyZA0KZnJvbSBvbmU8YnI+ DQomZ3Q7IGRldmljZSB0byBhbm90aGVyPzxicj4NCiZndDsgPGJyPg0KJmd0OyBnYW8ueWFuZzJA enRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgSGkgSGFubmVzLDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlIHNpbmNlcmVseSBmaXJz dC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFBQSdzIGtlcm5lbCBpcyBpZGVudGl0 eS4gTXkgcHJvcG9zYWwgaXMgdGhhdCB1c2luZyBISVAncyBpZGVudGl0eShzdWNoDQphcyA8YnI+ DQomZ3Q7ICZndDsgSElUKSBhcyB0aGUga2VybmVsIG9mIEFBQS4gV2hpbGUgSElQIGNhbiBiZSB1 c2VkIGZvciBhbGwga2luZHMNCm9mIDxicj4NCiZndDsgJmd0OyBhcHBsaWNhdGlvbiBsZXZlbCBw cm90b2NvbCwgc3VjaCBhcyBTSVAsIEhUVFAgYW5kIHNvIG9uLCB0aGVuDQp0aGUgQUFBIGNhbiA8 YnI+DQomZ3Q7ICZndDsgYmUgdXNlZCBmb3IgbW9yZSB0aGFuIG9uZSBhcHBsaWNhdGlvbiBsZXZl bCBwcm90b2NvbC4gQW5kIGlmDQpvcGVyYXRvcnMgPGJyPg0KJmd0OyAmZ3Q7IGRlcGxveSB0aGlz IGtpbmQgb2YgbmV0d29yaywgdGhleSBjYW4gdXNpbmcgb25lIGluZnJhc3RydWN0dXJlDQpmb3Ig bW9yZSA8YnI+DQomZ3Q7ICZndDsgdGhhbiBvbmUgYXBwbGljYXRpb24uPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyBVc2luZyBTSVAvSU1TIGFzIGV4YW1wbGUsIHVzZXIgbWFuYWdlbWVu dCwgcmVnaXN0cmF0aW9uLCBhdXRoZW50aWNhdGlvbg0KPGJyPg0KJmd0OyAmZ3Q7IGFuZCBQQ0Mo QXV0aG9yaXphdGlvbiwgYW5kIEFjY291bnRpbmcpIGNhbiBiZSBpbXBsZW1lbnRlZCBpbg0KdGhl IDxicj4NCiZndDsgJmd0OyBpbmZyYXN0cnVjdHVyZS4gQW5kIFNJUCBhcHBsaWNhdGlvbiBjYW4g b25seSBmb2N1cyBvbiBzZXNzaW9uL2NhbGwNCjxicj4NCiZndDsgJmd0OyBjb250cm9sLiBGdXJ0 aGVyLCBpZiB0aGUgb3BlcmF0b3JzIHdhbnQgdG8gZGVwbG95IGEgbmV3IGFwcGxpY2F0aW9uDQpi ZXlvbmQgPGJyPg0KJmd0OyAmZ3Q7IFNJUCwgdGhlIGluZnJhc3RydWN0dXJlIHdvdWxkIGJlIHJl dXNhYmxlLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhpcyBjb25jZXB0IGlzIHJh dyBub3csIHNvIEknZCBsaWtlIHRvIGhlYXIgbW9yZSBvZiB5b3VyIGNvbW1lbnRzL2ZlZWxpbmcN Cjxicj4NCiZndDsgJmd0OyB0byBsaWdodCBpdCB1cC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBHYW88YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAuLi48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCm1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppcyBj b25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWlu dGFpbiBzZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRl bnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NCiZndDsgVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQN CmludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hvbSB0aGV5IGFyZQ0KYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3INCm9mIHRoZSBtZXNzYWdl LiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGlu ZGl2aWR1YWwNCnNlbmRlci48YnI+DQomZ3Q7IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0NCnN5c3RlbS48YnI+DQomZ3Q7 IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7IGRpc3BhdGNoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgZGlzcGF0Y2hAaWV0 Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlz cGF0Y2g8YnI+DQo8YnI+DQo8YnI+DQpDdWxsZW4gSmVubmluZ3M8YnI+DQpGb3IgY29ycG9yYXRl IGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOjxicj4NCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9h Ym91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbDxicj4NCjxicj4NCjxicj4N Cjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRp b24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZu YnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3Nv bGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29y Z2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtp cyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92 ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNy ZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJz cDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7 Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7 YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtp dCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7 c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtp bmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5 Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNw O3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3Bs ZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtp biZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNw O2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2Fu ZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4N CjwvcHJlPg== --=_alternative 0007576F4825771A_=-- From Martin.Huelsemann@telekom.de Thu May 6 09:58:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF42B3A6A0D for ; Thu, 6 May 2010 09:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp0Ptk-I3XAs for ; Thu, 6 May 2010 09:58:20 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 2AACF3A698E for ; Thu, 6 May 2010 09:58:19 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 06 May 2010 18:57:45 +0200 Received: from S4DE9JSAAIL.ost.t-com.de ([10.125.177.200]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 18:57:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 May 2010 18:57:45 +0200 Message-ID: In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F1BE4@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Using session-id for dialog correlation Thread-Index: AcrmNuwi6qvbpieVQEqOL1XxIRQ97QEm38AgAAletzAAjt5KMA== References: <430FC6BDED356B4C8498F634416644A91A8A5F1281@mail> <430FC6BDED356B4C8498F634416644A91A8A5F1BE4@mail> From: To: X-OriginalArrivalTime: 06 May 2010 16:57:44.0868 (UTC) FILETIME=[3F902640:01CAED3D] Cc: dispatch@ietf.org, L.Liess@telekom.de Subject: Re: [dispatch] Using session-id for dialog correlation X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 16:58:21 -0000 > -----Urspr=FCngliche Nachricht----- > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Gesendet: Montag, 3. Mai 2010 21:52 > An: H=FClsemann, Martin; dispatch@ietf.org > Betreff: RE: [dispatch] Using session-id for dialog correlation >=20 >=20 >=20 > > -----Original Message----- > > From: Martin.Huelsemann@telekom.de=20 > > [mailto:Martin.Huelsemann@telekom.de] > > Sent: Monday, May 03, 2010 11:19 AM > > To: Hadriel Kaplan; dispatch@ietf.org > > Subject: AW: [dispatch] Using session-id for dialog correlation > >=20 > > > From Hadriel: > > > 1) The Session-ID only provides a single value which is=20 > the same on=20 > > > both "sides" of a B2BUA. The AS *is* a B2BUA, so when it=20 > gets the=20 > > > resource-list with a Session-ID, how does it know which side of=20 > > > session-id 1 to re-INVITE? I.e., how does it know to send a=20 > > > re-INVITE to call-id 1c vs. 1b? The tags were there to=20 > do that, but=20 > > > they no longer match. We could define a flag/param for=20 > Session-ID=20 > > > to indicate uac vs. uas, if you think that would help (I was=20 > > > prepared to do that in the draft at one point, to avoid this=20 > > > problem). > >=20 > > The AS has more capabilities than a normal B2BUA, it also=20 > looks at the=20 > > URI in the ressource list, which is UA-B, so it sends the=20 > re-INVITE to=20 > > the call-id 1c side. >=20 > I think that's brittle - by "brittle" I mean makes=20 > assumptions about the network that will not be true in all=20 > cases and cause it to fail. (maybe) >=20 > For example, assume the following call-flow: >=20 > +----+ +-----+ +-----+ +-----+ +----+ > |UA-A| | AS | |B2BUA| | AS | |UA-B| > +----+ +-----+ +-----+ +-----+ +----+ > | | | | | > |INVITE | | | | > |callid:1a |callid:1b |callid:1c |callid:1d | > |----------->|----------->|---------->|----------->| > |sessid:1 |sessid:1 |sessid:1 |sessid:1 | > | | | | | > |INVITE |re-INVITE | | | > |callid:2a |callid:1b | | | > |----------->|----------->| | | > |sessid:2 |sessid:1 |re-INVITE | | > |RL| |callid:1c |callid:1d | > | | |---------->|----------->| > | | |sessid:1 |sessid:1 | > | | | | | >=20 > Note that now there are *two* AS's in the path. This is like=20 > the original drawing, but the call got routed by the first AS=20 > to a stateful-Proxy or B2BUA, which sent it to a second AS. >=20 > Now imagine that the AS on the left and the one on the right=20 > are the *same* AS. (That's not as unlikely as one would=20 > think, especially in 3gpp) That's too true. >=20 > So the AS gets a RL with wrong info, but a matching=20 > session-id and a RL-entry for UA-B. Would it bypass the=20 > B2BUA in the middle for the re-INVITE, because it finds UA-B=20 > in its local table? So the problem is that the AS now has the choice wether to send the = re-INVITE in dialog 1b or dialog 1d, do I understand correct?=20 If the AS gets involved several times during session initiation with the = same Session ID, it would have to store the related Dialog IDs in order, = and then send the re-INVITE in the first dialog it has linked with the = Session ID (and of course linked with UA-B).=20 A mechanism like this could be part of the solution. But of course this = is not a trivial problem, and we have to consider it very carefully at = the further development of this IMS service. >=20 >=20 > > > 2) What if the AS has multiple dialogs for that same=20 > Session-ID? It=20 > > > could have - for example in a "normal" ad-hoc > > > rfc5366 conference scenario the AS could have invited multiple=20 > > > participants to the same initial conference call, and=20 > could arguably=20 > > > use the same session-id for all legs. So if another=20 > invite referred=20 > > > to that conference call, it would be ambiguous which leg it meant. > >=20 > > A dialog initiator, UAs or AS, should not use the same=20 > Session-ID for=20 > > 2 different dialogs. Maybe you remember the discussion we=20 > had on the=20 > > ML with Salvatore on "session-id" for disagregated media, where we=20 > > came to the conclusion that we should not use the same id. >=20 > I don't remember it, but I'm not sure it matters: take the=20 > example above. The call comes into the AS, goes to a=20 > next-hop B2BUA without forking, gets routed back to the same=20 > AS, and voil=E0: 2 dialogs on the AS with the same session-id. The same as above, the AS would have to order the dialogs somehow. >=20 >=20 > > > 4) In this *particular* scenario the solution is easier: make the=20 > > > B2BUA's understand resource-lists, and make them change the=20 > > > callid/tags in them correctly. After all, that's what's=20 > causing the=20 > > > mismatch at the AS. But isn't this a rather=20 > unlikely/rare scenario? =20 > > > I mean do you really intend every call to go through an=20 > AS, just in=20 > > > case it ends up becoming a 3pcc conf call? > >=20 > > If the AS checks the body with the resource list this would be the=20 > > ideal solution. But most B2BUAs today do not understand=20 > RL.. So we had=20 > > to look for an e2e dialog correlator. >=20 > But you can make them do so. They are under the same=20 > administrative control, and subject to 3GPP specs, no? Actually the behaviour of and the requirements for B2BUAs are not = described very well yet. And the other problem is, they do allready = exist in the network. While we could define requirements for new ones = (and hope vendors will implement), it's very difficult to change the = functionality of existing ones. And this could lead to the situation one = old B2BUA could destroy the whole service. Regards, Martin >=20 > -hadriel >=20 From gonzalo.camarillo@ericsson.com Fri May 7 03:51:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C383A686A for ; Fri, 7 May 2010 03:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.008 X-Spam-Level: X-Spam-Status: No, score=-102.008 tagged_above=-999 required=5 tests=[AWL=-2.009, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo5AVk3xV72h for ; Fri, 7 May 2010 03:51:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CE35E3A6358 for ; Fri, 7 May 2010 03:51:50 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-e5-4be3f0b86738 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 46.08.21861.9B0F3EB4; Fri, 7 May 2010 12:51:37 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 12:50:52 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 12:50:52 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2BC09231C for ; Fri, 7 May 2010 13:50:52 +0300 (EEST) Message-ID: <4BE3F08B.7000006@ericsson.com> Date: Fri, 07 May 2010 13:50:51 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------040901040307090802050206" X-OriginalArrivalTime: 07 May 2010 10:50:52.0439 (UTC) FILETIME=[298BCA70:01CAEDD3] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 10:51:52 -0000 This is a multi-part message in MIME format. --------------040901040307090802050206 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks, I have make a few editorial changes to the Alert Info charter proposal in order to clarify what we want to do (see attachment). Please, let me know if you have some comments. I would like to get the whole IESG to review it relatively soon. One thing that still needs a bit of work is the last sentence of the charter: "Whenever possible, the Alert-Info URNs identifiers should be semantic." The whole charter motivates the use of semantic identifiers but then, in the last sentence, it opens the door to non-semantic identifiers (e.g., urn:alert:duration:short). We need to either focus on working on semantic identifiers only or add more text explaining the reasons why we also want to define non semantic identifiers. Opinions? Thanks, Gonzalo --------------040901040307090802050206 Content-Type: text/plain; name="alert-info-charter-proposal.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="alert-info-charter-proposal.txt" The SIP Alert-Info URN (SAIU) working group is chartered to define a new URN-scheme that allows SIP to convey a particular alert indication using a name instead of a referenced URI. The Alert-Info URN addresses issues encountered in current systems that use the Alert-Info header field. RFC 3261 allows a user agent server or a proxy to provide a specific ringing tone, which can be played to the calling user, as a reference (e.g., an HTTP URI) in the Alert-Info header. In some situations, the calling user may not be able to understand the meaning of the ringing tone being played. For example, a user from a given country may not be familiar with the tone used to indicate call waiting in another country. Similarly, a hearing impaired person may prefer to get a visual call waiting indication instead of a call waiting tone. The following are additional examples of potentially problematic situations: * ringing tones which indicate services as call waiting, call forwarding, blind transfer, automatic callback, call hold, etc. * tones for emergency announcements sent over PBX systems or over the local telephone network. * country-specific ringing tones. * special ringing tones (e.g., ringing tones used in closed in enterprise networks, ringing tones used in some countries or when TDM gateways must map ringing -tones from legacy protocols to SIP at the edge of a network). All these issues can be resolved with a mechanism for user agents to exchange this type of alerting information in a semantic way. For example, a user agent client instructed to inform its user about a call waiting service being provided can use the personalized tones that were previously configured by the user. There are a variety of non-interoperable URI conventions and proprietary Alert-Info header field parameters to provide this type of information today. A standardized set of Alert-Info URNs will increase SIP interoperability for this header field by replacing proprietary conventions. The group will produce a specification that: * describes the problem statement. * describes requirements and use cases. * defines an Alert-Info URN-scheme which allows to resolve the interoperability problems described in the use cases. * defines the specific Alert-Info URNs identifiers for some of the use cases above. The Alert-Info URN scheme must be open, so that additional Alert-Info URN identifiers can be defined later if necessary. Whenever possible, the Alert-Info URNs identifiers should be semantic. Goals and Milestones ==================== Apr 2011 - Alert-Info URN specification to IESG (PS) --------------040901040307090802050206-- From pkyzivat@cisco.com Fri May 7 06:50:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1FB3A6B1C for ; Fri, 7 May 2010 06:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.074 X-Spam-Level: X-Spam-Status: No, score=-9.074 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFxxBBwkq-js for ; Fri, 7 May 2010 06:50:01 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0E5923A6B8B for ; Fri, 7 May 2010 06:47:04 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPu240tAZnwN/2dsb2JhbACeFXGkWplYhRUE X-IronPort-AV: E=Sophos;i="4.52,348,1270425600"; d="scan'208";a="108934635" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 May 2010 13:46:52 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o47DkqP9008369; Fri, 7 May 2010 13:46:52 GMT Message-ID: <4BE419CC.7050507@cisco.com> Date: Fri, 07 May 2010 09:46:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4BE3F08B.7000006@ericsson.com> In-Reply-To: <4BE3F08B.7000006@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 13:50:01 -0000 Gonzalo Camarillo wrote: > Folks, > > I have make a few editorial changes to the Alert Info charter proposal > in order to clarify what we want to do (see attachment). Please, let me > know if you have some comments. I would like to get the whole IESG to > review it relatively soon. > > One thing that still needs a bit of work is the last sentence of the > charter: "Whenever possible, the Alert-Info URNs identifiers should be > semantic." > > The whole charter motivates the use of semantic identifiers but then, in > the last sentence, it opens the door to non-semantic identifiers (e.g., > urn:alert:duration:short). > > We need to either focus on working on semantic identifiers only or add > more text explaining the reasons why we also want to define non semantic > identifiers. Opinions? The distinction between "semantic" and (whatever the converse it - "literal"?) is a little fuzzy. Would it be better to use "brief" or "concise" rather than "duration:short"? Is "Beethoven's Fifth" (as a name) "semantic" or "literal"? I do think there is a place for URNs that are "names" for more literal things like that. But defining those should probably be out of scope for *this* exercise. Thanks, Paul From adam@nostrum.com Fri May 7 06:55:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A5C3A6AD2 for ; Fri, 7 May 2010 06:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_20=-0.74, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwkvPM7-m-hP for ; Fri, 7 May 2010 06:55:24 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id EFF513A6B70 for ; Fri, 7 May 2010 06:54:20 -0700 (PDT) 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 o47Ds4t7047793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 May 2010 08:54:04 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BE41B7C.2030402@nostrum.com> Date: Fri, 07 May 2010 08:54:04 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4BE3F08B.7000006@ericsson.com> In-Reply-To: <4BE3F08B.7000006@ericsson.com> Content-Type: multipart/alternative; boundary="------------080709050806080501010607" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 13:55:25 -0000 This is a multi-part message in MIME format. --------------080709050806080501010607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/7/10 5:50 AM, Gonzalo Camarillo wrote: > Folks, > > I have make a few editorial changes to the Alert Info charter proposal > in order to clarify what we want to do (see attachment). Please, let me > know if you have some comments. I would like to get the whole IESG to > review it relatively soon. > > One thing that still needs a bit of work is the last sentence of the > charter: "Whenever possible, the Alert-Info URNs identifiers should be > semantic." > > The whole charter motivates the use of semantic identifiers but then, in > the last sentence, it opens the door to non-semantic identifiers (e.g., > urn:alert:duration:short). > > We need to either focus on working on semantic identifiers only or add > more text explaining the reasons why we also want to define non semantic > identifiers. Opinions? > I've already explained my thoughts on the topic, but I'll summarize them again. We are going to be interoperating with legacy systems for the foreseeable future. In many of these legacy systems, the mechanism used to convey information is inherently non-semantic. When we interwork this mechanism with those systems, we have two choices: 1. Convert the non-semantic information that has arrived into a non-semantic indication in SIP (e.g., "short"), or 2. Irreversibly discard the information that has arrived. Option #2 leads to a clearly inferior experience. So, while I understand the motivation for defining semantic-only codes in this space, I think we need to allow conveying non-semantic information under limited circumstances. To be clear, I would argue for MUST-level language that prohibits the use of non-semantic indicators except for legacy interoperation -- but I think we need the charter to allow it. /a --------------080709050806080501010607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/7/10 5:50 AM, Gonzalo Camarillo wrote: 
Folks,

I have make a few editorial changes to the Alert Info charter proposal
in order to clarify what we want to do (see attachment). Please, let me
know if you have some comments. I would like to get the whole IESG to
review it relatively soon.

One thing that still needs a bit of work is the last sentence of the
charter: "Whenever possible, the Alert-Info URNs identifiers should be
semantic."

The whole charter motivates the use of semantic identifiers but then, in
the last sentence, it opens the door to non-semantic identifiers (e.g.,
urn:alert:duration:short).

We need to either focus on working on semantic identifiers only or add
more text explaining the reasons why we also want to define non semantic
identifiers. Opinions?

I've already explained my thoughts on the topic, but I'll summarize them again.

We are going to be interoperating with legacy systems for the foreseeable future. In many of these legacy systems, the mechanism used to convey information is inherently non-semantic. When we interwork this mechanism with those systems, we have two choices:

  1. Convert the non-semantic information that has arrived into a non-semantic indication in SIP (e.g., "short"), or
  2. Irreversibly discard the information that has arrived.
Option #2 leads to a clearly inferior experience.

So, while I understand the motivation for defining semantic-only codes in this space, I think we need to allow conveying non-semantic information under limited circumstances. To be clear, I would argue for MUST-level language that prohibits the use of non-semantic indicators except for legacy interoperation -- but I think we need the charter to allow it.

/a
--------------080709050806080501010607-- From john.elwell@siemens-enterprise.com Fri May 7 07:17:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6831B3A6AB4 for ; Fri, 7 May 2010 07:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh2SxsIe7QWm for ; Fri, 7 May 2010 07:17:30 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 2E2CC3A69E0 for ; Fri, 7 May 2010 07:17:22 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-98953; Fri, 7 May 2010 16:17:08 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 6A1AA1EB82AB; Fri, 7 May 2010 16:17:08 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 7 May 2010 16:17:08 +0200 From: "Elwell, John" To: "Leis, Peter (NSN - DE/Munich)" , ext Hadriel Kaplan , "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Date: Fri, 7 May 2010 16:17:07 +0200 Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sADKuJwA Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail> <430FC6BDED356B4C8498F634416644A91A8A5F1711@mail> <430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 14:17:31 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Leis, Peter=20 > (NSN - DE/Munich) > Sent: 03 May 2010 14:32 > To: ext Hadriel Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org > Subject: Re: [dispatch] New I-D:=20 > draft-dawes-dispatch-mediasec-parameter-01 >=20 >=20 > comments inline=20 >=20 > > -----Original Message----- > > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > > Sent: Friday, April 30, 2010 5:47 PM > > To: Leis, Peter (NSN - DE/Munich); Dawes, Peter, VF-Group;=20 > > dispatch@ietf.org > > Subject: RE: [dispatch] New I-D:=20 > > draft-dawes-dispatch-mediasec-parameter-01 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > > > Sent: Friday, April 30, 2010 4:17 AM > > > To: Hadriel Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org > > >=20 > > > > -----Original Message----- > > > > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > Sent: Thursday, April 29, 2010 6:59 PM > > > > > > > > Right, but I'm trying to figure out why that is. I mean > > > > what's the reason the UA needs to know at Registration time > > > > that it's next-hop b2bua can do srtp, instead of letting SDP > > > > handle it? > > > > > > > > I *think* the answer is so that it can later send an INVITE > > > > with an SDP offer without failing the request - is that=20 > > the reason? > > >=20 > > > Right > > =20 > > OK, and I also agree that's a real problem. That issue was=20 > > raised in the IETF in 2006/2007. There was a very simple=20 > > proposal to avoid that, in=20 > > draft-kaplan-mmusic-best-effort-srtp, but the decision of the=20 > > MMUSIC WG was to instead use=20 > > draft-ietf-mmusic-sdp-capability-negotiation to accomplish=20 > > it. That draft is now in the RFC editor's queue. I know=20 > > it's a lot of processing overhead, but that was the decision.=20 > > And I think 3gpp has put support for that into some=20 > release or other. > >=20 >=20 > The requirement in 3GPP is, that the UE has to know whether or not the > network (P-CSCF) will support SDES-SRTP before the session=20 > takes place, > if it wants to employ End2AccessEdge media plane security. This will > ensure that the IMS UE shares the media keys only with the P-CSCF and > not with some other entity.=20 [JRE] Why would the UE "want to employ End2AccessEdge" media plane security= , as opposed to E2E media plane security? I would have thought the UE would= always prefer the latter. Furthermore, the UE should not use keys that hav= e value outside this particular communication session, so if they get passe= d on beyond the P-CSCF, no harm is done. In fact, if they reach the remote = UA, you can end up with E2E security, which would be great from the UE's pe= rspective. > In addition, in 3GPP there is a=20 > requirement > that the UE knows whether media plane security is established between > itself and the network (i.e. End2AccessEdge), or whether media plane > security is established between itself and the far end.=20 [JRE] That would be interesting to know, but it is a more general problem -= any B2BUA can terminate SRTP, and SIP does not provide any mechanism to in= dicate whether SRTP is truly end-to-end or just end-to-some-B2BUA. Also a g= ateway to TDM will terminate SRTP, and SIP does not provide any means of in= dicating whether SRTP is truly end-to-end or end-to-first-TDM-gateway. John >=20 > As you said, CapNeg has a lot of processing overhead, and in addition, > it does not solve the requirements I have listed. >=20 >=20 > >=20 > > > > > RFC 3840 does only cover UA indicating support, but not SBC > > > > indicating > > > > > support. > > > > > > > > Actually, in a way it does. An SBC is a B2BUA. As a UA, it > > > > can indicate feature tags. What it *can't* do is indicate it > > > > in the REGISTER response it sends to the UA. But the UA > > > > could send an OPTIONS to the B2BUA and get it in a feature > > > > tag of the response to the OPTIONS. I know it sucks to send > > > > more SIP messages, but I don't see how to avoid that and be > > > > consistent with the SIP architecture. It's really weird for > > > > a REGISTER response to indicate media capabilities of the=20 > > Registrar. > > >=20 > > > use of OPTIONS was discussed, but due to the additional=20 > > signalling, it > > > was discarded. > >=20 > > Considering all of the other signaling already required=20 > > (subscription to reg-event, subscription to presence, xcap,=20 > > possibly subscription to Config server) isn't an OPTIONS just=20 > > a nit at this point? And that way this could be a general=20 > > solution, instead of a 3gpp-specific one. > >=20 > >=20 > > > The indication of network support for SDES-SRTP in response=20 > > to REGISTER > > > is not included by the registrar, but by the network=20 > > element placed at > > > the edge (the SBC/B2BUA) > >=20 > > I know, but from the UA's perspective the REGISTER response=20 > > is coming from the Registrar, possibly through proxies. =20 > > There's no logical/conceptual model in the IETF for a=20 > > REGISTER response to indicate media capabilities of some=20 > > middle hop of the REGISTER. > >=20 > > -hadriel > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From HKaplan@acmepacket.com Fri May 7 07:27:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4F13A6AE9 for ; Fri, 7 May 2010 07:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55Rph6hKdYey for ; Fri, 7 May 2010 07:27:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 46F2C3A6AB2 for ; Fri, 7 May 2010 07:27:46 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 7 May 2010 10:27:33 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 7 May 2010 10:27:30 -0400 From: Hadriel Kaplan To: Gonzalo Camarillo Date: Fri, 7 May 2010 10:27:27 -0400 Thread-Topic: [dispatch] Alert Info Charter Thread-Index: Acrt7DhpuQsGuBcnRXOPNZra4h6tXQAA7Zpw Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> In-Reply-To: <4BE419CC.7050507@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 14:27:47 -0000 I haven't been following the Alert-Info thread at all, so maybe I'm a good = test-case for whether this charter makes any sense. :) Like Paul, I have absolutely no idea what "semantic" vs. "non-semantic" URN= s are. I'm not sure you want to use the word "semantic" here. I think I k= now what the word "semantic" means: that the thing "has a meaning". But th= e URN "urn:alert:duration:short" does have a meaning; it means play a short= tone, presumably. :) I *think* what you're getting at is you want the URN to indicate the alerti= ng status, like urn:alert:status:call-waiting. So that the UAC receiving t= his URN can play whatever tone it wants for that status. Right? So it's l= ike defining specific SIP response sub-codes of 18x, but in a header instea= d of a response-code number? (or maybe it's like a Reason header value for = a response) Is that correct? -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, May 07, 2010 9:47 AM >=20 > Gonzalo Camarillo wrote: > > Folks, > > > > I have make a few editorial changes to the Alert Info charter proposal > > in order to clarify what we want to do (see attachment). Please, let me > > know if you have some comments. I would like to get the whole IESG to > > review it relatively soon. > > > > One thing that still needs a bit of work is the last sentence of the > > charter: "Whenever possible, the Alert-Info URNs identifiers should be > > semantic." > > > > The whole charter motivates the use of semantic identifiers but then, i= n > > the last sentence, it opens the door to non-semantic identifiers (e.g., > > urn:alert:duration:short). > > > > We need to either focus on working on semantic identifiers only or add > > more text explaining the reasons why we also want to define non semanti= c > > identifiers. Opinions? >=20 > The distinction between "semantic" and (whatever the converse it - > "literal"?) is a little fuzzy. >=20 > Would it be better to use "brief" or "concise" rather than > "duration:short"? >=20 > Is "Beethoven's Fifth" (as a name) "semantic" or "literal"? >=20 > I do think there is a place for URNs that are "names" for more literal > things like that. But defining those should probably be out of scope for > *this* exercise. >=20 > Thanks, > Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From tom111.taylor@bell.net Fri May 7 07:46:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FCFF3A6950 for ; Fri, 7 May 2010 07:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.039 X-Spam-Level: * X-Spam-Status: No, score=1.039 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUn81YS9kRhy for ; Fri, 7 May 2010 07:46:06 -0700 (PDT) Received: from blu0-omc4-s1.blu0.hotmail.com (blu0-omc4-s1.blu0.hotmail.com [65.55.111.140]) by core3.amsl.com (Postfix) with ESMTP id 0BC6A3A67B5 for ; Fri, 7 May 2010 07:46:01 -0700 (PDT) Received: from BLU0-SMTP41 ([65.55.111.135]) by blu0-omc4-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 May 2010 07:45:50 -0700 X-Originating-IP: [70.26.23.183] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.23.183]) by BLU0-SMTP41.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 May 2010 07:45:49 -0700 Date: Fri, 07 May 2010 10:45:46 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2010 14:45:49.0540 (UTC) FILETIME=[FC12B240:01CAEDF3] Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 14:46:07 -0000 I can talk about how this sort of thing was handled on the legacy switching side, for a switch whose innards I am familiar with. The routing tables pointed to what was called a "treatment" (your semantic URN). A second table pointed from the treatment itself to its implementation as tones (or announcements, in the switching case). That's your non-semantic URN. Our software designers had a big problem confusing "reorder treatment", a response to a very specific condition, with "reorder tone", which was used to implement a number of treatments. Anyway, I suggest a conscious effort be made to distinguish the semantics from the implementation, since the counterpart distinction exists on the circuit-switching side. Hadriel Kaplan wrote: > I haven't been following the Alert-Info thread at all, so maybe I'm a good > test-case for whether this charter makes any sense. :) > > Like Paul, I have absolutely no idea what "semantic" vs. "non-semantic" URNs > are. I'm not sure you want to use the word "semantic" here. I think I know > what the word "semantic" means: that the thing "has a meaning". But the URN > "urn:alert:duration:short" does have a meaning; it means play a short tone, > presumably. :) > > I *think* what you're getting at is you want the URN to indicate the alerting > status, like urn:alert:status:call-waiting. So that the UAC receiving this > URN can play whatever tone it wants for that status. Right? So it's like > defining specific SIP response sub-codes of 18x, but in a header instead of a > response-code number? (or maybe it's like a Reason header value for a > response) Is that correct? > > -hadriel > > ... From pkyzivat@cisco.com Fri May 7 07:55:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158E43A6950 for ; Fri, 7 May 2010 07:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.274 X-Spam-Level: X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDiAMndoXNNC for ; Fri, 7 May 2010 07:55:23 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3CE1B3A6B60 for ; Fri, 7 May 2010 07:55:09 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACvG40tAZnwN/2dsb2JhbACRDI0LcaUsmV2FFQQ X-IronPort-AV: E=Sophos;i="4.52,348,1270425600"; d="scan'208";a="108957093" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 May 2010 14:54:56 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o47Esutr000207; Fri, 7 May 2010 14:54:56 GMT Message-ID: <4BE429C0.9010707@cisco.com> Date: Fri, 07 May 2010 10:54:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 14:55:24 -0000 Hadriel Kaplan wrote: > I haven't been following the Alert-Info thread at all, so maybe I'm a good test-case for whether this charter makes any sense. :) > > Like Paul, I have absolutely no idea what "semantic" vs. "non-semantic" URNs are. I'm not sure you want to use the word "semantic" here. I think I know what the word "semantic" means: that the thing "has a meaning". But the URN "urn:alert:duration:short" does have a meaning; it means play a short tone, presumably. :) Well, I *have* been in the discussion. I do know more or less what is intended by "semantic", so now the word doesn't bother me, though there may indeed be some better word to use. My point is really that "semantic" and "literal" (or whatever) are like "big" and "small" - names for ends or directions on a continuum. In this case, "call-waiting" is closer to semantic than "tone:beep-beep". But "tone:beep-beep" is more semantic than an audio clip of the tone is. > I *think* what you're getting at is you want the URN to indicate the alerting status, like urn:alert:status:call-waiting. So that the UAC receiving this URN can play whatever tone it wants for that status. Right? Or something that is not just a tone - flashing lights, something on a display, etc. > So it's like defining specific SIP response sub-codes of 18x, but in a header instead of a response-code number? (or maybe it's like a Reason header value for a response) Is that correct? Yes. > -hadriel > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Friday, May 07, 2010 9:47 AM >> >> Gonzalo Camarillo wrote: >>> Folks, >>> >>> I have make a few editorial changes to the Alert Info charter proposal >>> in order to clarify what we want to do (see attachment). Please, let me >>> know if you have some comments. I would like to get the whole IESG to >>> review it relatively soon. >>> >>> One thing that still needs a bit of work is the last sentence of the >>> charter: "Whenever possible, the Alert-Info URNs identifiers should be >>> semantic." >>> >>> The whole charter motivates the use of semantic identifiers but then, in >>> the last sentence, it opens the door to non-semantic identifiers (e.g., >>> urn:alert:duration:short). >>> >>> We need to either focus on working on semantic identifiers only or add >>> more text explaining the reasons why we also want to define non semantic >>> identifiers. Opinions? >> The distinction between "semantic" and (whatever the converse it - >> "literal"?) is a little fuzzy. >> >> Would it be better to use "brief" or "concise" rather than >> "duration:short"? >> >> Is "Beethoven's Fifth" (as a name) "semantic" or "literal"? >> >> I do think there is a place for URNs that are "names" for more literal >> things like that. But defining those should probably be out of scope for >> *this* exercise. >> >> Thanks, >> Paul >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From HKaplan@acmepacket.com Fri May 7 07:59:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE413A6851 for ; Fri, 7 May 2010 07:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q29Hxzcun1Ci for ; Fri, 7 May 2010 07:59:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0AC9F3A6B08 for ; Fri, 7 May 2010 07:59:50 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 7 May 2010 10:59:37 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 7 May 2010 10:59:36 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Fri, 7 May 2010 10:59:35 -0400 Thread-Topic: [dispatch] Alert Info Charter Thread-Index: Acrt9VbwDFusfctMQ0yXhu0oKOiD7AAAIANw Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D75C3@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <4BE429C0.9010707@cisco.com> In-Reply-To: <4BE429C0.9010707@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 14:59:51 -0000 Oh, sorry I thought you were saying the word "semantic" had no clear meanin= g in this context. -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, May 07, 2010 10:55 AM > To: Hadriel Kaplan > Cc: Gonzalo Camarillo; DISPATCH > Subject: Re: [dispatch] Alert Info Charter >=20 >=20 >=20 > Hadriel Kaplan wrote: > > I haven't been following the Alert-Info thread at all, so maybe I'm a > good test-case for whether this charter makes any sense. :) > > > > Like Paul, I have absolutely no idea what "semantic" vs. "non-semantic" > URNs are. I'm not sure you want to use the word "semantic" here. I thin= k > I know what the word "semantic" means: that the thing "has a meaning". > But the URN "urn:alert:duration:short" does have a meaning; it means play > a short tone, presumably. :) >=20 > Well, I *have* been in the discussion. I do know more or less what is > intended by "semantic", so now the word doesn't bother me, though there > may indeed be some better word to use. >=20 > My point is really that "semantic" and "literal" (or whatever) are like > "big" and "small" - names for ends or directions on a continuum. >=20 > In this case, "call-waiting" is closer to semantic than > "tone:beep-beep". But "tone:beep-beep" is more semantic than an audio > clip of the tone is. >=20 > > I *think* what you're getting at is you want the URN to indicate the > alerting status, like urn:alert:status:call-waiting. So that the UAC > receiving this URN can play whatever tone it wants for that status. > Right? >=20 > Or something that is not just a tone - flashing lights, something on a > display, etc. >=20 > > So it's like defining specific SIP response sub-codes of 18x, but in a > header instead of a response-code number? (or maybe it's like a Reason > header value for a response) Is that correct? >=20 > Yes. >=20 > > -hadriel > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: Friday, May 07, 2010 9:47 AM > >> > >> Gonzalo Camarillo wrote: > >>> Folks, > >>> > >>> I have make a few editorial changes to the Alert Info charter proposa= l > >>> in order to clarify what we want to do (see attachment). Please, let > me > >>> know if you have some comments. I would like to get the whole IESG to > >>> review it relatively soon. > >>> > >>> One thing that still needs a bit of work is the last sentence of the > >>> charter: "Whenever possible, the Alert-Info URNs identifiers should b= e > >>> semantic." > >>> > >>> The whole charter motivates the use of semantic identifiers but then, > in > >>> the last sentence, it opens the door to non-semantic identifiers (e.g= ., > >>> urn:alert:duration:short). > >>> > >>> We need to either focus on working on semantic identifiers only or ad= d > >>> more text explaining the reasons why we also want to define non > semantic > >>> identifiers. Opinions? > >> The distinction between "semantic" and (whatever the converse it - > >> "literal"?) is a little fuzzy. > >> > >> Would it be better to use "brief" or "concise" rather than > >> "duration:short"? > >> > >> Is "Beethoven's Fifth" (as a name) "semantic" or "literal"? > >> > >> I do think there is a place for URNs that are "names" for more literal > >> things like that. But defining those should probably be out of scope > for > >> *this* exercise. > >> > >> Thanks, > >> Paul > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > From pkyzivat@cisco.com Fri May 7 08:12:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA8E528C127 for ; Fri, 7 May 2010 08:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.347 X-Spam-Level: X-Spam-Status: No, score=-9.347 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34-9g0yquVVi for ; Fri, 7 May 2010 08:12:43 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D273828C12A for ; Fri, 7 May 2010 08:11:53 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANvK40tAZnwN/2dsb2JhbACeF3GlMZlXhRUE X-IronPort-AV: E=Sophos;i="4.52,349,1270425600"; d="scan'208";a="108963512" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 May 2010 15:11:41 +0000 Received: from [161.44.182.95] (dhcp-161-44-182-95.cisco.com [161.44.182.95]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o47FBeIt006391; Fri, 7 May 2010 15:11:41 GMT Message-ID: <4BE42DAC.4070009@cisco.com> Date: Fri, 07 May 2010 11:11:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <4BE3F08B.7000006@ericsson.com> <4BE41B7C.2030402@nostrum.com> In-Reply-To: <4BE41B7C.2030402@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:12:47 -0000 Adam Roach wrote: >> We need to either focus on working on semantic identifiers only or add >> more text explaining the reasons why we also want to define non semantic >> identifiers. Opinions? >> > > I've already explained my thoughts on the topic, but I'll summarize them > again. > > We are going to be interoperating with legacy systems for the > foreseeable future. In many of these legacy systems, the mechanism used > to convey information is inherently non-semantic. When we interwork this > mechanism with those systems, we have two choices: > > 1. Convert the non-semantic information that has arrived into a > non-semantic indication in SIP (e.g., "short"), or > 2. Irreversibly discard the information that has arrived. > > Option #2 leads to a clearly inferior experience. > > So, while I understand the motivation for defining semantic-only codes > in this space, I think we need to allow conveying non-semantic > information under limited circumstances. To be clear, I would argue for > MUST-level language that prohibits the use of non-semantic indicators > except for legacy interoperation -- but I think we need the charter to > allow it. Adam, I understand your point in the abstract, but maybe not in practice. If non-semantic (literal) information is arriving, is there any practical way to convert it to a URN of any sort? I.e. if a reorder tone is being received by a gateway in the media stream, can we expect that it will decode that and be able to determine that it ought to convey an Alert-Info: urn:alert:reorder-tone OTOH, if it receives signaling that says "play a reorder-tone" then I agree it would be good to have an alert urn that specifies exactly that. How "semantic" the urn can be for that depends on the specificity of this signal in the environment in which it is received. Thanks, Paul From john.elwell@siemens-enterprise.com Fri May 7 08:15:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1623A6B8C for ; Fri, 7 May 2010 08:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdNEZa8UUHRD for ; Fri, 7 May 2010 08:15:13 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E9E163A6B8D for ; Fri, 7 May 2010 08:14:08 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-99823; Fri, 7 May 2010 17:13:55 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 88FB523F0278; Fri, 7 May 2010 17:13:55 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 7 May 2010 17:13:55 +0200 From: "Elwell, John" To: "Worley, Dale R (Dale)" , Paul Kyzivat , Gonzalo Camarillo Date: Fri, 7 May 2010 17:13:53 +0200 Thread-Topic: [dispatch] Disaggregated media - charter proposal Thread-Index: AcrrkRuJkD7cWJwaTBeex8/IpImwuQAHuS+9AJHwRmA= Message-ID: References: <4BE01BFC.2060902@ericsson.com>,<4BE026A2.9070909@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Disaggregated media - charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:15:22 -0000 I agree that deliverable #2 pre-supposes a particular form of solution, whi= ch until requirements are explored further, and different architectures con= sidered, is premature. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Worley, Dale R (Dale) > Sent: 04 May 2010 18:34 > To: Paul Kyzivat; Gonzalo Camarillo > Cc: DISPATCH > Subject: Re: [dispatch] Disaggregated media - charter proposal >=20 > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org]=20 > On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] >=20 > - deliverable number 2 (labeling multiple dialogs) presumes a > particular outcome to deliverable number 1. > _______________________________________________ >=20 > To be more clear, "deliverable number 2" is a specific=20 > implementation technique, and it is the #1 feature of the=20 > current proposals that people object to. So approving this=20 > charter proposal as it stands would beg the question=20 > regarding the most significant design choice. >=20 > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From HKaplan@acmepacket.com Fri May 7 08:20:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22283A6851 for ; Fri, 7 May 2010 08:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_40=-0.185, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TciUITSJ-Tkl for ; Fri, 7 May 2010 08:20:16 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 42FD83A6B65 for ; Fri, 7 May 2010 08:18:28 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 7 May 2010 11:18:15 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 7 May 2010 11:18:14 -0400 From: Hadriel Kaplan To: Tom Taylor Date: Fri, 7 May 2010 11:18:04 -0400 Thread-Topic: [dispatch] Alert Info Charter Thread-Index: Acrt9AqDPSJHOpqlS/uikzeedETbEwAAe4dw Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:20:18 -0000 Right, that's what I was trying to correlate the issue to. What this charter is really saying to me is that either there are not enoug= h 18x response-code values for all conditions, or there are multiple "sub-c= auses" for a 18x response. In other words, why isn't this just draft-jesske-dispatch-reason-in-respons= es-02, but possibly for protocol=3DSIP?=20 Why don't we just solve these problems one common way? Why do we need one = status code in the SIP response start line, another one in the Reason heade= r, and another one in an Alert-Info header? Is there a need for the Reason= header's status to be different than the Alert-Info's? Inquiring minds wa= nt to know. -hadriel > -----Original Message----- > From: Tom Taylor [mailto:tom111.taylor@bell.net] > Sent: Friday, May 07, 2010 10:46 AM > To: Hadriel Kaplan > Cc: Gonzalo Camarillo; DISPATCH > Subject: Re: [dispatch] Alert Info Charter >=20 > I can talk about how this sort of thing was handled on the legacy > switching > side, for a switch whose innards I am familiar with. The routing tables > pointed > to what was called a "treatment" (your semantic URN). A second table > pointed > from the treatment itself to its implementation as tones (or announcement= s, > in > the switching case). That's your non-semantic URN. Our software designers > had a > big problem confusing "reorder treatment", a response to a very specific > condition, with "reorder tone", which was used to implement a number of > treatments. >=20 > Anyway, I suggest a conscious effort be made to distinguish the semantics > from > the implementation, since the counterpart distinction exists on the > circuit-switching side. >=20 From gonzalo.camarillo@ericsson.com Fri May 7 08:22:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF693A6A59 for ; Fri, 7 May 2010 08:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.284 X-Spam-Level: X-Spam-Status: No, score=-105.284 tagged_above=-999 required=5 tests=[AWL=1.315, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTucKQnw4U79 for ; Fri, 7 May 2010 08:22:00 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 90C1B28C0E6 for ; Fri, 7 May 2010 08:20:47 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-c2-4be42fc11eb3 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 19.C5.08537.1CF24EB4; Fri, 7 May 2010 17:20:33 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 17:20:23 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 17:20:23 +0200 Received: from [131.160.126.129] (rvi2-126-129.lmf.ericsson.se [131.160.126.129]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6D5F6245A; Fri, 7 May 2010 18:20:23 +0300 (EEST) Message-ID: <4BE42FB7.3050200@ericsson.com> Date: Fri, 07 May 2010 18:20:23 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <4BE429C0.9010707@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D75C3@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D75C3@mail> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2010 15:20:23.0886 (UTC) FILETIME=[D07AC6E0:01CAEDF8] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: [dispatch] Terminology WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:22:02 -0000 Hi, thanks all of you for the input. I think all these comments will improve the charter significantly. In past conversations, the term "semantic" was applied to descriptions of events. A semantic URN would describe *what* is happening. For example, the call is waiting, or the callee is busy, or the call waiting queue is one person shorter now. On the other hand, non-semantic URNs would provide rendering instructions. For example, play a short tone followed by a long one. Of course, "play a given symphony" involves a more complex rendering, but is nevertheless non semantic, because the entity receiving such an instruction does not know anything about the event being signaled. Does it need to play that symphony because the callee is busy or because they call is waiting? Now, people who were involved in past discussions are familiar with this terminology, but it is clear from this thread that people reading the charter proposal for the first time did not find it clear enough. We have two options: we stick to the terms "semantic" and "non semantic" and explain more precisely what they mean, or we use different terms. Opinions? Thanks, Gonzalo On 07/05/2010 5:59 PM, Hadriel Kaplan wrote: > > Oh, sorry I thought you were saying the word "semantic" had no clear meaning in this context. > > -hadriel > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, May 07, 2010 10:55 AM >> To: Hadriel Kaplan >> Cc: Gonzalo Camarillo; DISPATCH >> Subject: Re: [dispatch] Alert Info Charter >> >> >> >> Hadriel Kaplan wrote: >>> I haven't been following the Alert-Info thread at all, so maybe I'm a >> good test-case for whether this charter makes any sense. :) >>> >>> Like Paul, I have absolutely no idea what "semantic" vs. "non-semantic" >> URNs are. I'm not sure you want to use the word "semantic" here. I think >> I know what the word "semantic" means: that the thing "has a meaning". >> But the URN "urn:alert:duration:short" does have a meaning; it means play >> a short tone, presumably. :) >> >> Well, I *have* been in the discussion. I do know more or less what is >> intended by "semantic", so now the word doesn't bother me, though there >> may indeed be some better word to use. >> >> My point is really that "semantic" and "literal" (or whatever) are like >> "big" and "small" - names for ends or directions on a continuum. >> >> In this case, "call-waiting" is closer to semantic than >> "tone:beep-beep". But "tone:beep-beep" is more semantic than an audio >> clip of the tone is. >> >>> I *think* what you're getting at is you want the URN to indicate the >> alerting status, like urn:alert:status:call-waiting. So that the UAC >> receiving this URN can play whatever tone it wants for that status. >> Right? >> >> Or something that is not just a tone - flashing lights, something on a >> display, etc. >> >>> So it's like defining specific SIP response sub-codes of 18x, but in a >> header instead of a response-code number? (or maybe it's like a Reason >> header value for a response) Is that correct? >> >> Yes. >> >>> -hadriel >>> >>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Friday, May 07, 2010 9:47 AM >>>> >>>> Gonzalo Camarillo wrote: >>>>> Folks, >>>>> >>>>> I have make a few editorial changes to the Alert Info charter proposal >>>>> in order to clarify what we want to do (see attachment). Please, let >> me >>>>> know if you have some comments. I would like to get the whole IESG to >>>>> review it relatively soon. >>>>> >>>>> One thing that still needs a bit of work is the last sentence of the >>>>> charter: "Whenever possible, the Alert-Info URNs identifiers should be >>>>> semantic." >>>>> >>>>> The whole charter motivates the use of semantic identifiers but then, >> in >>>>> the last sentence, it opens the door to non-semantic identifiers (e.g., >>>>> urn:alert:duration:short). >>>>> >>>>> We need to either focus on working on semantic identifiers only or add >>>>> more text explaining the reasons why we also want to define non >> semantic >>>>> identifiers. Opinions? >>>> The distinction between "semantic" and (whatever the converse it - >>>> "literal"?) is a little fuzzy. >>>> >>>> Would it be better to use "brief" or "concise" rather than >>>> "duration:short"? >>>> >>>> Is "Beethoven's Fifth" (as a name) "semantic" or "literal"? >>>> >>>> I do think there is a place for URNs that are "names" for more literal >>>> things like that. But defining those should probably be out of scope >> for >>>> *this* exercise. >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> 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 alan.b.johnston@gmail.com Fri May 7 08:28:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DF43A6977 for ; Fri, 7 May 2010 08:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_20=-0.74, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLooo7c2zROB for ; Fri, 7 May 2010 08:28:04 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 1197D3A6925 for ; Fri, 7 May 2010 08:28:04 -0700 (PDT) Received: by pxi19 with SMTP id 19so592563pxi.31 for ; Fri, 07 May 2010 08:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=5IlAV104SUjd+zKygopERPsk+CgNHQbepmUGcmhoYxw=; b=jXerUU6DlRAeNqgCVbl7MpASMkz4eJYNSiONrB05hOSQiGkauma8Ex4MqOyPDjwAYj MaagO85THl9lZniGIDRAMsOYClXo6RbMmW++37cmgBo5Rb3hqufI9vlzFB3RdUJNsl55 cLLTdcLDIHu+WH4lvc1l2GR5phwrIOPFNncag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=YeQcQP1neCHOtaS+vt0ecAEtSdlIeuPfP7LomFuk6x9Ia3ikE8S8rlFcL3+ozZgYau fiP1f5YZYm0PKlNqpfjlVVcu9apr+uQlkDMHoguqMk+VQrPpYRpVngCZjKrKE2W/DBmG aDKzsyZrnSui98JC3ErMsD6FtUI7fsYgYpYYs= Received: by 10.141.91.19 with SMTP id t19mr24922rvl.104.1273246068971; Fri, 07 May 2010 08:27:48 -0700 (PDT) Received: from AlanLaptop.sipserver.homeip.net (24-107-197-239.dhcp.stls.mo.charter.com [24.107.197.239]) by mx.google.com with ESMTPS id l29sm958087rvb.4.2010.05.07.08.27.46 (version=SSLv3 cipher=RC4-MD5); Fri, 07 May 2010 08:27:47 -0700 (PDT) Message-ID: <4BE43170.2030401@gmail.com> Date: Fri, 07 May 2010 10:27:44 -0500 From: Alan Johnston User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:28:05 -0000 Hadriel, The answer is that different entities generate the SIP response code/Reason value and select the alerting tone. Alerting is typically chosen locally, either by a UA or by a proxy/PBX for the UA, so this can't use a common mechanism. Also, every vendor implements this today using Alert-Info URI conventions. Unless you are arguing this is fundamentally broken somehow, fixing this interop problem by standardizing a few URNs seems like a very clean solution. Sure, we could invent a grand unifying theory and mechanism, but would it get deployed? - Alan - On 5/7/10 10:18 AM, Hadriel Kaplan wrote: > > Right, that's what I was trying to correlate the issue to. > What this charter is really saying to me is that either there are not enough 18x response-code values for all conditions, or there are multiple "sub-causes" for a 18x response. > > In other words, why isn't this just draft-jesske-dispatch-reason-in-responses-02, but possibly for protocol=SIP? > > Why don't we just solve these problems one common way? Why do we need one status code in the SIP response start line, another one in the Reason header, and another one in an Alert-Info header? Is there a need for the Reason header's status to be different than the Alert-Info's? Inquiring minds want to know. > > -hadriel > > >> -----Original Message----- >> From: Tom Taylor [mailto:tom111.taylor@bell.net] >> Sent: Friday, May 07, 2010 10:46 AM >> To: Hadriel Kaplan >> Cc: Gonzalo Camarillo; DISPATCH >> Subject: Re: [dispatch] Alert Info Charter >> >> I can talk about how this sort of thing was handled on the legacy >> switching >> side, for a switch whose innards I am familiar with. The routing tables >> pointed >> to what was called a "treatment" (your semantic URN). A second table >> pointed >> from the treatment itself to its implementation as tones (or announcements, >> in >> the switching case). That's your non-semantic URN. Our software designers >> had a >> big problem confusing "reorder treatment", a response to a very specific >> condition, with "reorder tone", which was used to implement a number of >> treatments. >> >> Anyway, I suggest a conscious effort be made to distinguish the semantics >> from >> the implementation, since the counterpart distinction exists on the >> circuit-switching side. >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From john.elwell@siemens-enterprise.com Fri May 7 08:28:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D773A698F for ; Fri, 7 May 2010 08:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLgsgj-C0o1g for ; Fri, 7 May 2010 08:28:37 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DEB923A68E4 for ; Fri, 7 May 2010 08:28:36 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-99996; Fri, 7 May 2010 17:28:23 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 85CA523F028E; Fri, 7 May 2010 17:28:23 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 7 May 2010 17:28:23 +0200 From: "Elwell, John" To: Paul Kyzivat , Adam Roach Date: Fri, 7 May 2010 17:28:22 +0200 Thread-Topic: [dispatch] Alert Info Charter Thread-Index: Acrt97vFQJAge1PRRlS+kqAsna1GpgAAWVTw Message-ID: References: <4BE3F08B.7000006@ericsson.com> <4BE41B7C.2030402@nostrum.com> <4BE42DAC.4070009@cisco.com> In-Reply-To: <4BE42DAC.4070009@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:28:38 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 07 May 2010 16:12 > To: Adam Roach > Cc: DISPATCH > Subject: Re: [dispatch] Alert Info Charter >=20 >=20 >=20 > Adam Roach wrote: >=20 > >> We need to either focus on working on semantic identifiers=20 > only or add > >> more text explaining the reasons why we also want to=20 > define non semantic > >> identifiers. Opinions? > >> =20 > >=20 > > I've already explained my thoughts on the topic, but I'll=20 > summarize them=20 > > again. > >=20 > > We are going to be interoperating with legacy systems for the=20 > > foreseeable future. In many of these legacy systems, the=20 > mechanism used=20 > > to convey information is inherently non-semantic. When we=20 > interwork this=20 > > mechanism with those systems, we have two choices: > >=20 > > 1. Convert the non-semantic information that has arrived into a > > non-semantic indication in SIP (e.g., "short"), or > > 2. Irreversibly discard the information that has arrived. > >=20 > > Option #2 leads to a clearly inferior experience. > >=20 > > So, while I understand the motivation for defining=20 > semantic-only codes=20 > > in this space, I think we need to allow conveying non-semantic=20 > > information under limited circumstances. To be clear, I=20 > would argue for=20 > > MUST-level language that prohibits the use of non-semantic=20 > indicators=20 > > except for legacy interoperation -- but I think we need the=20 > charter to=20 > > allow it. >=20 > Adam, I understand your point in the abstract, but maybe not=20 > in practice. >=20 > If non-semantic (literal) information is arriving, is there any=20 > practical way to convert it to a URN of any sort? I.e. if a=20 > reorder tone=20 > is being received by a gateway in the media stream, can we=20 > expect that=20 > it will decode that and be able to determine that it ought to=20 > convey an =09 > Alert-Info: urn:alert:reorder-tone >=20 > OTOH, if it receives signaling that says "play a reorder-tone" then I=20 > agree it would be good to have an alert urn that specifies=20 > exactly that.=20 > How "semantic" the urn can be for that depends on the specificity of=20 > this signal in the environment in which it is received. [JRE] This is confusing me further. What are the semantics of "reorder"? Do= es it mean "rearrange the order", or "place the order again". If the latter= , is that a request or demand to place the order again (e.g., make the call= again), or some sort of statement? I would suggest this word is not a very= good example of a "semantic" tone. I would expect the name of a semantic t= one to clearly indicate a particular condition, rather like SIP response co= des do. John >=20 > Thanks, > Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From gonzalo.camarillo@ericsson.com Fri May 7 08:28:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689593A698F for ; Fri, 7 May 2010 08:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=-1.630, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXP5zdbohvKy for ; Fri, 7 May 2010 08:28:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D1BB03A6957 for ; Fri, 7 May 2010 08:28:37 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-62-4be43198a805 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E4.28.21861.89134EB4; Fri, 7 May 2010 17:28:24 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 17:26:55 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 17:26:55 +0200 Received: from [131.160.126.129] (rvi2-126-129.lmf.ericsson.se [131.160.126.129]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 63D2E245A; Fri, 7 May 2010 18:26:55 +0300 (EEST) Message-ID: <4BE4313F.9030200@ericsson.com> Date: Fri, 07 May 2010 18:26:55 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Adam Roach References: <4BE3F08B.7000006@ericsson.com> <4BE41B7C.2030402@nostrum.com> In-Reply-To: <4BE41B7C.2030402@nostrum.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2010 15:26:55.0410 (UTC) FILETIME=[B9D89920:01CAEDF9] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: [dispatch] Scope: Non-semantic URNs WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:28:39 -0000 Hi, we could add text to the charter explaining that non-semantic (or whatever we decide to call them) URNs are only useful for gateways interworking with the PSTN or similar legacy telephone systems. The WG would only work on them within that limited scope. Would that work for everybody? I believe an explanation along these lines would be much better than the "whenever possible use semantic URNs" we currently have in the charter proposal :o) Thanks, Gonzalo On 07/05/2010 4:54 PM, Adam Roach wrote: > On 5/7/10 5:50 AM, Gonzalo Camarillo wrote: >> Folks, >> >> I have make a few editorial changes to the Alert Info charter proposal >> in order to clarify what we want to do (see attachment). Please, let me >> know if you have some comments. I would like to get the whole IESG to >> review it relatively soon. >> >> One thing that still needs a bit of work is the last sentence of the >> charter: "Whenever possible, the Alert-Info URNs identifiers should be >> semantic." >> >> The whole charter motivates the use of semantic identifiers but then, in >> the last sentence, it opens the door to non-semantic identifiers (e.g., >> urn:alert:duration:short). >> >> We need to either focus on working on semantic identifiers only or add >> more text explaining the reasons why we also want to define non semantic >> identifiers. Opinions? >> > > I've already explained my thoughts on the topic, but I'll summarize them > again. > > We are going to be interoperating with legacy systems for the > foreseeable future. In many of these legacy systems, the mechanism used > to convey information is inherently non-semantic. When we interwork this > mechanism with those systems, we have two choices: > > 1. Convert the non-semantic information that has arrived into a > non-semantic indication in SIP (e.g., "short"), or > 2. Irreversibly discard the information that has arrived. > > Option #2 leads to a clearly inferior experience. > > So, while I understand the motivation for defining semantic-only codes > in this space, I think we need to allow conveying non-semantic > information under limited circumstances. To be clear, I would argue for > MUST-level language that prohibits the use of non-semantic indicators > except for legacy interoperation -- but I think we need the charter to > allow it. > > /a From gonzalo.camarillo@ericsson.com Fri May 7 08:34:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FAC13A6B3D for ; Fri, 7 May 2010 08:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.051 X-Spam-Level: X-Spam-Status: No, score=-104.051 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_20=-0.74, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji+tpaqdbk58 for ; Fri, 7 May 2010 08:34:49 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0A3703A6A59 for ; Fri, 7 May 2010 08:34:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-93-4be4330b12bd Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 17.C6.08537.B0334EB4; Fri, 7 May 2010 17:34:35 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 17:33:42 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 17:33:42 +0200 Received: from [131.160.126.129] (rvi2-126-129.lmf.ericsson.se [131.160.126.129]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EB4E8245A; Fri, 7 May 2010 18:33:41 +0300 (EEST) Message-ID: <4BE432D5.6030907@ericsson.com> Date: Fri, 07 May 2010 18:33:41 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2010 15:33:42.0322 (UTC) FILETIME=[AC627120:01CAEDFA] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: [dispatch] Alternative approach WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:34:51 -0000 Hi, it would be good indeed to get comments on the alternative proposal below. That is, using status codes instead of URNs in order to signal the types of events we are dealing with in the URN proposal. In any case, we need a story to explain why we choose or don't choose such an alternative proposal. Thanks, Gonzalo On 07/05/2010 6:18 PM, Hadriel Kaplan wrote: > > Right, that's what I was trying to correlate the issue to. > What this charter is really saying to me is that either there are not enough 18x response-code values for all conditions, or there are multiple "sub-causes" for a 18x response. > > In other words, why isn't this just draft-jesske-dispatch-reason-in-responses-02, but possibly for protocol=SIP? > > Why don't we just solve these problems one common way? Why do we need one status code in the SIP response start line, another one in the Reason header, and another one in an Alert-Info header? Is there a need for the Reason header's status to be different than the Alert-Info's? Inquiring minds want to know. > > -hadriel > > >> -----Original Message----- >> From: Tom Taylor [mailto:tom111.taylor@bell.net] >> Sent: Friday, May 07, 2010 10:46 AM >> To: Hadriel Kaplan >> Cc: Gonzalo Camarillo; DISPATCH >> Subject: Re: [dispatch] Alert Info Charter >> >> I can talk about how this sort of thing was handled on the legacy >> switching >> side, for a switch whose innards I am familiar with. The routing tables >> pointed >> to what was called a "treatment" (your semantic URN). A second table >> pointed >> from the treatment itself to its implementation as tones (or announcements, >> in >> the switching case). That's your non-semantic URN. Our software designers >> had a >> big problem confusing "reorder treatment", a response to a very specific >> condition, with "reorder tone", which was used to implement a number of >> treatments. >> >> Anyway, I suggest a conscious effort be made to distinguish the semantics >> from >> the implementation, since the counterpart distinction exists on the >> circuit-switching side. >> From john.elwell@siemens-enterprise.com Fri May 7 08:36:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34F23A68F7 for ; Fri, 7 May 2010 08:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzcOP3d7uAbN for ; Fri, 7 May 2010 08:35:59 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 7D0183A6887 for ; Fri, 7 May 2010 08:35:59 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-100162; Fri, 7 May 2010 17:35:46 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 8742123F0278; Fri, 7 May 2010 17:35:46 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 7 May 2010 17:35:46 +0200 From: "Elwell, John" To: Gonzalo Camarillo , Hadriel Kaplan Date: Fri, 7 May 2010 17:35:44 +0200 Thread-Topic: [dispatch] Terminology WAS (Re: Alert Info Charter) Thread-Index: Acrt+Qa7Pk/JOD1lT1aKt6pHL6AspwAAdloQ Message-ID: References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <4BE429C0.9010707@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D75C3@mail> <4BE42FB7.3050200@ericsson.com> In-Reply-To: <4BE42FB7.3050200@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Terminology WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:36:00 -0000 In another place I think they used to talk about "functional" and "stimulus= ". John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 07 May 2010 16:20 > To: Hadriel Kaplan > Cc: DISPATCH > Subject: [dispatch] Terminology WAS (Re: Alert Info Charter) >=20 > Hi, >=20 > thanks all of you for the input. I think all these comments=20 > will improve > the charter significantly. >=20 > In past conversations, the term "semantic" was applied to descriptions > of events. A semantic URN would describe *what* is happening. For > example, the call is waiting, or the callee is busy, or the=20 > call waiting > queue is one person shorter now. >=20 > On the other hand, non-semantic URNs would provide rendering > instructions. For example, play a short tone followed by a=20 > long one. Of > course, "play a given symphony" involves a more complex rendering, but > is nevertheless non semantic, because the entity receiving such an > instruction does not know anything about the event being=20 > signaled. Does > it need to play that symphony because the callee is busy or=20 > because they > call is waiting? >=20 > Now, people who were involved in past discussions are=20 > familiar with this > terminology, but it is clear from this thread that people reading the > charter proposal for the first time did not find it clear enough. We > have two options: we stick to the terms "semantic" and "non semantic" > and explain more precisely what they mean, or we use different terms. > Opinions? >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > On 07/05/2010 5:59 PM, Hadriel Kaplan wrote: > >=20 > > Oh, sorry I thought you were saying the word "semantic" had=20 > no clear meaning in this context. > >=20 > > -hadriel > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, May 07, 2010 10:55 AM > >> To: Hadriel Kaplan > >> Cc: Gonzalo Camarillo; DISPATCH > >> Subject: Re: [dispatch] Alert Info Charter > >> > >> > >> > >> Hadriel Kaplan wrote: > >>> I haven't been following the Alert-Info thread at all, so=20 > maybe I'm a > >> good test-case for whether this charter makes any sense. :) > >>> > >>> Like Paul, I have absolutely no idea what "semantic" vs.=20 > "non-semantic" > >> URNs are. I'm not sure you want to use the word=20 > "semantic" here. I think > >> I know what the word "semantic" means: that the thing "has=20 > a meaning". > >> But the URN "urn:alert:duration:short" does have a=20 > meaning; it means play > >> a short tone, presumably. :) > >> > >> Well, I *have* been in the discussion. I do know more or=20 > less what is > >> intended by "semantic", so now the word doesn't bother me,=20 > though there > >> may indeed be some better word to use. > >> > >> My point is really that "semantic" and "literal" (or=20 > whatever) are like > >> "big" and "small" - names for ends or directions on a continuum. > >> > >> In this case, "call-waiting" is closer to semantic than > >> "tone:beep-beep". But "tone:beep-beep" is more semantic=20 > than an audio > >> clip of the tone is. > >> > >>> I *think* what you're getting at is you want the URN to=20 > indicate the > >> alerting status, like urn:alert:status:call-waiting. So=20 > that the UAC > >> receiving this URN can play whatever tone it wants for that status. > >> Right? > >> > >> Or something that is not just a tone - flashing lights,=20 > something on a > >> display, etc. > >> > >>> So it's like defining specific SIP response sub-codes of=20 > 18x, but in a > >> header instead of a response-code number? (or maybe it's=20 > like a Reason > >> header value for a response) Is that correct? > >> > >> Yes. > >> > >>> -hadriel > >>> > >>> > >>>> -----Original Message----- > >>>> From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Friday, May 07, 2010 9:47 AM > >>>> > >>>> Gonzalo Camarillo wrote: > >>>>> Folks, > >>>>> > >>>>> I have make a few editorial changes to the Alert Info=20 > charter proposal > >>>>> in order to clarify what we want to do (see=20 > attachment). Please, let > >> me > >>>>> know if you have some comments. I would like to get the=20 > whole IESG to > >>>>> review it relatively soon. > >>>>> > >>>>> One thing that still needs a bit of work is the last=20 > sentence of the > >>>>> charter: "Whenever possible, the Alert-Info URNs=20 > identifiers should be > >>>>> semantic." > >>>>> > >>>>> The whole charter motivates the use of semantic=20 > identifiers but then, > >> in > >>>>> the last sentence, it opens the door to non-semantic=20 > identifiers (e.g., > >>>>> urn:alert:duration:short). > >>>>> > >>>>> We need to either focus on working on semantic=20 > identifiers only or add > >>>>> more text explaining the reasons why we also want to define non > >> semantic > >>>>> identifiers. Opinions? > >>>> The distinction between "semantic" and (whatever the=20 > converse it - > >>>> "literal"?) is a little fuzzy. > >>>> > >>>> Would it be better to use "brief" or "concise" rather than > >>>> "duration:short"? > >>>> > >>>> Is "Beethoven's Fifth" (as a name) "semantic" or "literal"? > >>>> > >>>> I do think there is a place for URNs that are "names"=20 > for more literal > >>>> things like that. But defining those should probably be=20 > out of scope > >> for > >>>> *this* exercise. > >>>> > >>>> Thanks, > >>>> Paul > >>>> _______________________________________________ > >>>> 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 > = From john.elwell@siemens-enterprise.com Fri May 7 08:40:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12823A6960 for ; Fri, 7 May 2010 08:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+exba4vjal2 for ; Fri, 7 May 2010 08:40:58 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 95E973A6957 for ; Fri, 7 May 2010 08:40:58 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-100059; Fri, 7 May 2010 17:40:45 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 82C781EB82AB; Fri, 7 May 2010 17:40:45 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 7 May 2010 17:40:45 +0200 From: "Elwell, John" To: Gonzalo Camarillo , Hadriel Kaplan Date: Fri, 7 May 2010 17:40:43 +0200 Thread-Topic: [dispatch] Alternative approach WAS (Re: Alert Info Charter) Thread-Index: Acrt+t4hU7hSppBtSByVbEInWhyApwAAEeSA Message-ID: References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE432D5.6030907@ericsson.com> In-Reply-To: <4BE432D5.6030907@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Alternative approach WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:40:59 -0000 We already have the Alert-Info header field, which is meant to be the vehic= le for ringing and ring-back tones, and I don't see the point in trying to = be disruptive there. On the other hand, some of the semantic tones suggested are for conditions = that might not necessarily coincide with the sending of an INVITE request o= r a 18x response, and hence Alert-Info would not be available as things sta= nd. So it depends whether people really see this work applying outside the = context of INVITE requests and 18x responses. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 07 May 2010 16:34 > To: Hadriel Kaplan > Cc: DISPATCH > Subject: [dispatch] Alternative approach WAS (Re: Alert Info Charter) >=20 > Hi, >=20 > it would be good indeed to get comments on the alternative proposal > below. That is, using status codes instead of URNs in order to signal > the types of events we are dealing with in the URN proposal. >=20 > In any case, we need a story to explain why we choose or don't choose > such an alternative proposal. >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > On 07/05/2010 6:18 PM, Hadriel Kaplan wrote: > >=20 > > Right, that's what I was trying to correlate the issue to. > > What this charter is really saying to me is that either=20 > there are not enough 18x response-code values for all=20 > conditions, or there are multiple "sub-causes" for a 18x response. > >=20 > > In other words, why isn't this just=20 > draft-jesske-dispatch-reason-in-responses-02, but possibly=20 > for protocol=3DSIP?=20 > >=20 > > Why don't we just solve these problems one common way? Why=20 > do we need one status code in the SIP response start line,=20 > another one in the Reason header, and another one in an=20 > Alert-Info header? Is there a need for the Reason header's=20 > status to be different than the Alert-Info's? Inquiring=20 > minds want to know. > >=20 > > -hadriel > >=20 > >=20 > >> -----Original Message----- > >> From: Tom Taylor [mailto:tom111.taylor@bell.net] > >> Sent: Friday, May 07, 2010 10:46 AM > >> To: Hadriel Kaplan > >> Cc: Gonzalo Camarillo; DISPATCH > >> Subject: Re: [dispatch] Alert Info Charter > >> > >> I can talk about how this sort of thing was handled on the legacy > >> switching > >> side, for a switch whose innards I am familiar with. The=20 > routing tables > >> pointed > >> to what was called a "treatment" (your semantic URN). A=20 > second table > >> pointed > >> from the treatment itself to its implementation as tones=20 > (or announcements, > >> in > >> the switching case). That's your non-semantic URN. Our=20 > software designers > >> had a > >> big problem confusing "reorder treatment", a response to a=20 > very specific > >> condition, with "reorder tone", which was used to=20 > implement a number of > >> treatments. > >> > >> Anyway, I suggest a conscious effort be made to=20 > distinguish the semantics > >> from > >> the implementation, since the counterpart distinction exists on the > >> circuit-switching side. > >> >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From gonzalo.camarillo@ericsson.com Fri May 7 08:58:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B043A6ACF for ; Fri, 7 May 2010 08:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.982 X-Spam-Level: X-Spam-Status: No, score=-103.982 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AySVog9xPC2S for ; Fri, 7 May 2010 08:58:28 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4D5FC3A6AE8 for ; Fri, 7 May 2010 08:58:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-e5-4be43880aa66 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 48.98.08537.08834EB4; Fri, 7 May 2010 17:57:52 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 17:56:41 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 17:56:41 +0200 Received: from [131.160.126.129] (rvi2-126-129.lmf.ericsson.se [131.160.126.129]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 20F2D245A; Fri, 7 May 2010 18:56:41 +0300 (EEST) Message-ID: <4BE43838.7070807@ericsson.com> Date: Fri, 07 May 2010 18:56:40 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Elwell, John" , "Worley, Dale R (Dale)" , Paul Kyzivat References: <4BE01BFC.2060902@ericsson.com>, <4BE026A2.9070909@cisco.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------040003050206090607080409" X-OriginalArrivalTime: 07 May 2010 15:56:41.0591 (UTC) FILETIME=[E27E3070:01CAEDFD] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: [dispatch] Revised proposal WAS (Re: Disaggregated media - charter proposal) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:58:29 -0000 This is a multi-part message in MIME format. --------------040003050206090607080409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, thanks for your feedback based on the feedback received, I have revised the charter proposal (see attachment). Does this new revision address your comments? Thanks, Gonzalo --------------040003050206090607080409 Content-Type: text/plain; name="Disaggregated Media Charter Proposal.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Disaggregated Media Charter Proposal.txt" Disaggregated Media WG Charter ------------------------------ Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams coming from different devices under his or her control so that they are treated by the far end of the session as a single media session. Generally, a given participant uses a single device to establish (or participate in) a given multimedia session. Consequently, the SIP signaling to manage the multimedia session and the actual media streams are typically co-located in the same device. In scenarios involving disaggregated media, a user wants to establish a single multimedia session combining different media streams coming from different devices under his or her control. This creates a need to coordinate the exchange of the those media streams within the multimedia session. There are a number of existing mechanisms that can be used to coordinate different devices under user's control and to involve them in the call (e.g. Message Bus (Mbus) [RFC3259], Megaco [ITU-T H.248.1] and SIP 3pcc [RFC3725]). However, these mechanisms are intended to be used in "tightly coupled" scenarios. The use of all those mechanisms requires the presence of a "master" device. That is, at least one among the different devices under the control of the same user must support the control mechanism and be able to become a controller for the other devices in the call. Moreover, the "master" device is supposed to remain involved in the user's session for its entire duration given that performing a handover of the master role is typically cumbersome and sometimes impossible. The objective of this working group is to develop a framework for disaggregated media in "loosely-coupled" scenarios, where no single device needs to remain in the session for its entire duration and no single device needs to act as a master. Coordination among devices in this type of scenario is less tight than in the scenarios described above since they do not assume central elements with complete knowledge of the whole media session. While the framework may describe how to use existing mechanisms (e.g., the SIP REFER method) to coordinate devices, the working group will not develop new device coordination mechanisms. The framework may identify the need for new mechanisms to enable the implementation of loosely-coupled scenarios. In case the need for such new mechanisms is identified, the working group will specify them. Specifically, the proposed working group will develop the following deliverables: 1. A framework document describing key considerations for the exchange of disaggregated media in SIP. The document will include use cases and examples. The document may indentify the need for new mechanisms or extensions to existing mechanisms. 2. Specifications of new mechanisms or extensions to existing mechanisms if the need is identified in the framework. --------------040003050206090607080409-- From pkyzivat@cisco.com Fri May 7 08:59:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671463A6ACF for ; Fri, 7 May 2010 08:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxScwQbgcSdZ for ; Fri, 7 May 2010 08:59:51 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4C0823A6A8B for ; Fri, 7 May 2010 08:59:51 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN7V40tAZnwM/2dsb2JhbACeGHGlW5lPhRUE X-IronPort-AV: E=Sophos;i="4.52,349,1270425600"; d="scan'208";a="109117394" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 May 2010 15:59:38 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o47FxcVY026207; Fri, 7 May 2010 15:59:38 GMT Message-ID: <4BE438EA.4040303@cisco.com> Date: Fri, 07 May 2010 11:59:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Elwell, John" References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE432D5.6030907@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH , Hadriel Kaplan Subject: Re: [dispatch] Alternative approach WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:59:52 -0000 Elwell, John wrote: > We already have the Alert-Info header field, which is meant to be the vehicle for ringing and ring-back tones, and I don't see the point in trying to be disruptive there. I agree. > On the other hand, some of the semantic tones suggested are for conditions that might not necessarily coincide with the sending of an INVITE request or a 18x response, and hence Alert-Info would not be available as things stand. So it depends whether people really see this work applying outside the context of INVITE requests and 18x responses. Currently A-I is restricted to INVITE and 180. I have already proposed that this be relaxed, so that it can be used in 18x. Whether the same "problem" extends beyond that scope is unclear to me. Thanks, Paul > John > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: 07 May 2010 16:34 >> To: Hadriel Kaplan >> Cc: DISPATCH >> Subject: [dispatch] Alternative approach WAS (Re: Alert Info Charter) >> >> Hi, >> >> it would be good indeed to get comments on the alternative proposal >> below. That is, using status codes instead of URNs in order to signal >> the types of events we are dealing with in the URN proposal. >> >> In any case, we need a story to explain why we choose or don't choose >> such an alternative proposal. >> >> Thanks, >> >> Gonzalo >> >> >> On 07/05/2010 6:18 PM, Hadriel Kaplan wrote: >>> Right, that's what I was trying to correlate the issue to. >>> What this charter is really saying to me is that either >> there are not enough 18x response-code values for all >> conditions, or there are multiple "sub-causes" for a 18x response. >>> In other words, why isn't this just >> draft-jesske-dispatch-reason-in-responses-02, but possibly >> for protocol=SIP? >>> Why don't we just solve these problems one common way? Why >> do we need one status code in the SIP response start line, >> another one in the Reason header, and another one in an >> Alert-Info header? Is there a need for the Reason header's >> status to be different than the Alert-Info's? Inquiring >> minds want to know. >>> -hadriel >>> >>> >>>> -----Original Message----- >>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>> Sent: Friday, May 07, 2010 10:46 AM >>>> To: Hadriel Kaplan >>>> Cc: Gonzalo Camarillo; DISPATCH >>>> Subject: Re: [dispatch] Alert Info Charter >>>> >>>> I can talk about how this sort of thing was handled on the legacy >>>> switching >>>> side, for a switch whose innards I am familiar with. The >> routing tables >>>> pointed >>>> to what was called a "treatment" (your semantic URN). A >> second table >>>> pointed >>>> from the treatment itself to its implementation as tones >> (or announcements, >>>> in >>>> the switching case). That's your non-semantic URN. Our >> software designers >>>> had a >>>> big problem confusing "reorder treatment", a response to a >> very specific >>>> condition, with "reorder tone", which was used to >> implement a number of >>>> treatments. >>>> >>>> Anyway, I suggest a conscious effort be made to >> distinguish the semantics >>>> from >>>> the implementation, since the counterpart distinction exists on the >>>> circuit-switching side. >>>> >> _______________________________________________ >> 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 john.elwell@siemens-enterprise.com Fri May 7 09:01:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4C43A6AE8 for ; Fri, 7 May 2010 09:01:44 -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.331, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIfbaKSursci for ; Fri, 7 May 2010 09:01:43 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5D9213A6A8B for ; Fri, 7 May 2010 09:01:42 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-100414; Fri, 7 May 2010 18:01:29 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 9BB2A1EB82AB; Fri, 7 May 2010 18:01:29 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 7 May 2010 18:01:29 +0200 From: "Elwell, John" To: Gonzalo Camarillo , "Worley, Dale R (Dale)" , Paul Kyzivat Date: Fri, 7 May 2010 18:01:27 +0200 Thread-Topic: Revised proposal WAS (Re: [dispatch] Disaggregated media - charter proposal) Thread-Index: Acrt/hIr95V37914RL+p9zIrEbLQJgAAG20A Message-ID: References: <4BE01BFC.2060902@ericsson.com>,<4BE026A2.9070909@cisco.com> <4BE43838.7070807@ericsson.com> In-Reply-To: <4BE43838.7070807@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Revised proposal WAS (Re: Disaggregated media - charter proposal) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 16:01:44 -0000 Yes, thanks. John=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: 07 May 2010 16:57 > To: Elwell, John; Worley, Dale R (Dale); Paul Kyzivat > Cc: DISPATCH > Subject: Revised proposal WAS (Re: [dispatch] Disaggregated=20 > media - charter proposal) >=20 > Hi, >=20 > thanks for your feedback based on the feedback received, I=20 > have revised > the charter proposal (see attachment). Does this new revision address > your comments? >=20 > Thanks, >=20 > Gonzalo > = From pkyzivat@cisco.com Fri May 7 09:11:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7F03A6A8B for ; Fri, 7 May 2010 09:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.272 X-Spam-Level: X-Spam-Status: No, score=-10.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ2pQ2gH-01u for ; Fri, 7 May 2010 09:11:42 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id AA5473A6AE8 for ; Fri, 7 May 2010 09:11:42 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPrX40tAZnwN/2dsb2JhbACeGHGla5lPhRUE X-IronPort-AV: E=Sophos;i="4.52,349,1270425600"; d="scan'208";a="109120665" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 May 2010 16:11:29 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o47GBTge024478; Fri, 7 May 2010 16:11:29 GMT Message-ID: <4BE43BB1.2090406@cisco.com> Date: Fri, 07 May 2010 12:11:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4BE01BFC.2060902@ericsson.com>, <4BE026A2.9070909@cisco.com> <4BE43838.7070807@ericsson.com> In-Reply-To: <4BE43838.7070807@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Revised proposal WAS (Re: Disaggregated media - charter proposal) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 16:11:44 -0000 Gonzalo, Yes, this is acceptable to me. I don't believe that a solution with no master (at least briefly) is possible, or important, I accept that others think so, and I'm willing to hear them out on it. Thanks, Paul Gonzalo Camarillo wrote: > Hi, > > thanks for your feedback based on the feedback received, I have revised > the charter proposal (see attachment). Does this new revision address > your comments? > > Thanks, > > Gonzalo > From gonzalo.camarillo@ericsson.com Fri May 7 09:18:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798963A6A12 for ; Fri, 7 May 2010 09:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.282 X-Spam-Level: X-Spam-Status: No, score=-103.282 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5gSwIOOIkhe for ; Fri, 7 May 2010 09:18:08 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 51BE23A6869 for ; Fri, 7 May 2010 09:18:08 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-a9-4be43d32b1fd Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 24.7B.21861.23D34EB4; Fri, 7 May 2010 18:17:54 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 18:17:14 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 18:17:13 +0200 Received: from [131.160.126.129] (rvi2-126-129.lmf.ericsson.se [131.160.126.129]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DF87D245A; Fri, 7 May 2010 19:17:13 +0300 (EEST) Message-ID: <4BE43D08.7010407@ericsson.com> Date: Fri, 07 May 2010 19:17:12 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <4BE01BFC.2060902@ericsson.com>, <4BE026A2.9070909@cisco.com> <4BE43838.7070807@ericsson.com> <4BE43BB1.2090406@cisco.com> In-Reply-To: <4BE43BB1.2090406@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2010 16:17:13.0926 (UTC) FILETIME=[C1059660:01CAEE00] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Revised proposal WAS (Re: Disaggregated media - charter proposal) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 16:18:09 -0000 Hi Paul, from past discussions, people mentioned scenarios where the "master" (i.e., the entity with complete knowledge of all the devices involved in the session at one end) was the human user. In any case, I agree with you that this is exactly the type of thing that should be discussed in this WG. Thanks, Gonzalo On 07/05/2010 7:11 PM, Paul Kyzivat wrote: > Gonzalo, > > Yes, this is acceptable to me. > > I don't believe that a solution with no master (at least briefly) is > possible, or important, I accept that others think so, and I'm willing > to hear them out on it. > > Thanks, > Paul > > Gonzalo Camarillo wrote: >> Hi, >> >> thanks for your feedback based on the feedback received, I have revised >> the charter proposal (see attachment). Does this new revision address >> your comments? >> >> Thanks, >> >> Gonzalo >> From HKaplan@acmepacket.com Fri May 7 09:42:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E5628B797 for ; Fri, 7 May 2010 09:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[AWL=-1.008, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNoa8foIByS8 for ; Fri, 7 May 2010 09:42:45 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7AE8C3A6B1A for ; Fri, 7 May 2010 09:42:36 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 7 May 2010 12:42:22 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 7 May 2010 12:42:22 -0400 From: Hadriel Kaplan To: Alan Johnston Date: Fri, 7 May 2010 12:42:22 -0400 Thread-Topic: [dispatch] Alert Info Charter Thread-Index: Acrt+e05l7fKkaWTRmS7DNwvEp9sWwAAKeWQ Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> In-Reply-To: <4BE43170.2030401@gmail.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 Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 16:42:47 -0000 > -----Original Message----- > From: Alan Johnston [mailto:alan.b.johnston@gmail.com] > Sent: Friday, May 07, 2010 11:28 AM > To: Hadriel Kaplan >=20 > The answer is that different entities generate the SIP response > code/Reason value and select the alerting tone. Alerting is typically > chosen locally, either by a UA or by a proxy/PBX for the UA, so this > can't use a common mechanism. Right, what you want is the device generating the response indicates the co= ndition, and the UAC receiving the response generates a locally-mapped tone= for that condition. I get that, and it makes a lot of sense to me. So ISTM what we want is for the device generating the SIP response to indic= ate a status code, which the UAC can map to whatever tones it wants. The funny thing is we already have a way to do that. Two ways, in fact: the= message's status-line status-code number, and the Reason header value.=20 I'm not actually proposing the SIP message response status-code be expanded= for this (both because of interop issues and because there aren't enough d= igits in 18x to accommodate all conditions). But I think the Reason header= isn't a bad choice. =20 > Also, every vendor implements this today using Alert-Info URI > conventions. Unless you are arguing this is fundamentally broken > somehow, fixing this interop problem by standardizing a few URNs seems > like a very clean solution. Actually, it *is* broken, in three ways (though they may all be fixable): 1) You can't add more URN values later, because you don't know if the UAC u= nderstands the new URN. Compare this to a status-code model, where you can= treat a new 187 code as a 180 if you don't understand the 187. (although I= suppose you could actually just make the URN a number format, or define th= e format to indicate a default as well, so you can get this property) 2) An Alert-Info header can only appear in 180 responses, and not 182, 183,= etc. I suppose 3261 could be extended though to include it in other respo= nses, though. 3) You can't deploy this new URN scheme in a backwards-compatible fashion i= n practice, unless you have an indicator in the request which states the UA= C supports it. If you have such an indicator, you might as well put this i= n a Reason header instead and not have two different headers to indicate th= e same status. And as it turns out, if you use the Reason header then I do= n't think you need an indicator in the request to begin with. > Sure, we could invent a grand unifying theory and mechanism, but would > it get deployed? If there are real interop problems with Alert-Info, and people really want = to fix them, and it's not much more work... then yes I think it would. I'm= not suggesting a lot of additional work, am I? I don't think using the Reason header alone instead of both is such a big c= hange. Seems simpler to me, in fact. -hadriel From HKaplan@acmepacket.com Fri May 7 09:49:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D463A6B71 for ; Fri, 7 May 2010 09:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZxG-ln0SajG for ; Fri, 7 May 2010 09:49:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3D99C3A6B40 for ; Fri, 7 May 2010 09:47:23 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 7 May 2010 12:47:10 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 7 May 2010 12:47:09 -0400 From: Hadriel Kaplan To: Gonzalo Camarillo , Adam Roach Date: Fri, 7 May 2010 12:47:06 -0400 Thread-Topic: [dispatch] Scope: Non-semantic URNs WAS (Re: Alert Info Charter) Thread-Index: Acrt+fxLryWzMOuQQ9Sr4jwqvsvEpwACtCYw Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7641@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE41B7C.2030402@nostrum.com> <4BE4313F.9030200@ericsson.com> In-Reply-To: <4BE4313F.9030200@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Scope: Non-semantic URNs WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 16:49:04 -0000 Or you could make the charter not pre-suppose a solution. ;) -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Friday, May 07, 2010 11:27 AM > To: Adam Roach >=20 > we could add text to the charter explaining that non-semantic (or > whatever we decide to call them) URNs are only useful for gateways > interworking with the PSTN or similar legacy telephone systems. The WG > would only work on them within that limited scope. Would that work for > everybody? >=20 > I believe an explanation along these lines would be much better than the > "whenever possible use semantic URNs" we currently have in the charter > proposal :o) >=20 > Thanks, >=20 > Gonzalo From brett@broadsoft.com Fri May 7 09:56:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1AD3A6914 for ; Fri, 7 May 2010 09:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+c1j5KWvNAM for ; Fri, 7 May 2010 09:56:46 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id D742C3A68E8 for ; Fri, 7 May 2010 09:56:46 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Fri, 7 May 2010 09:56:34 -0700 From: Brett Tate To: Paul Kyzivat , DISPATCH Date: Fri, 7 May 2010 09:55:37 -0700 Thread-Topic: [dispatch] Alternative approach WAS (Re: Alert Info Charter) Thread-Index: Acrt/mXZactTjHtARNSkWerekX75LQABORiw Message-ID: <747A6506A991724FB09B129B79D5FEB614812DECCC@EXMBXCLUS01.citservers.local> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE432D5.6030907@ericsson.com> <4BE438EA.4040303@cisco.com> In-Reply-To: <4BE438EA.4040303@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] Alternative approach WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 16:56:47 -0000 > Currently A-I is restricted to INVITE and 180. I have already proposed > that this be relaxed, so that it can be used in 18x. >=20 > Whether the same "problem" extends beyond that scope is unclear to me. The scope should likely be extended to allow Alert-Info within UPDATE. It = looks like rfc3261 already allows Alert-Info within re-INVITE. From brett@broadsoft.com Fri May 7 10:27:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C018E3A67C2 for ; Fri, 7 May 2010 10:27:51 -0700 (PDT) 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.308, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dK-d6zVjXCDf for ; Fri, 7 May 2010 10:27:51 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id E54C53A63C9 for ; Fri, 7 May 2010 10:27:50 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Fri, 7 May 2010 10:27:38 -0700 From: Brett Tate To: Paul Kyzivat , DISPATCH Date: Fri, 7 May 2010 10:26:41 -0700 Thread-Topic: [dispatch] Alternative approach WAS (Re: Alert Info Charter) Thread-Index: Acrt/mXZactTjHtARNSkWerekX75LQABORiwAAFx8JA= Message-ID: <747A6506A991724FB09B129B79D5FEB614812DECFE@EXMBXCLUS01.citservers.local> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE432D5.6030907@ericsson.com> <4BE438EA.4040303@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] Alternative approach WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 17:27:51 -0000 Since REFER can be used to originate calls, Alert-Info should likely be val= id within REFER. Since I assume some vendors send Alert-Info within INFO or NOTIFY during a = call waiting notification, Alert-Info potentially should also be valid ther= e. However I guess making it valid could wait until someone officially reg= isters such a usages. > -----Original Message----- > From: Brett Tate > Sent: Friday, May 07, 2010 12:56 PM > To: 'Paul Kyzivat'; DISPATCH > Subject: RE: [dispatch] Alternative approach WAS (Re: Alert Info > Charter) >=20 > > Currently A-I is restricted to INVITE and 180. I have already > proposed > > that this be relaxed, so that it can be used in 18x. > > > > Whether the same "problem" extends beyond that scope is unclear to > me. >=20 > The scope should likely be extended to allow Alert-Info within UPDATE. > It looks like rfc3261 already allows Alert-Info within re-INVITE. From HKaplan@acmepacket.com Fri May 7 10:46:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E0E3A67D4 for ; Fri, 7 May 2010 10:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X228j8+Hyt5V for ; Fri, 7 May 2010 10:46:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 51F7E3A67C2 for ; Fri, 7 May 2010 10:46:08 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 7 May 2010 13:45:53 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 7 May 2010 13:45:52 -0400 From: Hadriel Kaplan To: "Elwell, John" , Gonzalo Camarillo Date: Fri, 7 May 2010 13:45:51 -0400 Thread-Topic: [dispatch] Alternative approach WAS (Re: Alert Info Charter) Thread-Index: Acrt+t4hU7hSppBtSByVbEInWhyApwAAEeSAAAOIttA= Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D767B@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE432D5.6030907@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Alternative approach WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 17:46:09 -0000 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, May 07, 2010 11:41 AM > To: Gonzalo Camarillo; Hadriel Kaplan >=20 > We already have the Alert-Info header field, which is meant to be the > vehicle for ringing and ring-back tones, and I don't see the point in > trying to be disruptive there. I can't tell in what way you mean that. =20 Do you mean it's less disruptive to put a status code into Alert-Info, beca= use people already use Alert-Info URI's for the ringing playback process? = =20 Or do you mean it's less disruptive to leave the Alert-Info for what it was= intended for: to indicate the URI of a ringtone with no semantics, and ins= tead put the status code into something which is actually meant for status = code? And what do you mean by "disruptive"? To me "disruptive" is when interop o= r service issues happen due to the proposed change, but maybe you mean some= thing different? -hadriel From HKaplan@acmepacket.com Fri May 7 11:19:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8443A6978 for ; Fri, 7 May 2010 11:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9XEZz9VDi5k for ; Fri, 7 May 2010 11:18:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 664193A6918 for ; Fri, 7 May 2010 11:13:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 7 May 2010 14:13:38 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 7 May 2010 14:13:38 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Fri, 7 May 2010 14:13:36 -0400 Thread-Topic: What session-id is for Thread-Index: AcqmaCUl73AiWOL4Tr23C8aae28icRHpusyw Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D76A1@mail> References: <010201ca8335$9e5a3de0$db0eb9a0$@us> <1265376915.3931.153.camel@scott> In-Reply-To: <1265376915.3931.153.camel@scott> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] What session-id is for X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 18:19:04 -0000 So I was looking back in the mailing list archive to try to figure out the = background on alert-info URN proposal, and came upon this thread on the Ses= sion-id draft that I hadn't seen. To be clear: the *secure-call-id* draft was just describing a way for Call-= ID to be created by any UAC, such that topology-hiding middleboxes such as = SBC's don't have to go mucking with them. That's all. *Session-ID* is meant to be an end-to-end identifier created by any UA, tha= t goes through ANY form of B2BUA, not just SBC's. I mean App servers, soft= switches, PBX's, IP-IP transcoders, 3PCC servers, MSC's, S-CSCF's, BGCFs, A= LG's, and whatever else sits "in the middle". Frankly if session-id was just for SBC's, I wouldn't bother with an IETF in= ternet draft. I don't care much about interoperating with the other SBC ve= ndors. :) -hadriel > -----Original Message----- > From: Scott Lawrence [mailto:scottlawrenc@avaya.com] > Sent: Friday, February 05, 2010 8:35 AM > To: Spencer Dawkins > Cc: Richard Shockey; Hadriel Kaplan; dispatch@ietf.org > Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id- > 00.txt >=20 > Hadriel Kaplan wrote: >=20 > > >> I've re-submitted a draft I originally submitted to the SIP WG back > > >> when it was in existence. The draft defines a session correlation > > >> identifier for troubleshooting purposes. >=20 > > >> > There are several reasons for having a globally unique session > > >> > identifier for the same SIP session, which can be maintained > across > > >> > B2BUAs and other SIP middle-boxes. This draft proposes a new SIP > > >> > header to carry such a value: Session-ID. >=20 > Spencer Dawkins adds: >=20 > > I'm remembering that Hadriel had two drafts at about the same time - on= e > was > > a BCP on Call-ID, and one was on Session ID, and I'm remembering a lot > of > > confusion during discussions. > > > > So I'm hoping that at least some of the objection was caused by > confusion! > > > > https://datatracker.ietf.org/drafts/draft-kaplan-sip-secure-call-id/ an= d > > https://datatracker.ietf.org/drafts/draft-kaplan-sip-session-id/, just > for > > the record... >=20 > I agree with Hadriel that the 'secure call id' draft actually solves > some different problems (and think that draft should certainly be > progressed - we've already started implementing the ideas in it in some > of our user agents). >=20 > The problem of correlation across middleboxes of various kinds is > certainly an important one, and deserving of attention. >=20 > I'd like to point out that there is another draft that helps with some > of the other more complex scenarios in which one is attempting to > determine the relationship between different sessions: >=20 > http://tools.ietf.org/html/draft-worley-references > The References Header for SIP >=20 > we've also been using this in our products and found it very useful. >=20 > With respect to what to do about the session-id proposal: I think that > in some perfect world that we don't live in, it would be better to adopt > the secure-call-id proposal and also make the rule that such ids MUST > NOT be changed when passing through a B2BUA; the call-id would then have > the characteristics that the session-id needs. I accept, however, that > this big a change to the handling of call-id by existing products is > unlikely. >=20 > It seems to me that session-id as proposed is valuable iff we can reach > a consensus that existing non-proxy middleboxes (whether they are called > SBCs or Application Servers or whatever) will pass these through > unmodified, or at least that in some reasonable time they can be > convinced to start doing so. Based on the discussion to date, I'm not > yet convinced of that... >=20 > I wonder whether or not it's time that we bit the bullet and try to > actually comprehensively write down what the correct and harmful > behaviors for non-proxy middleboxes are? >=20 >=20 From adam@nostrum.com Fri May 7 11:40:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2DD3A6822 for ; Fri, 7 May 2010 11:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_20=-0.74, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgZR78j9MXIL for ; Fri, 7 May 2010 11:40:50 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5A2393A67EC for ; Fri, 7 May 2010 11:40:50 -0700 (PDT) Received: from dn3-110.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 o47IeVbD079699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 May 2010 13:40:32 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BE45E9F.3090905@nostrum.com> Date: Fri, 07 May 2010 13:40:31 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <4BE3F08B.7000006@ericsson.com> <4BE41B7C.2030402@nostrum.com> <4BE42DAC.4070009@cisco.com> In-Reply-To: <4BE42DAC.4070009@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 18:40:52 -0000 On 5/7/10 10:11 AM, Paul Kyzivat wrote: > > > Adam Roach wrote: > >>> We need to either focus on working on semantic identifiers only or add >>> more text explaining the reasons why we also want to define non >>> semantic >>> identifiers. Opinions? >> >> I've already explained my thoughts on the topic, but I'll summarize >> them again. >> >> We are going to be interoperating with legacy systems for the >> foreseeable future. In many of these legacy systems, the mechanism >> used to convey information is inherently non-semantic. When we >> interwork this mechanism with those systems, we have two choices: >> >> 1. Convert the non-semantic information that has arrived into a >> non-semantic indication in SIP (e.g., "short"), or >> 2. Irreversibly discard the information that has arrived. >> >> Option #2 leads to a clearly inferior experience. >> >> So, while I understand the motivation for defining semantic-only >> codes in this space, I think we need to allow conveying non-semantic >> information under limited circumstances. To be clear, I would argue >> for MUST-level language that prohibits the use of non-semantic >> indicators except for legacy interoperation -- but I think we need >> the charter to allow it. > > Adam, I understand your point in the abstract, but maybe not in practice. > > If non-semantic (literal) information is arriving, is there any > practical way to convert it to a URN of any sort? I.e. if a reorder > tone is being received by a gateway in the media stream, can we expect > that it will decode that and be able to determine that it ought to > convey an > Alert-Info: urn:alert:reorder-tone > > OTOH, if it receives signaling that says "play a reorder-tone" then I > agree it would be good to have an alert urn that specifies exactly > that. How "semantic" the urn can be for that depends on the > specificity of this signal in the environment in which it is received. Not interworking with *in-band* tones -- I'm talking about other protocols that include indication of ringing and/or ringback tone in the signaling. For example, TIA/EIA-41-D and 3GPP2 A.S0014 both define a number of tones that end up being used all over the place. Some of these are what we've been calling semantic ("inter-group alerting"), while others clearly aren't ("short-short-long"). A.S0014 defines: 1. Normal Alerting 2. Inter-group Alerting 3. Special/Priority Alerting 4. Ping Ring (abbreviated alert) 5. Abbreviated intercept 6. Abbreviated reorder I think #1 and #4 are covered in the current document, but the others aren't clearly represented. If you throw in the TIA/EIA values, you also have things like: 1. Long (Normal) 2. Short-Short 3. Short-Short-Long 4. Short-Short2 5. Short-Long-Short 6. Short-Short-Short-Short 7. PBX Long (Normal) 8. PBX Short-Short 9. PBX Short-Short-Long 10. PBX Short-Long-Short 11. PBX Short-Short-Short-Short Additionally, A.S0014 allows indication of pitch (high, normal, low) as part of the ringtone designation. /a From pkyzivat@cisco.com Fri May 7 11:46:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160FE3A6919 for ; Fri, 7 May 2010 11:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.527 X-Spam-Level: X-Spam-Status: No, score=-9.527 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMjekJ-PL61Y for ; Fri, 7 May 2010 11:46:22 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BAE453A6923 for ; Fri, 7 May 2010 11:46:07 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIr840tAZnwM/2dsb2JhbACeGXGmOZlShRUE X-IronPort-AV: E=Sophos;i="4.52,349,1270425600"; d="scan'208";a="109165409" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 May 2010 18:45:55 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o47IjsJb020584; Fri, 7 May 2010 18:45:54 GMT Message-ID: <4BE45FE7.8090403@cisco.com> Date: Fri, 07 May 2010 14:45:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Elwell, John" References: <4BE3F08B.7000006@ericsson.com> <4BE41B7C.2030402@nostrum.com> <4BE42DAC.4070009@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 18:46:23 -0000 Elwell, John wrote: > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 07 May 2010 16:12 >> To: Adam Roach >> Cc: DISPATCH >> Subject: Re: [dispatch] Alert Info Charter >> >> >> >> Adam Roach wrote: >> >>>> We need to either focus on working on semantic identifiers >> only or add >>>> more text explaining the reasons why we also want to >> define non semantic >>>> identifiers. Opinions? >>>> >>> I've already explained my thoughts on the topic, but I'll >> summarize them >>> again. >>> >>> We are going to be interoperating with legacy systems for the >>> foreseeable future. In many of these legacy systems, the >> mechanism used >>> to convey information is inherently non-semantic. When we >> interwork this >>> mechanism with those systems, we have two choices: >>> >>> 1. Convert the non-semantic information that has arrived into a >>> non-semantic indication in SIP (e.g., "short"), or >>> 2. Irreversibly discard the information that has arrived. >>> >>> Option #2 leads to a clearly inferior experience. >>> >>> So, while I understand the motivation for defining >> semantic-only codes >>> in this space, I think we need to allow conveying non-semantic >>> information under limited circumstances. To be clear, I >> would argue for >>> MUST-level language that prohibits the use of non-semantic >> indicators >>> except for legacy interoperation -- but I think we need the >> charter to >>> allow it. >> Adam, I understand your point in the abstract, but maybe not >> in practice. >> >> If non-semantic (literal) information is arriving, is there any >> practical way to convert it to a URN of any sort? I.e. if a >> reorder tone >> is being received by a gateway in the media stream, can we >> expect that >> it will decode that and be able to determine that it ought to >> convey an >> Alert-Info: urn:alert:reorder-tone >> >> OTOH, if it receives signaling that says "play a reorder-tone" then I >> agree it would be good to have an alert urn that specifies >> exactly that. >> How "semantic" the urn can be for that depends on the specificity of >> this signal in the environment in which it is received. > [JRE] This is confusing me further. What are the semantics of "reorder"? Does it mean "rearrange the order", or "place the order again". If the latter, is that a request or demand to place the order again (e.g., make the call again), or some sort of statement? I would suggest this word is not a very good example of a "semantic" tone. I would expect the name of a semantic tone to clearly indicate a particular condition, rather like SIP response codes do. Sorry if my reasoning was obscure. I was trying to query Adam about the point he was making, which was explicitly when "semantic" information is not available. So I grabbed something at random (reorder-tone) as an example of something that is *not* semantic. So I do take Adam's point - *if* we have cases where a request to play a particular tone is received, identifying that tone "by name", then maybe there should be a way to include such names in the alert-info as URNs. That would lose less information than either dropping them or rendering them as actual media. (These URNs would not necessarily have to be the same URN scheme as the "semantic" ones. I think that choice should be made based on who is going to administer them.) Thanks, Paul P.S. In certain contexts it may be possible to infer semantics from either a named request for "reorder-tone" or even by decoding media rendering a reorder-tone, *if* you know that in the context where it is received it is only used as an expression of a particular semantic. But certainly that wasn't what Adam meant. If you can infer the semantics, no matter how, then of course you can signal it using the appropriate semantic URN. From adam@nostrum.com Fri May 7 11:47:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803933A6835 for ; Fri, 7 May 2010 11:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtVULIzO2spO for ; Fri, 7 May 2010 11:47:01 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 747353A67EC for ; Fri, 7 May 2010 11:46:57 -0700 (PDT) Received: from dn3-110.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 o47Ikga7080198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 May 2010 13:46:43 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BE46012.1070702@nostrum.com> Date: Fri, 07 May 2010 13:46:42 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Elwell, John" References: <4BE3F08B.7000006@ericsson.com> <4BE41B7C.2030402@nostrum.com> <4BE42DAC.4070009@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 18:47:02 -0000 On 5/7/10 10:28 AM, Elwell, John wrote: > [JRE] This is confusing me further. What are the semantics of "reorder"? http://dictionary.sensagent.com/reorder+tone/en-en/ /a From pkyzivat@cisco.com Fri May 7 11:58:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6981D3A67EC for ; Fri, 7 May 2010 11:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.268 X-Spam-Level: X-Spam-Status: No, score=-10.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Dlx0LAnPek2 for ; Fri, 7 May 2010 11:58:10 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 513F43A67FF for ; Fri, 7 May 2010 11:58:10 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJf/40tAZnwN/2dsb2JhbACeGXGmTJlNhRUE X-IronPort-AV: E=Sophos;i="4.52,349,1270425600"; d="scan'208";a="109028683" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 May 2010 18:57:57 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o47Ivvfp026975; Fri, 7 May 2010 18:57:57 GMT Message-ID: <4BE462BC.6070804@cisco.com> Date: Fri, 07 May 2010 14:58:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <4BE3F08B.7000006@ericsson.com> <4BE41B7C.2030402@nostrum.com> <4BE42DAC.4070009@cisco.com> <4BE45E9F.3090905@nostrum.com> In-Reply-To: <4BE45E9F.3090905@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 18:58:11 -0000 Adam, OK, that is exactly what I was looking for. (I'm just a SIP guy - none of this crufty old telco stuff for me.) I've got no problem with covering such things. The current proposal includes a number of orthogonal "dimensions" that can be provided, and are expected to be "combined" to select what to render. But those are all "semantic" dimensions. This non-semantic sort is at least a different "dimension", and it probably makes little sense to combine it with semantic dimensions. They are most likely mutually exclusive. Thanks, Paul Adam Roach wrote: > On 5/7/10 10:11 AM, Paul Kyzivat wrote: >> >> >> Adam Roach wrote: >> >>>> We need to either focus on working on semantic identifiers only or add >>>> more text explaining the reasons why we also want to define non >>>> semantic >>>> identifiers. Opinions? >>> >>> I've already explained my thoughts on the topic, but I'll summarize >>> them again. >>> >>> We are going to be interoperating with legacy systems for the >>> foreseeable future. In many of these legacy systems, the mechanism >>> used to convey information is inherently non-semantic. When we >>> interwork this mechanism with those systems, we have two choices: >>> >>> 1. Convert the non-semantic information that has arrived into a >>> non-semantic indication in SIP (e.g., "short"), or >>> 2. Irreversibly discard the information that has arrived. >>> >>> Option #2 leads to a clearly inferior experience. >>> >>> So, while I understand the motivation for defining semantic-only >>> codes in this space, I think we need to allow conveying non-semantic >>> information under limited circumstances. To be clear, I would argue >>> for MUST-level language that prohibits the use of non-semantic >>> indicators except for legacy interoperation -- but I think we need >>> the charter to allow it. >> >> Adam, I understand your point in the abstract, but maybe not in practice. >> >> If non-semantic (literal) information is arriving, is there any >> practical way to convert it to a URN of any sort? I.e. if a reorder >> tone is being received by a gateway in the media stream, can we expect >> that it will decode that and be able to determine that it ought to >> convey an >> Alert-Info: urn:alert:reorder-tone >> >> OTOH, if it receives signaling that says "play a reorder-tone" then I >> agree it would be good to have an alert urn that specifies exactly >> that. How "semantic" the urn can be for that depends on the >> specificity of this signal in the environment in which it is received. > > > Not interworking with *in-band* tones -- I'm talking about other > protocols that include indication of ringing and/or ringback tone in the > signaling. For example, TIA/EIA-41-D and 3GPP2 A.S0014 both define a > number of tones that end up being used all over the place. Some of these > are what we've been calling semantic ("inter-group alerting"), while > others clearly aren't ("short-short-long"). > > A.S0014 defines: > > 1. Normal Alerting > 2. Inter-group Alerting > 3. Special/Priority Alerting > 4. Ping Ring (abbreviated alert) > 5. Abbreviated intercept > 6. Abbreviated reorder > > I think #1 and #4 are covered in the current document, but the others > aren't clearly represented. > > If you throw in the TIA/EIA values, you also have things like: > > 1. Long (Normal) > 2. Short-Short > 3. Short-Short-Long > 4. Short-Short2 > 5. Short-Long-Short > 6. Short-Short-Short-Short > 7. PBX Long (Normal) > 8. PBX Short-Short > 9. PBX Short-Short-Long > 10. PBX Short-Long-Short > 11. PBX Short-Short-Short-Short > > > Additionally, A.S0014 allows indication of pitch (high, normal, low) as > part of the ringtone designation. > > /a > From dworley@avaya.com Fri May 7 12:46:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADC283A6842 for ; Fri, 7 May 2010 12:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ntonbv7NSCk for ; Fri, 7 May 2010 12:46:32 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 3328B3A67F6 for ; Fri, 7 May 2010 12:46:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,349,1270440000"; d="scan'208";a="187692921" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 May 2010 15:46:18 -0400 X-IronPort-AV: E=Sophos;i="4.52,349,1270440000"; d="scan'208";a="459958103" 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; 07 May 2010 15:46:17 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Fri, 7 May 2010 15:46:17 -0400 From: "WORLEY, Dale R (Dale)" To: Gonzalo Camarillo , "Elwell, John" , Paul Kyzivat Date: Fri, 7 May 2010 15:45:32 -0400 Thread-Topic: Revised proposal WAS (Re: [dispatch] Disaggregated media - charter proposal) Thread-Index: Acrt/hABF8OIgq8xR9297ZlSTZYbUQAH8rUr Message-ID: References: <4BE01BFC.2060902@ericsson.com>,<4BE026A2.9070909@cisco.com> , <4BE43838.7070807@ericsson.com> In-Reply-To: <4BE43838.7070807@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Revised proposal WAS (Re: Disaggregated media - charter proposal) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 19:46:33 -0000 ________________________________________ From: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] thanks for your feedback based on the feedback received, I have revised the charter proposal (see attachment). Does this new revision address your comments? ________________________________________ Yes, that's better. Dale From gonzalo.camarillo@ericsson.com Fri May 7 13:01:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7C83A6990 for ; Fri, 7 May 2010 13:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.274 X-Spam-Level: X-Spam-Status: No, score=-105.274 tagged_above=-999 required=5 tests=[AWL=1.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrvDf2wcUcxL for ; Fri, 7 May 2010 13:01:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 1642A3A67EC for ; Fri, 7 May 2010 13:01:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-45-4be471899a6d Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E9.14.08537.98174EB4; Fri, 7 May 2010 22:01:13 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 22:00:50 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 22:00:50 +0200 Received: from [131.160.126.129] (rvi2-126-129.lmf.ericsson.se [131.160.126.129]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7CE4C245A; Fri, 7 May 2010 23:00:50 +0300 (EEST) Message-ID: <4BE47171.5030401@ericsson.com> Date: Fri, 07 May 2010 23:00:49 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE41B7C.2030402@nostrum.com> <4BE4313F.9030200@ericsson.com> <430FC6BDED356B4C8498F634416644A91A8A7D7641@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7641@mail> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2010 20:00:50.0845 (UTC) FILETIME=[FE20F4D0:01CAEE1F] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Scope: Non-semantic URNs WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 20:01:29 -0000 Hi, it is not really about presupposing a solution. It is about motivating what we want to specify. It is just weird to have a charter that uses several paragraphs justifying the need for semantic URNs and then in the last line says that non-semantic URNs are also in scope without providing any justification for them. Cheers, Gonzalo On 07/05/2010 7:47 PM, Hadriel Kaplan wrote: > > Or you could make the charter not pre-suppose a solution. ;) > > -hadriel > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Gonzalo Camarillo >> Sent: Friday, May 07, 2010 11:27 AM >> To: Adam Roach >> >> we could add text to the charter explaining that non-semantic (or >> whatever we decide to call them) URNs are only useful for gateways >> interworking with the PSTN or similar legacy telephone systems. The WG >> would only work on them within that limited scope. Would that work for >> everybody? >> >> I believe an explanation along these lines would be much better than the >> "whenever possible use semantic URNs" we currently have in the charter >> proposal :o) >> >> Thanks, >> >> Gonzalo From HKaplan@acmepacket.com Fri May 7 18:54:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE2D3A659A for ; Fri, 7 May 2010 18:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2lR0fAUlbbK for ; Fri, 7 May 2010 18:54:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EAD673A6407 for ; Fri, 7 May 2010 18:54:07 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 7 May 2010 21:53:55 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 7 May 2010 21:53:52 -0400 From: Hadriel Kaplan To: Gonzalo Camarillo Date: Fri, 7 May 2010 21:53:52 -0400 Thread-Topic: [dispatch] Scope: Non-semantic URNs WAS (Re: Alert Info Charter) Thread-Index: AcruIBlc13tq1UbBRzuxzm2dvfXduAADz2Rg Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7756@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE41B7C.2030402@nostrum.com> <4BE4313F.9030200@ericsson.com> <430FC6BDED356B4C8498F634416644A91A8A7D7641@mail> <4BE47171.5030401@ericsson.com> In-Reply-To: <4BE47171.5030401@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Scope: Non-semantic URNs WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 01:54:09 -0000 Sorry for the confusion - I meant not pre-suppose the solution uses a URN i= n the Alert-Info header to begin with. Since what you really want is effec= tively a status code, it seemed silly to me to have two or more "status cod= es" in the same message, in different fields. It's like the old "do what I= mean not what I say", only here we have multiple things you say, each comp= eting to be the one you really mean. In particular, there's another I-D draft-jesske-dispatch-reason-in-response= s-02, which could also solve the problem, but the charter would rule it out= because the charter defines the solution. Or think of it another way: per= haps the Alert-Info solution can accommodate the needs of the reason-in-res= ponses draft as well. -hadriel > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Friday, May 07, 2010 4:01 PM > To: Hadriel Kaplan >=20 > it is not really about presupposing a solution. It is about motivating > what we want to specify. It is just weird to have a charter that uses > several paragraphs justifying the need for semantic URNs and then in the > last line says that non-semantic URNs are also in scope without > providing any justification for them. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > On 07/05/2010 7:47 PM, Hadriel Kaplan wrote: > > > > Or you could make the charter not pre-suppose a solution. ;) > > > > -hadriel From gonzalo.camarillo@ericsson.com Fri May 7 23:26:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204B33A68C8 for ; Fri, 7 May 2010 23:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.289 X-Spam-Level: X-Spam-Status: No, score=-105.289 tagged_above=-999 required=5 tests=[AWL=1.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6dsu+8HRnme for ; Fri, 7 May 2010 23:26:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2686F3A6836 for ; Fri, 7 May 2010 23:26:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-b3-4be503ee054a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E5.38.08537.EE305EB4; Sat, 8 May 2010 08:25:50 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 May 2010 08:25:00 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 May 2010 08:24:59 +0200 Received: from [131.160.126.129] (rvi2-126-129.lmf.ericsson.se [131.160.126.129]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AD5AF254A; Sat, 8 May 2010 09:24:59 +0300 (EEST) Message-ID: <4BE503B9.4020904@ericsson.com> Date: Sat, 08 May 2010 09:24:57 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE41B7C.2030402@nostrum.com> <4BE4313F.9030200@ericsson.com> <430FC6BDED356B4C8498F634416644A91A8A7D7641@mail> <4BE47171.5030401@ericsson.com> <430FC6BDED356B4C8498F634416644A91A8A7D7756@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7756@mail> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 May 2010 06:25:00.0037 (UTC) FILETIME=[2F962B50:01CAEE77] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Scope: Non-semantic URNs WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 06:26:06 -0000 Hi Hadriel, yes, I also think we should discuss that. That is why I changed the subject lines in my replies so that the threads do not get too confusing ;o)... I called the discussion below "Alternative Approach", as opposed to, for example, this one (Scope: Non-semantic URNs), which is about the scope of the effort. Thanks, Gonzalo On 08/05/2010 4:53 AM, Hadriel Kaplan wrote: > > Sorry for the confusion - I meant not pre-suppose the solution uses a URN in the Alert-Info header to begin with. Since what you really want is effectively a status code, it seemed silly to me to have two or more "status codes" in the same message, in different fields. It's like the old "do what I mean not what I say", only here we have multiple things you say, each competing to be the one you really mean. > > In particular, there's another I-D draft-jesske-dispatch-reason-in-responses-02, which could also solve the problem, but the charter would rule it out because the charter defines the solution. Or think of it another way: perhaps the Alert-Info solution can accommodate the needs of the reason-in-responses draft as well. > > -hadriel > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Friday, May 07, 2010 4:01 PM >> To: Hadriel Kaplan >> >> it is not really about presupposing a solution. It is about motivating >> what we want to specify. It is just weird to have a charter that uses >> several paragraphs justifying the need for semantic URNs and then in the >> last line says that non-semantic URNs are also in scope without >> providing any justification for them. >> >> Cheers, >> >> Gonzalo >> >> >> On 07/05/2010 7:47 PM, Hadriel Kaplan wrote: >>> >>> Or you could make the charter not pre-suppose a solution. ;) >>> >>> -hadriel From HKaplan@acmepacket.com Sat May 8 08:09:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15E728C0D8 for ; Sat, 8 May 2010 08:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8kAPsupJNG0 for ; Sat, 8 May 2010 08:09:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D10AE28C0CE for ; Sat, 8 May 2010 08:09:53 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 8 May 2010 11:09:41 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 8 May 2010 11:09:40 -0400 From: Hadriel Kaplan To: Gonzalo Camarillo Date: Sat, 8 May 2010 11:09:39 -0400 Thread-Topic: Proposed alert-info charter text for Response code (was: Status codes vs Alert-Info URNs) Thread-Index: AcrufVHgAXrZncXlQ0mYldcfw1cRvQAQaglw Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D776C@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE50DA7.9050002@gmail.com> In-Reply-To: <4BE50DA7.9050002@gmail.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 Subject: [dispatch] Proposed alert-info charter text for Response code (was: Status codes vs Alert-Info URNs) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 15:09:54 -0000 Proposed text for why the SIP Response Status-Code in particular is not use= ful: "While the SIP Response 18x Status-Code in the Status-Line does offer seman= tic indication of the alerting state, it is not useful for solving this cha= rter's problems because there aren't enough numeric values available to ind= icate all of the possible semantic alerting conditions. Furthermore, it ca= n only be indicated in a SIP Response message, whereas this charter's scope= covers Requests as well." -hadriel > -----Original Message----- > From: Gonzalo Camarillo [mailto:gcamaril@gmail.com] > Sent: Saturday, May 08, 2010 3:07 AM >=20 > As Hadriel indicates, semantic indications (i.e., your call is in a > queue) in SIP have been traditionally provided in status codes. If we > decided to use Alert-Info URNs instead, we would need to explain why in > the charter. From HKaplan@acmepacket.com Sat May 8 08:30:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8F03A6AAD for ; Sat, 8 May 2010 08:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbcjgmB0nRyY for ; Sat, 8 May 2010 08:30:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D5B613A6950 for ; Sat, 8 May 2010 08:30:17 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 8 May 2010 11:30:05 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 8 May 2010 11:30:04 -0400 From: Hadriel Kaplan To: Gonzalo Camarillo Date: Sat, 8 May 2010 11:30:03 -0400 Thread-Topic: Which messages for Alert-info (Was: Status codes vs Alert-Info URNs) Thread-Index: AcrufVHgAXrZncXlQ0mYldcfw1cRvQAQ1WDg Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7770@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE50DA7.9050002@gmail.com> In-Reply-To: <4BE50DA7.9050002@gmail.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 Subject: [dispatch] Which messages for Alert-info (Was: Status codes vs Alert-Info URNs) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 15:30:19 -0000 > -----Original Message----- > From: Gonzalo Camarillo [mailto:gcamaril@gmail.com] > Sent: Saturday, May 08, 2010 3:07 AM > To: Hadriel Kaplan >=20 > To make this decision, we also need to agree on which messages need to > carry these semantic indications. It is only INVITEs and 180 responses, > INVITEs and 1xx responses, or something else? RESPONSES: If you don't support it in the 181, 182 and 183, we'd have to explain why n= ot. Because the use-cases for call-forwarding and call-waiting are explici= tly indicated in the charter, and afaik those *are* 181 and 182. And 183 i= s supposed to be the response code used when 180/181/182 are not semantical= ly correct, so again it seems appropriate for this type of thing. REQUESTS: You may want it to be available in a BYE as well. For example, disconnecte= d calls due to error cases sometimes get special tones.=20 Brett mentioned the UPDATE method, since re-INVITE is covered, which seems = reasonable. He also mentioned the REFER method, though I'm not sure in what way he mean= t it. (ie, is it for the receiver of the REFER, or is it meant to be in the= INVITE created from it) He also said "Since I assume some vendors send Alert-Info within INFO or NO= TIFY during a call waiting notification, Alert-Info potentially should also= be valid there. However I guess making it valid could wait until someone = officially registers such a usages." Personally I don't see any reason to restrict what methods it's allowed to = be put into - it's always up to the receiver to decide if it wants to use i= t anyway. It doesn't affect dialog state, so what's the harm? -hadriel From HKaplan@acmepacket.com Sat May 8 13:36:45 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1BD3A6800 for ; Sat, 8 May 2010 13:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPCE4RD7uUOZ for ; Sat, 8 May 2010 13:36:44 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E51453A67F6 for ; Sat, 8 May 2010 13:36:43 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 8 May 2010 16:36:29 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 8 May 2010 16:36:24 -0400 From: Hadriel Kaplan To: DISPATCH Date: Sat, 8 May 2010 16:35:59 -0400 Thread-Topic: Session-ID charter proposal Thread-Index: Acru7hEeWNeW30tuRSO6mKAMMzClGg== Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 20:36:45 -0000 Howdy, I have asked the DISPATCH chairs what to do with Session-ID, given the feed= back I received to make it a standards-track vs. individual informational s= ubmission. There is no obvious current WG for this work, so they asked me = to post a strawman charter proposal, which I propose as follows: SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCO= TCH) Charter: ---------------------------------- The SIPSCOTCH working group is chartered to define a mechanism that allows = operators and monitoring equipment to correlate SIP messages and dialogs of= the same higher-level end-to-end "session" or "message-flow". In particul= ar, the mechanism must be able to allow such correlation across SIP B2BUAs = of as many functional types as possible, such as Application Servers, Softs= witches, PBXs, SBCs, etc. Although other solutions may be possible, this working group will focus on = defining a new SIP Header field for such a purpose, similar to the Call-ID = header field, in order to provide a simple, easily deployable mechanism whi= ch can work across SIP domains. The SIP Call-ID header field value itself i= s not usable for such correlation, because many B2BUAs must create a new Ca= ll-ID value on their UAC "side" in order to function properly, and to compl= y with the rules of RFC 3261.=20 It should be noted that certain SIP B2BUAs perform a "topology-hiding" func= tion, as described in RFC 5853. The working group will take such functions= into account for the correlation mechanism, as well as provide guidance fo= r implementers of the mechanism to avoid triggering such a function for the= mechanism's header field value. Lastly, although in certain environments such a mechanism may be usable for= dialog correlation in SIP state machines, it is not the goal of this worki= ng group to address that usage. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dec 2010 - New header specification to IESG (PS) From gonzalo.camarillo@ericsson.com Sun May 9 00:51:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192B53A6819 for ; Sun, 9 May 2010 00:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.508 X-Spam-Level: X-Spam-Status: No, score=-101.508 tagged_above=-999 required=5 tests=[AWL=-2.501, BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSTJCzlzmYDc for ; Sun, 9 May 2010 00:51:22 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D307D3A6781 for ; Sun, 9 May 2010 00:51:21 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-c5-4be6696cf09c Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D9.FA.21861.C6966EB4; Sun, 9 May 2010 09:51:08 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 May 2010 09:49:47 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 May 2010 09:49:48 +0200 Received: from [131.160.126.129] (rvi2-126-129.lmf.ericsson.se [131.160.126.129]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DEED3254A; Sun, 9 May 2010 10:49:46 +0300 (EEST) Message-ID: <4BE5418F.1010005@ericsson.com> Date: Sat, 08 May 2010 13:48:47 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2010 07:49:48.0109 (UTC) FILETIME=[32BA17D0:01CAEF4C] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: [dispatch] Status codes vs Alert-Info URNs WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 07:51:23 -0000 Hi, this is the most important issue we have to resolve before I revise the charter again in order to get it reviewed by the IESG. Let me try and summarize the discussions so far: RFC3261 defines Alert-Info for non-semantic indications (e.g., you should play this particular tone). Extending it to describe those non-semantic indications (e.g., play a short tone followed by a long one) seems not to be controversial. It seems we want to scope those extensions to interworking situations, though. As Hadriel indicates, semantic indications (i.e., your call is in a queue) in SIP have been traditionally provided in status codes. If we decided to use Alert-Info URNs instead, we would need to explain why in the charter. To make this decision, we also need to agree on which messages need to carry these semantic indications. It is only INVITEs and 180 responses, INVITEs and 1xx responses, or something else? Another conversation we have had a few times in the context of allowing Reason header fields in responses is what happens when we carry two semantic indicators about the status of a given call (e.g., the status code and a URN, or the status code and another status code in a Reason header field). Thinking of this can be useful in the context of chartering this WG as well. Thanks, Gonzalo On 07/05/2010 7:42 PM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Alan Johnston [mailto:alan.b.johnston@gmail.com] >> Sent: Friday, May 07, 2010 11:28 AM >> To: Hadriel Kaplan >> >> The answer is that different entities generate the SIP response >> code/Reason value and select the alerting tone. Alerting is typically >> chosen locally, either by a UA or by a proxy/PBX for the UA, so this >> can't use a common mechanism. > > Right, what you want is the device generating the response indicates the condition, and the UAC receiving the response generates a locally-mapped tone for that condition. I get that, and it makes a lot of sense to me. > > So ISTM what we want is for the device generating the SIP response to indicate a status code, which the UAC can map to whatever tones it wants. > > The funny thing is we already have a way to do that. Two ways, in fact: the message's status-line status-code number, and the Reason header value. > > I'm not actually proposing the SIP message response status-code be expanded for this (both because of interop issues and because there aren't enough digits in 18x to accommodate all conditions). But I think the Reason header isn't a bad choice. > > >> Also, every vendor implements this today using Alert-Info URI >> conventions. Unless you are arguing this is fundamentally broken >> somehow, fixing this interop problem by standardizing a few URNs seems >> like a very clean solution. > > Actually, it *is* broken, in three ways (though they may all be fixable): > > 1) You can't add more URN values later, because you don't know if the UAC understands the new URN. Compare this to a status-code model, where you can treat a new 187 code as a 180 if you don't understand the 187. (although I suppose you could actually just make the URN a number format, or define the format to indicate a default as well, so you can get this property) > > 2) An Alert-Info header can only appear in 180 responses, and not 182, 183, etc. I suppose 3261 could be extended though to include it in other responses, though. > > 3) You can't deploy this new URN scheme in a backwards-compatible fashion in practice, unless you have an indicator in the request which states the UAC supports it. If you have such an indicator, you might as well put this in a Reason header instead and not have two different headers to indicate the same status. And as it turns out, if you use the Reason header then I don't think you need an indicator in the request to begin with. > > >> Sure, we could invent a grand unifying theory and mechanism, but would >> it get deployed? > > If there are real interop problems with Alert-Info, and people really want to fix them, and it's not much more work... then yes I think it would. I'm not suggesting a lot of additional work, am I? > > I don't think using the Reason header alone instead of both is such a big change. Seems simpler to me, in fact. > > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From gonzalo.camarillo@ericsson.com Sun May 9 01:03:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E4D3A681F for ; Sun, 9 May 2010 01:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.976 X-Spam-Level: X-Spam-Status: No, score=-103.976 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1TqHpcZt40Q for ; Sun, 9 May 2010 01:03:37 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C272E3A63D3 for ; Sun, 9 May 2010 01:03:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-15-4be66c4b4213 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D0.2B.08537.B4C66EB4; Sun, 9 May 2010 10:03:23 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 May 2010 10:03:06 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 May 2010 10:03:06 +0200 Received: from [131.160.126.129] (rvi2-126-129.lmf.ericsson.se [131.160.126.129]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 024BE254A; Sun, 9 May 2010 11:03:04 +0300 (EEST) Message-ID: <4BE66C34.6020502@ericsson.com> Date: Sun, 09 May 2010 11:03:00 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE50DA7.9050002@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D776C@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D776C@mail> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2010 08:03:06.0258 (UTC) FILETIME=[0E75F720:01CAEF4E] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Proposed alert-info charter text for Response code X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 08:03:38 -0000 Hi, inline: On 08/05/2010 6:09 PM, Hadriel Kaplan wrote: > > Proposed text for why the SIP Response Status-Code in particular is > not useful: > > "While the SIP Response 18x Status-Code in the Status-Line does offer > semantic indication of the alerting state, it is not useful for > solving this charter's problems because there aren't enough numeric > values available to indicate all of the possible semantic alerting > conditions. yes, this is a limitation... but it could be resolved relatively easily. In fact, there were discussions about how to extend the status code namespace some time ago. > Furthermore, it can only be indicated in a SIP Response > message, whereas this charter's scope covers Requests as well." yes, that explains why the "status line" cannot be used for this... but Reason header fields can carry status codes in some requests (they could be extended to cover INVITEs as well if needed). In summary, Hadriel has identified two limitations about using status codes for this. Is defining URNs a better or a worse solution than specifying ways to overcome these limitations? As indicated in this thread before, we need to look at backwards compatibility issues as well so that whatever we define has as many chances as possible to be deployed. Thanks, Gonzalo From peter.musgrave@magorcorp.com Sun May 9 04:30:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A123A68DE for ; Sun, 9 May 2010 04:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.291 X-Spam-Level: X-Spam-Status: No, score=0.291 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sGZXLesXf-6 for ; Sun, 9 May 2010 04:30:26 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 0FF5E3A6891 for ; Sun, 9 May 2010 04:30:13 -0700 (PDT) Received: by gwaa12 with SMTP id a12so1505339gwa.31 for ; Sun, 09 May 2010 04:29:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.235.9 with SMTP id i9mr5835984ybh.239.1273404599553; Sun, 09 May 2010 04:29:59 -0700 (PDT) Received: by 10.150.58.14 with HTTP; Sun, 9 May 2010 04:29:59 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> Date: Sun, 9 May 2010 07:29:59 -0400 Message-ID: From: Peter Musgrave To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 11:30:27 -0000 Hi Hadrial, Draft charter seems to hit the right points. Is it worth noting that the solution must ensure endpoint anonymity - or is it ok to leave that for the draft? (At first it seemed bizarre to create a WG for a single doc - but after rereading a bunch of RAI charters I too could not really see where else this could fit). Peter Musgrave On Sat, May 8, 2010 at 4:35 PM, Hadriel Kaplan wro= te: > Howdy, > I have asked the DISPATCH chairs what to do with Session-ID, given the fe= edback I received to make it a standards-track vs. individual informational= submission. =A0There is no obvious current WG for this work, so they asked= me to post a strawman charter proposal, which I propose as follows: > > > SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPS= COTCH) Charter: > ---------------------------------- > The SIPSCOTCH working group is chartered to define a mechanism that allow= s operators and monitoring equipment to correlate SIP messages and dialogs = of the same higher-level end-to-end "session" or "message-flow". =A0In part= icular, the mechanism must be able to allow such correlation across SIP B2B= UAs of as many functional types as possible, such as Application Servers, S= oftswitches, PBXs, SBCs, etc. > > Although other solutions may be possible, this working group will focus o= n defining a new SIP Header field for such a purpose, similar to the Call-I= D header field, in order to provide a simple, easily deployable mechanism w= hich can work across SIP domains. The SIP Call-ID header field value itself= is not usable for such correlation, because many B2BUAs must create a new = Call-ID value on their UAC "side" in order to function properly, and to com= ply with the rules of RFC 3261. > > It should be noted that certain SIP B2BUAs perform a "topology-hiding" fu= nction, as described in RFC 5853. =A0The working group will take such funct= ions into account for the correlation mechanism, as well as provide guidanc= e for implementers of the mechanism to avoid triggering such a function for= the mechanism's header field value. > > Lastly, although in certain environments such a mechanism may be usable f= or dialog correlation in SIP state machines, it is not the goal of this wor= king group to address that usage. > > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dec 2010 - New header specification to IESG (PS) > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From peter.musgrave@magorcorp.com Sun May 9 04:45:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921183A68AF for ; Sun, 9 May 2010 04:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.328 X-Spam-Level: X-Spam-Status: No, score=0.328 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ax9Szgrp7el for ; Sun, 9 May 2010 04:45:09 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id AEF833A690E for ; Sun, 9 May 2010 04:45:08 -0700 (PDT) Received: by gwaa12 with SMTP id a12so1508162gwa.31 for ; Sun, 09 May 2010 04:44:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.207.21 with SMTP id e21mr4275361ybg.416.1273405494319; Sun, 09 May 2010 04:44:54 -0700 (PDT) Received: by 10.150.58.14 with HTTP; Sun, 9 May 2010 04:44:54 -0700 (PDT) In-Reply-To: <4BE044AE.7020405@gmx.net> References: <4BE044AE.7020405@gmx.net> Date: Sun, 9 May 2010 07:44:54 -0400 Message-ID: From: Peter Musgrave To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: dispatch mailing list Subject: Re: [dispatch] HITs in SIP/SDP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 11:45:10 -0000 Hi Hannes, Thanks for the reference. So if I understand correctly this speaks to using HIP for media encryption but not for identification. i.e. The SDPs still have IN4 in the c= line. I was wondering if HITs had been discussed in the context of host location. i.e. could a HIP connection be established prior to sending an initial INVITE by making reference to the HIT in the request URI? I also have the same question about using in SDPs either in the c= line or as an address candidate of some form. This appears to me to have the advantage of letting the HIP socket code become the place where ICE lives and then the media sub-system can just use it. Thanks, Peter Musgrave On Tue, May 4, 2010 at 12:00 PM, Hannes Tschofenig wrote: > Some time ago we worked on a draft about the interaction between HIP and > SIP: > http://tools.ietf.org/html/draft-tschofenig-hiprg-host-identities-06 > > But the problem statement there was very different. It essentially > simplified HIP deployment with the help of SIP. > > I believe that Gao has a different goal. I have not fully understood why he > believes that HIP is the solution since I don't understand the problem. > > Ciao > Hannes > > > Peter Musgrave wrote: >> >> Hi Gao/Dispatch, >> >> I though I would separate Gao's question about HIP in SIP into a >> thread specific to the protocol issues. >> >> Has this topic been raised before? >> >> Do people see benefits in using HITs (built in NAT traversal, handling >> of multi-homed and mobility issues etc.)? >> >> Is the use of HITs in SIP/SDP protocols largely a matter of adding >> conventions for URLs and SDP c= lines etc. or is it "deep"? >> >> I suspect that the later is true (especially in mixed HIP/non-HIP >> calls since they would e.g. still need ICE and perhaps the HITs become >> candidates in an SDP offer)? The multi-homed and address mobility >> issue may also cause deeper issues. >> >> >> Peter Musgrave >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > From peter.musgrave@magorcorp.com Sun May 9 07:32:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B933A69DF for ; Sun, 9 May 2010 07:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.229 X-Spam-Level: X-Spam-Status: No, score=0.229 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6NekH3zUOef for ; Sun, 9 May 2010 07:32:15 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 47F3E3A6A0B for ; Sun, 9 May 2010 07:29:52 -0700 (PDT) Received: by gyh4 with SMTP id 4so1537168gyh.31 for ; Sun, 09 May 2010 07:29:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.250.5 with SMTP id x5mr7133437ybh.295.1273415378001; Sun, 09 May 2010 07:29:38 -0700 (PDT) Received: by 10.150.58.14 with HTTP; Sun, 9 May 2010 07:29:37 -0700 (PDT) Date: Sun, 9 May 2010 10:29:37 -0400 Message-ID: From: Peter Musgrave To: jdrosen@jdrosen.net, fluffy@cisco.com, dispatch mailing list Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dispatch] draft-rosenberg-dispatch-vipr-overview-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 14:32:15 -0000 Hi Jonathan/Cullen, I have a use-case question for ViPR. Scenario: Alice is at PSTN 1-800-111-1111 x1111 Bob is at PSTN 1-800-222-2222 x2222 Alice and Bob support ViPR and know their PSTN numbers - but may not be the sole ViPR endpoints for the PSTN number within their enterprises. Neither Alice nor Bob's SIP-PSTN connection supports ViPR. Alice calls Bob's PSTN number and sends digits 2222 to connect to Bob. Both parties now have the shared secret of the PSTN call. Alice then wants to call Bob again (and ideally ViPR should make this a SIP call). So if Alice starts with dialing the PSTN number there is no knowledge that it's Bob she wants to contact. If she learned Bob has a SIP/ViPR endpoint could she be presented with a direct call option? Can ViPR make this a SIP call? Regards, Peter Musgrave From laura.liess.dt@googlemail.com Sun May 9 09:44:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4543A6A63 for ; Sun, 9 May 2010 09:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.325 X-Spam-Level: X-Spam-Status: No, score=0.325 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LskJKgfnSZ+p for ; Sun, 9 May 2010 09:44:45 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 1846D3A6A59 for ; Sun, 9 May 2010 09:44:41 -0700 (PDT) Received: by wwi18 with SMTP id 18so54611wwi.31 for ; Sun, 09 May 2010 09:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SkSl0r3PA7AlnFJvK6vTq3Q57EySHdWCpi8EFe2odxs=; b=xoK1a3rFwJ2mXqlBscAOpeyYmcq34QtStwonuCOkuMtEN+4WxdZad090H8hvcMXvmC 9JaZDJYGBvxlfo69ejoyd2eVTofTgvibeFthAkzV4fanTDrqE+RWVESjCN6ynlG+iRyy l02YPu9dd4VgwrrrYgdDWLdcU4iTcPqi7wpk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aMIB3Ltb3Z9Kb/X6SZkEoIe5+UKRSSmHKtKlv/9I3vIoISbRzT6Ykb2T/dO+qqTmJ1 3WXnRtoi+g1ytDigRLej6A1mbh5GX1tySy57hJP6NJL4rr6AzV3fDlKCJQcD2J7Mjo6H fDcBHBkKF0VeylFCrhypHSKSKOtSUJ6KEa89g= MIME-Version: 1.0 Received: by 10.216.160.208 with SMTP id u58mr1408771wek.141.1273423466250; Sun, 09 May 2010 09:44:26 -0700 (PDT) Received: by 10.216.173.212 with HTTP; Sun, 9 May 2010 09:44:26 -0700 (PDT) In-Reply-To: <4BE5418F.1010005@ericsson.com> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE5418F.1010005@ericsson.com> Date: Sun, 9 May 2010 18:44:26 +0200 Message-ID: From: Laura Liess To: Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH , Hadriel Kaplan Subject: Re: [dispatch] Status codes vs Alert-Info URNs WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 16:44:47 -0000 Hi, I don't think that replacing the Alert-Info URNs with respose/status codes is a good idea, for following reasons: - The Alert-Info URN is tightly coupled with the rendering. It is not the rendering itself but an indication describing the semantic or the characteristic(s) of the rendering. In the general case it does not describe the call status. - We choosed to use URNs as a flexible and extensible Internet-like mechanism to work for the general case in Internet, beyond the PSTN-like telephony. Currently we have only telephony use-cases, but we intended to define a general mechanism. - We choosed to use URN so the receiving UA can querry URN-resolvers to get the rendering. - We already have use cases which seems to me to be problematic if you want to cover them with codes. E.g. country ringback tones. With the Alert-info URN we have urn:alert:locale:country.. How could you represent this as response/status codes? - What about combination rules? This was one of the issues for which we had a lot of discussions for Alert-Info URNs. Thanks to Paul, we have now a quite flexible and well-sttructured syntax for Alert-Info URN (still not in the draft, but the the result of a ML-discussion): alert-category =3D "service" / "priority" / "source" / "duration" / "delay" / "locale" / extension-category extension-category =3D token Values for alert-indications: urn:alert:service: - normal (default) - call-waiting - forward - recall.callback - recall.hold - recall.transfer - private. urn:alert:priority: - normal (default) - low - high - private. urn:alert:source: - unclassified (default) - internal - external - friend - family - private. urn:alert:duration: - normal (default) - short (or "zip") - long - private. urn:alert:delay: - none (default) - yes - private. urn:alert:locale: - default (default) - country. - private. Combination Rules: -The categories are orthogonal. There can be at most one instance of each alert-category in an Alert-Info header. - The implementation is free to ignore any or all received Alert-Info URNs= . I don't think it is possible to achieve something similar using response/status codes. I am definitively opposed to replace the Alert-Info URNs with response or status codes. Laura 2010/5/8 Gonzalo Camarillo : > Hi, > > this is the most important issue we have to resolve before I revise the > charter again in order to get it reviewed by the IESG. Let me try and > summarize the discussions so far: > > RFC3261 defines Alert-Info for non-semantic indications (e.g., you > should play this particular tone). Extending it to describe those > non-semantic indications (e.g., play a short tone followed by a long > one) seems not to be controversial. It seems we want to scope those > extensions to interworking situations, though. > > As Hadriel indicates, semantic indications (i.e., your call is in a > queue) in SIP have been traditionally provided in status codes. If we > decided to use Alert-Info URNs instead, we would need to explain why in > the charter. > > To make this decision, we also need to agree on which messages need to > carry these semantic indications. It is only INVITEs and 180 responses, > INVITEs and 1xx responses, or something else? > > Another conversation we have had a few times in the context of allowing > Reason header fields in responses is what happens when we carry two > semantic indicators about the status of a given call (e.g., the status > code and a URN, or the status code and another status code in a Reason > header field). Thinking of this can be useful in the context of > chartering this WG as well. > > Thanks, > > Gonzalo > > > On 07/05/2010 7:42 PM, Hadriel Kaplan wrote: >> >>> -----Original Message----- >>> From: Alan Johnston [mailto:alan.b.johnston@gmail.com] >>> Sent: Friday, May 07, 2010 11:28 AM >>> To: Hadriel Kaplan >>> >>> The answer is that different entities generate the SIP response >>> code/Reason value and select the alerting tone. =A0Alerting is typicall= y >>> chosen locally, either by a UA or by a proxy/PBX for the UA, so this >>> can't use a common mechanism. >> >> Right, what you want is the device generating the response indicates the= condition, and the UAC receiving the response generates a locally-mapped t= one for that condition. =A0I get that, and it makes a lot of sense to me. >> >> So ISTM what we want is for the device generating the SIP response to in= dicate a status code, which the UAC can map to whatever tones it wants. >> >> The funny thing is we already have a way to do that. Two ways, in fact: = the message's status-line status-code number, and the Reason header value. >> >> I'm not actually proposing the SIP message response status-code be expan= ded for this (both because of interop issues and because there aren't enoug= h digits in 18x to accommodate all conditions). =A0But I think the Reason h= eader isn't a bad choice. >> >> >>> Also, every vendor implements this today using Alert-Info URI >>> conventions. =A0Unless you are arguing this is fundamentally broken >>> somehow, fixing this interop problem by standardizing a few URNs seems >>> like a very clean solution. >> >> Actually, it *is* broken, in three ways (though they may all be fixable)= : >> >> 1) You can't add more URN values later, because you don't know if the UA= C understands the new URN. =A0Compare this to a status-code model, where yo= u can treat a new 187 code as a 180 if you don't understand the 187. (altho= ugh I suppose you could actually just make the URN a number format, or defi= ne the format to indicate a default as well, so you can get this property) >> >> 2) An Alert-Info header can only appear in 180 responses, and not 182, 1= 83, etc. =A0I suppose 3261 could be extended though to include it in other = responses, though. >> >> 3) You can't deploy this new URN scheme in a backwards-compatible fashio= n in practice, unless you have an indicator in the request which states the= UAC supports it. =A0If you have such an indicator, you might as well put t= his in a Reason header instead and not have two different headers to indica= te the same status. =A0And as it turns out, if you use the Reason header th= en I don't think you need an indicator in the request to begin with. >> >> >>> Sure, we could invent a grand unifying theory and mechanism, but would >>> it get deployed? >> >> If there are real interop problems with Alert-Info, and people really wa= nt to fix them, and it's not much more work... then yes I think it would. = =A0I'm not suggesting a lot of additional work, am I? >> >> I don't think using the Reason header alone instead of both is such a bi= g change. =A0Seems simpler to me, in fact. >> >> -hadriel >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From laura.liess.dt@googlemail.com Sun May 9 12:18:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8B928C0CE for ; Sun, 9 May 2010 12:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.204 X-Spam-Level: X-Spam-Status: No, score=0.204 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiuuwSGi4l53 for ; Sun, 9 May 2010 12:18:04 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id CDE633A6A97 for ; Sun, 9 May 2010 12:18:01 -0700 (PDT) Received: by wyb39 with SMTP id 39so614116wyb.31 for ; Sun, 09 May 2010 12:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=uE//U1WJ5g6vmbBDA8X54zkMKnJDaXXBkf4nbOrMfq4=; b=MaGi/MhP5Wy3bWW2q4Bdl5UHUOFgBJy4oSECXvVR4nwxBn5T1KQz/0QBdwAoPSgfGt wrRHhuYEHANYcQiXDpyEwlGQ/CspsXh38bYj8v77L/b1xnJk0v9U8N/SDLmlzNVfynCM xarrMR6fv4fq86s4dLRqE2nRd5ORRk9+Cd6P4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bxmjqKHyWtwF9NoyBIk6Cev1MEUC79oRAXS/AEm8YWhSCcudRaGEHO2HuaqzFkl2gs GXj4PO6cA9elVTwbGiKIx8so0O5bwHyRGt1z0xnF7Xm0lPisFG/KCLk1HlQTIBKa2PCz G89eK/gBwFaz7TZFVNJ+Ln/u8CRJIw57EIMWA= MIME-Version: 1.0 Received: by 10.216.86.73 with SMTP id v51mr1786607wee.108.1273432667167; Sun, 09 May 2010 12:17:47 -0700 (PDT) Received: by 10.216.173.212 with HTTP; Sun, 9 May 2010 12:17:47 -0700 (PDT) In-Reply-To: <4BE3F08B.7000006@ericsson.com> References: <4BE3F08B.7000006@ericsson.com> Date: Sun, 9 May 2010 21:17:47 +0200 Message-ID: From: Laura Liess To: Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 19:18:06 -0000 Gonzalo, I agree with you that the last sentence is confusing. We discussed a lot about semantic vs. non-semantic . But now I think now 'non-semantic' is the wrong word. E.g. 'short' *is* a semantic name not for the tone itself, but for a tone characteristica. I would propose to change the last sentence in 'The Alert-Info URNs identifiers must be semantic names for renderings or rendering characteristics. ' Or to remove it without replacement. Opinions? Thanks a lot Laura 2010/5/7 Gonzalo Camarillo : > Folks, > > I have make a few editorial changes to the Alert Info charter proposal > in order to clarify what we want to do (see attachment). Please, let me > know if you have some comments. I would like to get the whole IESG to > review it relatively soon. > > One thing that still needs a bit of work is the last sentence of the > charter: "Whenever possible, the Alert-Info URNs identifiers should be > semantic." > > The whole charter motivates the use of semantic identifiers but then, in > the last sentence, it opens the door to non-semantic identifiers (e.g., > urn:alert:duration:short). > > We need to either focus on working on semantic identifiers only or add > more text explaining the reasons why we also want to define non semantic > identifiers. Opinions? > > Thanks, > > Gonzalo > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From gao.yang2@zte.com.cn Sun May 9 19:25:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09CA28C113 for ; Sun, 9 May 2010 19:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.682 X-Spam-Level: X-Spam-Status: No, score=-95.682 tagged_above=-999 required=5 tests=[AWL=-1.647, BAYES_60=1, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upwYZzURQn2Q for ; Sun, 9 May 2010 19:25:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 095F13A699D for ; Sun, 9 May 2010 19:25:19 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 36887992332426; Mon, 10 May 2010 10:20:05 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 6793.4062882609; Mon, 10 May 2010 10:25:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4A2OenU094618; Mon, 10 May 2010 10:24:41 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Peter Musgrave MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 10 May 2010 10:22:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-10 10:24:35, Serialize complete at 2010-05-10 10:24:35 Content-Type: multipart/alternative; boundary="=_alternative 000D36574825771F_=" X-MAIL: mse2.zte.com.cn o4A2OenU094618 Cc: dispatch mailing list , Hannes Tschofenig Subject: Re: [dispatch] HITs in SIP/SDP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 02:25:22 -0000 This is a multipart message in MIME format. --=_alternative 000D36574825771F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGV0ZXIgTXVzZ3JhdmUsDQoNCg0KUGV0ZXIgTXVzZ3JhdmUgPHBldGVyLm11c2dyYXZlQG1h Z29yY29ycC5jb20+INC009ogMjAxMC0wNS0wOSAxOTo0NDo1NDoNCg0KPiBIaSBIYW5uZXMsDQo+ IA0KPiBUaGFua3MgZm9yIHRoZSByZWZlcmVuY2UuIFNvIGlmIEkgdW5kZXJzdGFuZCBjb3JyZWN0 bHkgdGhpcyBzcGVha3MgdG8NCj4gdXNpbmcgSElQIGZvciBtZWRpYSBlbmNyeXB0aW9uIGJ1dCBu b3QgZm9yIGlkZW50aWZpY2F0aW9uLiBpLmUuIFRoZQ0KPiBTRFBzIHN0aWxsIGhhdmUgSU40IGlu IHRoZSBjPSBsaW5lLg0KPiANCj4gSSB3YXMgd29uZGVyaW5nIGlmIEhJVHMgaGFkIGJlZW4gZGlz Y3Vzc2VkIGluIHRoZSBjb250ZXh0IG9mIGhvc3QNCj4gbG9jYXRpb24uIGkuZS4gY291bGQgYSBI SVAgY29ubmVjdGlvbiBiZSBlc3RhYmxpc2hlZCBwcmlvciB0byBzZW5kaW5nDQo+IGFuIGluaXRp YWwgSU5WSVRFIGJ5IG1ha2luZyByZWZlcmVuY2UgdG8gdGhlIEhJVCBpbiB0aGUgcmVxdWVzdCBV Ukk/IA0KDQpZZXMuIFN1cHBvc2luZyBBIGFuZCBCIGhhcyBhIEhJUCBjb25uZWN0aW9uIGZvciBv bmUgdXNlLiBUaGVuIEEgYW5kIEIgd2FudCANCnRvIHJldXNlIHRoZSBISVAgY29ubmNldGlvbiBh bmQgaGF2ZSBhIGNhbGwvc2Vzc2lvbiBieSBTSVAuIFRoaXMgaXMgDQp0eXBpY2FsIHVzZSBjYXNl IG9mIGhhdmluZyBISVAgY29ubmVjdGlvbiBiZWZvcmUgSU5WSVRFLg0KDQpCdXQgSSdkIGxpa2Ug dG8gcG9pbnQgb3V0IHRoYXQsIGlmIHdlIHdhbnQgdG8gdXNlICJISVAgYmFzZWQgU0lQIiwgc29t ZSANCmFzcGVjdCBvZiBTSVAgc2hvdWxkIGJlIGN1dHRlZCBkb3duLCBzdWNoIGFzIHNvbWUgcGFy dCBvZiBpdCdzIHJvdXRpbmcgDQptZWNoYW5pc20uDQoNCj4gSSBhbHNvIGhhdmUgdGhlIHNhbWUg cXVlc3Rpb24gYWJvdXQgdXNpbmcgaW4gU0RQcyBlaXRoZXIgaW4gdGhlIGM9IGxpbmUNCj4gb3Ig YXMgYW4gYWRkcmVzcyBjYW5kaWRhdGUgb2Ygc29tZSBmb3JtLg0KDQpJIHRoaW5rIGl0IHdvdWxk IGJlIGJvdGgsIHdoaWxlIHdpdGggZGlmZmVyZW50IGZ1bmN0aW9uLg0KDQo+IA0KPiBUaGlzIGFw cGVhcnMgdG8gbWUgdG8gaGF2ZSB0aGUgYWR2YW50YWdlIG9mIGxldHRpbmcgdGhlIEhJUCBzb2Nr ZXQNCj4gY29kZSBiZWNvbWUgdGhlIHBsYWNlIHdoZXJlIElDRSBsaXZlcyBhbmQgdGhlbiB0aGUg bWVkaWEgc3ViLXN5c3RlbQ0KPiBjYW4ganVzdCB1c2UgaXQuDQoNCkkgZG9uJ3QgdW5kZXJzdGFu ZCB0aGlzIGlzc3VlIHdlbGwuIENvdWxkIHlvdSBzYXkgbW9yZSBhYm91dCBpdC4gVGhhbmtzLg0K DQpSZWdhcmRzLA0KDQpHYW8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24g aXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8g bWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNv bnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBh bnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20g dGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3 cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBz ZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3Bh bSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 000D36574825771F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFBldGVyIE11c2dyYXZlLDwv Zm9udD4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlBldGVyIE11c2dyYXZlICZs dDtwZXRlci5tdXNncmF2ZUBtYWdvcmNvcnAuY29tJmd0Ow0K0LTT2iAyMDEwLTA1LTA5IDE5OjQ0 OjU0Ojxicj4NCjxicj4NCiZndDsgSGkgSGFubmVzLDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFu a3MgZm9yIHRoZSByZWZlcmVuY2UuIFNvIGlmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkgdGhpcyBz cGVha3MNCnRvPGJyPg0KJmd0OyB1c2luZyBISVAgZm9yIG1lZGlhIGVuY3J5cHRpb24gYnV0IG5v dCBmb3IgaWRlbnRpZmljYXRpb24uIGkuZS4gVGhlPGJyPg0KJmd0OyBTRFBzIHN0aWxsIGhhdmUg SU40IGluIHRoZSBjPSBsaW5lLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHdhcyB3b25kZXJpbmcg aWYgSElUcyBoYWQgYmVlbiBkaXNjdXNzZWQgaW4gdGhlIGNvbnRleHQgb2YgaG9zdDxicj4NCiZn dDsgbG9jYXRpb24uIGkuZS4gY291bGQgYSBISVAgY29ubmVjdGlvbiBiZSBlc3RhYmxpc2hlZCBw cmlvciB0byBzZW5kaW5nPGJyPg0KJmd0OyBhbiBpbml0aWFsIElOVklURSBieSBtYWtpbmcgcmVm ZXJlbmNlIHRvIHRoZSBISVQgaW4gdGhlIHJlcXVlc3QgVVJJPw0KPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5ZZXMuIFN1cHBvc2luZyBBIGFuZCBCIGhhcyBhIEhJUCBj b25uZWN0aW9uIGZvciBvbmUNCnVzZS4gVGhlbiBBIGFuZCBCIHdhbnQgdG8gcmV1c2UgdGhlIEhJ UCBjb25uY2V0aW9uIGFuZCBoYXZlIGEgY2FsbC9zZXNzaW9uDQpieSBTSVAuIFRoaXMgaXMgdHlw aWNhbCB1c2UgY2FzZSBvZiBoYXZpbmcgSElQIGNvbm5lY3Rpb24gYmVmb3JlIElOVklURS48L2Zv bnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkJ1dCBJJ2QgbGlrZSB0byBwb2lu dCBvdXQgdGhhdCwgaWYgd2Ugd2FudCB0byB1c2UNCiZxdW90O0hJUCBiYXNlZCBTSVAmcXVvdDss IHNvbWUgYXNwZWN0IG9mIFNJUCBzaG91bGQgYmUgY3V0dGVkIGRvd24sIHN1Y2gNCmFzIHNvbWUg cGFydCBvZiBpdCdzIHJvdXRpbmcgbWVjaGFuaXNtLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+PGJyPg0KJmd0OyBJIGFsc28gaGF2ZSB0aGUgc2FtZSBxdWVzdGlvbiBhYm91dCB1 c2luZyBpbiBTRFBzIGVpdGhlciBpbiB0aGUgYz0NCmxpbmU8YnI+DQomZ3Q7IG9yIGFzIGFuIGFk ZHJlc3MgY2FuZGlkYXRlIG9mIHNvbWUgZm9ybS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPkkgdGhpbmsgaXQgd291bGQgYmUgYm90aCwgd2hpbGUgd2l0aCBkaWZmZXJl bnQgZnVuY3Rpb24uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7 IDxicj4NCiZndDsgVGhpcyBhcHBlYXJzIHRvIG1lIHRvIGhhdmUgdGhlIGFkdmFudGFnZSBvZiBs ZXR0aW5nIHRoZSBISVAgc29ja2V0PGJyPg0KJmd0OyBjb2RlIGJlY29tZSB0aGUgcGxhY2Ugd2hl cmUgSUNFIGxpdmVzIGFuZCB0aGVuIHRoZSBtZWRpYSBzdWItc3lzdGVtPGJyPg0KJmd0OyBjYW4g anVzdCB1c2UgaXQuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIGRv bid0IHVuZGVyc3RhbmQgdGhpcyBpc3N1ZSB3ZWxsLiBDb3VsZCB5b3Ugc2F5DQptb3JlIGFib3V0 IGl0LiBUaGFua3MuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpSZWdh cmRzLDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+R2FvPC9mb250Pjwv dHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5 Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5i c3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVy dHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNw O1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50 aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7 b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJz cDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7 dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5i c3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJz cDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7 Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3Im bmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtv ciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDth ZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0 aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5 Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4m bmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNw O21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZu YnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNw O2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 000D36574825771F_=-- From john.elwell@siemens-enterprise.com Mon May 10 00:54:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8A528C13E for ; Mon, 10 May 2010 00:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDBMiQB65-pk for ; Mon, 10 May 2010 00:54:08 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A688A28C135 for ; Mon, 10 May 2010 00:54:07 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-110791; Mon, 10 May 2010 09:53:54 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B6DF51EB82AB; Mon, 10 May 2010 09:53:54 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 10 May 2010 09:53:54 +0200 From: "Elwell, John" To: Hadriel Kaplan , Gonzalo Camarillo Date: Mon, 10 May 2010 09:53:53 +0200 Thread-Topic: [dispatch] Alternative approach WAS (Re: Alert Info Charter) Thread-Index: Acrt+t4hU7hSppBtSByVbEInWhyApwAAEeSAAAOIttAAgxU68A== Message-ID: References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE432D5.6030907@ericsson.com> <430FC6BDED356B4C8498F634416644A91A8A7D767B@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D767B@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Alternative approach WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 07:54:08 -0000 =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: 07 May 2010 18:46 > To: Elwell, John; Gonzalo Camarillo > Cc: DISPATCH > Subject: RE: [dispatch] Alternative approach WAS (Re: Alert=20 > Info Charter) >=20 >=20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, May 07, 2010 11:41 AM > > To: Gonzalo Camarillo; Hadriel Kaplan > >=20 > > We already have the Alert-Info header field, which is meant=20 > to be the > > vehicle for ringing and ring-back tones, and I don't see=20 > the point in > > trying to be disruptive there. >=20 > I can't tell in what way you mean that. =20 >=20 > Do you mean it's less disruptive to put a status code into=20 > Alert-Info, because people already use Alert-Info URI's for=20 > the ringing playback process? =20 [JRE] I mean it is less disruptive to use Alert-Info, because that is what = people do today. But that implies using a URL/URN in Alert-Info, not a stat= us code. John >=20 > Or do you mean it's less disruptive to leave the Alert-Info=20 > for what it was intended for: to indicate the URI of a=20 > ringtone with no semantics, and instead put the status code=20 > into something which is actually meant for status code? >=20 > And what do you mean by "disruptive"? To me "disruptive" is=20 > when interop or service issues happen due to the proposed=20 > change, but maybe you mean something different? >=20 > -hadriel >=20 > = From john.elwell@siemens-enterprise.com Mon May 10 01:01:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F0328C154 for ; Mon, 10 May 2010 01:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9WA3WhfiUH2 for ; Mon, 10 May 2010 01:01:40 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8A5203A680E for ; Mon, 10 May 2010 01:01:11 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-111056; Mon, 10 May 2010 10:00:59 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id B575D23F028E; Mon, 10 May 2010 10:00:59 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 10 May 2010 10:00:59 +0200 From: "Elwell, John" To: Adam Roach Date: Mon, 10 May 2010 10:00:58 +0200 Thread-Topic: [dispatch] Alert Info Charter Thread-Index: AcruFai1zk+7AuTSSO2LwutfMWcsVwCAOSVQ Message-ID: References: <4BE3F08B.7000006@ericsson.com> <4BE41B7C.2030402@nostrum.com> <4BE42DAC.4070009@cisco.com> <4BE46012.1070702@nostrum.com> In-Reply-To: <4BE46012.1070702@nostrum.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 Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 08:01:41 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 07 May 2010 19:47 > To: Elwell, John > Cc: Paul Kyzivat; DISPATCH > Subject: Re: [dispatch] Alert Info Charter >=20 > On 5/7/10 10:28 AM, Elwell, John wrote: > > [JRE] This is confusing me further. What are the semantics=20 > of "reorder"? >=20 > http://dictionary.sensagent.com/reorder+tone/en-en/ >=20 > /a >=20 [JRE] So, as Paul says, it is literal, not semantic. It has several differe= nt meanings in North America, and no meaning elsewhere. John From victor.pascual.avila@gmail.com Mon May 10 04:36:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D513A68BD for ; Mon, 10 May 2010 04:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTpJM3e8d4Mi for ; Mon, 10 May 2010 04:36:23 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id B9CBD3A6839 for ; Mon, 10 May 2010 04:36:22 -0700 (PDT) Received: by bwz9 with SMTP id 9so1733085bwz.29 for ; Mon, 10 May 2010 04:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VRUHln0SDoklIsFD9bZ94g5rUYVfnnuqqjne2QgQaJI=; b=sptfX9hdwsOcapnk7qscm1/yLEv8w7Di7EsyDcN2m3ns9oufV8pUZY1YVTxS9Dk7+b a8H3x/DxULqeCAoPIqmNG4ORVixVFDKu5iVixLdlTE1LjOsXigahy01bSQahRB/744cl BUsPbxvcmh+7ZI+/veUITA0JTuJGeo6Zk8B7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xMItOnpENQdS5gMaYDF1BMTR3wGJOlOB6ZRYYkyHRMJxkSu1Sl9UEJsLOzPSaS2RL1 rFPPjJO8EdlOst7hj+7WIuaWTlzmcEdjk+ufqHi0NhxDPPQTmTyLhW4q9FBRKcvcBOPc 3522XSso8EuvZg637NOosjpa4UD1jinnvyrE4= MIME-Version: 1.0 Received: by 10.204.129.70 with SMTP id n6mr2331038bks.152.1273491354513; Mon, 10 May 2010 04:35:54 -0700 (PDT) Received: by 10.204.70.141 with HTTP; Mon, 10 May 2010 04:35:53 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> Date: Mon, 10 May 2010 13:35:53 +0200 Message-ID: From: Victor Pascual Avila To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 11:36:24 -0000 Looks good to me. Just one quick question: will this WG produce a single deliverable? -Victor On Sat, May 8, 2010 at 10:35 PM, Hadriel Kaplan wr= ote: > Howdy, > I have asked the DISPATCH chairs what to do with Session-ID, given the fe= edback I received to make it a standards-track vs. individual informational= submission. =C2=A0There is no obvious current WG for this work, so they as= ked me to post a strawman charter proposal, which I propose as follows: > > > SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPS= COTCH) Charter: > ---------------------------------- > The SIPSCOTCH working group is chartered to define a mechanism that allow= s operators and monitoring equipment to correlate SIP messages and dialogs = of the same higher-level end-to-end "session" or "message-flow". =C2=A0In p= articular, the mechanism must be able to allow such correlation across SIP = B2BUAs of as many functional types as possible, such as Application Servers= , Softswitches, PBXs, SBCs, etc. > > Although other solutions may be possible, this working group will focus o= n defining a new SIP Header field for such a purpose, similar to the Call-I= D header field, in order to provide a simple, easily deployable mechanism w= hich can work across SIP domains. The SIP Call-ID header field value itself= is not usable for such correlation, because many B2BUAs must create a new = Call-ID value on their UAC "side" in order to function properly, and to com= ply with the rules of RFC 3261. > > It should be noted that certain SIP B2BUAs perform a "topology-hiding" fu= nction, as described in RFC 5853. =C2=A0The working group will take such fu= nctions into account for the correlation mechanism, as well as provide guid= ance for implementers of the mechanism to avoid triggering such a function = for the mechanism's header field value. > > Lastly, although in certain environments such a mechanism may be usable f= or dialog correlation in SIP state machines, it is not the goal of this wor= king group to address that usage. > > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dec 2010 - New header specification to IESG (PS) > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Victor Pascual =C3=81vila From laura.liess.dt@googlemail.com Mon May 10 04:45:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7CF33A6BAB for ; Mon, 10 May 2010 04:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=0.951, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyLNhFsn8rv8 for ; Mon, 10 May 2010 04:45:15 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 8A8393A68DC for ; Mon, 10 May 2010 04:45:15 -0700 (PDT) Received: by wwi18 with SMTP id 18so519429wwi.31 for ; Mon, 10 May 2010 04:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=phd4X2bkzjhz6XZbF04AdRGqSp+04MfXMxusq1jYLKY=; b=fI12b5dyVETSdMTB5Rjd8X3Uz5xir6FFEdiqbBz9oPg5SOZeKNlcDO8f5YvEXvHxMr /ynd0FxpgI527KqZ/xib0VKr1NfNmWO0C1MprjBf1zHFW0ZJgsH3vPszfNhrMknudIVn rPGuJxGVUYU1+PaoG7L3UMJ1CMKgrsMgazAYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Lkjn++Lm3iphqqEX51NcbPtxxrq93QT5Nq5Oq8Q8kUIexgGCybo2SY/2d1qaGTQmyB tRZ6rKTIienMMJ2xk6NCne7MRYwqlB/LBnqjtNGGsZleieTCRXW5Lci7Wt6Al7cN1ujV hSNUFU8q4gnIXOU+gpg6wFWkXF5q5ngR9pF8A= MIME-Version: 1.0 Received: by 10.216.169.199 with SMTP id n49mr2358569wel.42.1273491898173; Mon, 10 May 2010 04:44:58 -0700 (PDT) Received: by 10.216.173.212 with HTTP; Mon, 10 May 2010 04:44:58 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> Date: Mon, 10 May 2010 13:44:58 +0200 Message-ID: From: Laura Liess To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 11:45:16 -0000 Hi Hadriel, this looks fine to me. Laura 2010/5/8 Hadriel Kaplan : > Howdy, > I have asked the DISPATCH chairs what to do with Session-ID, given the fe= edback I received to make it a standards-track vs. individual informational= submission. =A0There is no obvious current WG for this work, so they asked= me to post a strawman charter proposal, which I propose as follows: > > > SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPS= COTCH) Charter: > ---------------------------------- > The SIPSCOTCH working group is chartered to define a mechanism that allow= s operators and monitoring equipment to correlate SIP messages and dialogs = of the same higher-level end-to-end "session" or "message-flow". =A0In part= icular, the mechanism must be able to allow such correlation across SIP B2B= UAs of as many functional types as possible, such as Application Servers, S= oftswitches, PBXs, SBCs, etc. > > Although other solutions may be possible, this working group will focus o= n defining a new SIP Header field for such a purpose, similar to the Call-I= D header field, in order to provide a simple, easily deployable mechanism w= hich can work across SIP domains. The SIP Call-ID header field value itself= is not usable for such correlation, because many B2BUAs must create a new = Call-ID value on their UAC "side" in order to function properly, and to com= ply with the rules of RFC 3261. > > It should be noted that certain SIP B2BUAs perform a "topology-hiding" fu= nction, as described in RFC 5853. =A0The working group will take such funct= ions into account for the correlation mechanism, as well as provide guidanc= e for implementers of the mechanism to avoid triggering such a function for= the mechanism's header field value. > > Lastly, although in certain environments such a mechanism may be usable f= or dialog correlation in SIP state machines, it is not the goal of this wor= king group to address that usage. > > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dec 2010 - New header specification to IESG (PS) > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From gao.yang2@zte.com.cn Mon May 10 06:00:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCFF728C18E; Mon, 10 May 2010 06:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.232 X-Spam-Level: X-Spam-Status: No, score=-96.232 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUDZpxxMHjDb; Mon, 10 May 2010 06:00:14 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 967423A693C; Mon, 10 May 2010 06:00:11 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580712302718646; Mon, 10 May 2010 20:55:24 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 30460.4086600708; Mon, 10 May 2010 20:55:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4ACxiAc087771; Mon, 10 May 2010 20:59:44 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 10 May 2010 20:56:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-10 20:59:25, Serialize complete at 2010-05-10 20:59:25 Content-Type: multipart/alternative; boundary="=_alternative 004755004825771F_=" X-MAIL: mse2.zte.com.cn o4ACxiAc087771 Cc: dispatch-bounces@ietf.org, DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 13:00:15 -0000 This is a multipart message in MIME format. --=_alternative 004755004825771F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkknZCBsaWtlIHRvIHNlZSB0aGUgcmVxdWlyZW1lbnQgb2YgdGhlIGhlYWRlciBhbmQg dHlwaWNhbCB1c2UgY2FzZSBmb3IgaXQgDQppbiB0aGUgY2hhcnRlci4NCg0KVGhhbmtzLA0KDQpH YW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAw MTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWls IDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQoNCg0KDQpIYWRyaWVsIEthcGxhbiA8SEthcGxhbkBhY21lcGFja2V0LmNvbT4gDQq3orz+ yMs6ICBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnDQoyMDEwLTA1LTA5IDA0OjM1DQoNCsrVvP7I yw0KRElTUEFUQ0ggPGRpc3BhdGNoQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpbZGlzcGF0Y2hd IFNlc3Npb24tSUQgY2hhcnRlciBwcm9wb3NhbA0KDQoNCg0KDQoNCg0KSG93ZHksDQpJIGhhdmUg YXNrZWQgdGhlIERJU1BBVENIIGNoYWlycyB3aGF0IHRvIGRvIHdpdGggU2Vzc2lvbi1JRCwgZ2l2 ZW4gdGhlIA0KZmVlZGJhY2sgSSByZWNlaXZlZCB0byBtYWtlIGl0IGEgc3RhbmRhcmRzLXRyYWNr IHZzLiBpbmRpdmlkdWFsIA0KaW5mb3JtYXRpb25hbCBzdWJtaXNzaW9uLiAgVGhlcmUgaXMgbm8g b2J2aW91cyBjdXJyZW50IFdHIGZvciB0aGlzIHdvcmssIA0Kc28gdGhleSBhc2tlZCBtZSB0byBw b3N0IGEgc3RyYXdtYW4gY2hhcnRlciBwcm9wb3NhbCwgd2hpY2ggSSBwcm9wb3NlIGFzIA0KZm9s bG93czoNCg0KDQpTSVAgU2lnbmFsaW5nLUNPbW11bmljYXRpb24gVHJvdWJsZXNob290aW5nIHdp dGggQ29ycmVsYXRpb24gSGVhZGVyIA0KKFNJUFNDT1RDSCkgQ2hhcnRlcjoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoZSBTSVBTQ09UQ0ggd29ya2luZyBncm91cCBpcyBj aGFydGVyZWQgdG8gZGVmaW5lIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIA0Kb3BlcmF0b3JzIGFu ZCBtb25pdG9yaW5nIGVxdWlwbWVudCB0byBjb3JyZWxhdGUgU0lQIG1lc3NhZ2VzIGFuZCBkaWFs b2dzIA0Kb2YgdGhlIHNhbWUgaGlnaGVyLWxldmVsIGVuZC10by1lbmQgInNlc3Npb24iIG9yICJt ZXNzYWdlLWZsb3ciLiAgSW4gDQpwYXJ0aWN1bGFyLCB0aGUgbWVjaGFuaXNtIG11c3QgYmUgYWJs ZSB0byBhbGxvdyBzdWNoIGNvcnJlbGF0aW9uIGFjcm9zcyANClNJUCBCMkJVQXMgb2YgYXMgbWFu eSBmdW5jdGlvbmFsIHR5cGVzIGFzIHBvc3NpYmxlLCBzdWNoIGFzIEFwcGxpY2F0aW9uIA0KU2Vy dmVycywgU29mdHN3aXRjaGVzLCBQQlhzLCBTQkNzLCBldGMuDQoNCkFsdGhvdWdoIG90aGVyIHNv bHV0aW9ucyBtYXkgYmUgcG9zc2libGUsIHRoaXMgd29ya2luZyBncm91cCB3aWxsIGZvY3VzIG9u IA0KZGVmaW5pbmcgYSBuZXcgU0lQIEhlYWRlciBmaWVsZCBmb3Igc3VjaCBhIHB1cnBvc2UsIHNp bWlsYXIgdG8gdGhlIENhbGwtSUQgDQpoZWFkZXIgZmllbGQsIGluIG9yZGVyIHRvIHByb3ZpZGUg YSBzaW1wbGUsIGVhc2lseSBkZXBsb3lhYmxlIG1lY2hhbmlzbSANCndoaWNoIGNhbiB3b3JrIGFj cm9zcyBTSVAgZG9tYWlucy4gVGhlIFNJUCBDYWxsLUlEIGhlYWRlciBmaWVsZCB2YWx1ZSANCml0 c2VsZiBpcyBub3QgdXNhYmxlIGZvciBzdWNoIGNvcnJlbGF0aW9uLCBiZWNhdXNlIG1hbnkgQjJC VUFzIG11c3QgY3JlYXRlIA0KYSBuZXcgQ2FsbC1JRCB2YWx1ZSBvbiB0aGVpciBVQUMgInNpZGUi IGluIG9yZGVyIHRvIGZ1bmN0aW9uIHByb3Blcmx5LCBhbmQgDQp0byBjb21wbHkgd2l0aCB0aGUg cnVsZXMgb2YgUkZDIDMyNjEuIA0KDQpJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBjZXJ0YWluIFNJ UCBCMkJVQXMgcGVyZm9ybSBhICJ0b3BvbG9neS1oaWRpbmciIA0KZnVuY3Rpb24sIGFzIGRlc2Ny aWJlZCBpbiBSRkMgNTg1My4gIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgdGFrZSBzdWNoIA0KZnVu Y3Rpb25zIGludG8gYWNjb3VudCBmb3IgdGhlIGNvcnJlbGF0aW9uIG1lY2hhbmlzbSwgYXMgd2Vs bCBhcyBwcm92aWRlIA0KZ3VpZGFuY2UgZm9yIGltcGxlbWVudGVycyBvZiB0aGUgbWVjaGFuaXNt IHRvIGF2b2lkIHRyaWdnZXJpbmcgc3VjaCBhIA0KZnVuY3Rpb24gZm9yIHRoZSBtZWNoYW5pc20n cyBoZWFkZXIgZmllbGQgdmFsdWUuDQoNCkxhc3RseSwgYWx0aG91Z2ggaW4gY2VydGFpbiBlbnZp cm9ubWVudHMgc3VjaCBhIG1lY2hhbmlzbSBtYXkgYmUgdXNhYmxlIA0KZm9yIGRpYWxvZyBjb3Jy ZWxhdGlvbiBpbiBTSVAgc3RhdGUgbWFjaGluZXMsIGl0IGlzIG5vdCB0aGUgZ29hbCBvZiB0aGlz IA0Kd29ya2luZyBncm91cCB0byBhZGRyZXNzIHRoYXQgdXNhZ2UuDQoNCkdvYWxzIGFuZCBNaWxl c3RvbmVzDQo9PT09PT09PT09PT09PT09PT09PQ0KRGVjIDIwMTAgLSBOZXcgaGVhZGVyIHNwZWNp ZmljYXRpb24gdG8gSUVTRyAoUFMpDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCmRpc3BhdGNoQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQoNCg0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3Jn YW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lw aWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBh cmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1l c3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBo YXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lz dGVtLg0K --=_alternative 004755004825771F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSdkIGxpa2UgdG8gc2VlIHRoZSByZXF1 aXJlbWVudCBvZiB0aGUNCmhlYWRlciBhbmQgdHlwaWNhbCB1c2UgY2FzZSBmb3IgaXQgaW4gdGhl IGNoYXJ0ZXIuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7 OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7 IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248 YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxi cj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5IYWRyaWVsIEthcGxhbiAmbHQ7 SEthcGxhbkBhY21lcGFja2V0LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9y ZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA1LTA5IDA0 OjM1PC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPkRJU1BBVENIICZsdDtkaXNwYXRjaEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltkaXNwYXRjaF0gU2Vzc2lv bi1JRCBjaGFydGVyIHByb3Bvc2FsPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Ib3dkeSw8YnI+DQpJIGhhdmUgYXNrZWQgdGhlIERJU1BB VENIIGNoYWlycyB3aGF0IHRvIGRvIHdpdGggU2Vzc2lvbi1JRCwgZ2l2ZW4gdGhlDQpmZWVkYmFj ayBJIHJlY2VpdmVkIHRvIG1ha2UgaXQgYSBzdGFuZGFyZHMtdHJhY2sgdnMuIGluZGl2aWR1YWwg aW5mb3JtYXRpb25hbA0Kc3VibWlzc2lvbi4gJm5ic3A7VGhlcmUgaXMgbm8gb2J2aW91cyBjdXJy ZW50IFdHIGZvciB0aGlzIHdvcmssIHNvIHRoZXkNCmFza2VkIG1lIHRvIHBvc3QgYSBzdHJhd21h biBjaGFydGVyIHByb3Bvc2FsLCB3aGljaCBJIHByb3Bvc2UgYXMgZm9sbG93czo8YnI+DQo8YnI+ DQo8YnI+DQpTSVAgU2lnbmFsaW5nLUNPbW11bmljYXRpb24gVHJvdWJsZXNob290aW5nIHdpdGgg Q29ycmVsYXRpb24gSGVhZGVyIChTSVBTQ09UQ0gpDQpDaGFydGVyOjxicj4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpUaGUgU0lQU0NPVENIIHdvcmtpbmcgZ3JvdXAg aXMgY2hhcnRlcmVkIHRvIGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cw0Kb3BlcmF0b3Jz IGFuZCBtb25pdG9yaW5nIGVxdWlwbWVudCB0byBjb3JyZWxhdGUgU0lQIG1lc3NhZ2VzIGFuZCBk aWFsb2dzDQpvZiB0aGUgc2FtZSBoaWdoZXItbGV2ZWwgZW5kLXRvLWVuZCAmcXVvdDtzZXNzaW9u JnF1b3Q7IG9yICZxdW90O21lc3NhZ2UtZmxvdyZxdW90Oy4NCiZuYnNwO0luIHBhcnRpY3VsYXIs IHRoZSBtZWNoYW5pc20gbXVzdCBiZSBhYmxlIHRvIGFsbG93IHN1Y2ggY29ycmVsYXRpb24NCmFj cm9zcyBTSVAgQjJCVUFzIG9mIGFzIG1hbnkgZnVuY3Rpb25hbCB0eXBlcyBhcyBwb3NzaWJsZSwg c3VjaCBhcyBBcHBsaWNhdGlvbg0KU2VydmVycywgU29mdHN3aXRjaGVzLCBQQlhzLCBTQkNzLCBl dGMuPGJyPg0KPGJyPg0KQWx0aG91Z2ggb3RoZXIgc29sdXRpb25zIG1heSBiZSBwb3NzaWJsZSwg dGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMNCm9uIGRlZmluaW5nIGEgbmV3IFNJUCBIZWFk ZXIgZmllbGQgZm9yIHN1Y2ggYSBwdXJwb3NlLCBzaW1pbGFyIHRvIHRoZSBDYWxsLUlEDQpoZWFk ZXIgZmllbGQsIGluIG9yZGVyIHRvIHByb3ZpZGUgYSBzaW1wbGUsIGVhc2lseSBkZXBsb3lhYmxl IG1lY2hhbmlzbQ0Kd2hpY2ggY2FuIHdvcmsgYWNyb3NzIFNJUCBkb21haW5zLiBUaGUgU0lQIENh bGwtSUQgaGVhZGVyIGZpZWxkIHZhbHVlIGl0c2VsZg0KaXMgbm90IHVzYWJsZSBmb3Igc3VjaCBj b3JyZWxhdGlvbiwgYmVjYXVzZSBtYW55IEIyQlVBcyBtdXN0IGNyZWF0ZSBhIG5ldw0KQ2FsbC1J RCB2YWx1ZSBvbiB0aGVpciBVQUMgJnF1b3Q7c2lkZSZxdW90OyBpbiBvcmRlciB0byBmdW5jdGlv biBwcm9wZXJseSwNCmFuZCB0byBjb21wbHkgd2l0aCB0aGUgcnVsZXMgb2YgUkZDIDMyNjEuIDxi cj4NCjxicj4NCkl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGNlcnRhaW4gU0lQIEIyQlVBcyBwZXJm b3JtIGEgJnF1b3Q7dG9wb2xvZ3ktaGlkaW5nJnF1b3Q7DQpmdW5jdGlvbiwgYXMgZGVzY3JpYmVk IGluIFJGQyA1ODUzLiAmbmJzcDtUaGUgd29ya2luZyBncm91cCB3aWxsIHRha2Ugc3VjaA0KZnVu Y3Rpb25zIGludG8gYWNjb3VudCBmb3IgdGhlIGNvcnJlbGF0aW9uIG1lY2hhbmlzbSwgYXMgd2Vs bCBhcyBwcm92aWRlDQpndWlkYW5jZSBmb3IgaW1wbGVtZW50ZXJzIG9mIHRoZSBtZWNoYW5pc20g dG8gYXZvaWQgdHJpZ2dlcmluZyBzdWNoIGEgZnVuY3Rpb24NCmZvciB0aGUgbWVjaGFuaXNtJ3Mg aGVhZGVyIGZpZWxkIHZhbHVlLjxicj4NCjxicj4NCkxhc3RseSwgYWx0aG91Z2ggaW4gY2VydGFp biBlbnZpcm9ubWVudHMgc3VjaCBhIG1lY2hhbmlzbSBtYXkgYmUgdXNhYmxlDQpmb3IgZGlhbG9n IGNvcnJlbGF0aW9uIGluIFNJUCBzdGF0ZSBtYWNoaW5lcywgaXQgaXMgbm90IHRoZSBnb2FsIG9m IHRoaXMNCndvcmtpbmcgZ3JvdXAgdG8gYWRkcmVzcyB0aGF0IHVzYWdlLjxicj4NCjxicj4NCkdv YWxzIGFuZCBNaWxlc3RvbmVzPGJyPg0KPT09PT09PT09PT09PT09PT09PT08YnI+DQpEZWMgMjAx MCAtIE5ldyBoZWFkZXIgc3BlY2lmaWNhdGlvbiB0byBJRVNHIChQUyk8YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRpc3BhdGNo IG1haWxpbmcgbGlzdDxicj4NCmRpc3BhdGNoQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaDxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0K PGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNw O05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlz Jm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4m bmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGln YXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJl Jm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZu YnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3Rv Jm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7Zmls ZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZp ZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7 dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJz cDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVz c2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZu YnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNw O3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7 QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNz YWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwm bmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtz Y2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZu YnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 004755004825771F_=-- From gao.yang2@zte.com.cn Mon May 10 06:15:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB093A68A7 for ; Mon, 10 May 2010 06:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.834 X-Spam-Level: X-Spam-Status: No, score=-95.834 tagged_above=-999 required=5 tests=[AWL=-1.399, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id basOGfELNABi for ; Mon, 10 May 2010 06:15:19 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 6C6D33A68A0 for ; Mon, 10 May 2010 06:15:08 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 36887992332426; Mon, 10 May 2010 21:09:48 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 6793.2776214488; Mon, 10 May 2010 21:14:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4ADF00d098345; Mon, 10 May 2010 21:15:00 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 10 May 2010 21:12:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-10 21:14:41, Serialize complete at 2010-05-10 21:14:41 Content-Type: multipart/alternative; boundary="=_alternative 0048BAD24825771F_=" X-MAIL: mse2.zte.com.cn o4ADF00d098345 Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 13:15:20 -0000 This is a multipart message in MIME format. --=_alternative 0048BAD24825771F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNClBsZWFzZSBsZXQgbWUgbWFrZSBteSBxdWVzdGlvbiBjbGVhcmx5LiBDb25zaWRlcmlu ZyANCmJpbGxpbmcvY2hhcmdpbmcvcG9saWN5IGFuZCBMSShsYXdmdWwgaW50ZXJjZXB0aW9uKSwg dGhlcmUncyB1c2UgY2FzZXMgb2YgDQpjb3JyZWxhdGluZyAic2Vzc2lvbiIgYW5kICJtZXNzYWdl LWZsb3ciLiBJbiBmYWN0LCB3ZSBoYXZlIGRvbmUgDQpiaWxsaW5nL2NoYXJnaW5nL3BvbGljeSBh bmQgTEkgd2l0aG91dCBzdWNoIG5ldyBoZWFkZXIuIFNvLCBJIHNhaWQgdGhhdCBJIA0KZGlkIG5v dCBmaW5kIHJlcXVpcmVtZW50IG9mIGRlZmluaW5nIG5ldyBoZWFkZXIgdG8gY29ycmVsYXRlICJz ZXNzaW9uIiBhbmQgDQoibWVzc2FnZS1mbG93Ii4NCg0KTWF5YmUgdGhlcmUncyB1c2UgY2FzZSBh bmQgcmVxdWlyZW1lbnQgZm9yIHRoZSBuZXcgaGVhZGVyLiBTbywgSSdkIGxpa2UgdG8gDQpzZWUg aXQncyBkZXRhaWwuDQoNClRoYW5rcywNCg0KR2FvIA0KDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAg IDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLS0tINeqt6LIyyBHYW9ZYW5nMTQw MTk3L3VzZXIvenRlX2x0ZCDKsbzkIDIwMTAtMDUtMTAgMjE6MDIgLS0tLS0NCg0KR2FvWWFuZzE0 MDE5Ny91c2VyL3p0ZV9sdGQNCjIwMTAtMDUtMTAgMjA6NTYNCg0KytW8/sjLDQpIYWRyaWVsIEth cGxhbiA8SEthcGxhbkBhY21lcGFja2V0LmNvbT4NCrOty80NCkRJU1BBVENIIDxkaXNwYXRjaEBp ZXRmLm9yZz4sIGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcNCtb3zOINClJlOiBbZGlzcGF0Y2hd IFNlc3Npb24tSUQgY2hhcnRlciBwcm9wb3NhbA0KDQoNCg0KDQoNCg0KSGksDQoNCkknZCBsaWtl IHRvIHNlZSB0aGUgcmVxdWlyZW1lbnQgb2YgdGhlIGhlYWRlciBhbmQgdHlwaWNhbCB1c2UgY2Fz ZSBmb3IgaXQgDQppbiB0aGUgY2hhcnRlci4NCg0KVGhhbmtzLA0KDQpHYW8NCg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4 NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0 ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQpIYWRy aWVsIEthcGxhbiA8SEthcGxhbkBhY21lcGFja2V0LmNvbT4gDQq3orz+yMs6ICBkaXNwYXRjaC1i b3VuY2VzQGlldGYub3JnDQoyMDEwLTA1LTA5IDA0OjM1DQoNCsrVvP7Iyw0KRElTUEFUQ0ggPGRp c3BhdGNoQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpbZGlzcGF0Y2hdIFNlc3Npb24tSUQgY2hh cnRlciBwcm9wb3NhbA0KDQoNCg0KDQoNCg0KSG93ZHksDQpJIGhhdmUgYXNrZWQgdGhlIERJU1BB VENIIGNoYWlycyB3aGF0IHRvIGRvIHdpdGggU2Vzc2lvbi1JRCwgZ2l2ZW4gdGhlIA0KZmVlZGJh Y2sgSSByZWNlaXZlZCB0byBtYWtlIGl0IGEgc3RhbmRhcmRzLXRyYWNrIHZzLiBpbmRpdmlkdWFs IA0KaW5mb3JtYXRpb25hbCBzdWJtaXNzaW9uLiAgVGhlcmUgaXMgbm8gb2J2aW91cyBjdXJyZW50 IFdHIGZvciB0aGlzIHdvcmssIA0Kc28gdGhleSBhc2tlZCBtZSB0byBwb3N0IGEgc3RyYXdtYW4g Y2hhcnRlciBwcm9wb3NhbCwgd2hpY2ggSSBwcm9wb3NlIGFzIA0KZm9sbG93czoNCg0KDQpTSVAg U2lnbmFsaW5nLUNPbW11bmljYXRpb24gVHJvdWJsZXNob290aW5nIHdpdGggQ29ycmVsYXRpb24g SGVhZGVyIA0KKFNJUFNDT1RDSCkgQ2hhcnRlcjoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClRoZSBTSVBTQ09UQ0ggd29ya2luZyBncm91cCBpcyBjaGFydGVyZWQgdG8gZGVm aW5lIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIA0Kb3BlcmF0b3JzIGFuZCBtb25pdG9yaW5nIGVx dWlwbWVudCB0byBjb3JyZWxhdGUgU0lQIG1lc3NhZ2VzIGFuZCBkaWFsb2dzIA0Kb2YgdGhlIHNh bWUgaGlnaGVyLWxldmVsIGVuZC10by1lbmQgInNlc3Npb24iIG9yICJtZXNzYWdlLWZsb3ciLiAg SW4gDQpwYXJ0aWN1bGFyLCB0aGUgbWVjaGFuaXNtIG11c3QgYmUgYWJsZSB0byBhbGxvdyBzdWNo IGNvcnJlbGF0aW9uIGFjcm9zcyANClNJUCBCMkJVQXMgb2YgYXMgbWFueSBmdW5jdGlvbmFsIHR5 cGVzIGFzIHBvc3NpYmxlLCBzdWNoIGFzIEFwcGxpY2F0aW9uIA0KU2VydmVycywgU29mdHN3aXRj aGVzLCBQQlhzLCBTQkNzLCBldGMuDQoNCkFsdGhvdWdoIG90aGVyIHNvbHV0aW9ucyBtYXkgYmUg cG9zc2libGUsIHRoaXMgd29ya2luZyBncm91cCB3aWxsIGZvY3VzIG9uIA0KZGVmaW5pbmcgYSBu ZXcgU0lQIEhlYWRlciBmaWVsZCBmb3Igc3VjaCBhIHB1cnBvc2UsIHNpbWlsYXIgdG8gdGhlIENh bGwtSUQgDQpoZWFkZXIgZmllbGQsIGluIG9yZGVyIHRvIHByb3ZpZGUgYSBzaW1wbGUsIGVhc2ls eSBkZXBsb3lhYmxlIG1lY2hhbmlzbSANCndoaWNoIGNhbiB3b3JrIGFjcm9zcyBTSVAgZG9tYWlu cy4gVGhlIFNJUCBDYWxsLUlEIGhlYWRlciBmaWVsZCB2YWx1ZSANCml0c2VsZiBpcyBub3QgdXNh YmxlIGZvciBzdWNoIGNvcnJlbGF0aW9uLCBiZWNhdXNlIG1hbnkgQjJCVUFzIG11c3QgY3JlYXRl IA0KYSBuZXcgQ2FsbC1JRCB2YWx1ZSBvbiB0aGVpciBVQUMgInNpZGUiIGluIG9yZGVyIHRvIGZ1 bmN0aW9uIHByb3Blcmx5LCBhbmQgDQp0byBjb21wbHkgd2l0aCB0aGUgcnVsZXMgb2YgUkZDIDMy NjEuIA0KDQpJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBjZXJ0YWluIFNJUCBCMkJVQXMgcGVyZm9y bSBhICJ0b3BvbG9neS1oaWRpbmciIA0KZnVuY3Rpb24sIGFzIGRlc2NyaWJlZCBpbiBSRkMgNTg1 My4gIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgdGFrZSBzdWNoIA0KZnVuY3Rpb25zIGludG8gYWNj b3VudCBmb3IgdGhlIGNvcnJlbGF0aW9uIG1lY2hhbmlzbSwgYXMgd2VsbCBhcyBwcm92aWRlIA0K Z3VpZGFuY2UgZm9yIGltcGxlbWVudGVycyBvZiB0aGUgbWVjaGFuaXNtIHRvIGF2b2lkIHRyaWdn ZXJpbmcgc3VjaCBhIA0KZnVuY3Rpb24gZm9yIHRoZSBtZWNoYW5pc20ncyBoZWFkZXIgZmllbGQg dmFsdWUuDQoNCkxhc3RseSwgYWx0aG91Z2ggaW4gY2VydGFpbiBlbnZpcm9ubWVudHMgc3VjaCBh IG1lY2hhbmlzbSBtYXkgYmUgdXNhYmxlIA0KZm9yIGRpYWxvZyBjb3JyZWxhdGlvbiBpbiBTSVAg c3RhdGUgbWFjaGluZXMsIGl0IGlzIG5vdCB0aGUgZ29hbCBvZiB0aGlzIA0Kd29ya2luZyBncm91 cCB0byBhZGRyZXNzIHRoYXQgdXNhZ2UuDQoNCkdvYWxzIGFuZCBNaWxlc3RvbmVzDQo9PT09PT09 PT09PT09PT09PT09PQ0KRGVjIDIwMTAgLSBOZXcgaGVhZGVyIHNwZWNpZmljYXRpb24gdG8gSUVT RyAoUFMpDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCmRpc3BhdGNoQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlz IG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRl ZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVy cy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0 aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3Nl IG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0048BAD24825771F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UGxlYXNlIGxldCBtZSBtYWtlIG15IHF1 ZXN0aW9uIGNsZWFybHkuDQpDb25zaWRlcmluZyBiaWxsaW5nL2NoYXJnaW5nL3BvbGljeSBhbmQg TEkobGF3ZnVsIGludGVyY2VwdGlvbiksIHRoZXJlJ3MNCnVzZSBjYXNlcyBvZiBjb3JyZWxhdGlu ZyAmcXVvdDtzZXNzaW9uJnF1b3Q7IGFuZCAmcXVvdDttZXNzYWdlLWZsb3cmcXVvdDsuDQpJbiBm YWN0LCB3ZSBoYXZlIGRvbmUgYmlsbGluZy9jaGFyZ2luZy9wb2xpY3kgYW5kIExJIHdpdGhvdXQg c3VjaCBuZXcgaGVhZGVyLg0KU28sIEkgc2FpZCB0aGF0IEkgZGlkIG5vdCBmaW5kIHJlcXVpcmVt ZW50IG9mIGRlZmluaW5nIG5ldyBoZWFkZXIgdG8gY29ycmVsYXRlDQomcXVvdDtzZXNzaW9uJnF1 b3Q7IGFuZCAmcXVvdDttZXNzYWdlLWZsb3cmcXVvdDsuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5NYXliZSB0aGVyZSdzIHVzZSBjYXNlIGFuZCByZXF1 aXJlbWVudA0KZm9yIHRoZSBuZXcgaGVhZGVyLiBTbywgSSdkIGxpa2UgdG8gc2VlIGl0J3MgZGV0 YWlsLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhh bmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2Fv ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5i c3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5i c3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20u Y248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj48 Zm9udCBzaXplPTEgY29sb3I9IzgwMDA4MCBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLSDXqreiyMsg R2FvWWFuZzE0MDE5Ny91c2VyL3p0ZV9sdGQNCsqxvOQgMjAxMC0wNS0xMCAyMTowMiAtLS0tLTwv Zm9udD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lk dGg9NDAlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5HYW9ZYW5nMTQwMTk3L3Vz ZXIvenRlX2x0ZDwvYj48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ MjAxMC0wNS0xMCAyMDo1NjwvZm9udD4NCjx0ZCB3aWR0aD01OSU+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5IYWRyaWVsIEthcGxhbiAmbHQ7SEthcGxhbkBhY21lcGFja2V0LmNv bSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkRJU1BBVENIICZsdDtkaXNwYXRjaEBpZXRmLm9yZyZn dDssDQpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98zi PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW2Rp c3BhdGNoXSBTZXNzaW9uLUlEIGNoYXJ0ZXIgcHJvcG9zYWw8L2ZvbnQ+PGEgaHJlZj1Ob3Rlczov L05KTUFJTDAxLzQ4MjU3MTY5MDAyREY4RUUvREFCQTk3NUI5RkIxMTNFQjg1MjU2NEI1MDAxMjgz RUEvNzlBNzA2MTVBMkQ2QUUxOTQ4MjU3NzFEMDA3MTFENzg+wbS90zwvYT48L3RhYmxlPg0KPGJy Pg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3Rh YmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5IaSw8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkknZCBsaWtl IHRvIHNlZSB0aGUgcmVxdWlyZW1lbnQgb2YgdGhlDQpoZWFkZXIgYW5kIHR5cGljYWwgdXNlIGNh c2UgZm9yIGl0IGluIHRoZSBjaGFydGVyLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBa aXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxi cj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55 YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08 L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SGFk cmllbCBLYXBsYW4gJmx0O0hLYXBsYW5AYWNtZXBhY2tldC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0K PGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO2Rpc3BhdGNo LWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+MjAxMC0wNS0wOSAwNDozNTwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5ESVNQQVRDSCAmbHQ7ZGlzcGF0Y2hAaWV0Zi5vcmcmZ3Q7PC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5b ZGlzcGF0Y2hdIFNlc3Npb24tSUQgY2hhcnRlciBwcm9wb3NhbDwvZm9udD48L3RhYmxlPg0KPGJy Pg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3Rh YmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SG93ZHksPGJyPg0KSSBoYXZl IGFza2VkIHRoZSBESVNQQVRDSCBjaGFpcnMgd2hhdCB0byBkbyB3aXRoIFNlc3Npb24tSUQsIGdp dmVuIHRoZQ0KZmVlZGJhY2sgSSByZWNlaXZlZCB0byBtYWtlIGl0IGEgc3RhbmRhcmRzLXRyYWNr IHZzLiBpbmRpdmlkdWFsIGluZm9ybWF0aW9uYWwNCnN1Ym1pc3Npb24uICZuYnNwO1RoZXJlIGlz IG5vIG9idmlvdXMgY3VycmVudCBXRyBmb3IgdGhpcyB3b3JrLCBzbyB0aGV5DQphc2tlZCBtZSB0 byBwb3N0IGEgc3RyYXdtYW4gY2hhcnRlciBwcm9wb3NhbCwgd2hpY2ggSSBwcm9wb3NlIGFzIGZv bGxvd3M6PGJyPg0KPGJyPg0KPGJyPg0KU0lQIFNpZ25hbGluZy1DT21tdW5pY2F0aW9uIFRyb3Vi bGVzaG9vdGluZyB3aXRoIENvcnJlbGF0aW9uIEhlYWRlciAoU0lQU0NPVENIKQ0KQ2hhcnRlcjo8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KVGhlIFNJUFNDT1RD SCB3b3JraW5nIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZWZpbmUgYSBtZWNoYW5pc20gdGhhdCBh bGxvd3MNCm9wZXJhdG9ycyBhbmQgbW9uaXRvcmluZyBlcXVpcG1lbnQgdG8gY29ycmVsYXRlIFNJ UCBtZXNzYWdlcyBhbmQgZGlhbG9ncw0Kb2YgdGhlIHNhbWUgaGlnaGVyLWxldmVsIGVuZC10by1l bmQgJnF1b3Q7c2Vzc2lvbiZxdW90OyBvciAmcXVvdDttZXNzYWdlLWZsb3cmcXVvdDsuDQombmJz cDtJbiBwYXJ0aWN1bGFyLCB0aGUgbWVjaGFuaXNtIG11c3QgYmUgYWJsZSB0byBhbGxvdyBzdWNo IGNvcnJlbGF0aW9uDQphY3Jvc3MgU0lQIEIyQlVBcyBvZiBhcyBtYW55IGZ1bmN0aW9uYWwgdHlw ZXMgYXMgcG9zc2libGUsIHN1Y2ggYXMgQXBwbGljYXRpb24NClNlcnZlcnMsIFNvZnRzd2l0Y2hl cywgUEJYcywgU0JDcywgZXRjLjxicj4NCjxicj4NCkFsdGhvdWdoIG90aGVyIHNvbHV0aW9ucyBt YXkgYmUgcG9zc2libGUsIHRoaXMgd29ya2luZyBncm91cCB3aWxsIGZvY3VzDQpvbiBkZWZpbmlu ZyBhIG5ldyBTSVAgSGVhZGVyIGZpZWxkIGZvciBzdWNoIGEgcHVycG9zZSwgc2ltaWxhciB0byB0 aGUgQ2FsbC1JRA0KaGVhZGVyIGZpZWxkLCBpbiBvcmRlciB0byBwcm92aWRlIGEgc2ltcGxlLCBl YXNpbHkgZGVwbG95YWJsZSBtZWNoYW5pc20NCndoaWNoIGNhbiB3b3JrIGFjcm9zcyBTSVAgZG9t YWlucy4gVGhlIFNJUCBDYWxsLUlEIGhlYWRlciBmaWVsZCB2YWx1ZSBpdHNlbGYNCmlzIG5vdCB1 c2FibGUgZm9yIHN1Y2ggY29ycmVsYXRpb24sIGJlY2F1c2UgbWFueSBCMkJVQXMgbXVzdCBjcmVh dGUgYSBuZXcNCkNhbGwtSUQgdmFsdWUgb24gdGhlaXIgVUFDICZxdW90O3NpZGUmcXVvdDsgaW4g b3JkZXIgdG8gZnVuY3Rpb24gcHJvcGVybHksDQphbmQgdG8gY29tcGx5IHdpdGggdGhlIHJ1bGVz IG9mIFJGQyAzMjYxLiA8YnI+DQo8YnI+DQpJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBjZXJ0YWlu IFNJUCBCMkJVQXMgcGVyZm9ybSBhICZxdW90O3RvcG9sb2d5LWhpZGluZyZxdW90Ow0KZnVuY3Rp b24sIGFzIGRlc2NyaWJlZCBpbiBSRkMgNTg1My4gJm5ic3A7VGhlIHdvcmtpbmcgZ3JvdXAgd2ls bCB0YWtlIHN1Y2gNCmZ1bmN0aW9ucyBpbnRvIGFjY291bnQgZm9yIHRoZSBjb3JyZWxhdGlvbiBt ZWNoYW5pc20sIGFzIHdlbGwgYXMgcHJvdmlkZQ0KZ3VpZGFuY2UgZm9yIGltcGxlbWVudGVycyBv ZiB0aGUgbWVjaGFuaXNtIHRvIGF2b2lkIHRyaWdnZXJpbmcgc3VjaCBhIGZ1bmN0aW9uDQpmb3Ig dGhlIG1lY2hhbmlzbSdzIGhlYWRlciBmaWVsZCB2YWx1ZS48YnI+DQo8YnI+DQpMYXN0bHksIGFs dGhvdWdoIGluIGNlcnRhaW4gZW52aXJvbm1lbnRzIHN1Y2ggYSBtZWNoYW5pc20gbWF5IGJlIHVz YWJsZQ0KZm9yIGRpYWxvZyBjb3JyZWxhdGlvbiBpbiBTSVAgc3RhdGUgbWFjaGluZXMsIGl0IGlz IG5vdCB0aGUgZ29hbCBvZiB0aGlzDQp3b3JraW5nIGdyb3VwIHRvIGFkZHJlc3MgdGhhdCB1c2Fn ZS48YnI+DQo8YnI+DQpHb2FscyBhbmQgTWlsZXN0b25lczxicj4NCj09PT09PT09PT09PT09PT09 PT09PGJyPg0KRGVjIDIwMTAgLSBOZXcgaGVhZGVyIHNwZWNpZmljYXRpb24gdG8gSUVTRyAoUFMp PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpkaXNwYXRjaCBtYWlsaW5nIGxpc3Q8YnI+DQpkaXNwYXRjaEBpZXRmLm9yZzxicj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2g8YnI+DQo8YnI+ DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5i c3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtj b250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkm bmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6 YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJz cDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJz cDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZu YnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlz Y2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZu YnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJz cDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVs eSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNw O2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNl aXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2Um bmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMm bmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJz cDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3By ZT4= --=_alternative 0048BAD24825771F_=-- From pkyzivat@cisco.com Mon May 10 06:48:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07F1E3A694F for ; Mon, 10 May 2010 06:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.973 X-Spam-Level: X-Spam-Status: No, score=-8.973 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFpMLO2IAM2I for ; Mon, 10 May 2010 06:48:00 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 35C503A6948 for ; Mon, 10 May 2010 06:48:00 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALqq50urRN+J/2dsb2JhbACeHnGjGpkShRQE X-IronPort-AV: E=Sophos;i="4.52,362,1270425600"; d="scan'208";a="527572245" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 10 May 2010 13:47:49 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o4ADlntK029100; Mon, 10 May 2010 13:47:49 GMT Message-ID: <4BE80E84.70900@cisco.com> Date: Mon, 10 May 2010 09:47:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE50DA7.9050002@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D7770@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7770@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH , Gonzalo Camarillo Subject: Re: [dispatch] Which messages for Alert-info (Was: Status codes vs Alert-Info URNs) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 13:48:01 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:gcamaril@gmail.com] >> Sent: Saturday, May 08, 2010 3:07 AM >> To: Hadriel Kaplan >> >> To make this decision, we also need to agree on which messages need to >> carry these semantic indications. It is only INVITEs and 180 responses, >> INVITEs and 1xx responses, or something else? > > RESPONSES: > If you don't support it in the 181, 182 and 183, we'd have to explain why not. Because the use-cases for call-forwarding and call-waiting are explicitly indicated in the charter, and afaik those *are* 181 and 182. And 183 is supposed to be the response code used when 180/181/182 are not semantically correct, so again it seems appropriate for this type of thing. Clearly 100 should be excluded, as should 199. So limiting to 180-183 seems reasonable. AFAIK there is no common semantic formally associated with 18x in general, so limiting to that probably doesn't make sense. > REQUESTS: > You may want it to be available in a BYE as well. For example, disconnected calls due to error cases sometimes get special tones. > Brett mentioned the UPDATE method, since re-INVITE is covered, which seems reasonable. > He also mentioned the REFER method, though I'm not sure in what way he meant it. (ie, is it for the receiver of the REFER, or is it meant to be in the INVITE created from it) > He also said "Since I assume some vendors send Alert-Info within INFO or NOTIFY during a call waiting notification, Alert-Info potentially should also be valid there. However I guess making it valid could wait until someone officially registers such a usages." > > Personally I don't see any reason to restrict what methods it's allowed to be put into - it's always up to the receiver to decide if it wants to use it anyway. It doesn't affect dialog state, so what's the harm? This draft is mostly about *what* is rendered, not *when* it is rendered. Expanding beyond INVITE and its responses is really broadening alerting to contexts where it hasn't been applicable in the past. Thats even true of broadening beyond 180 to 180-183, but is arguably a much "smaller" change. It is true that the actual alerting is always discretionary, so broadening need not be disruptive on existing implementations, since they are free to ignore. I guess for now I am inclined to be "conservative" and broaden to 180-183 but not further. But I'm not strongly against broadening further. Thanks, Paul From HKaplan@acmepacket.com Mon May 10 09:28:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146513A6888 for ; Mon, 10 May 2010 09:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.993 X-Spam-Level: X-Spam-Status: No, score=-0.993 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fzaiuj18OT0o for ; Mon, 10 May 2010 09:28:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AA7413A6840 for ; Mon, 10 May 2010 09:28:53 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 10 May 2010 12:28:41 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 10 May 2010 12:28:41 -0400 From: Hadriel Kaplan To: Peter Musgrave Date: Mon, 10 May 2010 12:28:40 -0400 Thread-Topic: [dispatch] Session-ID charter proposal Thread-Index: Acrvavn0bfciynOrTuOyiWE2O9ZsXgA8qSLQ Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D793D@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:28:55 -0000 Hi Peter, I think the sentence stating we must take topology-hiding into account shou= ld satisfy the anonymization issue. Do you agree? -hadriel > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > Sent: Sunday, May 09, 2010 7:30 AM > To: Hadriel Kaplan >=20 > Draft charter seems to hit the right points. >=20 > Is it worth noting that the solution must ensure endpoint anonymity - > or is it ok to leave that for the draft? From peter.musgrave@magorcorp.com Mon May 10 09:31:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025993A69DB for ; Mon, 10 May 2010 09:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.045 X-Spam-Level: X-Spam-Status: No, score=-1.045 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgnfK4tF9BvA for ; Mon, 10 May 2010 09:31:19 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 2CCD73A69D4 for ; Mon, 10 May 2010 09:31:19 -0700 (PDT) Received: by gyh4 with SMTP id 4so2115940gyh.31 for ; Mon, 10 May 2010 09:31:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.188.9 with SMTP id l9mr7816015ybf.109.1273509063073; Mon, 10 May 2010 09:31:03 -0700 (PDT) Received: by 10.150.58.14 with HTTP; Mon, 10 May 2010 09:31:03 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D793D@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> <430FC6BDED356B4C8498F634416644A91A8A7D793D@mail> Date: Mon, 10 May 2010 12:31:03 -0400 Message-ID: From: Peter Musgrave To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:31:20 -0000 I agree Peter Musgrave On Mon, May 10, 2010 at 12:28 PM, Hadriel Kaplan w= rote: > > Hi Peter, > I think the sentence stating we must take topology-hiding into account sh= ould satisfy the anonymization issue. =A0Do you agree? > > -hadriel > >> -----Original Message----- >> From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] >> Sent: Sunday, May 09, 2010 7:30 AM >> To: Hadriel Kaplan >> >> Draft charter seems to hit the right points. >> >> Is it worth noting that the solution must ensure endpoint anonymity - >> or is it ok to leave that for the draft? > > From HKaplan@acmepacket.com Mon May 10 09:31:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579E33A69F5 for ; Mon, 10 May 2010 09:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6ylzWZ56LLr for ; Mon, 10 May 2010 09:31:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 18F1C3A68F5 for ; Mon, 10 May 2010 09:31:41 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 10 May 2010 12:31:29 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 10 May 2010 12:31:29 -0400 From: Hadriel Kaplan To: Victor Pascual Avila Date: Mon, 10 May 2010 12:31:25 -0400 Thread-Topic: [dispatch] Session-ID charter proposal Thread-Index: AcrwNQ5G2/3NkhkmQXC2Sodj6xR5xgAKNL6Q Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D793F@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:31:42 -0000 Right now it has only one deliverable, under the Goals and Milestones secti= on. In theory one could always modify a charter of any WG to add more deli= verables later, and I've never seen a charter which said "this charter must= not be changed". :) In practice changing a charter takes consensus anyway, and my guess is any = attempt to do that for this charter would be squashed by consensus. -hadriel > -----Original Message----- > From: Victor Pascual Avila [mailto:victor.pascual.avila@gmail.com] > Sent: Monday, May 10, 2010 7:36 AM > To: Hadriel Kaplan > Cc: DISPATCH > Subject: Re: [dispatch] Session-ID charter proposal >=20 > Looks good to me. Just one quick question: will this WG produce a > single deliverable? >=20 > -Victor >=20 > On Sat, May 8, 2010 at 10:35 PM, Hadriel Kaplan > wrote: > > Howdy, > > I have asked the DISPATCH chairs what to do with Session-ID, given the > feedback I received to make it a standards-track vs. individual > informational submission. =A0There is no obvious current WG for this work= , > so they asked me to post a strawman charter proposal, which I propose as > follows: > > > > > > SIP Signaling-COmmunication Troubleshooting with Correlation Header > (SIPSCOTCH) Charter: > > ---------------------------------- > > The SIPSCOTCH working group is chartered to define a mechanism that > allows operators and monitoring equipment to correlate SIP messages and > dialogs of the same higher-level end-to-end "session" or "message- > flow". =A0In particular, the mechanism must be able to allow such > correlation across SIP B2BUAs of as many functional types as possible, > such as Application Servers, Softswitches, PBXs, SBCs, etc. > > > > Although other solutions may be possible, this working group will focus > on defining a new SIP Header field for such a purpose, similar to the > Call-ID header field, in order to provide a simple, easily deployable > mechanism which can work across SIP domains. The SIP Call-ID header field > value itself is not usable for such correlation, because many B2BUAs must > create a new Call-ID value on their UAC "side" in order to function > properly, and to comply with the rules of RFC 3261. > > > > It should be noted that certain SIP B2BUAs perform a "topology-hiding" > function, as described in RFC 5853. =A0The working group will take such > functions into account for the correlation mechanism, as well as provide > guidance for implementers of the mechanism to avoid triggering such a > function for the mechanism's header field value. > > > > Lastly, although in certain environments such a mechanism may be usable > for dialog correlation in SIP state machines, it is not the goal of this > working group to address that usage. > > > > Goals and Milestones > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Dec 2010 - New header specification to IESG (PS) > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 >=20 >=20 > -- > Victor Pascual =C1vila From HKaplan@acmepacket.com Mon May 10 09:34:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB6B3A69DB for ; Mon, 10 May 2010 09:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.319 X-Spam-Level: * X-Spam-Status: No, score=1.319 tagged_above=-999 required=5 tests=[AWL=-3.300, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG932H+PaR0C for ; Mon, 10 May 2010 09:34:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E3B2A3A68F5 for ; Mon, 10 May 2010 09:34:33 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 10 May 2010 12:34:22 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 10 May 2010 12:34:21 -0400 From: Hadriel Kaplan To: "gao.yang2@zte.com.cn" Date: Mon, 10 May 2010 12:33:51 -0400 Thread-Topic: [dispatch] Session-ID charter proposal Thread-Index: AcrwQtpw190a2h8SQ4mUtRYGsVeqwwAG20EA Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7941@mail> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A8A7D7941mail_" MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:34:39 -0000 --_000_430FC6BDED356B4C8498F634416644A91A8A7D7941mail_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhlIHB1cnBvc2UgaXMgZm9yIHRyb3VibGVzaG9vdGluZywgYWNyb3NzIG11bHRpcGxlIHN5c3Rl bXMuICBJIGhhZCB0aGF0IGluIHRoZSB0aXRsZSBvZiB0aGUgY2hhcnRlciwgYnV0IHlvdaGvcmUg cmlnaHQgSSBmb3Jnb3QgdG8gZXhwbGljaXRseSBjYWxsIHRoYXQgb3V0IGluIHRoZSBjaGFydGVy Lg0KSG93IGFib3V0IHRoaXMgbmV3IGZpcnN0IHNlbnRlbmNlOg0KVGhlIFNJUFNDT1RDSCB3b3Jr aW5nIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZWZpbmUgYSBtZWNoYW5pc20gdGhhdCBhbGxvd3Mg b3BlcmF0b3JzIGFuZCBtb25pdG9yaW5nIGVxdWlwbWVudCB0byBjb3JyZWxhdGUgU0lQIG1lc3Nh Z2VzIGFuZCBkaWFsb2dzIG9mIHRoZSBzYW1lIGhpZ2hlci1sZXZlbCBlbmQtdG8tZW5kICJzZXNz aW9uIiBvciAibWVzc2FnZS1mbG93IiBhY3Jvc3MgbXVsdGlwbGUgU0lQIGRldmljZXMsIGZvciB0 aGUgcHVycG9zZSBvZiB0cm91Ymxlc2hvb3RpbmcuDQoNCi1oYWRyaWVsDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBnYW8ueWFuZzJAenRlLmNvbS5jbiBbbWFpbHRv Omdhby55YW5nMkB6dGUuY29tLmNuXQ0KU2VudDogTW9uZGF5LCBNYXkgMTAsIDIwMTAgOToxMiBB TQ0KVG86IEhhZHJpZWwgS2FwbGFuDQpDYzogRElTUEFUQ0gNClN1YmplY3Q6IFJlOiBbZGlzcGF0 Y2hdIFNlc3Npb24tSUQgY2hhcnRlciBwcm9wb3NhbA0KDQoNCkhpLA0KDQpQbGVhc2UgbGV0IG1l IG1ha2UgbXkgcXVlc3Rpb24gY2xlYXJseS4gQ29uc2lkZXJpbmcgYmlsbGluZy9jaGFyZ2luZy9w b2xpY3kgYW5kIExJKGxhd2Z1bCBpbnRlcmNlcHRpb24pLCB0aGVyZSdzIHVzZSBjYXNlcyBvZiBj b3JyZWxhdGluZyAic2Vzc2lvbiIgYW5kICJtZXNzYWdlLWZsb3ciLiBJbiBmYWN0LCB3ZSBoYXZl IGRvbmUgYmlsbGluZy9jaGFyZ2luZy9wb2xpY3kgYW5kIExJIHdpdGhvdXQgc3VjaCBuZXcgaGVh ZGVyLiBTbywgSSBzYWlkIHRoYXQgSSBkaWQgbm90IGZpbmQgcmVxdWlyZW1lbnQgb2YgZGVmaW5p bmcgbmV3IGhlYWRlciB0byBjb3JyZWxhdGUgInNlc3Npb24iIGFuZCAibWVzc2FnZS1mbG93Ii4N Cg0KTWF5YmUgdGhlcmUncyB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnQgZm9yIHRoZSBuZXcgaGVh ZGVyLiBTbywgSSdkIGxpa2UgdG8gc2VlIGl0J3MgZGV0YWlsLg0KDQpUaGFua3MsDQoNCkdhbw0K DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KWmlwICAgIDogMjEwMDEyDQpU ZWwgICAgOiA4NzIxMQ0KVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCmVfbWFpbCA6IGdhby55 YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0t LS0g16q3osjLIEdhb1lhbmcxNDAxOTcvdXNlci96dGVfbHRkIMqxvOQgMjAxMC0wNS0xMCAyMTow MiAtLS0tLQ0KR2FvWWFuZzE0MDE5Ny91c2VyL3p0ZV9sdGQNCg0KMjAxMC0wNS0xMCAyMDo1Ng0K DQrK1bz+yMsNCg0KSGFkcmllbCBLYXBsYW4gPEhLYXBsYW5AYWNtZXBhY2tldC5jb20+DQoNCrOt y80NCg0KRElTUEFUQ0ggPGRpc3BhdGNoQGlldGYub3JnPiwgZGlzcGF0Y2gtYm91bmNlc0BpZXRm Lm9yZw0KDQrW98ziDQoNClJlOiBbZGlzcGF0Y2hdIFNlc3Npb24tSUQgY2hhcnRlciBwcm9wb3Nh bMG0vdM8Tm90ZXM6Ly9OSk1BSUwwMS80ODI1NzE2OTAwMkRGOEVFL0RBQkE5NzVCOUZCMTEzRUI4 NTI1NjRCNTAwMTI4M0VBLzc5QTcwNjE1QTJENkFFMTk0ODI1NzcxRDAwNzExRDc4Pg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpIaSwNCg0KSSdkIGxpa2UgdG8gc2VlIHRoZSByZXF1aXJlbWVudCBvZiB0 aGUgaGVhZGVyIGFuZCB0eXBpY2FsIHVzZSBjYXNlIGZvciBpdCBpbiB0aGUgY2hhcnRlci4NCg0K VGhhbmtzLA0KDQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClpp cCAgICA6IDIxMDAxMg0KVGVsICAgIDogODcyMTENClRlbDIgICA6KCs4NiktMDI1LTUyODc3MjEx DQplX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCg0KSGFkcmllbCBLYXBsYW4gPEhLYXBsYW5AYWNtZXBhY2tldC5jb20+DQq3 orz+yMs6ICBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnDQoNCjIwMTAtMDUtMDkgMDQ6MzUNCg0K ytW8/sjLDQoNCkRJU1BBVENIIDxkaXNwYXRjaEBpZXRmLm9yZz4NCg0Ks63LzQ0KDQoNCg0K1vfM 4g0KDQpbZGlzcGF0Y2hdIFNlc3Npb24tSUQgY2hhcnRlciBwcm9wb3NhbA0KDQoNCg0KDQoNCg0K DQoNCg0KDQpIb3dkeSwNCkkgaGF2ZSBhc2tlZCB0aGUgRElTUEFUQ0ggY2hhaXJzIHdoYXQgdG8g ZG8gd2l0aCBTZXNzaW9uLUlELCBnaXZlbiB0aGUgZmVlZGJhY2sgSSByZWNlaXZlZCB0byBtYWtl IGl0IGEgc3RhbmRhcmRzLXRyYWNrIHZzLiBpbmRpdmlkdWFsIGluZm9ybWF0aW9uYWwgc3VibWlz c2lvbi4gIFRoZXJlIGlzIG5vIG9idmlvdXMgY3VycmVudCBXRyBmb3IgdGhpcyB3b3JrLCBzbyB0 aGV5IGFza2VkIG1lIHRvIHBvc3QgYSBzdHJhd21hbiBjaGFydGVyIHByb3Bvc2FsLCB3aGljaCBJ IHByb3Bvc2UgYXMgZm9sbG93czoNCg0KDQpTSVAgU2lnbmFsaW5nLUNPbW11bmljYXRpb24gVHJv dWJsZXNob290aW5nIHdpdGggQ29ycmVsYXRpb24gSGVhZGVyIChTSVBTQ09UQ0gpIENoYXJ0ZXI6 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGUgU0lQU0NPVENIIHdvcmtp bmcgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBv cGVyYXRvcnMgYW5kIG1vbml0b3JpbmcgZXF1aXBtZW50IHRvIGNvcnJlbGF0ZSBTSVAgbWVzc2Fn ZXMgYW5kIGRpYWxvZ3Mgb2YgdGhlIHNhbWUgaGlnaGVyLWxldmVsIGVuZC10by1lbmQgInNlc3Np b24iIG9yICJtZXNzYWdlLWZsb3ciLiAgSW4gcGFydGljdWxhciwgdGhlIG1lY2hhbmlzbSBtdXN0 IGJlIGFibGUgdG8gYWxsb3cgc3VjaCBjb3JyZWxhdGlvbiBhY3Jvc3MgU0lQIEIyQlVBcyBvZiBh cyBtYW55IGZ1bmN0aW9uYWwgdHlwZXMgYXMgcG9zc2libGUsIHN1Y2ggYXMgQXBwbGljYXRpb24g U2VydmVycywgU29mdHN3aXRjaGVzLCBQQlhzLCBTQkNzLCBldGMuDQoNCkFsdGhvdWdoIG90aGVy IHNvbHV0aW9ucyBtYXkgYmUgcG9zc2libGUsIHRoaXMgd29ya2luZyBncm91cCB3aWxsIGZvY3Vz IG9uIGRlZmluaW5nIGEgbmV3IFNJUCBIZWFkZXIgZmllbGQgZm9yIHN1Y2ggYSBwdXJwb3NlLCBz aW1pbGFyIHRvIHRoZSBDYWxsLUlEIGhlYWRlciBmaWVsZCwgaW4gb3JkZXIgdG8gcHJvdmlkZSBh IHNpbXBsZSwgZWFzaWx5IGRlcGxveWFibGUgbWVjaGFuaXNtIHdoaWNoIGNhbiB3b3JrIGFjcm9z cyBTSVAgZG9tYWlucy4gVGhlIFNJUCBDYWxsLUlEIGhlYWRlciBmaWVsZCB2YWx1ZSBpdHNlbGYg aXMgbm90IHVzYWJsZSBmb3Igc3VjaCBjb3JyZWxhdGlvbiwgYmVjYXVzZSBtYW55IEIyQlVBcyBt dXN0IGNyZWF0ZSBhIG5ldyBDYWxsLUlEIHZhbHVlIG9uIHRoZWlyIFVBQyAic2lkZSIgaW4gb3Jk ZXIgdG8gZnVuY3Rpb24gcHJvcGVybHksIGFuZCB0byBjb21wbHkgd2l0aCB0aGUgcnVsZXMgb2Yg UkZDIDMyNjEuDQoNCkl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGNlcnRhaW4gU0lQIEIyQlVBcyBw ZXJmb3JtIGEgInRvcG9sb2d5LWhpZGluZyIgZnVuY3Rpb24sIGFzIGRlc2NyaWJlZCBpbiBSRkMg NTg1My4gIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgdGFrZSBzdWNoIGZ1bmN0aW9ucyBpbnRvIGFj Y291bnQgZm9yIHRoZSBjb3JyZWxhdGlvbiBtZWNoYW5pc20sIGFzIHdlbGwgYXMgcHJvdmlkZSBn dWlkYW5jZSBmb3IgaW1wbGVtZW50ZXJzIG9mIHRoZSBtZWNoYW5pc20gdG8gYXZvaWQgdHJpZ2dl cmluZyBzdWNoIGEgZnVuY3Rpb24gZm9yIHRoZSBtZWNoYW5pc20ncyBoZWFkZXIgZmllbGQgdmFs dWUuDQoNCkxhc3RseSwgYWx0aG91Z2ggaW4gY2VydGFpbiBlbnZpcm9ubWVudHMgc3VjaCBhIG1l Y2hhbmlzbSBtYXkgYmUgdXNhYmxlIGZvciBkaWFsb2cgY29ycmVsYXRpb24gaW4gU0lQIHN0YXRl IG1hY2hpbmVzLCBpdCBpcyBub3QgdGhlIGdvYWwgb2YgdGhpcyB3b3JraW5nIGdyb3VwIHRvIGFk ZHJlc3MgdGhhdCB1c2FnZS4NCg0KR29hbHMgYW5kIE1pbGVzdG9uZXMNCj09PT09PT09PT09PT09 PT09PT09DQpEZWMgMjAxMCAtIE5ldyBoZWFkZXIgc3BlY2lmaWNhdGlvbiB0byBJRVNHIChQUykN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRpc3Bh dGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBp cyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFy ZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8g ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQoN ClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRl bnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUg bWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQg Zm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --_000_430FC6BDED356B4C8498F634416644A91A8A7D7941mail_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

The purpose is for troubleshooting, ac= ross multiple systems.  I had that in the title of the charter, but you=A1= =AFre right I forgot to explicitly call that out in the charter.

How about this new first sentence:

The SIPSCOTCH working group is chartered to defi= ne a mechanism that allows operators and monitoring equipment to correlate SIP messages and dialogs of the same higher-level end-to-end "session"= ; or "message-flow" across multiple SIP devices, for the purpose of tr= oubleshooting.

 

-hadriel

 

From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: Monday, May 10, 2010 9= :12 AM
To: Hadriel Kaplan
Cc: DISPATCH
Subject: Re: [dispatch] Sess= ion-ID charter proposal

 


Hi,

Please let me make my question clearly. Considering billing/charging/policy and LI(lawful interception), there's use cases of correlating "session&quo= t; and "message-flow". In fact, we have done billing/charging/policy= and LI without such new header. So, I said that I did not find requirement of defining new header to correlate "session" and "message-flow".

Maybe there's use case and requirement for the new header. So, I'd like to see it= 's detail.

Thanks,

Gao  

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
----- = =D7=AA=B7=A2=C8=CB GaoYang140197/user/zte_ltd =CA=B1=BC=E4 2010-05-10 21:02 ----- <= /p>

GaoYang140197/user/zte_ltd=

2010-05-10 20:56

=CA=D5=BC=FE= =C8=CB

Hadriel Kaplan= <HKaplan@acmepacket.com>

=B3=AD=CB=CD=

DISPATCH <= dispatch@ietf.org>, dispatch-bounces@ietf.org

=D6=F7=CC=E2=

Re: [dispatch] Session-ID charter proposa= l=C1=B4=BD=D3

 

 

 




Hi,

I'd like to see the requirement of the header and typical use case for it in th= e charter.

Thanks,

Gao

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Hadrie= l Kaplan <HKaplan@acmepacket.com>
=B7=A2=BC=FE= =C8=CB:  dispatch-bounces@ietf.org

2010-05-09 04:35

=CA=D5=BC=FE= =C8=CB

DISPATCH <= dispatch@ietf.org>

=B3=AD=CB=CD=

 

=D6=F7=CC=E2=

[dispatch] Session-ID charter proposal

 

 

 




Howdy,
I have asked the DISPATCH chairs what to do with Session-ID, given the feedback I received to make it a standards-track vs. individual informational submission.  There is no obvious= current WG for this work, so they asked me to post a strawman charter proposal, whi= ch I propose as follows:


SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCOTCH) Charter:
----------------------------------
The SIPSCOTCH working group is chartered to define = a mechanism that allows operators and monitoring equipment to correlate SIP messages and dialogs of the same higher-level end-to-end "session"= ; or "message-flow".  In particular, the = mechanism must be able to allow such correlation across SIP B2BUAs of as many functio= nal types as possible, such as Application Servers, Softswitches, PBXs, SBCs, e= tc.

Although other solutions may be possible, this work= ing group will focus on defining a new SIP Header field for such a purpose, sim= ilar to the Call-ID header field, in order to provide a simple, easily deployabl= e mechanism which can work across SIP domains. The SIP Call-ID header field v= alue itself is not usable for such correlation, because many B2BUAs must create = a new Call-ID value on their UAC "side" in order to function proper= ly, and to comply with the rules of RFC 3261.

It should be noted that certain SIP B2BUAs perform = a "topology-hiding" function, as described in RFC 5853.  The working group w= ill take such functions into account for the correlation mechanism, as well as provi= de guidance for implementers of the mechanism to avoid triggering such a funct= ion for the mechanism's header field value.

Lastly, although in certain environments such a mec= hanism may be usable for dialog correlation in SIP state machines, it is not the g= oal of this working group to address that usage.

Goals and Milestones
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Dec 2010 - New header specification to IESG (PS)

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


&nb=
sp;
-------------------=
-------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This<=
font
face=3D"Courier New"> email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This<=
font
face=3D"Courier New"> message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--_000_430FC6BDED356B4C8498F634416644A91A8A7D7941mail_-- From HKaplan@acmepacket.com Mon May 10 09:56:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C633A6A44 for ; Mon, 10 May 2010 09:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+ZhVGtXG9TP for ; Mon, 10 May 2010 09:56:24 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EDD4A3A6A27 for ; Mon, 10 May 2010 09:56:21 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 10 May 2010 12:56:10 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 10 May 2010 12:56:09 -0400 From: Hadriel Kaplan To: "Elwell, John" , Gonzalo Camarillo Date: Mon, 10 May 2010 12:56:08 -0400 Thread-Topic: [dispatch] Alternative approach WAS (Re: Alert Info Charter) Thread-Index: Acrt+t4hU7hSppBtSByVbEInWhyApwAAEeSAAAOIttAAgxU68AASVnpA Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D794E@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE432D5.6030907@ericsson.com> <430FC6BDED356B4C8498F634416644A91A8A7D767B@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Alternative approach WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:56:25 -0000 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, May 10, 2010 3:54 AM > To: Hadriel Kaplan; Gonzalo Camarillo >=20 > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: 07 May 2010 18:46 > > To: Elwell, John; Gonzalo Camarillo > > > > Do you mean it's less disruptive to put a status code into > > Alert-Info, because people already use Alert-Info URI's for > > the ringing playback process? > > [JRE] I mean it is less disruptive to use Alert-Info, because that is wha= t > people do today. But that implies using a URL/URN in Alert-Info, not a > status code. But lots of people use the response's status-line status-code instead, too.= Heck, there's plenty of endpoints that ignore Alert-Info altogether. The= re is no single thing _all_ devices do today. I assumed that was one of th= e problems we're trying to fix. Don't get me wrong - I'm not opposed to using Alert-Info to carry an "alert= -status", I'm just trying to understand how it relates to the status-codes = in the SIP response status-line and a Reason header (if there is a Reason h= eader). =20 So far, whenever a "semantic" URN is used, it sounds like the same thing to= me as a status-code. It's only the "literal" ones that are not. Today Al= ert-Info carries "literal" ones - whether by reference (HTTP URL) or by val= ue (a "short-short" URN), it's still a literal: "play this tone". What you= guys are saying is "sometimes we don't want a literal, we want a call stat= us/condition indication which the UA/proxy can treat itself". Well, we alr= eady have those, so I'm trying to understand what the problem is with what = we have. -hadriel From pkyzivat@cisco.com Mon May 10 10:12:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC703A6A2A for ; Mon, 10 May 2010 10:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9fSvgcSulMU for ; Mon, 10 May 2010 10:12:45 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 63B393A69C6 for ; Mon, 10 May 2010 10:12:42 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAALb50tAZnwM/2dsb2JhbACeIXGjbZlDhRQE X-IronPort-AV: E=Sophos;i="4.52,363,1270425600"; d="scan'208";a="109869413" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 10 May 2010 17:12:28 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4AHCS5P023318; Mon, 10 May 2010 17:12:28 GMT Message-ID: <4BE83E7E.5030006@cisco.com> Date: Mon, 10 May 2010 13:12:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE432D5.6030907@ericsson.com> <430FC6BDED356B4C8498F634416644A91A8A7D767B@mail> <430FC6BDED356B4C8498F634416644A91A8A7D794E@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D794E@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Alternative approach WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 17:12:46 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Monday, May 10, 2010 3:54 AM >> To: Hadriel Kaplan; Gonzalo Camarillo >> >>> -----Original Message----- >>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>> Sent: 07 May 2010 18:46 >>> To: Elwell, John; Gonzalo Camarillo >>> >>> Do you mean it's less disruptive to put a status code into >>> Alert-Info, because people already use Alert-Info URI's for >>> the ringing playback process? >> [JRE] I mean it is less disruptive to use Alert-Info, because that is what >> people do today. But that implies using a URL/URN in Alert-Info, not a >> status code. > > But lots of people use the response's status-line status-code instead, too. Heck, there's plenty of endpoints that ignore Alert-Info altogether. There is no single thing _all_ devices do today. I assumed that was one of the problems we're trying to fix. > > Don't get me wrong - I'm not opposed to using Alert-Info to carry an "alert-status", I'm just trying to understand how it relates to the status-codes in the SIP response status-line and a Reason header (if there is a Reason header). > > So far, whenever a "semantic" URN is used, it sounds like the same thing to me as a status-code. It's only the "literal" ones that are not. Today Alert-Info carries "literal" ones - whether by reference (HTTP URL) or by value (a "short-short" URN), it's still a literal: "play this tone". What you guys are saying is "sometimes we don't want a literal, we want a call status/condition indication which the UA/proxy can treat itself". Well, we already have those, so I'm trying to understand what the problem is with what we have. Hadriel, The way the A-I stuff has developed, there are now a number of properties that can be provided as distinct URNs, which are then combined to determine the actual alert. I guess the same could be done with reason codes, except that it would be a bit contrived to say that "locale:FR" was a "reason". Thanks, Paul From HKaplan@acmepacket.com Mon May 10 10:37:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32DB028C223 for ; Mon, 10 May 2010 10:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q-7Yk9L6uwQ for ; Mon, 10 May 2010 10:37:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 60F3C28C20A for ; Mon, 10 May 2010 10:34:00 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 10 May 2010 13:33:47 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 10 May 2010 13:33:47 -0400 From: Hadriel Kaplan To: Laura Liess , Gonzalo Camarillo Date: Mon, 10 May 2010 13:33:37 -0400 Thread-Topic: [dispatch] Status codes vs Alert-Info URNs WAS (Re: Alert Info Charter) Thread-Index: AcrvlvNWPpN4QzVgROqjAmznOEzlJAAyuQlA Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7977@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE5418F.1010005@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Status codes vs Alert-Info URNs WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 17:37:12 -0000 > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: Sunday, May 09, 2010 12:44 PM > To: Gonzalo Camarillo >=20 > I don't think that replacing the Alert-Info URNs with respose/status > codes is a good idea, for following reasons: > - The Alert-Info URN is tightly coupled with the rendering. It is not > the rendering itself but an indication describing the semantic or the > characteristic(s) of the rendering. In the general case it does not > describe the call status. Right, it does not describe the call status, just a "ringtone". > - We choosed to use URNs as a flexible and extensible Internet-like > mechanism to work for the general case in Internet, beyond the > PSTN-like telephony. Currently we have only telephony use-cases, but > we intended to define a general mechanism. > - We choosed to use URN so the receiving UA can querry URN-resolvers > to get the rendering. Sounds good. > - We already have use cases which seems to me to be problematic if you > want to cover them with codes. E.g. country ringback tones. With the > Alert-info URN we have urn:alert:locale:country. code>. How could you represent this as response/status codes? They wouldn't, because that indications is NOT "semantic" to begin with. I= t's literal. What that URN is, is really a ringtone. It happens to be tha= t the ringtone is by reference, and the reference is a name rather than loc= ation. (ie, a URN vs. a URL) It is not "semantic" because it carries no more "meaning" than any other Al= ert-Info. It's just a defined name for mapping to a tone. (I'm not exactl= y sure how a country-specific name could ever work in practice nor why it s= olves interop issues, but that's another topic :) > - What about combination rules? This was one of the issues for which > we had a lot of discussions for Alert-Info URNs. > Thanks to Paul, we have now a quite flexible and well-sttructured > syntax for Alert-Info URN (still not in the draft, but the the result > of a ML-discussion): > [snipped ABNF] > Combination Rules: > -The categories are orthogonal. There can be at most one instance of > each alert-category in an > Alert-Info header. > - The implementation is free to ignore any or all received Alert-Info > URNs. I snipped the ABNF out, because I think that's really for the solution to f= igure out. But I sure hope the final list ends up being smaller than that,= if what you want is universal interoperability. :) > I don't think it is possible to achieve something similar using > response/status codes. Of course not - status codes are meant to provide status indication of the = call. Like "the call is ringing" or "the call is queued" or "the call is b= eing forwarded". *That* has "semantic" or "meaning". I thought that the c= harter was saying that's what you guys wanted in Alert-Info. =20 But the more it's being explained, the more I think you don't really want t= hat. You just want a resource name as opposed to a resource locator. So w= hy confuse it any further with language about "semantic"?? If the IETF dec= ides to define a URN for "short-short", that's just as meaningful or meanin= gless as "call-waiting" - because this is being used ONLY for ringtone name= s, not for call status. -hadriel From HKaplan@acmepacket.com Mon May 10 10:44:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4BD23A6C04 for ; Mon, 10 May 2010 10:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLaRZjfxYcAE for ; Mon, 10 May 2010 10:44:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BDC5F3A6A58 for ; Mon, 10 May 2010 10:41:25 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 10 May 2010 13:41:13 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 10 May 2010 13:41:13 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Mon, 10 May 2010 13:41:12 -0400 Thread-Topic: [dispatch] Alternative approach WAS (Re: Alert Info Charter) Thread-Index: AcrwZAa77KDvPaYqT9COYcVXGS6vxgAAxWDQ Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7980@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE432D5.6030907@ericsson.com> <430FC6BDED356B4C8498F634416644A91A8A7D767B@mail> <430FC6BDED356B4C8498F634416644A91A8A7D794E@mail> <4BE83E7E.5030006@cisco.com> In-Reply-To: <4BE83E7E.5030006@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Alternative approach WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 17:44:52 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, May 10, 2010 1:13 PM >=20 > Hadriel, >=20 > The way the A-I stuff has developed, there are now a number of > properties that can be provided as distinct URNs, which are then > combined to determine the actual alert. I guess the same could be done > with reason codes, except that it would be a bit contrived to say that > "locale:FR" was a "reason". I *think* the real answer to this is to stop using the word "semantic". Th= ese URNs have no real meaning. They're just names. The names may have pro= perties, like priority or locale or whatever, but at the end of the day if = the name "short-short" gets standardized, it's just as meaningful or meanin= gless as the name "call-waiting". That way you can ignore the overlap with= status-codes in other fields. -hadriel From pkyzivat@cisco.com Mon May 10 11:07:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECEF03A6A59 for ; Mon, 10 May 2010 11:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.056 X-Spam-Level: X-Spam-Status: No, score=-9.056 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuLUAmfMNx23 for ; Mon, 10 May 2010 11:07:33 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9EB623A6A80 for ; Mon, 10 May 2010 11:06:31 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF/o50tAZnwM/2dsb2JhbACeI3GjWZlPhRQE X-IronPort-AV: E=Sophos;i="4.52,363,1270425600"; d="scan'208";a="109746868" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 10 May 2010 18:06:20 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4AI6KhG010578; Mon, 10 May 2010 18:06:20 GMT Message-ID: <4BE84B20.7000703@cisco.com> Date: Mon, 10 May 2010 14:06:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE432D5.6030907@ericsson.com> <430FC6BDED356B4C8498F634416644A91A8A7D767B@mail> <430FC6BDED356B4C8498F634416644A91A8A7D794E@mail> <4BE83E7E.5030006@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7980@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7980@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Alternative approach WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 18:07:35 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, May 10, 2010 1:13 PM >> >> Hadriel, >> >> The way the A-I stuff has developed, there are now a number of >> properties that can be provided as distinct URNs, which are then >> combined to determine the actual alert. I guess the same could be done >> with reason codes, except that it would be a bit contrived to say that >> "locale:FR" was a "reason". > > I *think* the real answer to this is to stop using the word "semantic". These URNs have no real meaning. They're just names. The names may have properties, like priority or locale or whatever, but at the end of the day if the name "short-short" gets standardized, it's just as meaningful or meaningless as the name "call-waiting". That way you can ignore the overlap with status-codes in other fields. I'm perfectly happy to shed the "semantic" term in favor of something else. I already stated that I think this is a continuum rather than black/white. I think in general there is a preference for "more semantic, less literal", but that varies. So I do think "call-waiting" is more meaningful and more productively translated to suit various needs than "short-short" is. For instance it is more easily translated into something meaningful to deaf people. Thanks, Paul From HKaplan@acmepacket.com Mon May 10 11:12:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6E028C1C8 for ; Mon, 10 May 2010 11:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.341 X-Spam-Level: X-Spam-Status: No, score=-1.341 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPs7dJnxuWQa for ; Mon, 10 May 2010 11:12:23 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2EA4E3A6C04 for ; Mon, 10 May 2010 11:10:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 10 May 2010 14:10:38 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 10 May 2010 14:10:38 -0400 From: Hadriel Kaplan To: Laura Liess , Gonzalo Camarillo Date: Mon, 10 May 2010 14:10:37 -0400 Thread-Topic: Country-Locale-specific ringtones (was: Status codes vs Alert-Info URNs) Thread-Index: AcrvlvNWPpN4QzVgROqjAmznOEzlJAA03LMg Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7995@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE5418F.1010005@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: [dispatch] Country-Locale-specific ringtones (was: Status codes vs Alert-Info URNs) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 18:12:25 -0000 Out of curiosity - how do you see this country locale thing working? The charter says "For example, a user from a given country may not be famil= iar with the tone used to indicate call waiting in another country." So let's say I'm in the US and I call a number in France. Do I get back "u= rn:alert:locale:country.fr"? How is that useful to me? Or do proxies in t= he path convert it to "urn:alert:locale:country.us"? -hadriel > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: Sunday, May 09, 2010 12:44 PM > To: Gonzalo Camarillo > - We already have use cases which seems to me to be problematic if you > want to cover them with codes. E.g. country ringback tones. With the > Alert-info URN we have urn:alert:locale:country. code>. How could you represent this as response/status codes? From HKaplan@acmepacket.com Mon May 10 11:29:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8141E3A6C87 for ; Mon, 10 May 2010 11:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCtdQ7yPxuDd for ; Mon, 10 May 2010 11:29:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 147E73A6C03 for ; Mon, 10 May 2010 11:22:20 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 10 May 2010 14:22:08 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 10 May 2010 14:22:08 -0400 From: Hadriel Kaplan To: DISPATCH Date: Mon, 10 May 2010 14:22:04 -0400 Thread-Topic: Updates Session-ID charter Thread-Index: AcrwbbD3I0kahOGNSc2Kyg+gjSbVgA== Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Updates Session-ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 18:29:27 -0000 Howdy, Here is an updated charter, which I think addresses Gao's concern: SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCO= TCH) Charter: ---------------------------------- The SIPSCOTCH working group is chartered to define a mechanism that allows = operators and monitoring equipment to correlate SIP messages and dialogs of= the same higher-level end-to-end "session" across multiple SIP device hops= for the same "message-flow", for the purpose of troubleshooting. In parti= cular, the mechanism must be able to allow such correlation across SIP B2BU= As of as many functional types as possible, such as Application Servers, So= ftswitches, PBXs, SBCs, etc. Although other solutions may be possible, this working group will focus on = defining a new SIP Header field for such a purpose, similar to the Call-ID = header field, in order to provide a simple, easily deployable mechanism whi= ch can work across SIP domains. The SIP Call-ID header field value itself i= s not usable for such correlation, because many B2BUAs must create a new Ca= ll-ID value on their UAC "side" in order to function properly, and to compl= y with the rules of RFC 3261.=20 It should be noted that certain SIP B2BUAs perform a "topology-hiding" func= tion, as described in RFC 5853. The working group will take such functions= into account for the correlation mechanism, as well as provide guidance fo= r implementers of the mechanism to avoid triggering such a function for the= mechanism's header field value. Lastly, although in certain environments such a mechanism may be usable for= dialog correlation in SIP state machines, it is not the goal of this worki= ng group to address that usage. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dec 2010 - New header specification to IESG (PS) From pkyzivat@cisco.com Mon May 10 11:35:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA5B3A6C41 for ; Mon, 10 May 2010 11:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.257 X-Spam-Level: X-Spam-Status: No, score=-10.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfBUDIIrS9eK for ; Mon, 10 May 2010 11:35:33 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AB6CA3A6C75 for ; Mon, 10 May 2010 11:28:58 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABPt50tAZnwM/2dsb2JhbACeI3GjVplLhRQE X-IronPort-AV: E=Sophos;i="4.52,363,1270425600"; d="scan'208";a="109753838" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 10 May 2010 18:28:47 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4AISkvT017637; Mon, 10 May 2010 18:28:46 GMT Message-ID: <4BE85067.5050800@cisco.com> Date: Mon, 10 May 2010 14:28:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE5418F.1010005@ericsson.com> <430FC6BDED356B4C8498F634416644A91A8A7D7995@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7995@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH , Laura Liess Subject: Re: [dispatch] Country-Locale-specific ringtones X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 18:35:35 -0000 Hadriel Kaplan wrote: > Out of curiosity - how do you see this country locale thing working? > > The charter says "For example, a user from a given country may not be familiar with the tone used to indicate call waiting in another country." > > So let's say I'm in the US and I call a number in France. Do I get back "urn:alert:locale:country.fr"? How is that useful to me? Or do proxies in the path convert it to "urn:alert:locale:country.us"? That's a policy thing. Perhaps the UAS includes urn:alert:locale:country.fr because they want you to know they are in France, and so that you will get the true French experience. Then you local proxy, if you have one, may exert its own influence. (If so, hopefully it is because you configured it to do so.) It may override the locale with your default, or leave it alone, or whatever. And then your UA may honor it if it knows how, or ignore it, or ... Thanks, Paul > -hadriel > >> -----Original Message----- >> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >> Sent: Sunday, May 09, 2010 12:44 PM >> To: Gonzalo Camarillo >> - We already have use cases which seems to me to be problematic if you >> want to cover them with codes. E.g. country ringback tones. With the >> Alert-info URN we have urn:alert:locale:country.> code>. How could you represent this as response/status codes? > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From rifatyu@avaya.com Mon May 10 12:00:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A308828C38A for ; Mon, 10 May 2010 12:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkNdMaTIkBe0 for ; Mon, 10 May 2010 12:00:22 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id C0DE228C2C8 for ; Mon, 10 May 2010 11:52:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,363,1270440000"; d="scan'208,217";a="188004080" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 May 2010 14:52:28 -0400 X-IronPort-AV: E=Sophos;i="4.52,363,1270440000"; d="scan'208,217";a="461137371" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 May 2010 14:52:27 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 10 May 2010 14:52:27 -0400 From: "SHEKH-YUSEF, RIFAAT (RIFAAT)" To: "dispatch@ietf.org" , "mary.ietf.barnes@gmail.com" , "fluffy@cisco.com" Date: Mon, 10 May 2010 14:52:23 -0400 Thread-Topic: [dispatch] New I-D: draft-yusef-dispatch-ach-rest-api-00 Thread-Index: Acrwce0R9mYFd1j9Sx6Q3/xrk2831g== Message-ID: <6369CB70BFD88942B9705AC1E639A33821FDC0C703@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33821FDC0C703DCUS1MBEX4glo_" MIME-Version: 1.0 Subject: [dispatch] New I-D: draft-yusef-dispatch-ach-rest-api-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 19:00:23 -0000 --_000_6369CB70BFD88942B9705AC1E639A33821FDC0C703DCUS1MBEX4glo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have submitted the following ID and would like to add it as an agenda it= em for dispatch. http://datatracker.ietf.org/doc/draft-yusef-dispatch-ach-rest-api/ This work started in the BLISS WG, but the original draft has expired and t= he current plan for BLISS is to finish the current work and close. Regards, Rifaat -------------------- A new version of I-D, draft-yusef-dispatch-ach-rest-api-00.txt has been suc= cessfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository= . Filename: draft-yusef-dispatch-ach-rest-api Revision: 00 Title: ACH RESTful Interface Creation_date: 2010-05-10 WG ID: Independent Submission Number_of_pages: 18 Abstract: This document defines a RESTful interface that allows a RESTful client to d= irectly affect the Automatic Call Handling (ACH) behavior at a domain autho= ritative for a specific SIP address. The IETF Secretariat. --_000_6369CB70BFD88942B9705AC1E639A33821FDC0C703DCUS1MBEX4glo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
We have submitted the following ID and would like to add it as an agen= da item for dispatch.
 
 
This work started in the BLISS WG, but the original draft has expired = and the current plan for BLISS is to finish the current work and close.
 
 
Regards,
Rifaat
 
--------------------
 
A new version of I-D, draft-yusef-dispatch-ach-rest-api-00.txt has bee= n successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repos= itory.
 
Filename:        draft-yusef-dispat= ch-ach-rest-api
Revision:        00
Title:           ACH= RESTful Interface
Creation_date:   2010-05-10
WG ID:           Ind= ependent Submission
Number_of_pages: 18
 
Abstract:
This document defines a RESTful interface that allows a RESTful client= to directly affect the Automatic Call Handling (ACH) behavior at a domain = authoritative for a specific SIP address.
 
 
 
The IETF Secretariat.
 
 
 
 --_000_6369CB70BFD88942B9705AC1E639A33821FDC0C703DCUS1MBEX4glo_-- From laura.liess.dt@googlemail.com Mon May 10 13:55:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1315528C1E3 for ; Mon, 10 May 2010 13:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.138 X-Spam-Level: X-Spam-Status: No, score=0.138 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiykmOWPKrqw for ; Mon, 10 May 2010 13:55:19 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 60B103A6D1B for ; Mon, 10 May 2010 13:51:42 -0700 (PDT) Received: by wwi18 with SMTP id 18so1001101wwi.31 for ; Mon, 10 May 2010 13:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eVqAz1muh8eTbndAupYZ91UV6C46VHzyDD0D91A5X/o=; b=GB1uIrY2TVgqhikagq9fHQc1HtzxFuQACAFIYazvswk05dD1Cx37NoaXvsBjfTNQve Jhj/Pgkp6KO+qFgG+jSvTLLbfjAz4npEryMgGiMrUWV8+WmIpPUCxg71k9mSZ7ksySeV EpP6ofyjP8olipeEdjU6e7kXpDSTmhGfUsZGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=S9DujIdFHSICQ4hadbRbLNGu+bwQLun2vbYLIbehkFD00M8xntzFxdi3rJl2c8TDQN rHiW3YIwBWvQ6Fz7snwosuIpf/CdI37uL2aApDqdVxJsBf1zYCC6M+pxGET0fSw3c+Z2 Cfv4hXmmWO/g15kX7DD44k/jfrn6+/5+89asg= MIME-Version: 1.0 Received: by 10.216.185.148 with SMTP id u20mr2847127wem.29.1273524687959; Mon, 10 May 2010 13:51:27 -0700 (PDT) Received: by 10.216.173.212 with HTTP; Mon, 10 May 2010 13:51:27 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7995@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE5418F.1010005@ericsson.com> <430FC6BDED356B4C8498F634416644A91A8A7D7995@mail> Date: Mon, 10 May 2010 22:51:27 +0200 Message-ID: From: Laura Liess To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] Country-Locale-specific ringtones (was: Status codes vs Alert-Info URNs) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 20:55:20 -0000 Hadriel, please see inline. 2010/5/10 Hadriel Kaplan : > > Out of curiosity - how do you see this country locale thing working? > > The charter says "For example, a user from a given country may not be fam= iliar with the tone used to indicate call waiting in another country." This sentence does not refer to the country locale, only to call waiting where user A and user B are in different environements. If A calls B and UA B initiates call waiting, UA B wants A to get a call waiting specific rendering instead of the normal ringing tone. If UA B sends to UA A a URL for a specific tone known to UAB as "call waiting tone", e.g. AT&T call waiting tone, A, being a DT customer may not understand it, because DT uses another tone for call waiting. If it is a URN instead of a URL, this URN can be resolved by the UA A in the DT call waiting tone. > > So let's say I'm in the US and I call a number in France. =A0Do I get bac= k "urn:alert:locale:country.fr"? =A0How is that useful to me? =A0Or do prox= ies in the path convert it to "urn:alert:locale:country.us"? The requirement for Alert-Info URNs for country ringing tones came from Dean. My understanding was that it was needed in some other SDO (3GPP2?). We had a lot of discussion on this issue during one of the past IETF-meetings. It seams that in many cases in PSTN when A calls B, A gets the B's country ringing tone. They want to have the same with SIP using Alert-Info URN. Paul already described the handling. Laura > > -hadriel > >> -----Original Message----- >> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >> Sent: Sunday, May 09, 2010 12:44 PM >> To: Gonzalo Camarillo >> - We already have use cases which seems to me to be problematic if you >> want to cover them with codes. =A0E.g. country ringback tones. With the >> Alert-info URN we have urn:alert:locale:country.> code>. =A0How could you represent this as response/status codes? > From gao.yang2@zte.com.cn Mon May 10 18:20:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60DB63A6A7A for ; Mon, 10 May 2010 18:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.794 X-Spam-Level: X-Spam-Status: No, score=-95.794 tagged_above=-999 required=5 tests=[AWL=-1.359, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzwc+KThMyFV for ; Mon, 10 May 2010 18:20:00 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id DDE0628C101 for ; Mon, 10 May 2010 18:19:52 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 36887992332426; Tue, 11 May 2010 09:14:12 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 30460.2776214488; Tue, 11 May 2010 09:15:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4B1JEob089865; Tue, 11 May 2010 09:19:16 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7941@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 11 May 2010 09:16:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-11 09:19:12, Serialize complete at 2010-05-11 09:19:12 Content-Type: multipart/alternative; boundary="=_alternative 000738E448257720_=" X-MAIL: mse2.zte.com.cn o4B1JEob089865 Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 01:20:07 -0000 This is a multipart message in MIME format. --=_alternative 000738E448257720_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCk15IG1lYW5zIGlzLCBpbiB0aGUgYW55IHBvaW50IG9mIHRoZSB0cmF2ZXJzZSBvZiB0 aGUgc2lwIGRpYWxvZywgd2UgY2FuIA0KaWRlbnRpZnkgdGhlIGNvcnJlbGF0aW9uLiBBbmQgYXQg ZGlmZmVyZW50IHBvaW50cyBvbiB0aGUgdHdvIHNpZGVzIG9mIA0KQjJCVUEgZXF1aXBtZW50KHN1 Y2ggYXMgQVMpLCB3ZSBjYW4gZmlndXJlIG91dCB0aGUgY29ycmVsYXRpb24gYnkgdGhlIA0KbWFw cGluZy9jb3JyZWxhdGlvbiBieSB0aGUgQjJCVUEgZXF1aXBtZW50Lg0KDQpDb25zaWRlcmluZyB0 aGUgbmV3IGhlYWRlciwgaWYgdGhlIEIyQlVBIGVxdWlwbWVudCBqdXN0IGV4cHVyZ2F0ZSB0aGUg DQpoZWFkZXIgZnJvbSBvbmUgc2lkZSdzIGRpYWxvZyB0byBhbm90aGVyLCB3b3VsZCBpdCBiZSBh IHByb2JsZW0gZm9yIHRoZSANCmNvcnJlbGF0aW9uPw0KDQpNeSBxdWVzdGlvbnMgbWF5IGJlIHRv byBlYXJseS4gTWF5YmUgeW91IGNhbiBhbnN3ZXIgaXQgYXQgdGhlIGRyYWZ0IHN0YWdlLg0KDQpU aGFua3MsDQoNCkdhbw0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFpp cCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4Nzcy MTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCg0KDQoNCkhhZHJpZWwgS2FwbGFuIDxIS2FwbGFuQGFjbWVwYWNrZXQu Y29tPiANCjIwMTAtMDUtMTEgMDA6MzMNCg0KytW8/sjLDQoiZ2FvLnlhbmcyQHp0ZS5jb20uY24i IDxnYW8ueWFuZzJAenRlLmNvbS5jbj4NCrOty80NCkRJU1BBVENIIDxkaXNwYXRjaEBpZXRmLm9y Zz4NCtb3zOINClJFOiBbZGlzcGF0Y2hdIFNlc3Npb24tSUQgY2hhcnRlciBwcm9wb3NhbA0KDQoN Cg0KDQoNCg0KVGhlIHB1cnBvc2UgaXMgZm9yIHRyb3VibGVzaG9vdGluZywgYWNyb3NzIG11bHRp cGxlIHN5c3RlbXMuICBJIGhhZCB0aGF0IA0KaW4gdGhlIHRpdGxlIG9mIHRoZSBjaGFydGVyLCBi dXQgeW91oa9yZSByaWdodCBJIGZvcmdvdCB0byBleHBsaWNpdGx5IGNhbGwgDQp0aGF0IG91dCBp biB0aGUgY2hhcnRlci4NCkhvdyBhYm91dCB0aGlzIG5ldyBmaXJzdCBzZW50ZW5jZToNClRoZSBT SVBTQ09UQ0ggd29ya2luZyBncm91cCBpcyBjaGFydGVyZWQgdG8gZGVmaW5lIGEgbWVjaGFuaXNt IHRoYXQgYWxsb3dzIA0Kb3BlcmF0b3JzIGFuZCBtb25pdG9yaW5nIGVxdWlwbWVudCB0byBjb3Jy ZWxhdGUgU0lQIG1lc3NhZ2VzIGFuZCBkaWFsb2dzIA0Kb2YgdGhlIHNhbWUgaGlnaGVyLWxldmVs IGVuZC10by1lbmQgInNlc3Npb24iIG9yICJtZXNzYWdlLWZsb3ciIGFjcm9zcyANCm11bHRpcGxl IFNJUCBkZXZpY2VzLCBmb3IgdGhlIHB1cnBvc2Ugb2YgdHJvdWJsZXNob290aW5nLg0KIA0KLWhh ZHJpZWwNCiANCg0KRnJvbTogZ2FvLnlhbmcyQHp0ZS5jb20uY24gW21haWx0bzpnYW8ueWFuZzJA enRlLmNvbS5jbl0gDQpTZW50OiBNb25kYXksIE1heSAxMCwgMjAxMCA5OjEyIEFNDQpUbzogSGFk cmllbCBLYXBsYW4NCkNjOiBESVNQQVRDSA0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gU2Vzc2lv bi1JRCBjaGFydGVyIHByb3Bvc2FsDQogDQoNCkhpLCANCg0KUGxlYXNlIGxldCBtZSBtYWtlIG15 IHF1ZXN0aW9uIGNsZWFybHkuIENvbnNpZGVyaW5nIA0KYmlsbGluZy9jaGFyZ2luZy9wb2xpY3kg YW5kIExJKGxhd2Z1bCBpbnRlcmNlcHRpb24pLCB0aGVyZSdzIHVzZSBjYXNlcyBvZiANCmNvcnJl bGF0aW5nICJzZXNzaW9uIiBhbmQgIm1lc3NhZ2UtZmxvdyIuIEluIGZhY3QsIHdlIGhhdmUgZG9u ZSANCmJpbGxpbmcvY2hhcmdpbmcvcG9saWN5IGFuZCBMSSB3aXRob3V0IHN1Y2ggbmV3IGhlYWRl ci4gU28sIEkgc2FpZCB0aGF0IEkgDQpkaWQgbm90IGZpbmQgcmVxdWlyZW1lbnQgb2YgZGVmaW5p bmcgbmV3IGhlYWRlciB0byBjb3JyZWxhdGUgInNlc3Npb24iIGFuZCANCiJtZXNzYWdlLWZsb3ci LiANCg0KTWF5YmUgdGhlcmUncyB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnQgZm9yIHRoZSBuZXcg aGVhZGVyLiBTbywgSSdkIGxpa2UgdG8gDQpzZWUgaXQncyBkZXRhaWwuIA0KDQpUaGFua3MsIA0K DQpHYW8gICANCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClppcCAgICA6 IDIxMDAxMg0KVGVsICAgIDogODcyMTENClRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQplX21h aWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0gDQotLS0tLSDXqreiyMsgR2FvWWFuZzE0MDE5Ny91c2VyL3p0ZV9sdGQgyrG85CAyMDEw LTA1LTEwIDIxOjAyIC0tLS0tIA0KDQpHYW9ZYW5nMTQwMTk3L3VzZXIvenRlX2x0ZCANCjIwMTAt MDUtMTAgMjA6NTYgDQoNCg0KytW8/sjLDQpIYWRyaWVsIEthcGxhbiA8SEthcGxhbkBhY21lcGFj a2V0LmNvbT4gDQqzrcvNDQpESVNQQVRDSCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+LCBkaXNwYXRjaC1i b3VuY2VzQGlldGYub3JnIA0K1vfM4g0KUmU6IFtkaXNwYXRjaF0gU2Vzc2lvbi1JRCBjaGFydGVy IHByb3Bvc2FswbS90w0KIA0KDQoNCiANCiANCg0KDQoNCg0KSGksIA0KDQpJJ2QgbGlrZSB0byBz ZWUgdGhlIHJlcXVpcmVtZW50IG9mIHRoZSBoZWFkZXIgYW5kIHR5cGljYWwgdXNlIGNhc2UgZm9y IGl0IA0KaW4gdGhlIGNoYXJ0ZXIuIA0KDQpUaGFua3MsIA0KDQpHYW8gDQoNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQpaaXAgICAgOiAyMTAwMTINClRlbCAgICA6IDg3MjEx DQpUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20u Y24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IA0KDQoNCkhhZHJpZWwgS2Fw bGFuIDxIS2FwbGFuQGFjbWVwYWNrZXQuY29tPiANCreivP7IyzogIGRpc3BhdGNoLWJvdW5jZXNA aWV0Zi5vcmcgDQoyMDEwLTA1LTA5IDA0OjM1IA0KDQoNCsrVvP7Iyw0KRElTUEFUQ0ggPGRpc3Bh dGNoQGlldGYub3JnPiANCrOty80NCiANCtb3zOINCltkaXNwYXRjaF0gU2Vzc2lvbi1JRCBjaGFy dGVyIHByb3Bvc2FsDQogDQoNCg0KIA0KIA0KDQoNCg0KDQpIb3dkeSwNCkkgaGF2ZSBhc2tlZCB0 aGUgRElTUEFUQ0ggY2hhaXJzIHdoYXQgdG8gZG8gd2l0aCBTZXNzaW9uLUlELCBnaXZlbiB0aGUg DQpmZWVkYmFjayBJIHJlY2VpdmVkIHRvIG1ha2UgaXQgYSBzdGFuZGFyZHMtdHJhY2sgdnMuIGlu ZGl2aWR1YWwgDQppbmZvcm1hdGlvbmFsIHN1Ym1pc3Npb24uICBUaGVyZSBpcyBubyBvYnZpb3Vz IGN1cnJlbnQgV0cgZm9yIHRoaXMgd29yaywgDQpzbyB0aGV5IGFza2VkIG1lIHRvIHBvc3QgYSBz dHJhd21hbiBjaGFydGVyIHByb3Bvc2FsLCB3aGljaCBJIHByb3Bvc2UgYXMgDQpmb2xsb3dzOg0K DQoNClNJUCBTaWduYWxpbmctQ09tbXVuaWNhdGlvbiBUcm91Ymxlc2hvb3Rpbmcgd2l0aCBDb3Jy ZWxhdGlvbiBIZWFkZXIgDQooU0lQU0NPVENIKSBDaGFydGVyOg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KVGhlIFNJUFNDT1RDSCB3b3JraW5nIGdyb3VwIGlzIGNoYXJ0ZXJl ZCB0byBkZWZpbmUgYSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgDQpvcGVyYXRvcnMgYW5kIG1vbml0 b3JpbmcgZXF1aXBtZW50IHRvIGNvcnJlbGF0ZSBTSVAgbWVzc2FnZXMgYW5kIGRpYWxvZ3MgDQpv ZiB0aGUgc2FtZSBoaWdoZXItbGV2ZWwgZW5kLXRvLWVuZCAic2Vzc2lvbiIgb3IgIm1lc3NhZ2Ut ZmxvdyIuICBJbiANCnBhcnRpY3VsYXIsIHRoZSBtZWNoYW5pc20gbXVzdCBiZSBhYmxlIHRvIGFs bG93IHN1Y2ggY29ycmVsYXRpb24gYWNyb3NzIA0KU0lQIEIyQlVBcyBvZiBhcyBtYW55IGZ1bmN0 aW9uYWwgdHlwZXMgYXMgcG9zc2libGUsIHN1Y2ggYXMgQXBwbGljYXRpb24gDQpTZXJ2ZXJzLCBT b2Z0c3dpdGNoZXMsIFBCWHMsIFNCQ3MsIGV0Yy4NCg0KQWx0aG91Z2ggb3RoZXIgc29sdXRpb25z IG1heSBiZSBwb3NzaWJsZSwgdGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMgb24gDQpkZWZp bmluZyBhIG5ldyBTSVAgSGVhZGVyIGZpZWxkIGZvciBzdWNoIGEgcHVycG9zZSwgc2ltaWxhciB0 byB0aGUgQ2FsbC1JRCANCmhlYWRlciBmaWVsZCwgaW4gb3JkZXIgdG8gcHJvdmlkZSBhIHNpbXBs ZSwgZWFzaWx5IGRlcGxveWFibGUgbWVjaGFuaXNtIA0Kd2hpY2ggY2FuIHdvcmsgYWNyb3NzIFNJ UCBkb21haW5zLiBUaGUgU0lQIENhbGwtSUQgaGVhZGVyIGZpZWxkIHZhbHVlIA0KaXRzZWxmIGlz IG5vdCB1c2FibGUgZm9yIHN1Y2ggY29ycmVsYXRpb24sIGJlY2F1c2UgbWFueSBCMkJVQXMgbXVz dCBjcmVhdGUgDQphIG5ldyBDYWxsLUlEIHZhbHVlIG9uIHRoZWlyIFVBQyAic2lkZSIgaW4gb3Jk ZXIgdG8gZnVuY3Rpb24gcHJvcGVybHksIGFuZCANCnRvIGNvbXBseSB3aXRoIHRoZSBydWxlcyBv ZiBSRkMgMzI2MS4gDQoNCkl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGNlcnRhaW4gU0lQIEIyQlVB cyBwZXJmb3JtIGEgInRvcG9sb2d5LWhpZGluZyIgDQpmdW5jdGlvbiwgYXMgZGVzY3JpYmVkIGlu IFJGQyA1ODUzLiAgVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCB0YWtlIHN1Y2ggDQpmdW5jdGlvbnMg aW50byBhY2NvdW50IGZvciB0aGUgY29ycmVsYXRpb24gbWVjaGFuaXNtLCBhcyB3ZWxsIGFzIHBy b3ZpZGUgDQpndWlkYW5jZSBmb3IgaW1wbGVtZW50ZXJzIG9mIHRoZSBtZWNoYW5pc20gdG8gYXZv aWQgdHJpZ2dlcmluZyBzdWNoIGEgDQpmdW5jdGlvbiBmb3IgdGhlIG1lY2hhbmlzbSdzIGhlYWRl ciBmaWVsZCB2YWx1ZS4NCg0KTGFzdGx5LCBhbHRob3VnaCBpbiBjZXJ0YWluIGVudmlyb25tZW50 cyBzdWNoIGEgbWVjaGFuaXNtIG1heSBiZSB1c2FibGUgDQpmb3IgZGlhbG9nIGNvcnJlbGF0aW9u IGluIFNJUCBzdGF0ZSBtYWNoaW5lcywgaXQgaXMgbm90IHRoZSBnb2FsIG9mIHRoaXMgDQp3b3Jr aW5nIGdyb3VwIHRvIGFkZHJlc3MgdGhhdCB1c2FnZS4NCg0KR29hbHMgYW5kIE1pbGVzdG9uZXMN Cj09PT09PT09PT09PT09PT09PT09DQpEZWMgMjAxMCAtIE5ldyBoZWFkZXIgc3BlY2lmaWNhdGlv biB0byBJRVNHIChQUykNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCg0KDQogDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgaXMgDQpzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlv bi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgDQpjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCANCmFyZSBu b3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRp b24gdG8gDQpvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0 aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRo ZSBvcmlnaW5hdG9yIG9mIA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gDQpzeXN0ZW0uDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNv bmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50 YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50 cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZp bGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBw bGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhw cmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVy Lg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkg WlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 000738E448257720_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TXkgbWVhbnMgaXMsIGluIHRoZSBhbnkg cG9pbnQgb2YgdGhlDQp0cmF2ZXJzZSBvZiB0aGUgc2lwIGRpYWxvZywgd2UgY2FuIGlkZW50aWZ5 IHRoZSBjb3JyZWxhdGlvbi4gQW5kIGF0IGRpZmZlcmVudA0KcG9pbnRzIG9uIHRoZSB0d28gc2lk ZXMgb2YgQjJCVUEgZXF1aXBtZW50KHN1Y2ggYXMgQVMpLCB3ZSBjYW4gZmlndXJlIG91dA0KdGhl IGNvcnJlbGF0aW9uIGJ5IHRoZSBtYXBwaW5nL2NvcnJlbGF0aW9uIGJ5IHRoZSBCMkJVQSBlcXVp cG1lbnQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5D b25zaWRlcmluZyB0aGUgbmV3IGhlYWRlciwgaWYgdGhlIEIyQlVBDQplcXVpcG1lbnQganVzdCBl eHB1cmdhdGUgdGhlIGhlYWRlciBmcm9tIG9uZSBzaWRlJ3MgZGlhbG9nIHRvIGFub3RoZXIsDQp3 b3VsZCBpdCBiZSBhIHByb2JsZW0gZm9yIHRoZSBjb3JyZWxhdGlvbj88L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk15IHF1ZXN0aW9ucyBtYXkgYmUgdG9v IGVhcmx5LiBNYXliZQ0KeW91IGNhbiBhbnN3ZXIgaXQgYXQgdGhlIGRyYWZ0IHN0YWdlLjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0K IFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUy ODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SGFkcmllbCBLYXBsYW4gJmx0O0hLYXBsYW5AYWNtZXBh Y2tldC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjIwMTAtMDUtMTEgMDA6MzM8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Z2FvLnlhbmcyQHp0ZS5jb20uY24mcXVvdDsgJmx0 O2dhby55YW5nMkB6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+RElTUEFUQ0ggJmx0 O2Rpc3BhdGNoQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFtkaXNwYXRjaF0g U2Vzc2lvbi1JRCBjaGFydGVyIHByb3Bvc2FsPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPlRoZSBw dXJwb3NlIGlzIGZvciB0cm91Ymxlc2hvb3RpbmcsDQphY3Jvc3MgbXVsdGlwbGUgc3lzdGVtcy4g Jm5ic3A7SSBoYWQgdGhhdCBpbiB0aGUgdGl0bGUgb2YgdGhlIGNoYXJ0ZXIsDQpidXQgeW91oa9y ZSByaWdodCBJIGZvcmdvdCB0byBleHBsaWNpdGx5IGNhbGwgdGhhdCBvdXQgaW4gdGhlIGNoYXJ0 ZXIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj5I b3cgYWJvdXQgdGhpcyBuZXcgZmlyc3Qgc2VudGVuY2U6PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhlIFNJUFNDT1RDSCB3b3JraW5nIGdyb3VwIGlzIGNoYXJ0 ZXJlZA0KdG8gZGVmaW5lIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIG9wZXJhdG9ycyBhbmQgbW9u aXRvcmluZyBlcXVpcG1lbnQgdG8NCmNvcnJlbGF0ZSBTSVAgbWVzc2FnZXMgYW5kIGRpYWxvZ3Mg b2YgdGhlIHNhbWUgaGlnaGVyLWxldmVsIGVuZC10by1lbmQNCiZxdW90O3Nlc3Npb24mcXVvdDsg b3IgJnF1b3Q7bWVzc2FnZS1mbG93JnF1b3Q7IGFjcm9zcyBtdWx0aXBsZSBTSVAgZGV2aWNlcywN CmZvciB0aGUgcHVycG9zZSBvZiB0cm91Ymxlc2hvb3RpbmcuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPi1oYWRyaWVsPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8ZGl2 IGFsaWduPWNlbnRlcj4NCjxicj4NCjxocj48L2Rpdj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i VGFob21hIj48Yj5Gcm9tOjwvYj4gZ2FvLnlhbmcyQHp0ZS5jb20uY24gW21haWx0bzpnYW8ueWFu ZzJAenRlLmNvbS5jbl0NCjxiPjxicj4NClNlbnQ6PC9iPiBNb25kYXksIE1heSAxMCwgMjAxMCA5 OjEyIEFNPGI+PGJyPg0KVG86PC9iPiBIYWRyaWVsIEthcGxhbjxiPjxicj4NCkNjOjwvYj4gRElT UEFUQ0g8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtkaXNwYXRjaF0gU2Vzc2lvbi1JRCBjaGFy dGVyIHByb3Bvc2FsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhp LDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KUGxlYXNlIGxldCBtZSBtYWtlIG15IHF1 ZXN0aW9uIGNsZWFybHkuIENvbnNpZGVyaW5nIGJpbGxpbmcvY2hhcmdpbmcvcG9saWN5DQphbmQg TEkobGF3ZnVsIGludGVyY2VwdGlvbiksIHRoZXJlJ3MgdXNlIGNhc2VzIG9mIGNvcnJlbGF0aW5n ICZxdW90O3Nlc3Npb24mcXVvdDsNCmFuZCAmcXVvdDttZXNzYWdlLWZsb3cmcXVvdDsuIEluIGZh Y3QsIHdlIGhhdmUgZG9uZSBiaWxsaW5nL2NoYXJnaW5nL3BvbGljeQ0KYW5kIExJIHdpdGhvdXQg c3VjaCBuZXcgaGVhZGVyLiBTbywgSSBzYWlkIHRoYXQgSSBkaWQgbm90IGZpbmQgcmVxdWlyZW1l bnQNCm9mIGRlZmluaW5nIG5ldyBoZWFkZXIgdG8gY29ycmVsYXRlICZxdW90O3Nlc3Npb24mcXVv dDsgYW5kICZxdW90O21lc3NhZ2UtZmxvdyZxdW90Oy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQpNYXliZSB0aGVyZSdzIHVzZSBjYXNlIGFuZCByZXF1aXJlbWVudCBmb3IgdGhlIG5l dyBoZWFkZXIuIFNvLCBJJ2QgbGlrZQ0KdG8gc2VlIGl0J3MgZGV0YWlsLjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KVGhhbmtzLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K R2FvICZuYnNwOyA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT08YnI+DQpaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0K VGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3 NzIxMTxicj4NCmVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPg0KPC9mb250Pjxmb250IHNpemU9MSBjb2xvcj0jODAwMDgwIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCi0tLS0tINeqt6LIyyBHYW9ZYW5nMTQwMTk3L3VzZXIvenRlX2x0ZCDKsbzkIDIwMTAt MDUtMTAgMjE6MDIgLS0tLS08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0K PC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTMzJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+R2FvWWFuZzE0MDE5Ny91 c2VyL3p0ZV9sdGQ8L2I+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA1LTEwIDIwOjU2 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0 aD02NiU+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTglPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTkxJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+SGFkcmllbCBLYXBsYW4gJmx0O0hLYXBsYW5AYWNtZXBhY2tldC5jb20mZ3Q7PC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ RElTUEFUQ0ggJmx0O2Rpc3BhdGNoQGlldGYub3JnJmd0OywNCmRpc3BhdGNoLWJvdW5jZXNAaWV0 Zi5vcmc8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlJlOiBbZGlzcGF0Y2hdIFNlc3Npb24tSUQgY2hhcnRlciBwcm9wb3NhbDwvZm9udD48 YSBocmVmPU5vdGVzOi8vbmptYWlsMDEvNDgyNTcxNjkwMDJERjhFRS9EQUJBOTc1QjlGQjExM0VC ODUyNTY0QjUwMDEyODNFQS83OUE3MDYxNUEyRDZBRTE5NDgyNTc3MUQwMDcxMUQ3OD48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT7BtL3TPC91PjwvZm9udD48L2E+ PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250 Pg0KPHA+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTUwJT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPHRk IHdpZHRoPTUwJT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjwv dGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpI aSw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkknZCBsaWtlIHRvIHNlZSB0aGUgcmVx dWlyZW1lbnQgb2YgdGhlIGhlYWRlciBhbmQgdHlwaWNhbCB1c2UgY2FzZSBmb3INCml0IGluIHRo ZSBjaGFydGVyLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KVGhhbmtzLDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KR2FvPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NClppcCAmbmJzcDsgJm5i c3A7OiAyMTAwMTI8YnI+DQpUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQpUZWwyICZuYnNw OyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248 YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+DQo8cD4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTElPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj5IYWRyaWVsIEthcGxhbiAmbHQ7SEthcGxhbkBhY21lcGFja2V0LmNvbSZn dDs8L2I+DQo8YnI+DQq3orz+yMs6ICZuYnNwO2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDUtMDkgMDQ6MzU8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTQ4JT4NCjxicj4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MTIlPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2 Pg0KPHRkIHdpZHRoPTg3JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+RElTUEFUQ0gg Jmx0O2Rpc3BhdGNoQGlldGYub3JnJmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ 1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W2Rp c3BhdGNoXSBTZXNzaW9uLUlEIGNoYXJ0ZXIgcHJvcG9zYWw8L2ZvbnQ+PC90YWJsZT4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPHA+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPHRkIHdpZHRoPTUwJT48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250PjwvdGFibGU+DQo8YnI+PC90 YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpIb3dkeSw8YnI+DQpJIGhh dmUgYXNrZWQgdGhlIERJU1BBVENIIGNoYWlycyB3aGF0IHRvIGRvIHdpdGggU2Vzc2lvbi1JRCwg Z2l2ZW4gdGhlDQpmZWVkYmFjayBJIHJlY2VpdmVkIHRvIG1ha2UgaXQgYSBzdGFuZGFyZHMtdHJh Y2sgdnMuIGluZGl2aWR1YWwgaW5mb3JtYXRpb25hbA0Kc3VibWlzc2lvbi4gPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5UaGVyZQ0KaXMgbm8gb2J2aW91cyBjdXJyZW50IFdHIGZvciB0aGlzIHdv cmssIHNvIHRoZXkgYXNrZWQgbWUgdG8gcG9zdCBhIHN0cmF3bWFuDQpjaGFydGVyIHByb3Bvc2Fs LCB3aGljaCBJIHByb3Bvc2UgYXMgZm9sbG93czo8YnI+DQo8YnI+DQo8YnI+DQpTSVAgU2lnbmFs aW5nLUNPbW11bmljYXRpb24gVHJvdWJsZXNob290aW5nIHdpdGggQ29ycmVsYXRpb24gSGVhZGVy IChTSVBTQ09UQ0gpDQpDaGFydGVyOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQpUaGUgU0lQU0NPVENIIHdvcmtpbmcgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRl ZmluZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cw0Kb3BlcmF0b3JzIGFuZCBtb25pdG9yaW5nIGVx dWlwbWVudCB0byBjb3JyZWxhdGUgU0lQIG1lc3NhZ2VzIGFuZCBkaWFsb2dzDQpvZiB0aGUgc2Ft ZSBoaWdoZXItbGV2ZWwgZW5kLXRvLWVuZCAmcXVvdDtzZXNzaW9uJnF1b3Q7IG9yICZxdW90O21l c3NhZ2UtZmxvdyZxdW90Oy4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SW4NCnBhcnRpY3Vs YXIsIHRoZSBtZWNoYW5pc20gbXVzdCBiZSBhYmxlIHRvIGFsbG93IHN1Y2ggY29ycmVsYXRpb24g YWNyb3NzDQpTSVAgQjJCVUFzIG9mIGFzIG1hbnkgZnVuY3Rpb25hbCB0eXBlcyBhcyBwb3NzaWJs ZSwgc3VjaCBhcyBBcHBsaWNhdGlvbg0KU2VydmVycywgU29mdHN3aXRjaGVzLCBQQlhzLCBTQkNz LCBldGMuPGJyPg0KPGJyPg0KQWx0aG91Z2ggb3RoZXIgc29sdXRpb25zIG1heSBiZSBwb3NzaWJs ZSwgdGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMNCm9uIGRlZmluaW5nIGEgbmV3IFNJUCBI ZWFkZXIgZmllbGQgZm9yIHN1Y2ggYSBwdXJwb3NlLCBzaW1pbGFyIHRvIHRoZSBDYWxsLUlEDQpo ZWFkZXIgZmllbGQsIGluIG9yZGVyIHRvIHByb3ZpZGUgYSBzaW1wbGUsIGVhc2lseSBkZXBsb3lh YmxlIG1lY2hhbmlzbQ0Kd2hpY2ggY2FuIHdvcmsgYWNyb3NzIFNJUCBkb21haW5zLiBUaGUgU0lQ IENhbGwtSUQgaGVhZGVyIGZpZWxkIHZhbHVlIGl0c2VsZg0KaXMgbm90IHVzYWJsZSBmb3Igc3Vj aCBjb3JyZWxhdGlvbiwgYmVjYXVzZSBtYW55IEIyQlVBcyBtdXN0IGNyZWF0ZSBhIG5ldw0KQ2Fs bC1JRCB2YWx1ZSBvbiB0aGVpciBVQUMgJnF1b3Q7c2lkZSZxdW90OyBpbiBvcmRlciB0byBmdW5j dGlvbiBwcm9wZXJseSwNCmFuZCB0byBjb21wbHkgd2l0aCB0aGUgcnVsZXMgb2YgUkZDIDMyNjEu IDxicj4NCjxicj4NCkl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGNlcnRhaW4gU0lQIEIyQlVBcyBw ZXJmb3JtIGEgJnF1b3Q7dG9wb2xvZ3ktaGlkaW5nJnF1b3Q7DQpmdW5jdGlvbiwgYXMgZGVzY3Jp YmVkIGluIFJGQyA1ODUzLiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4m bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZQ0Kd29ya2luZyBn cm91cCB3aWxsIHRha2Ugc3VjaCBmdW5jdGlvbnMgaW50byBhY2NvdW50IGZvciB0aGUgY29ycmVs YXRpb24NCm1lY2hhbmlzbSwgYXMgd2VsbCBhcyBwcm92aWRlIGd1aWRhbmNlIGZvciBpbXBsZW1l bnRlcnMgb2YgdGhlIG1lY2hhbmlzbQ0KdG8gYXZvaWQgdHJpZ2dlcmluZyBzdWNoIGEgZnVuY3Rp b24gZm9yIHRoZSBtZWNoYW5pc20ncyBoZWFkZXIgZmllbGQgdmFsdWUuPGJyPg0KPGJyPg0KTGFz dGx5LCBhbHRob3VnaCBpbiBjZXJ0YWluIGVudmlyb25tZW50cyBzdWNoIGEgbWVjaGFuaXNtIG1h eSBiZSB1c2FibGUNCmZvciBkaWFsb2cgY29ycmVsYXRpb24gaW4gU0lQIHN0YXRlIG1hY2hpbmVz LCBpdCBpcyBub3QgdGhlIGdvYWwgb2YgdGhpcw0Kd29ya2luZyBncm91cCB0byBhZGRyZXNzIHRo YXQgdXNhZ2UuPGJyPg0KPGJyPg0KR29hbHMgYW5kIE1pbGVzdG9uZXM8YnI+DQo9PT09PT09PT09 PT09PT09PT09PTxicj4NCkRlYyAyMDEwIC0gTmV3IGhlYWRlciBzcGVjaWZpY2F0aW9uIHRvIElF U0cgKFBTKTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KZGlzcGF0Y2ggbWFpbGluZyBsaXN0PGJyPg0KZGlzcGF0Y2hAaWV0Zi5v cmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPGJy Pg0KPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5aVEU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ SW5mb3JtYXRpb248L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+U2VjdXJpdHk8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+Tm90aWNlOjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5UaGU8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+aW5mb3JtYXRpb248L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Y29udGFpbmVkPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPmluPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPnRoaXM8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+bWFpbDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5pczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i Q291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5zb2xl bHk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+cHJvcGVydHk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+b2Y8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+dGhlPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVy IE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPnNlbmRlcidzPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPm9yZ2FuaXphdGlvbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+VGhp czwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj5tYWlsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3Vy aWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmNvbW11bmlj YXRpb248L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+aXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNv dXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Y29uZmlk ZW50aWFsLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5SZWNpcGllbnRzPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPm5hbWVkPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmFib3ZlPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PmFyZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5vYmxpZ2F0ZWQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ dG88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+bWFpbnRhaW48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+c2Vj cmVjeTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5hbmQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNv dXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+YXJlPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPm5vdDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBO ZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5wZXJtaXR0ZWQ8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+dG88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3 Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ZGlzY2xvc2U8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+dGhlPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmNvbnRlbnRzPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPm9mPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPnRoaXM8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+Y29tbXVuaWNhdGlvbjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXci Pg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj50bzwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj5vdGhlcnMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij5UaGlzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmVtYWlsPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmFu ZDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj5hbnk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJp ZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ZmlsZXM8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+dHJhbnNtaXR0ZWQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNv dXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+d2l0aDwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj5pdDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBO ZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5hcmU8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Y29uZmlkZW50aWFsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVy IE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmFuZDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj5pbnRlbmRlZDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBO ZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5zb2xlbHk8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+Zm9yPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPnRoZTwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj51c2U8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+b2Y8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ dGhlPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmluZGl2aWR1YWw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ b3I8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ZW50aXR5PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJD b3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPnRvPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPndob208L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIg TmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+dGhleTwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj5hcmU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4N CjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+YWRkcmVzc2VkLjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj5JZjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0K PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj55b3U8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+aGF2ZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5yZWNlaXZlZDwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj50aGlzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmVtYWlsPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PmluPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmVycm9yPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJD b3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPnBsZWFz ZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj5ub3RpZnk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNv dXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+dGhlPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPm9yaWdpbmF0b3I8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNv dXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+b2Y8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+dGhlPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5l dyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPm1lc3NhZ2UuPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPkFueTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXci Pg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj52aWV3czwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj5leHByZXNzZWQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3 Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+aW48L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+dGhpczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5tZXNzYWdlPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPmFyZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj50aG9zZTwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij5vZjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj50aGU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNv dXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+aW5kaXZp ZHVhbDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5zZW5kZXIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj5UaGlzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVy IE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPm1lc3NhZ2U8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+aGFzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5l dyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmJlZW48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+c2Nhbm5lZDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXci Pg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5mb3I8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+dmlydXNlczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0K PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5hbmQ8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+U3BhbTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5ieTwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5a VEU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+QW50aS1TcGFtPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPnN5 c3RlbS48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNw O1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29u dGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5i c3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0 aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7 Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7 YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJz cDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Ns b3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5p Y2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJz cDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7 YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkm bmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1 YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDth cmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2 ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5i c3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7 dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5i c3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7 U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 000738E448257720_=-- From gao.yang2@zte.com.cn Mon May 10 20:24:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A8B28C111; Mon, 10 May 2010 20:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.849 X-Spam-Level: X-Spam-Status: No, score=-95.849 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcYFFiFuoCUG; Mon, 10 May 2010 20:24:25 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 4845B28C108; Mon, 10 May 2010 20:24:04 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368872302718646; Tue, 11 May 2010 11:18:26 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 6793.4086600708; Tue, 11 May 2010 11:23:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4B3Mcb7049575; Tue, 11 May 2010 11:23:02 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 11 May 2010 11:20:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-11 11:22:56, Serialize complete at 2010-05-11 11:22:56 Content-Type: multipart/alternative; boundary="=_alternative 00128C9048257720_=" X-MAIL: mse2.zte.com.cn o4B3Mcb7049575 Cc: dispatch-bounces@ietf.org, DISPATCH Subject: Re: [dispatch] Updates Session-ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 03:24:26 -0000 This is a multipart message in MIME format. --=_alternative 00128C9048257720_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QXMgeW91ciBjaGFydGVyIGlzICpob25lc3QqIGVub3VnaCh5b3VyIGVtcGhhc2l6aW5nIG9mICJv dGhlciBzb2x1dGlvbnMgDQptYXkgYmUgcG9zc2libGUiKSwgdGhlbiBJIGFtIE9LIHdpdGggdGhp cyB2ZXJzaW9uLg0KDQpBbmQgSSBndWVzcyB5b3UgY2FuIGRvIHRoZSBhbnRpdGhlc2VzIGxhdGVy IGluIHlvdXIgZHJhZnRzLg0KDQpUaGFua3MsDQoNCkdhbw0KDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVs MiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCkhhZHJpZWwgS2FwbGFu IDxIS2FwbGFuQGFjbWVwYWNrZXQuY29tPiANCreivP7IyzogIGRpc3BhdGNoLWJvdW5jZXNAaWV0 Zi5vcmcNCjIwMTAtMDUtMTEgMDI6MjINCg0KytW8/sjLDQpESVNQQVRDSCA8ZGlzcGF0Y2hAaWV0 Zi5vcmc+DQqzrcvNDQoNCtb3zOINCltkaXNwYXRjaF0gVXBkYXRlcyBTZXNzaW9uLUlEIGNoYXJ0 ZXINCg0KDQoNCg0KDQoNCkhvd2R5LA0KSGVyZSBpcyBhbiB1cGRhdGVkIGNoYXJ0ZXIsIHdoaWNo IEkgdGhpbmsgYWRkcmVzc2VzIEdhbydzIGNvbmNlcm46DQoNCg0KU0lQIFNpZ25hbGluZy1DT21t dW5pY2F0aW9uIFRyb3VibGVzaG9vdGluZyB3aXRoIENvcnJlbGF0aW9uIEhlYWRlciANCihTSVBT Q09UQ0gpIENoYXJ0ZXI6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGUg U0lQU0NPVENIIHdvcmtpbmcgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRlZmluZSBhIG1lY2hhbmlz bSB0aGF0IGFsbG93cyANCm9wZXJhdG9ycyBhbmQgbW9uaXRvcmluZyBlcXVpcG1lbnQgdG8gY29y cmVsYXRlIFNJUCBtZXNzYWdlcyBhbmQgZGlhbG9ncyANCm9mIHRoZSBzYW1lIGhpZ2hlci1sZXZl bCBlbmQtdG8tZW5kICJzZXNzaW9uIiBhY3Jvc3MgbXVsdGlwbGUgU0lQIGRldmljZSANCmhvcHMg Zm9yIHRoZSBzYW1lICJtZXNzYWdlLWZsb3ciLCBmb3IgdGhlIHB1cnBvc2Ugb2YgdHJvdWJsZXNo b290aW5nLiAgSW4gDQpwYXJ0aWN1bGFyLCB0aGUgbWVjaGFuaXNtIG11c3QgYmUgYWJsZSB0byBh bGxvdyBzdWNoIGNvcnJlbGF0aW9uIGFjcm9zcyANClNJUCBCMkJVQXMgb2YgYXMgbWFueSBmdW5j dGlvbmFsIHR5cGVzIGFzIHBvc3NpYmxlLCBzdWNoIGFzIEFwcGxpY2F0aW9uIA0KU2VydmVycywg U29mdHN3aXRjaGVzLCBQQlhzLCBTQkNzLCBldGMuDQoNCkFsdGhvdWdoIG90aGVyIHNvbHV0aW9u cyBtYXkgYmUgcG9zc2libGUsIHRoaXMgd29ya2luZyBncm91cCB3aWxsIGZvY3VzIG9uIA0KZGVm aW5pbmcgYSBuZXcgU0lQIEhlYWRlciBmaWVsZCBmb3Igc3VjaCBhIHB1cnBvc2UsIHNpbWlsYXIg dG8gdGhlIENhbGwtSUQgDQpoZWFkZXIgZmllbGQsIGluIG9yZGVyIHRvIHByb3ZpZGUgYSBzaW1w bGUsIGVhc2lseSBkZXBsb3lhYmxlIG1lY2hhbmlzbSANCndoaWNoIGNhbiB3b3JrIGFjcm9zcyBT SVAgZG9tYWlucy4gVGhlIFNJUCBDYWxsLUlEIGhlYWRlciBmaWVsZCB2YWx1ZSANCml0c2VsZiBp cyBub3QgdXNhYmxlIGZvciBzdWNoIGNvcnJlbGF0aW9uLCBiZWNhdXNlIG1hbnkgQjJCVUFzIG11 c3QgY3JlYXRlIA0KYSBuZXcgQ2FsbC1JRCB2YWx1ZSBvbiB0aGVpciBVQUMgInNpZGUiIGluIG9y ZGVyIHRvIGZ1bmN0aW9uIHByb3Blcmx5LCBhbmQgDQp0byBjb21wbHkgd2l0aCB0aGUgcnVsZXMg b2YgUkZDIDMyNjEuIA0KDQpJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBjZXJ0YWluIFNJUCBCMkJV QXMgcGVyZm9ybSBhICJ0b3BvbG9neS1oaWRpbmciIA0KZnVuY3Rpb24sIGFzIGRlc2NyaWJlZCBp biBSRkMgNTg1My4gIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgdGFrZSBzdWNoIA0KZnVuY3Rpb25z IGludG8gYWNjb3VudCBmb3IgdGhlIGNvcnJlbGF0aW9uIG1lY2hhbmlzbSwgYXMgd2VsbCBhcyBw cm92aWRlIA0KZ3VpZGFuY2UgZm9yIGltcGxlbWVudGVycyBvZiB0aGUgbWVjaGFuaXNtIHRvIGF2 b2lkIHRyaWdnZXJpbmcgc3VjaCBhIA0KZnVuY3Rpb24gZm9yIHRoZSBtZWNoYW5pc20ncyBoZWFk ZXIgZmllbGQgdmFsdWUuDQoNCkxhc3RseSwgYWx0aG91Z2ggaW4gY2VydGFpbiBlbnZpcm9ubWVu dHMgc3VjaCBhIG1lY2hhbmlzbSBtYXkgYmUgdXNhYmxlIA0KZm9yIGRpYWxvZyBjb3JyZWxhdGlv biBpbiBTSVAgc3RhdGUgbWFjaGluZXMsIGl0IGlzIG5vdCB0aGUgZ29hbCBvZiB0aGlzIA0Kd29y a2luZyBncm91cCB0byBhZGRyZXNzIHRoYXQgdXNhZ2UuDQoNCkdvYWxzIGFuZCBNaWxlc3RvbmVz DQo9PT09PT09PT09PT09PT09PT09PQ0KRGVjIDIwMTAgLSBOZXcgaGVhZGVyIHNwZWNpZmljYXRp b24gdG8gSUVTRyAoUFMpDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCg0KDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6 YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50 cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBu b3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRp b24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGgg aXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmln aW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2Fn ZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBi ZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0u DQo= --=_alternative 00128C9048257720_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFzIHlvdXIgY2hhcnRlciBpcyAq aG9uZXN0KiBlbm91Z2goPC9mb250Pjx0dD48Zm9udCBzaXplPTI+eW91cg0KZW1waGFzaXppbmcg b2YgJnF1b3Q7b3RoZXIgc29sdXRpb25zIG1heSBiZSBwb3NzaWJsZTwvZm9udD48L3R0Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDspLA0KdGhlbiBJIGFtIE9LIHdpdGggdGhp cyB2ZXJzaW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+QW5kIEkgZ3Vlc3MgeW91IGNhbiBkbyB0aGUgYW50aXRoZXNlcw0KbGF0ZXIgaW4geW91ciBk cmFmdHMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5U aGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5H YW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAy MTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDoo Kzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+ DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYl Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5IYWRyaWVsIEthcGxhbiAmbHQ7SEth cGxhbkBhY21lcGFja2V0LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZzwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA1LTExIDAyOjIy PC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PkRJU1BBVENIICZsdDtkaXNwYXRjaEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltkaXNwYXRjaF0gVXBkYXRlcyBT ZXNzaW9uLUlEIGNoYXJ0ZXI8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPkhvd2R5LDxicj4NCkhlcmUgaXMgYW4gdXBkYXRlZCBjaGFydGVy LCB3aGljaCBJIHRoaW5rIGFkZHJlc3NlcyBHYW8ncyBjb25jZXJuOjxicj4NCjxicj4NCjxicj4N ClNJUCBTaWduYWxpbmctQ09tbXVuaWNhdGlvbiBUcm91Ymxlc2hvb3Rpbmcgd2l0aCBDb3JyZWxh dGlvbiBIZWFkZXIgKFNJUFNDT1RDSCkNCkNoYXJ0ZXI6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NClRoZSBTSVBTQ09UQ0ggd29ya2luZyBncm91cCBpcyBjaGFy dGVyZWQgdG8gZGVmaW5lIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzDQpvcGVyYXRvcnMgYW5kIG1v bml0b3JpbmcgZXF1aXBtZW50IHRvIGNvcnJlbGF0ZSBTSVAgbWVzc2FnZXMgYW5kIGRpYWxvZ3MN Cm9mIHRoZSBzYW1lIGhpZ2hlci1sZXZlbCBlbmQtdG8tZW5kICZxdW90O3Nlc3Npb24mcXVvdDsg YWNyb3NzIG11bHRpcGxlDQpTSVAgZGV2aWNlIGhvcHMgZm9yIHRoZSBzYW1lICZxdW90O21lc3Nh Z2UtZmxvdyZxdW90OywgZm9yIHRoZSBwdXJwb3NlDQpvZiB0cm91Ymxlc2hvb3RpbmcuICZuYnNw O0luIHBhcnRpY3VsYXIsIHRoZSBtZWNoYW5pc20gbXVzdCBiZSBhYmxlIHRvDQphbGxvdyBzdWNo IGNvcnJlbGF0aW9uIGFjcm9zcyBTSVAgQjJCVUFzIG9mIGFzIG1hbnkgZnVuY3Rpb25hbCB0eXBl cyBhcw0KcG9zc2libGUsIHN1Y2ggYXMgQXBwbGljYXRpb24gU2VydmVycywgU29mdHN3aXRjaGVz LCBQQlhzLCBTQkNzLCBldGMuPGJyPg0KPGJyPg0KQWx0aG91Z2ggb3RoZXIgc29sdXRpb25zIG1h eSBiZSBwb3NzaWJsZSwgdGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMNCm9uIGRlZmluaW5n IGEgbmV3IFNJUCBIZWFkZXIgZmllbGQgZm9yIHN1Y2ggYSBwdXJwb3NlLCBzaW1pbGFyIHRvIHRo ZSBDYWxsLUlEDQpoZWFkZXIgZmllbGQsIGluIG9yZGVyIHRvIHByb3ZpZGUgYSBzaW1wbGUsIGVh c2lseSBkZXBsb3lhYmxlIG1lY2hhbmlzbQ0Kd2hpY2ggY2FuIHdvcmsgYWNyb3NzIFNJUCBkb21h aW5zLiBUaGUgU0lQIENhbGwtSUQgaGVhZGVyIGZpZWxkIHZhbHVlIGl0c2VsZg0KaXMgbm90IHVz YWJsZSBmb3Igc3VjaCBjb3JyZWxhdGlvbiwgYmVjYXVzZSBtYW55IEIyQlVBcyBtdXN0IGNyZWF0 ZSBhIG5ldw0KQ2FsbC1JRCB2YWx1ZSBvbiB0aGVpciBVQUMgJnF1b3Q7c2lkZSZxdW90OyBpbiBv cmRlciB0byBmdW5jdGlvbiBwcm9wZXJseSwNCmFuZCB0byBjb21wbHkgd2l0aCB0aGUgcnVsZXMg b2YgUkZDIDMyNjEuIDxicj4NCjxicj4NCkl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGNlcnRhaW4g U0lQIEIyQlVBcyBwZXJmb3JtIGEgJnF1b3Q7dG9wb2xvZ3ktaGlkaW5nJnF1b3Q7DQpmdW5jdGlv biwgYXMgZGVzY3JpYmVkIGluIFJGQyA1ODUzLiAmbmJzcDtUaGUgd29ya2luZyBncm91cCB3aWxs IHRha2Ugc3VjaA0KZnVuY3Rpb25zIGludG8gYWNjb3VudCBmb3IgdGhlIGNvcnJlbGF0aW9uIG1l Y2hhbmlzbSwgYXMgd2VsbCBhcyBwcm92aWRlDQpndWlkYW5jZSBmb3IgaW1wbGVtZW50ZXJzIG9m IHRoZSBtZWNoYW5pc20gdG8gYXZvaWQgdHJpZ2dlcmluZyBzdWNoIGEgZnVuY3Rpb24NCmZvciB0 aGUgbWVjaGFuaXNtJ3MgaGVhZGVyIGZpZWxkIHZhbHVlLjxicj4NCjxicj4NCkxhc3RseSwgYWx0 aG91Z2ggaW4gY2VydGFpbiBlbnZpcm9ubWVudHMgc3VjaCBhIG1lY2hhbmlzbSBtYXkgYmUgdXNh YmxlDQpmb3IgZGlhbG9nIGNvcnJlbGF0aW9uIGluIFNJUCBzdGF0ZSBtYWNoaW5lcywgaXQgaXMg bm90IHRoZSBnb2FsIG9mIHRoaXMNCndvcmtpbmcgZ3JvdXAgdG8gYWRkcmVzcyB0aGF0IHVzYWdl Ljxicj4NCjxicj4NCkdvYWxzIGFuZCBNaWxlc3RvbmVzPGJyPg0KPT09PT09PT09PT09PT09PT09 PT08YnI+DQpEZWMgMjAxMCAtIE5ldyBoZWFkZXIgc3BlY2lmaWNhdGlvbiB0byBJRVNHIChQUyk8 YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCmRpc3BhdGNoIG1haWxpbmcgbGlzdDxicj4NCmRpc3BhdGNoQGlldGYub3Jn PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaDxicj4N Cjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRp b24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZu YnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3Nv bGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29y Z2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtp cyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92 ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNy ZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJz cDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7 Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7 YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtp dCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7 c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtp bmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5 Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNw O3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3Bs ZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtp biZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNw O2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2Fu ZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4N CjwvcHJlPg== --=_alternative 00128C9048257720_=-- From HKaplan@acmepacket.com Mon May 10 20:59:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA0C28C106 for ; Mon, 10 May 2010 20:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.437 X-Spam-Level: * X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[AWL=-3.368, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFsoaC3buHDn for ; Mon, 10 May 2010 20:59:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D471428C0F5 for ; Mon, 10 May 2010 20:59:09 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 10 May 2010 23:58:58 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 10 May 2010 23:58:55 -0400 From: Hadriel Kaplan To: "gao.yang2@zte.com.cn" Date: Mon, 10 May 2010 23:58:55 -0400 Thread-Topic: [dispatch] Session-ID charter proposal Thread-Index: AcrwqBYQ+Xl00fBtQqi1kCX45m5iLQAEd0Mg Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7AAC@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D7941@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A8A7D7AACmail_" MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 03:59:12 -0000 --_000_430FC6BDED356B4C8498F634416644A91A8A7D7AACmail_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Tm8gQjJCVUEgaGFzIHRvIHN1cHBvcnQgYW55IG5ldyBSRkMuICBBc3N1bWluZyB0aGUgV0cgZGVj aWRlcyBvbiBhIG5ldyBoZWFkZXIgobBGb29iYXKhsSBmb3IgdGhlIG1lY2hhbmlzbSwgYW5kIHB1 Ymxpc2hlZCBhbiBSRkMgWFlaIHNheWluZyBCMkJVQaGvcyBtdXN0IHBhc3MgobBGb29iYXKhsSB0 aHJvdWdoLCB0aGVuIGEgQjJCVUEgZG9lcyBub3QgaGF2ZSB0byBwYXNzIGl0IHRocm91Z2ggqEMg aXQganVzdCB3b3VsZG6hr3QgYmUgaW1wbGVtZW50aW5nIG9yIGJlIGNvbXBsaWFudCB3aXRoIFJG QyBYWVogaWYgaXQgZGlkbqGvdC4gIEJ1dCBpZiB0aGUgQjJCVUEgY2xhaW1lZCBjb21wbGlhbmNl IHdpdGggUkZDIFhZWiwgdGhlbiBpdCB3b3VsZCBoYXZlIHRvIGZvbGxvdyB0aGUgUkZDIGFuZCBw YXNzIKGwRm9vYmFyobEgd2hlbiBpdKGvcyBzZXQgdG8gqEMgaXQgY291bGQgbm90IGV4cHVyZ2F0 ZSB0aGUgaGVhZGVyIGlmIGl0IGNsYWltZWQgdG8gaW1wbGVtZW50IHRoZSBSRkMuICBJZiBvcGVy YXRvcnMgd2FudCB0aGlzIHRoaW5nLCB0aGVuIHRoZXmhr2xsIHRlbGwgdGhlaXIgdmVuZG9ycyB0 byBkbyBSRkMgWFlaLg0KDQpJoa9tIG5vdCBzdXJlIGlmIHRoYXQgd2FzIHlvdXIgcXVlc3Rpb24v Y29tbWVudCB0aG91Z2guICBNYXliZSB5b3UganVzdCBtZWFuIKGwd2UgZG9uoa90IG5lZWQgdGhp c6GxLiAgVGhhdKGvcyBmaW5lLCB0aGVuIHlvdSBkb26hr3QgbmVlZCBpdC4gIE1hbnkgaWYgbm90 IGFsbCBCMkJVQSB2ZW5kb3JzIGhhdmUgbWVhbnMgb2YgY29ycmVsYXRpbmcgbWVzc2FnZXMsIHdo ZXRoZXIgaXQgYmUgaW4gcHJvcHJpZXRhcnkgaGVhZGVycywgobBzcGVjaWFsobEgaW5mbyBpbiBD YWxsLUlEcywgb3IganVzdCBsb2dzIG9yIGV2ZW4gQ0RScy4gIEFuZCBhIGZldyBtb25pdG9yaW5n IHZlbmRvcnMgaGF2ZSBmaWd1cmVkIG91dCBob3cgdG8gY29ycmVsYXRlIHRoZSBtZXNzYWdlcyB3 aGVuIHRoZXkgY3Jvc3MgdGhyb3VnaCBCMkJVQaGvcyB0b28sIG9yIHdpbGwgY29sbGVjdCB0aGUg bG9ncyBzcGVjaWZpY2FsbHkgdG8gZG8gc28uICBUaGF0oa9zIGFsbCBmaW5lLCBhbmQgbm9ib2R5 oa9zIHN0b3BwaW5nIHRoZW0uICBXZaGvcmUganVzdCBwcm92aWRpbmcgYSBtZWNoYW5pc20gdG8g bGV0IHBlb3BsZSBkbyBpdCBtb3JlIHNpbXBseSwgaW4gYSBjb25zaXN0ZW50IGZhc2hpb24sIHdp dGhvdXQgaGF2aW5nIHRvIGdvIHRocm91Z2ggYWxsIHRoYXQuDQoNCkkga25vdyBpdKGvcyBoYXJk IHRvIGp1c3RpZnkgaW1wbGVtZW50aW5nIHRoaXMgdGhpbmcgd2hlbiB5b3UgYWxyZWFkeSBoYXZl IGEgd2F5IHRvIGNvcnJlbGF0ZSBpdCB5b3Vyc2VsZiwgb3IgaWYgeW91ciBmYXZvcml0ZSBtb25p dG9yaW5nIHZlbmRvcnMgaGF2ZSBhbHJlYWR5IGZpZ3VyZWQgb3V0IGhvdyB0by4gIEmhr3ZlIGhh ZCB0aGF0IHNhbWUgcHJvYmxlbSBhcmd1aW5nIGZvciBpdCBpbiBteSBvd24gY29tcGFueSwgYmVj YXVzZSB3ZSB0b28gaGF2ZSBkaWZmZXJlbnQgd2F5cyBvZiBkb2luZyBpdCBhbHJlYWR5LiAgQnV0 IGlmIHdlIHdhbnQgU0lQIHRvIGJlIGRlcGxveWVkIGZhc3RlciBhbmQgY29zdCBsZXNzIGluIG9w ZXgsIHdlIGhhdmUgdG8gaGVscCBvcGVyYXRvcnMgbWFuYWdlIGFuZCB0cm91Ymxlc2hvb3QgYXMg ZWFzaWx5IGFzIHBvc3NpYmxlLiAgVGhpcyBXRyBpcyBmb3IganVzdCBvbmUgc21hbGwgcGllY2Us IGJ1dCBpdKGvcyBhbHNvIG5vdCB0aGF0IG11Y2ggd29yayBmb3IgQjJCVUEgdmVuZG9ycyBJIHdv dWxkIHRoaW5rL2hvcGUuDQoNCi1oYWRyaWVsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpGcm9tOiBnYW8ueWFuZzJAenRlLmNvbS5jbiBbbWFpbHRvOmdhby55YW5nMkB6dGUu Y29tLmNuXQ0KU2VudDogTW9uZGF5LCBNYXkgMTAsIDIwMTAgOToxNyBQTQ0KVG86IEhhZHJpZWwg S2FwbGFuDQpDYzogRElTUEFUQ0gNClN1YmplY3Q6IFJFOiBbZGlzcGF0Y2hdIFNlc3Npb24tSUQg Y2hhcnRlciBwcm9wb3NhbA0KDQoNCkhpLA0KDQpNeSBtZWFucyBpcywgaW4gdGhlIGFueSBwb2lu dCBvZiB0aGUgdHJhdmVyc2Ugb2YgdGhlIHNpcCBkaWFsb2csIHdlIGNhbiBpZGVudGlmeSB0aGUg Y29ycmVsYXRpb24uIEFuZCBhdCBkaWZmZXJlbnQgcG9pbnRzIG9uIHRoZSB0d28gc2lkZXMgb2Yg QjJCVUEgZXF1aXBtZW50KHN1Y2ggYXMgQVMpLCB3ZSBjYW4gZmlndXJlIG91dCB0aGUgY29ycmVs YXRpb24gYnkgdGhlIG1hcHBpbmcvY29ycmVsYXRpb24gYnkgdGhlIEIyQlVBIGVxdWlwbWVudC4N Cg0KQ29uc2lkZXJpbmcgdGhlIG5ldyBoZWFkZXIsIGlmIHRoZSBCMkJVQSBlcXVpcG1lbnQganVz dCBleHB1cmdhdGUgdGhlIGhlYWRlciBmcm9tIG9uZSBzaWRlJ3MgZGlhbG9nIHRvIGFub3RoZXIs IHdvdWxkIGl0IGJlIGEgcHJvYmxlbSBmb3IgdGhlIGNvcnJlbGF0aW9uPw0KDQpNeSBxdWVzdGlv bnMgbWF5IGJlIHRvbyBlYXJseS4gTWF5YmUgeW91IGNhbiBhbnN3ZXIgaXQgYXQgdGhlIGRyYWZ0 IHN0YWdlLg0KDQpUaGFua3MsDQoNCkdhbw0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KWmlwICAgIDogMjEwMDEyDQpUZWwgICAgOiA4NzIxMQ0KVGVsMiAgIDooKzg2KS0w MjUtNTI4NzcyMTENCmVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KDQpIYWRyaWVsIEthcGxhbiA8SEthcGxhbkBhY21lcGFj a2V0LmNvbT4NCg0KMjAxMC0wNS0xMSAwMDozMw0KDQrK1bz+yMsNCg0KImdhby55YW5nMkB6dGUu Y29tLmNuIiA8Z2FvLnlhbmcyQHp0ZS5jb20uY24+DQoNCrOty80NCg0KRElTUEFUQ0ggPGRpc3Bh dGNoQGlldGYub3JnPg0KDQrW98ziDQoNClJFOiBbZGlzcGF0Y2hdIFNlc3Npb24tSUQgY2hhcnRl ciBwcm9wb3NhbA0KDQoNCg0KDQoNCg0KDQoNCg0KDQpUaGUgcHVycG9zZSBpcyBmb3IgdHJvdWJs ZXNob290aW5nLCBhY3Jvc3MgbXVsdGlwbGUgc3lzdGVtcy4gIEkgaGFkIHRoYXQgaW4gdGhlIHRp dGxlIG9mIHRoZSBjaGFydGVyLCBidXQgeW91oa9yZSByaWdodCBJIGZvcmdvdCB0byBleHBsaWNp dGx5IGNhbGwgdGhhdCBvdXQgaW4gdGhlIGNoYXJ0ZXIuDQpIb3cgYWJvdXQgdGhpcyBuZXcgZmly c3Qgc2VudGVuY2U6DQpUaGUgU0lQU0NPVENIIHdvcmtpbmcgZ3JvdXAgaXMgY2hhcnRlcmVkIHRv IGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBvcGVyYXRvcnMgYW5kIG1vbml0b3Jpbmcg ZXF1aXBtZW50IHRvIGNvcnJlbGF0ZSBTSVAgbWVzc2FnZXMgYW5kIGRpYWxvZ3Mgb2YgdGhlIHNh bWUgaGlnaGVyLWxldmVsIGVuZC10by1lbmQgInNlc3Npb24iIG9yICJtZXNzYWdlLWZsb3ciIGFj cm9zcyBtdWx0aXBsZSBTSVAgZGV2aWNlcywgZm9yIHRoZSBwdXJwb3NlIG9mIHRyb3VibGVzaG9v dGluZy4NCg0KLWhhZHJpZWwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpGcm9tOiBnYW8ueWFuZzJAenRlLmNvbS5jbiBbbWFpbHRvOmdhby55YW5nMkB6dGUuY29tLmNu XQ0KU2VudDogTW9uZGF5LCBNYXkgMTAsIDIwMTAgOToxMiBBTQ0KVG86IEhhZHJpZWwgS2FwbGFu DQpDYzogRElTUEFUQ0gNClN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFNlc3Npb24tSUQgY2hhcnRl ciBwcm9wb3NhbA0KDQoNCkhpLA0KDQpQbGVhc2UgbGV0IG1lIG1ha2UgbXkgcXVlc3Rpb24gY2xl YXJseS4gQ29uc2lkZXJpbmcgYmlsbGluZy9jaGFyZ2luZy9wb2xpY3kgYW5kIExJKGxhd2Z1bCBp bnRlcmNlcHRpb24pLCB0aGVyZSdzIHVzZSBjYXNlcyBvZiBjb3JyZWxhdGluZyAic2Vzc2lvbiIg YW5kICJtZXNzYWdlLWZsb3ciLiBJbiBmYWN0LCB3ZSBoYXZlIGRvbmUgYmlsbGluZy9jaGFyZ2lu Zy9wb2xpY3kgYW5kIExJIHdpdGhvdXQgc3VjaCBuZXcgaGVhZGVyLiBTbywgSSBzYWlkIHRoYXQg SSBkaWQgbm90IGZpbmQgcmVxdWlyZW1lbnQgb2YgZGVmaW5pbmcgbmV3IGhlYWRlciB0byBjb3Jy ZWxhdGUgInNlc3Npb24iIGFuZCAibWVzc2FnZS1mbG93Ii4NCg0KTWF5YmUgdGhlcmUncyB1c2Ug Y2FzZSBhbmQgcmVxdWlyZW1lbnQgZm9yIHRoZSBuZXcgaGVhZGVyLiBTbywgSSdkIGxpa2UgdG8g c2VlIGl0J3MgZGV0YWlsLg0KDQpUaGFua3MsDQoNCkdhbw0KDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KWmlwICAgIDogMjEwMDEyDQpUZWwgICAgOiA4NzIxMQ0KVGVsMiAg IDooKzg2KS0wMjUtNTI4NzcyMTENCmVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tLS0g16q3osjLIEdhb1lhbmcxNDAx OTcvdXNlci96dGVfbHRkIMqxvOQgMjAxMC0wNS0xMCAyMTowMiAtLS0tLQ0KR2FvWWFuZzE0MDE5 Ny91c2VyL3p0ZV9sdGQNCg0KMjAxMC0wNS0xMCAyMDo1Ng0KDQoNCsrVvP7Iyw0KDQpIYWRyaWVs IEthcGxhbiA8SEthcGxhbkBhY21lcGFja2V0LmNvbT4NCg0Ks63LzQ0KDQpESVNQQVRDSCA8ZGlz cGF0Y2hAaWV0Zi5vcmc+LCBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnDQoNCtb3zOINCg0KUmU6 IFtkaXNwYXRjaF0gU2Vzc2lvbi1JRCBjaGFydGVyIHByb3Bvc2FswbS90zxOb3RlczovL25qbWFp bDAxLzQ4MjU3MTY5MDAyREY4RUUvREFCQTk3NUI5RkIxMTNFQjg1MjU2NEI1MDAxMjgzRUEvNzlB NzA2MTVBMkQ2QUUxOTQ4MjU3NzFEMDA3MTFENzg+DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KSGksDQoNCkknZCBsaWtlIHRvIHNlZSB0aGUgcmVxdWlyZW1lbnQgb2YgdGhlIGhlYWRlciBh bmQgdHlwaWNhbCB1c2UgY2FzZSBmb3IgaXQgaW4gdGhlIGNoYXJ0ZXIuDQoNClRoYW5rcywNCg0K R2FvDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpaaXAgICAgOiAyMTAw MTINClRlbCAgICA6IDg3MjExDQpUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KZV9tYWlsIDog Z2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQpIYWRyaWVsIEthcGxhbiA8SEthcGxhbkBhY21lcGFja2V0LmNvbT4NCreivP7IyzogIGRpc3Bh dGNoLWJvdW5jZXNAaWV0Zi5vcmcNCg0KMjAxMC0wNS0wOSAwNDozNQ0KDQoNCsrVvP7Iyw0KDQpE SVNQQVRDSCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+DQoNCrOty80NCg0KDQoNCtb3zOINCg0KW2Rpc3Bh dGNoXSBTZXNzaW9uLUlEIGNoYXJ0ZXIgcHJvcG9zYWwNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpIb3dkeSwNCkkgaGF2ZSBhc2tlZCB0aGUgRElTUEFUQ0ggY2hhaXJzIHdoYXQgdG8gZG8g d2l0aCBTZXNzaW9uLUlELCBnaXZlbiB0aGUgZmVlZGJhY2sgSSByZWNlaXZlZCB0byBtYWtlIGl0 IGEgc3RhbmRhcmRzLXRyYWNrIHZzLiBpbmRpdmlkdWFsIGluZm9ybWF0aW9uYWwgc3VibWlzc2lv bi4gIFRoZXJlIGlzIG5vIG9idmlvdXMgY3VycmVudCBXRyBmb3IgdGhpcyB3b3JrLCBzbyB0aGV5 IGFza2VkIG1lIHRvIHBvc3QgYSBzdHJhd21hbiBjaGFydGVyIHByb3Bvc2FsLCB3aGljaCBJIHBy b3Bvc2UgYXMgZm9sbG93czoNCg0KDQpTSVAgU2lnbmFsaW5nLUNPbW11bmljYXRpb24gVHJvdWJs ZXNob290aW5nIHdpdGggQ29ycmVsYXRpb24gSGVhZGVyIChTSVBTQ09UQ0gpIENoYXJ0ZXI6DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGUgU0lQU0NPVENIIHdvcmtpbmcg Z3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBvcGVy YXRvcnMgYW5kIG1vbml0b3JpbmcgZXF1aXBtZW50IHRvIGNvcnJlbGF0ZSBTSVAgbWVzc2FnZXMg YW5kIGRpYWxvZ3Mgb2YgdGhlIHNhbWUgaGlnaGVyLWxldmVsIGVuZC10by1lbmQgInNlc3Npb24i IG9yICJtZXNzYWdlLWZsb3ciLiAgSW4gcGFydGljdWxhciwgdGhlIG1lY2hhbmlzbSBtdXN0IGJl IGFibGUgdG8gYWxsb3cgc3VjaCBjb3JyZWxhdGlvbiBhY3Jvc3MgU0lQIEIyQlVBcyBvZiBhcyBt YW55IGZ1bmN0aW9uYWwgdHlwZXMgYXMgcG9zc2libGUsIHN1Y2ggYXMgQXBwbGljYXRpb24gU2Vy dmVycywgU29mdHN3aXRjaGVzLCBQQlhzLCBTQkNzLCBldGMuDQoNCkFsdGhvdWdoIG90aGVyIHNv bHV0aW9ucyBtYXkgYmUgcG9zc2libGUsIHRoaXMgd29ya2luZyBncm91cCB3aWxsIGZvY3VzIG9u IGRlZmluaW5nIGEgbmV3IFNJUCBIZWFkZXIgZmllbGQgZm9yIHN1Y2ggYSBwdXJwb3NlLCBzaW1p bGFyIHRvIHRoZSBDYWxsLUlEIGhlYWRlciBmaWVsZCwgaW4gb3JkZXIgdG8gcHJvdmlkZSBhIHNp bXBsZSwgZWFzaWx5IGRlcGxveWFibGUgbWVjaGFuaXNtIHdoaWNoIGNhbiB3b3JrIGFjcm9zcyBT SVAgZG9tYWlucy4gVGhlIFNJUCBDYWxsLUlEIGhlYWRlciBmaWVsZCB2YWx1ZSBpdHNlbGYgaXMg bm90IHVzYWJsZSBmb3Igc3VjaCBjb3JyZWxhdGlvbiwgYmVjYXVzZSBtYW55IEIyQlVBcyBtdXN0 IGNyZWF0ZSBhIG5ldyBDYWxsLUlEIHZhbHVlIG9uIHRoZWlyIFVBQyAic2lkZSIgaW4gb3JkZXIg dG8gZnVuY3Rpb24gcHJvcGVybHksIGFuZCB0byBjb21wbHkgd2l0aCB0aGUgcnVsZXMgb2YgUkZD IDMyNjEuDQoNCkl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGNlcnRhaW4gU0lQIEIyQlVBcyBwZXJm b3JtIGEgInRvcG9sb2d5LWhpZGluZyIgZnVuY3Rpb24sIGFzIGRlc2NyaWJlZCBpbiBSRkMgNTg1 My4gIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgdGFrZSBzdWNoIGZ1bmN0aW9ucyBpbnRvIGFjY291 bnQgZm9yIHRoZSBjb3JyZWxhdGlvbiBtZWNoYW5pc20sIGFzIHdlbGwgYXMgcHJvdmlkZSBndWlk YW5jZSBmb3IgaW1wbGVtZW50ZXJzIG9mIHRoZSBtZWNoYW5pc20gdG8gYXZvaWQgdHJpZ2dlcmlu ZyBzdWNoIGEgZnVuY3Rpb24gZm9yIHRoZSBtZWNoYW5pc20ncyBoZWFkZXIgZmllbGQgdmFsdWUu DQoNCkxhc3RseSwgYWx0aG91Z2ggaW4gY2VydGFpbiBlbnZpcm9ubWVudHMgc3VjaCBhIG1lY2hh bmlzbSBtYXkgYmUgdXNhYmxlIGZvciBkaWFsb2cgY29ycmVsYXRpb24gaW4gU0lQIHN0YXRlIG1h Y2hpbmVzLCBpdCBpcyBub3QgdGhlIGdvYWwgb2YgdGhpcyB3b3JraW5nIGdyb3VwIHRvIGFkZHJl c3MgdGhhdCB1c2FnZS4NCg0KR29hbHMgYW5kIE1pbGVzdG9uZXMNCj09PT09PT09PT09PT09PT09 PT09DQpEZWMgMjAxMCAtIE5ldyBoZWFkZXIgc3BlY2lmaWNhdGlvbiB0byBJRVNHIChQUykNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNo IG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkg Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkg cHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmlj YXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0 ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2Ug dGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWls IGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFu eSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZp ZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBh bmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1h aWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0 byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4N Cg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZp ZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRo ZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ug b2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --_000_430FC6BDED356B4C8498F634416644A91A8A7D7AACmail_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

No B2BUA has to support any new RFC.  Assuming the WG decides on a new header =A1= =B0Foobar=A1=B1 for the mechanism, and published an RFC XYZ saying B2BUA=A1=AFs must pass =A1= =B0Foobar=A1=B1 through, then a B2BUA does not have to pass it through =A8C it just wouldn=A1=AFt be implementing or be complia= nt with RFC XYZ if it didn=A1=AFt.  But if the B2BUA claimed compliance with RFC X= YZ, then it would have to follow the RFC and pass =A1=B0Foobar=A1=B1 when it=A1=AFs = set to =A8C it could not expurgate the header if it claimed to implement the RFC.  If opera= tors want this thing, then they=A1=AFll tell their vendors to do RFC XYZ.

 

I=A1=AFm not sure if that was your question/comment though.  Maybe you just mean =A1=B0we don=A1=AFt need= this=A1=B1.  That=A1=AFs fine, then you don=A1=AFt need it.  Many if not all B2BUA vendors have= means of correlating messages, whether it be in proprietary headers, =A1=B0special= =A1=B1 info in Call-IDs, or just logs or even CDRs.  And a few monitoring vendors hav= e figured out how to correlate the messages when they cross through B2BUA=A1= =AFs too, or will collect the logs specifically to do so.  That=A1=AFs all fine,= and nobody=A1=AFs stopping them.  We=A1=AFre just providing a mechanism to= let people do it more simply, in a consistent fashion, without having to go through all t= hat.

 

I know it=A1=AFs hard to justify imple= menting this thing when you already have a way to correlate it yourself, or if your favorite monitoring vendors have already figured out how to.  I=A1=AFv= e had that same problem arguing for it in my own company, because we too have dif= ferent ways of doing it already.  But if we want SIP to be deployed faster an= d cost less in opex, we have to help operators manage and troubleshoot as easily a= s possible.  This WG is for just one small piece, but it=A1=AFs also not= that much work for B2BUA vendors I would think/hope.

 

-hadriel

 

From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: Monday, May 10, 2010 9= :17 PM
To: Hadriel Kaplan
Cc: DISPATCH
Subject: RE: [dispatch] Sess= ion-ID charter proposal

 


Hi,

My means is, in the any point of the traverse of the sip dialog, we can identi= fy the correlation. And at different points on the two sides of B2BUA equipment(such as AS), we can figure out the correlation by the mapping/correlation by the B2BUA equipment.

Considering the new header, if the B2BUA equipment just expurgate the header from one side's dialog to another, would it be a problem for the correlation?=

My questions may be too early. Maybe you can answer it at the draft stage.

Thanks,

Gao

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Hadrie= l Kaplan <HKaplan@acmepacket.com>

2010-05-11 00:33

=CA=D5=BC=FE= =C8=CB

"gao.yang2@zte.com.cn" <gao.yang2@zte.com.cn>

=B3=AD=CB=CD=

DISPATCH <= dispatch@ietf.org>

=D6=F7=CC=E2=

RE: [dispatch] Session-ID charter proposa= l

 

 

 




The purpose is for troubleshooting, across multiple systems.  I had that in the title of the charter, but you=A1= =AFre right I forgot to explicitly call that out in the charter. How about this new first sentence:
The SIPSCOTCH working group is chartered to define a mechanism that allows operators and monitoring equipment to correlate SIP messages and dialogs of= the same higher-level end-to-end "session" or "message-flow"= ; across multiple SIP devices, for the purpose of troubleshooting.
 
-hadriel
 

 


From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: Monday, May 10, 2010 9:12 AM
To: Hadriel Kaplan<= b>
Cc: DISPATCH
Subject: Re: [dispatch] Session-ID charter proposal
 

Hi,

Please let me make my question clearly. Considering billing/charging/policy= and LI(lawful interception), there's use cases of correlating "session&quo= t; and "message-flow". In fact, we have done billing/charging/policy= and LI without such new header. So, I said that I did not find requirement of defining new header to correlate "session" and "message-flow".

Maybe there's use case and requirement for the new header. So, I'd like to = see it's detail.

Thanks,

Gao  

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
----- =D7=AA=B7=A2=C8=CB GaoYang140197/user/zte_ltd = =CA=B1=BC=E4 2010-05-10 21:02 -----

GaoYang140197/user/zte_ltd= <= o:p>

2010-05-10 20:56

 

=CA=D5=BC=FE= =C8=CB

Hadriel Kaplan= <HKaplan@acmepacket.com>

=B3=AD=CB=CD=

DISPATCH <= dispatch@ietf.org>, dispatch-bounces@ietf.org

=D6=F7=CC=E2=

Re: [dispatch] Session-ID charter proposa= l=C1=B4=BD=D3


 

&nb= sp;

 

 





Hi,

I'd like to see the requirement of the header and typical use case for it i= n the charter.

Thanks,

Gao

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Hadrie= l Kaplan <HKaplan@acmepacket.com>
=B7=A2=BC=FE=C8=CB:  dispatch-bounces@ietf.org

2010-05-09 04:35

 

=CA=D5=BC=FE= =C8=CB

DISPATCH <= dispatch@ietf.org>

=B3=AD=CB=CD=

 

=D6=F7=CC=E2=

[dispatch] Session-ID charter proposal


 

&nb= sp;

 

 





Howdy,
I have asked the DISPATCH chairs what to do with Session-ID, given the feed= back I received to make it a standards-track vs. individual informational submission.  There is no obvious current WG for this work, so they asked me to post a strawman charter proposal, which I propose as follows:


SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCO= TCH) Charter:
----------------------------------
The SIPSCOTCH working group is chartered to define a mechanism that allows operators and monitoring equipment to correlate SIP messages and dialogs of= the same higher-level end-to-end "session" or "message-flow"= ;.  In particular, the mechanism must be able to allow such correlation across SIP B2BUAs of as many functional types as possible, such as Application Servers= , Softswitches, PBXs, SBCs, etc.

Although other solutions may be possible, this working group will focus on defining a new SIP Header field for such a purpose, similar to the Call-ID header field, in order to provide a simple, easily deployable mechanism whi= ch can work across SIP domains. The SIP Call-ID header field value itself is n= ot usable for such correlation, because many B2BUAs must create a new Call-ID value on their UAC "side" in order to function properly, and to c= omply with the rules of RFC 3261.

It should be noted that certain SIP B2BUAs perform a "topology-hiding" function, as described in RFC 5853.  The working group will take such functions into account for the correlation mechanism, as well as provide guidance for implementers of the mechanism to avoid triggering such a function for the mechanism's header field value.
Lastly, although in certain environments such a mechanism may be usable for dialog correlation in SIP state machines, it is not the goal of this workin= g group to address that usage.

Goals and Milestones
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dec 2010 - New header specification to IESG (PS)

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


 
------------= --------------------------------------------
ZTE Information= Security Notice: The<= font face=3D"Courier New"> information= contained in this= mail= is solely property of the<= font face=3D"Courier New"> sender's organization. This= mail= communication is confidential. Recipients<= /font> named above are<= font face=3D"Courier New"> obligated to maintain secrecy and<= font face=3D"Courier New"> are<= font face=3D"Courier New"> not<= font face=3D"Courier New"> permitted to disclose the<= font face=3D"Courier New"> contents of this= communication to others.
This<= /font> email and<= font face=3D"Courier New"> any<= font face=3D"Courier New"> files transmitted= with= it are<= font face=3D"Courier New"> confidential and<= font face=3D"Courier New"> intended solely for<= font face=3D"Courier New"> the<= font face=3D"Courier New"> use<= font face=3D"Courier New"> of the<= font face=3D"Courier New"> individual<= /font> or entity to whom= they= are<= font face=3D"Courier New"> addressed.<= /font> If you<= font face=3D"Courier New"> have= received this= email in error please notify the<= font face=3D"Courier New"> originator<= /font> of the<= font face=3D"Courier New"> message. Any<= font face=3D"Courier New"> views expressed in this= message are<= font face=3D"Courier New"> those of the<= font face=3D"Courier New"> individual<= /font> sender.
This<= /font> message has<= font face=3D"Courier New"> been= scanned for<= font face=3D"Courier New"> viruses and<= font face=3D"Courier New"> Spam= by ZTE<= font face=3D"Courier New"> Anti-Spam system. 

&nb=
sp;
-------------------=
-------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This<=
font
face=3D"Courier New"> email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This<=
font
face=3D"Courier New"> message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--_000_430FC6BDED356B4C8498F634416644A91A8A7D7AACmail_-- From gao.yang2@zte.com.cn Mon May 10 22:28:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C713A6CB3 for ; Mon, 10 May 2010 22:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.059 X-Spam-Level: X-Spam-Status: No, score=-97.059 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ugil2Yc0w6IG for ; Mon, 10 May 2010 22:27:56 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 2A86C3A6AD8 for ; Mon, 10 May 2010 22:21:43 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 58071992332426; Tue, 11 May 2010 13:16:25 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 6793.2776214488; Tue, 11 May 2010 13:20:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4B5KpXS093083; Tue, 11 May 2010 13:20:51 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7AAC@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 11 May 2010 13:18:06 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-11 13:20:44, Serialize complete at 2010-05-11 13:20:44 Content-Type: multipart/alternative; boundary="=_alternative 001D557548257720_=" X-MAIL: mse2.zte.com.cn o4B5KpXS093083 Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 05:28:00 -0000 This is a multipart message in MIME format. --=_alternative 001D557548257720_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 ID4gSaGvbSBub3Qgc3VyZSBpZiB0aGF0IHdhcyB5b3VyIHF1ZXN0aW9uL2NvbW1lbnQgdGhvdWdo LiAgTWF5YmUgeW91IA0KPiBqdXN0IG1lYW4gobB3ZSBkb26hr3QgbmVlZCB0aGlzobEuICBUaGF0 oa9zIGZpbmUsIHRoZW4geW91IGRvbqGvdCBuZWVkIA0KPiBpdC4gDQoNCkkgYW0gbm90IHRyeWlu ZyB0byBzYXkgIndlIGRvbid0IG5lZWQgdGhpcyIuIEkganVzdCB3YW50IHRvIGFzayB3aHkgd2Ug DQpuZWVkIHRoZSBoZWFkZXI/DQpJIGRpZG4ndCB3YW50IHRvIHN0b3AgeW91ciBwcm9jZXNzLiBK dXN0IHdhbnQgdG8gZ2V0IGEgbW9yZSBjb252aWN0aXZlIA0KYmFja2dyb3VuZCBmb3IgdGhpcyBu ZXcgaGVhZGVyLiBTbywgSSBzYWlkLCBhIGFudGl0aGVzZXMgbWlnaHQgYmUgbmVlZGVkLg0KDQo+ TWFueSBpZiBub3QgYWxsIEIyQlVBIHZlbmRvcnMgaGF2ZSBtZWFucyBvZiBjb3JyZWxhdGluZyAN Cj4gbWVzc2FnZXMsIHdoZXRoZXIgaXQgYmUgaW4gcHJvcHJpZXRhcnkgaGVhZGVycywgobBzcGVj aWFsobEgaW5mbyBpbiANCj4gQ2FsbC1JRHMsIG9yIGp1c3QgbG9ncyBvciBldmVuIENEUnMuICBB bmQgYSBmZXcgbW9uaXRvcmluZyB2ZW5kb3JzIA0KPiBoYXZlIGZpZ3VyZWQgb3V0IGhvdyB0byBj b3JyZWxhdGUgdGhlIG1lc3NhZ2VzIHdoZW4gdGhleSBjcm9zcyANCj4gdGhyb3VnaCBCMkJVQaGv cyB0b28sIG9yIHdpbGwgY29sbGVjdCB0aGUgbG9ncyBzcGVjaWZpY2FsbHkgdG8gZG8gc28uDQoN CkNvbnNpZGVyaW5nIHRoZXJlJ3Mgb25lIEIyQlVBIEFTIGluIHRoZSBuZXR3b3JrLCBhbmQgaXQg ZG9lc24ndCBzdXBwb3J0IA0KdGhpcyBoZWFkZXIuIFdoYXQgd291bGQgaGFwcGVuPyBBbmQgaWYg dGhlIEIyQlVBIEFTIGhhcyBiZWVuIGRlcGxveWVkIGluIA0KdGhlIG5ldHdvcmsgYmVmb3JlIHRo ZSBMSS9tb25pdG9yaW5nIGVxdWlwbWVudCwgaG93IGNhbiB0aGUgTEkvbW9uaXRvcmluZyANCmVx dWlwbWVudCdzIHBlb3BsZSBkZW1hbmQgdGhlIHN1cHBvcnRpbmcgb2YgdGhlIG5ldyBoZWFkZXIg Zm9yIHRoZSANCipibG9ja2luZyogQjJCVUEgQVM/DQoNCkknZCBsaWtlIHRvIGVtcGhhc2l6ZSB0 aGF0IExJIHRoaW5nIGlzIG5vdCBvcHRpb25hbCBsaWtlIG9uZSBzZXJ2aWUgbGV2ZWwgDQpleHRl bnNpb24uIFNvLCBhcyB0aGUgb3JpZ2luYWwgcmVxdWlyZW1lbnQgaXMgZnJvbSBMSS9tb25pdG9y aW5nIGFzcGVjdCwgDQp0aGUgaW50ZXJ3b3JraW5nIGFuZCBjb21wYXRpYmlsaXR5IGlzc3VlIG1p Z2h0IGJlIG1vcmUgdGhhbiBvcHRpb25hbCANCnN1cHBvcnRpbmcgb25lIHBvdGVudGlhbCBSRkMu DQoNCj4gVGhhdKGvcyBhbGwgZmluZSwgYW5kIG5vYm9keaGvcyBzdG9wcGluZyB0aGVtLiAgV2Wh r3JlIGp1c3QgcHJvdmlkaW5nIGENCj4gbWVjaGFuaXNtIHRvIGxldCBwZW9wbGUgZG8gaXQgbW9y ZSBzaW1wbHksIGluIGEgY29uc2lzdGVudCBmYXNoaW9uLCANCj4gd2l0aG91dCBoYXZpbmcgdG8g Z28gdGhyb3VnaCBhbGwgdGhhdC4NCg0KWWVzLiBBcyBJIHRoaW5rIG1lY2hhbmlzbSdzIGRlZmlu dGlvbiBpcyBvbmUgaXNzdWUsIGl0J3MgaW50ZXJ3b3JraW5nIGFuZCANCmNvbXBhdGliaWxpdHkg aXMgYW5vdGhlciBpc3N1ZS4NCg0KU28sIEknZCBsaWtlIHRvIGVtcGhhc2l6ZSB0aGF0IEkgYW0g T0sgd2l0aCB5b3VyIGNoYXJ0ZXIgYXMgSSBzYWlkLiBCdXQgSSANCmFtIG5vdCBzdXJlIGFib3V0 IGludGVyd29ya2luZyBhbmQgY29tcGF0aWJpbGl0eSBvZiB0aGUgbmV3IGhlYWRlci4gDQoNClRo YW5rcywNCg0KR2FvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNv bmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50 YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50 cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZp bGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBw bGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhw cmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVy Lg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkg WlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 001D557548257720_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgSaGvbSBub3Qgc3VyZSBpZiB0aGF0IHdhcyB5b3VyIHF1ZXN0aW9uL2NvbW1l bnQNCnRob3VnaC4gJm5ic3A7TWF5YmUgeW91IDxicj4NCiZndDsganVzdCBtZWFuIKGwd2UgZG9u oa90IG5lZWQgdGhpc6GxLiAmbmJzcDtUaGF0oa9zIGZpbmUsIHRoZW4geW91DQpkb26hr3QgbmVl ZCA8YnI+DQomZ3Q7IGl0LiAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPkkgYW0gbm90IHRyeWluZyB0byBzYXkgJnF1b3Q7d2UgZG9uJ3QgbmVlZCB0aGlzJnF1 b3Q7Lg0KSSBqdXN0IHdhbnQgdG8gYXNrIHdoeSB3ZSBuZWVkIHRoZSBoZWFkZXI/PC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIGRpZG4ndCB3YW50IHRvIHN0b3AgeW91ciBwcm9j ZXNzLiBKdXN0IHdhbnQgdG8gZ2V0DQphIG1vcmUgY29udmljdGl2ZSBiYWNrZ3JvdW5kIGZvciB0 aGlzIG5ldyBoZWFkZXIuIFNvLCBJIHNhaWQsIGEgPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPmFudGl0aGVzZXM8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj4NCm1pZ2h0 IGJlIG5lZWRlZC48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDtN YW55IGlmIG5vdCBhbGwgQjJCVUEgdmVuZG9ycyBoYXZlIG1lYW5zIG9mIGNvcnJlbGF0aW5nDQo8 YnI+DQomZ3Q7IG1lc3NhZ2VzLCB3aGV0aGVyIGl0IGJlIGluIHByb3ByaWV0YXJ5IGhlYWRlcnMs IKGwc3BlY2lhbKGxIGluZm8NCmluIDxicj4NCiZndDsgQ2FsbC1JRHMsIG9yIGp1c3QgbG9ncyBv ciBldmVuIENEUnMuICZuYnNwO0FuZCBhIGZldyBtb25pdG9yaW5nIHZlbmRvcnMNCjxicj4NCiZn dDsgaGF2ZSBmaWd1cmVkIG91dCBob3cgdG8gY29ycmVsYXRlIHRoZSBtZXNzYWdlcyB3aGVuIHRo ZXkgY3Jvc3MgPGJyPg0KJmd0OyB0aHJvdWdoIEIyQlVBoa9zIHRvbywgb3Igd2lsbCBjb2xsZWN0 IHRoZSBsb2dzIHNwZWNpZmljYWxseSB0byBkbw0Kc28uPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5Db25zaWRlcmluZyB0aGVyZSdzIG9uZSBCMkJVQSBBUyBpbiB0aGUg bmV0d29yaywgYW5kDQppdCBkb2Vzbid0IHN1cHBvcnQgdGhpcyBoZWFkZXIuIFdoYXQgd291bGQg aGFwcGVuPyBBbmQgaWYgdGhlIEIyQlVBIEFTDQpoYXMgYmVlbiBkZXBsb3llZCBpbiB0aGUgbmV0 d29yayBiZWZvcmUgdGhlIExJL21vbml0b3JpbmcgZXF1aXBtZW50LCBob3cNCmNhbiB0aGUgTEkv bW9uaXRvcmluZyBlcXVpcG1lbnQncyBwZW9wbGUgZGVtYW5kIHRoZSBzdXBwb3J0aW5nIG9mIHRo ZSBuZXcNCmhlYWRlciBmb3IgdGhlICpibG9ja2luZyogQjJCVUEgQVM/PC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JJ2QgbGlrZSB0byBlbXBoYXNpemUgdGhhdCBMSSB0 aGluZyBpcyBub3Qgb3B0aW9uYWwNCmxpa2Ugb25lIHNlcnZpZSBsZXZlbCBleHRlbnNpb24uIFNv LCBhcyB0aGUgb3JpZ2luYWwgcmVxdWlyZW1lbnQgaXMgZnJvbQ0KTEkvbW9uaXRvcmluZyBhc3Bl Y3QsIHRoZSBpbnRlcndvcmtpbmcgYW5kIGNvbXBhdGliaWxpdHkgaXNzdWUgbWlnaHQgYmUNCm1v cmUgdGhhbiBvcHRpb25hbCBzdXBwb3J0aW5nIG9uZSBwb3RlbnRpYWwgUkZDLjwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyBUaGF0oa9zIGFsbCBmaW5lLCBhbmQg bm9ib2R5oa9zIHN0b3BwaW5nIHRoZW0uICZuYnNwO1dloa9yZSBqdXN0DQpwcm92aWRpbmcgYTxi cj4NCiZndDsgbWVjaGFuaXNtIHRvIGxldCBwZW9wbGUgZG8gaXQgbW9yZSBzaW1wbHksIGluIGEg Y29uc2lzdGVudCBmYXNoaW9uLA0KPGJyPg0KJmd0OyB3aXRob3V0IGhhdmluZyB0byBnbyB0aHJv dWdoIGFsbCB0aGF0LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+WWVz LiBBcyBJIHRoaW5rIG1lY2hhbmlzbSdzIGRlZmludGlvbiBpcyBvbmUgaXNzdWUsDQppdCdzIGlu dGVyd29ya2luZyBhbmQgY29tcGF0aWJpbGl0eSBpcyBhbm90aGVyIGlzc3VlLjwvZm9udD48L3R0 Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+U28sIEknZCBsaWtlIHRvIGVtcGhhc2l6ZSB0 aGF0IEkgYW0gT0sgd2l0aCB5b3VyIGNoYXJ0ZXINCmFzIEkgc2FpZC4gQnV0IEkgYW0gbm90IHN1 cmUgYWJvdXQgaW50ZXJ3b3JraW5nIGFuZCBjb21wYXRpYmlsaXR5IG9mIHRoZQ0KbmV3IGhlYWRl ci4gJm5ic3A7IDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhhbmtz LDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+R2FvPC9mb250PjwvdHQ+ DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5i c3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkm bmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1Ro aXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFs LiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2Js aWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDth cmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhl Jm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtm aWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZu YnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRy ZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlz Jm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5i c3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJz cDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21l c3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNw O3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5 Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 001D557548257720_=-- From john.elwell@siemens-enterprise.com Tue May 11 01:16:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA693A6B3A for ; Tue, 11 May 2010 01:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLxfwiuMZ-Mj for ; Tue, 11 May 2010 01:16:20 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A88233A6B3E for ; Tue, 11 May 2010 01:15:36 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-127091; Tue, 11 May 2010 10:15:18 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 8056C1EB82AB; Tue, 11 May 2010 10:15:18 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 11 May 2010 10:15:18 +0200 From: "Elwell, John" To: "SHEKH-YUSEF, RIFAAT (RIFAAT)" , "dispatch@ietf.org" , "mary.ietf.barnes@gmail.com" , "fluffy@cisco.com" Date: Tue, 11 May 2010 10:15:17 +0200 Thread-Topic: [dispatch] New I-D: draft-yusef-dispatch-ach-rest-api-00 Thread-Index: Acrwce0R9mYFd1j9Sx6Q3/xrk2831gAa0x+g Message-ID: References: <6369CB70BFD88942B9705AC1E639A33821FDC0C703@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33821FDC0C703@DC-US1MBEX4.global.avaya.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] New I-D: draft-yusef-dispatch-ach-rest-api-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 08:16:21 -0000 More specifically, this work arose from BLISS work on automatic call handli= ng (ACH), the current draft of which is at: http://datatracker.ietf.org/doc/draft-ietf-bliss-ach-analysis/ The future of this draft is being discussed on the BLISS list. In particula= r see the message I posted today, in which I called for opinions on the way= forward with that draft: http://www.ietf.org/mail-archive/web/bliss/current/msg01104.html Please respond on the BLISS list if you have comments on that posting. John =20 > -----Original Message----- > From: SHEKH-YUSEF, RIFAAT (RIFAAT) [mailto:rifatyu@avaya.com]=20 > Sent: 10 May 2010 19:52 > To: dispatch@ietf.org; mary.ietf.barnes@gmail.com; fluffy@cisco.com > Cc: Elwell, John > Subject: [dispatch] New I-D: draft-yusef-dispatch-ach-rest-api-00 >=20 > Hi, > =20 > We have submitted the following ID and would like to add it=20 > as an agenda item for dispatch. > =20 > http://datatracker.ietf.org/doc/draft-yusef-dispatch-ach-rest- > api/=20 > =20 > =20 > This work started in the BLISS WG, but the original draft has=20 > expired and the current plan for BLISS is to finish the=20 > current work and close. > =20 > =20 > Regards, > Rifaat > =20 > -------------------- > =20 > A new version of I-D,=20 > draft-yusef-dispatch-ach-rest-api-00.txt has been=20 > successfully submitted by Rifaat Shekh-Yusef and posted to=20 > the IETF repository. > =20 > Filename: draft-yusef-dispatch-ach-rest-api > Revision: 00 > Title: ACH RESTful Interface > Creation_date: 2010-05-10 > WG ID: Independent Submission > Number_of_pages: 18 > =20 > Abstract: > This document defines a RESTful interface that allows a=20 > RESTful client to directly affect the Automatic Call Handling=20 > (ACH) behavior at a domain authoritative for a specific SIP address. > =20 > =20 > =20 > The IETF Secretariat. > =20 > =20 > = From partr@cisco.com Tue May 11 02:26:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8804528C24D for ; Tue, 11 May 2010 02:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.904 X-Spam-Level: X-Spam-Status: No, score=-8.904 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rxr5wz66HP8 for ; Tue, 11 May 2010 02:26:23 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 222093A6B87 for ; Tue, 11 May 2010 02:23:05 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJe+6EtAaHte/2dsb2JhbACeJ3GgeJljgmAOCIIaBIM+ X-IronPort-AV: E=Sophos;i="4.53,206,1272844800"; d="scan'208";a="324900779" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-1.cisco.com with ESMTP; 11 May 2010 09:22:53 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4B9Mq5B027997; Tue, 11 May 2010 09:22:53 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 14:52:53 +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, 11 May 2010 14:52:51 +0530 Message-ID: In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updates Session-ID charter Thread-Index: AcrwbbD3I0kahOGNSc2Kyg+gjSbVgAAfGqGA References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> From: "Parthasarathi R (partr)" To: "Hadriel Kaplan" , "DISPATCH" X-OriginalArrivalTime: 11 May 2010 09:22:53.0171 (UTC) FILETIME=[88826C30:01CAF0EB] Subject: Re: [dispatch] Updates Session-ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 09:26:24 -0000 Hi Hadriel, When multiple B2BUA SIP entities exists, session-id may be used for other services as well. The charter restricts only to troubleshooting currently. The session-id has to be considered for other use cases as well. For example, Media trombone (Media looping) in B2BUA(SBC) due to call forward from previous B2BUA(3PCC) hop shall be identified by the proposed session-id. I think that it is better to find the other use cases for session-id and include in the charter. Any specific reason for restricting only for troubleshooting only? Thanks Partha=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, May 10, 2010 11:52 PM To: DISPATCH Subject: [dispatch] Updates Session-ID charter Howdy, Here is an updated charter, which I think addresses Gao's concern: SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCOTCH) Charter: ---------------------------------- The SIPSCOTCH working group is chartered to define a mechanism that allows operators and monitoring equipment to correlate SIP messages and dialogs of the same higher-level end-to-end "session" across multiple SIP device hops for the same "message-flow", for the purpose of troubleshooting. In particular, the mechanism must be able to allow such correlation across SIP B2BUAs of as many functional types as possible, such as Application Servers, Softswitches, PBXs, SBCs, etc. Although other solutions may be possible, this working group will focus on defining a new SIP Header field for such a purpose, similar to the Call-ID header field, in order to provide a simple, easily deployable mechanism which can work across SIP domains. The SIP Call-ID header field value itself is not usable for such correlation, because many B2BUAs must create a new Call-ID value on their UAC "side" in order to function properly, and to comply with the rules of RFC 3261.=20 It should be noted that certain SIP B2BUAs perform a "topology-hiding" function, as described in RFC 5853. The working group will take such functions into account for the correlation mechanism, as well as provide guidance for implementers of the mechanism to avoid triggering such a function for the mechanism's header field value. Lastly, although in certain environments such a mechanism may be usable for dialog correlation in SIP state machines, it is not the goal of this working group to address that usage. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dec 2010 - New header specification to IESG (PS) _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Tue May 11 04:09:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DFE3A6882 for ; Tue, 11 May 2010 04:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JiAiVHHXMZm for ; Tue, 11 May 2010 04:09:46 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5822C3A6894 for ; Tue, 11 May 2010 04:09:31 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-129606; Tue, 11 May 2010 13:09:19 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 8F7A41EB82AB; Tue, 11 May 2010 13:09:19 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 11 May 2010 13:09:19 +0200 From: "Elwell, John" To: Hadriel Kaplan , Laura Liess , Gonzalo Camarillo Date: Tue, 11 May 2010 13:09:17 +0200 Thread-Topic: [dispatch] Status codes vs Alert-Info URNs WAS (Re: Alert Info Charter) Thread-Index: AcrvlvNWPpN4QzVgROqjAmznOEzlJAAyuQlAACXrTvA= Message-ID: References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE5418F.1010005@ericsson.com> <430FC6BDED356B4C8498F634416644A91A8A7D7977@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7977@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Status codes vs Alert-Info URNs WAS (Re: Alert Info Charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 11:09:47 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 10 May 2010 18:34 > To: Laura Liess; Gonzalo Camarillo > Cc: DISPATCH > Subject: Re: [dispatch] Status codes vs Alert-Info URNs WAS=20 > (Re: Alert Info Charter) >=20 >=20 >=20 > > -----Original Message----- > > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > > Sent: Sunday, May 09, 2010 12:44 PM > > To: Gonzalo Camarillo > >=20 > > I don't think that replacing the Alert-Info URNs with respose/status > > codes is a good idea, for following reasons: > > - The Alert-Info URN is tightly coupled with the rendering.=20 > It is not > > the rendering itself but an indication describing the=20 > semantic or the > > characteristic(s) of the rendering. In the general case it does not > > describe the call status. >=20 > Right, it does not describe the call status, just a "ringtone". >=20 >=20 > > - We choosed to use URNs as a flexible and extensible Internet-like > > mechanism to work for the general case in Internet, beyond the > > PSTN-like telephony. Currently we have only telephony use-cases, but > > we intended to define a general mechanism. > > - We choosed to use URN so the receiving UA can querry URN-resolvers > > to get the rendering. >=20 > Sounds good. >=20 >=20 > > - We already have use cases which seems to me to be=20 > problematic if you > > want to cover them with codes. E.g. country ringback=20 > tones. With the > > Alert-info URN we have urn:alert:locale:country. > code>. How could you represent this as response/status codes? >=20 > They wouldn't, because that indications is NOT "semantic" to=20 > begin with. It's literal. What that URN is, is really a=20 > ringtone. It happens to be that the ringtone is by=20 > reference, and the reference is a name rather than location.=20 > (ie, a URN vs. a URL) >=20 > It is not "semantic" because it carries no more "meaning"=20 > than any other Alert-Info. It's just a defined name for=20 > mapping to a tone. (I'm not exactly sure how a=20 > country-specific name could ever work in practice nor why it=20 > solves interop issues, but that's another topic :) >=20 >=20 > > - What about combination rules? This was one of the issues for which > > we had a lot of discussions for Alert-Info URNs. > > Thanks to Paul, we have now a quite flexible and well-sttructured > > syntax for Alert-Info URN (still not in the draft, but the=20 > the result > > of a ML-discussion): > > [snipped ABNF] > > Combination Rules: > > -The categories are orthogonal. There can be at most one instance of > > each alert-category in an > > Alert-Info header. > > - The implementation is free to ignore any or all received=20 > Alert-Info > > URNs. >=20 > I snipped the ABNF out, because I think that's really for the=20 > solution to figure out. But I sure hope the final list ends=20 > up being smaller than that, if what you want is universal=20 > interoperability. :) >=20 >=20 > > I don't think it is possible to achieve something similar using > > response/status codes. >=20 > Of course not - status codes are meant to provide status=20 > indication of the call. Like "the call is ringing" or "the=20 > call is queued" or "the call is being forwarded". *That* has=20 > "semantic" or "meaning". I thought that the charter was=20 > saying that's what you guys wanted in Alert-Info. =20 >=20 > But the more it's being explained, the more I think you don't=20 > really want that. You just want a resource name as opposed=20 > to a resource locator. So why confuse it any further with=20 > language about "semantic"?? If the IETF decides to define a=20 > URN for "short-short", that's just as meaningful or=20 > meaningless as "call-waiting" - because this is being used=20 > ONLY for ringtone names, not for call status. [JRE] I think "call-waiting" is a lot more meaningful than "short-short". T= he former can be rendered (audibly or otherwise) in a way consistent with t= he user interface, with a good chance that a user familiar with that user i= nterface will understand that the ringback tone means the call is waiting. = On the other hand "short-short" would presumably result in two short burst = of tone of some arbitrary duration, and what am I, the user, to make of tha= t? A user in a particular locale where two short bursts of tone are general= ly understood to have a particular meaning might understand, but a user out= side that locale would not. John >=20 > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From HKaplan@acmepacket.com Tue May 11 08:03:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114D328C236 for ; Tue, 11 May 2010 08:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEt54eVSckDF for ; Tue, 11 May 2010 08:03:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 66AE628C234 for ; Tue, 11 May 2010 08:03:24 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 11 May 2010 11:03:11 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 11 May 2010 11:03:11 -0400 From: Hadriel Kaplan To: "Parthasarathi R (partr)" , DISPATCH Date: Tue, 11 May 2010 11:02:33 -0400 Thread-Topic: [dispatch] Updates Session-ID charter Thread-Index: AcrwbbD3I0kahOGNSc2Kyg+gjSbVgAAfGqGAAAr6SIA= Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7BC0@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Updates Session-ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 15:03:27 -0000 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Tuesday, May 11, 2010 5:23 AM > To: Hadriel Kaplan; DISPATCH >=20 > When multiple B2BUA SIP entities exists, session-id may be used for > other services as well. The charter restricts only to troubleshooting > currently.=20 It's not so much "restricts", as much as that's the problem being solved. = I.e., it has a specific, defined problem and goal. =20 If you have specific use-cases in mind we can certainly talk about whether = they make sense for the charter. > The session-id has to be considered for other use cases as > well. For example, Media trombone (Media looping) in B2BUA(SBC) due to > call forward from previous B2BUA(3PCC) hop shall be identified by the > proposed session-id.=20 I'm not sure what you mean. I know what media tromboning is, but I have no= idea what that has to do with session-id. Session-id is a signaling-layer= header, not SDP. In practice you can't really "detect" media tromboning c= orrectly in the real world without looking at SDP. =20 You could detect signaling hairpin, but usually you want to do that for med= ia-layer reasons for which you need to look at SDP anyway. =20 You could detect signaling loop errors, assuming you're very careful to all= ow legitimate spirals... but that is logically equivalent to having a built= -in monitoring/troubleshooting device. There are actually several things y= ou can do with a session-id header which fall under that category, none of = which change the header in any way at a SIP layer. I don't think it's nece= ssary in the charter to itemize every use a monitoring device would have fo= r dialog/message correlation. > I think that it is better to find the other use > cases for session-id and include in the charter. Any specific reason for > restricting only for troubleshooting only? Generally we don't work that way - we don't create a solution and then look= for what problems it solves. :) =20 When I started the session-id draft I was actually trying to solve two prob= lems: troubleshooting, and dialog correlation/matching at the SIP level its= elf (e.g., for the dialog-event package and others). But I removed the sec= ond use-case based on discussions on the mailing list because it became evi= dent (to me at least) that we would (1) take a long time to converge on it = if ever, (2) it was a much harder problem to solve, and (3) it may not be s= olvable in the same way at all. -hadriel From laura.liess.dt@googlemail.com Tue May 11 13:36:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7713A6876 for ; Tue, 11 May 2010 13:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1961pNo1LpK for ; Tue, 11 May 2010 13:36:25 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 9697E3A67B5 for ; Tue, 11 May 2010 13:36:16 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so1113601fge.13 for ; Tue, 11 May 2010 13:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=fLiRPJ8F7Fsur7d2f4rWUDskLMtP6p3e+naJHh3Q+dE=; b=B0+Nrhg8q3GvniQ6S1rKGRq/UkOav97/S2tVU76evGwukooHfHQZprAghb7RXsOhx7 kO4NFBRkEyqL2CME5ivubI6nzyHRmSz5f5yjZFSAflLoHVVh4yopkaIpqFZ6kWdxXXaH K6Hpi9i0iyX6JcXyHbc1nLVTRkKIjLgv708/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=ifn72XIgnLyNu+fzsVEPz05s/g1WwMkIViDKzKyEzdp2xxDygJE9Zic9FNcbhWGcE3 eTc+sv5+Jz3SbuYlMSzZOhp7VAt1jHmRM0kS8gDKxJhdZTWci4wPtu6d0V4nTy4HeASD w1jkuNoTsouMJ+PBfkEtEWACfZ8yrdDzR+XEs= Received: by 10.86.124.4 with SMTP id w4mr12801907fgc.54.1273610162726; Tue, 11 May 2010 13:36:02 -0700 (PDT) Received: from LauraLiess (p54A7F50A.dip.t-dialin.net [84.167.245.10]) by mx.google.com with ESMTPS id e3sm937902fga.9.2010.05.11.13.35.58 (version=SSLv3 cipher=RC4-MD5); Tue, 11 May 2010 13:36:01 -0700 (PDT) From: Laura Liess To: "'Gonzalo Camarillo'" , References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE5418F.1010005@ericsson.com> In-Reply-To: <4BE5418F.1010005@ericsson.com> Date: Tue, 11 May 2010 22:35:51 +0200 Message-ID: <4be9bfb1.0338560a.1f23.4128@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrvTGoYP40eXnwsTTWhJb8KYvbW+wB589xw Content-Language: de Cc: 'Liess Laura' , 'Hadriel Kaplan' Subject: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 20:36:26 -0000 Gonzalo, I looked again at the mails and it seems to me that there is some misunderstanding here.=20 The identifier in the Alert-Info header contains information about what = the receiving UA should render to the user. We have two types of identifiers which can be used in the Alert-Info-header:=20 1) URIs which refer to a specific rendering (tone,text...). In this case = the specific rendering is selected by the sending UA and played to the = receiving UA's user. This is covered by the RFC 3261. =20 2) Names, semantic or non-semantic, are not covered by the RFC 3261. = They shouldbe covered by the Alert-Info URN. Using names instead of = references allows the receiving UA (or it's service provider) to select a specific rendering which is appropriate for its own user. Also in the = "non-semantic" case we are still dealing with names, e.g. urn:alert:duration:short and = this is not covered by the RFC 3261.=20 I think the text in the charter "... to exchange this type of alerting information in a semantic way." (first sentence in third paragraph) is confusing. I propose small changes to this paragraph: " These issues can be resolved with a mechanism for user agents to exchange rendering names instead of references to a particular = renderings. Rendering names can be resolved by the receiving UA according to local rules. For example, a user agent client instructed to inform its user = about a call waiting service can use the personalized renderings (tones or = text) that were previously configured by the user or the service provider's renderings." =20 The Alert-Info URN being about names, not only about semantic names, I = am not sure if the semantic/non-semantic issue belongs in the charter or in = the requirements. If it should be in the charter, what about replacing the = last sentence" Whenever possible, the Alert-Info URNs identifiers should be semantic." by the following = text: " When Alert-Info URNs are bound to a semantic supposed to be known in general, e.g. call waiting or French ringback tone, the name must = reflect this semantic.=20 The Alert-Info URN scheme also should allow non-semantic names, e.g. for ringing tones used in certain environments or when tones from legacy protocols must be translated to SIP at the edge of a network." Thanks a lot, Laura=20 =20 > -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im > Auftrag von Gonzalo Camarillo > Gesendet: Samstag, 8. Mai 2010 12:49 > An: Hadriel Kaplan > Cc: DISPATCH > Betreff: [dispatch] Status codes vs Alert-Info URNs WAS (Re: Alert = Info > Charter) >=20 > Hi, >=20 > this is the most important issue we have to resolve before I revise = the > charter again in order to get it reviewed by the IESG. Let me try and > summarize the discussions so far: >=20 > RFC3261 defines Alert-Info for non-semantic indications (e.g., you > should play this particular tone). Extending it to describe those > non-semantic indications (e.g., play a short tone followed by a long > one) seems not to be controversial. It seems we want to scope those > extensions to interworking situations, though. >=20 > As Hadriel indicates, semantic indications (i.e., your call is in a > queue) in SIP have been traditionally provided in status codes. If we > decided to use Alert-Info URNs instead, we would need to explain why = in > the charter. >=20 > To make this decision, we also need to agree on which messages need to > carry these semantic indications. It is only INVITEs and 180 = responses, > INVITEs and 1xx responses, or something else? >=20 > Another conversation we have had a few times in the context of = allowing > Reason header fields in responses is what happens when we carry two > semantic indicators about the status of a given call (e.g., the status > code and a URN, or the status code and another status code in a Reason > header field). Thinking of this can be useful in the context of > chartering this WG as well. >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > On 07/05/2010 7:42 PM, Hadriel Kaplan wrote: > > > >> -----Original Message----- > >> From: Alan Johnston [mailto:alan.b.johnston@gmail.com] > >> Sent: Friday, May 07, 2010 11:28 AM > >> To: Hadriel Kaplan > >> > >> The answer is that different entities generate the SIP response > >> code/Reason value and select the alerting tone. Alerting is = typically > >> chosen locally, either by a UA or by a proxy/PBX for the UA, so = this > >> can't use a common mechanism. > > > > Right, what you want is the device generating the response indicates > the condition, and the UAC receiving the response generates a locally- > mapped tone for that condition. I get that, and it makes a lot of = sense > to me. > > > > So ISTM what we want is for the device generating the SIP response = to > indicate a status code, which the UAC can map to whatever tones it = wants. > > > > The funny thing is we already have a way to do that. Two ways, in = fact: > the message's status-line status-code number, and the Reason header > value. > > > > I'm not actually proposing the SIP message response status-code be > expanded for this (both because of interop issues and because there > aren't enough digits in 18x to accommodate all conditions). But I = think > the Reason header isn't a bad choice. > > > > > >> Also, every vendor implements this today using Alert-Info URI > >> conventions. Unless you are arguing this is fundamentally broken > >> somehow, fixing this interop problem by standardizing a few URNs = seems > >> like a very clean solution. > > > > Actually, it *is* broken, in three ways (though they may all be > fixable): > > > > 1) You can't add more URN values later, because you don't know if = the > UAC understands the new URN. Compare this to a status-code model, = where > you can treat a new 187 code as a 180 if you don't understand the 187. > (although I suppose you could actually just make the URN a number = format, > or define the format to indicate a default as well, so you can get = this > property) > > > > 2) An Alert-Info header can only appear in 180 responses, and not = 182, > 183, etc. I suppose 3261 could be extended though to include it in = other > responses, though. > > > > 3) You can't deploy this new URN scheme in a backwards-compatible > fashion in practice, unless you have an indicator in the request which > states the UAC supports it. If you have such an indicator, you might = as > well put this in a Reason header instead and not have two different > headers to indicate the same status. And as it turns out, if you use = the > Reason header then I don't think you need an indicator in the request = to > begin with. > > > > > >> Sure, we could invent a grand unifying theory and mechanism, but = would > >> it get deployed? > > > > If there are real interop problems with Alert-Info, and people = really > want to fix them, and it's not much more work... then yes I think it > would. I'm not suggesting a lot of additional work, am I? > > > > I don't think using the Reason header alone instead of both is such = a > big change. Seems simpler to me, in fact. > > > > -hadriel > > _______________________________________________ > > 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 L.Liess@telekom.de Tue May 11 14:19:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567323A6A88 for ; Tue, 11 May 2010 14:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzAzTbCbcJya for ; Tue, 11 May 2010 14:19:25 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 9ADEF28C14A for ; Tue, 11 May 2010 14:17:18 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 11 May 2010 23:17:03 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 23:17:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 May 2010 23:17:02 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A004417BBF@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Alert Info Charter Thread-Index: AcrvTGoYP40eXnwsTTWhJb8KYvbW+wB589xwAAa5pSA= From: To: X-OriginalArrivalTime: 11 May 2010 21:17:03.0248 (UTC) FILETIME=[4D254900:01CAF14F] Subject: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 21:19:27 -0000 =20 Gonzalo, I looked again at the mails and it seems to me that there is some misunderstanding here.=20 The identifier in the Alert-Info header contains information about what = the receiving UA should render to the user. We have two types of identifiers which can be used in the Alert-Info-header:=20 1) URIs which refer to a specific rendering (tone,text...). In this case = the specific rendering is selected by the sending UA and played to the = receiving UA's user. This is covered by the RFC 3261. =20 2) Names, semantic or non-semantic, are not covered by the RFC 3261. = They shouldbe covered by the Alert-Info URN. Using names instead of = references allows the receiving UA (or it's service provider) to select a specific rendering which is appropriate for its own user. Also in the = "non-semantic" case we are still dealing with names, e.g. urn:alert:duration:short and = this is not covered by the RFC 3261.=20 I think the text in the charter "... to exchange this type of alerting information in a semantic way." (first sentence in third paragraph) is confusing. I propose small changes to this paragraph: " These issues can be resolved with a mechanism for user agents to exchange rendering names instead of references to a particular = renderings. Rendering names can be resolved by the receiving UA according to local rules. For example, a user agent client instructed to inform its user = about a call waiting service can use the personalized renderings (tones or = text) that were previously configured by the user or the service provider's renderings." =20 The Alert-Info URN being about names, not only about semantic names, I = am not sure if the semantic/non-semantic issue belongs in the charter or in = the requirements. If it should be in the charter, what about replacing the = last sentence" Whenever possible, the Alert-Info URNs identifiers should be semantic." by the following = text: " When Alert-Info URNs are bound to a semantic supposed to be known in general, e.g. call waiting or French ringback tone, the name must = reflect this semantic.=20 The Alert-Info URN scheme also should allow non-semantic names, e.g. for ringing tones used in certain environments or when tones from legacy protocols must be translated to SIP at the edge of a network." Thanks a lot, Laura=20 =20 > -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im > Auftrag von Gonzalo Camarillo > Gesendet: Samstag, 8. Mai 2010 12:49 > An: Hadriel Kaplan > Cc: DISPATCH > Betreff: [dispatch] Status codes vs Alert-Info URNs WAS (Re: Alert = Info > Charter) >=20 > Hi, >=20 > this is the most important issue we have to resolve before I revise = the > charter again in order to get it reviewed by the IESG. Let me try and > summarize the discussions so far: >=20 > RFC3261 defines Alert-Info for non-semantic indications (e.g., you > should play this particular tone). Extending it to describe those > non-semantic indications (e.g., play a short tone followed by a long > one) seems not to be controversial. It seems we want to scope those > extensions to interworking situations, though. >=20 > As Hadriel indicates, semantic indications (i.e., your call is in a > queue) in SIP have been traditionally provided in status codes. If we > decided to use Alert-Info URNs instead, we would need to explain why = in > the charter. >=20 > To make this decision, we also need to agree on which messages need to > carry these semantic indications. It is only INVITEs and 180 = responses, > INVITEs and 1xx responses, or something else? >=20 > Another conversation we have had a few times in the context of = allowing > Reason header fields in responses is what happens when we carry two > semantic indicators about the status of a given call (e.g., the status > code and a URN, or the status code and another status code in a Reason > header field). Thinking of this can be useful in the context of > chartering this WG as well. >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > On 07/05/2010 7:42 PM, Hadriel Kaplan wrote: > > > >> -----Original Message----- > >> From: Alan Johnston [mailto:alan.b.johnston@gmail.com] > >> Sent: Friday, May 07, 2010 11:28 AM > >> To: Hadriel Kaplan > >> > >> The answer is that different entities generate the SIP response > >> code/Reason value and select the alerting tone. Alerting is = typically > >> chosen locally, either by a UA or by a proxy/PBX for the UA, so = this > >> can't use a common mechanism. > > > > Right, what you want is the device generating the response indicates > the condition, and the UAC receiving the response generates a locally- > mapped tone for that condition. I get that, and it makes a lot of = sense > to me. > > > > So ISTM what we want is for the device generating the SIP response = to > indicate a status code, which the UAC can map to whatever tones it = wants. > > > > The funny thing is we already have a way to do that. Two ways, in = fact: > the message's status-line status-code number, and the Reason header > value. > > > > I'm not actually proposing the SIP message response status-code be > expanded for this (both because of interop issues and because there > aren't enough digits in 18x to accommodate all conditions). But I = think > the Reason header isn't a bad choice. > > > > > >> Also, every vendor implements this today using Alert-Info URI > >> conventions. Unless you are arguing this is fundamentally broken > >> somehow, fixing this interop problem by standardizing a few URNs = seems > >> like a very clean solution. > > > > Actually, it *is* broken, in three ways (though they may all be > fixable): > > > > 1) You can't add more URN values later, because you don't know if = the > UAC understands the new URN. Compare this to a status-code model, = where > you can treat a new 187 code as a 180 if you don't understand the 187. > (although I suppose you could actually just make the URN a number = format, > or define the format to indicate a default as well, so you can get = this > property) > > > > 2) An Alert-Info header can only appear in 180 responses, and not = 182, > 183, etc. I suppose 3261 could be extended though to include it in = other > responses, though. > > > > 3) You can't deploy this new URN scheme in a backwards-compatible > fashion in practice, unless you have an indicator in the request which > states the UAC supports it. If you have such an indicator, you might = as > well put this in a Reason header instead and not have two different > headers to indicate the same status. And as it turns out, if you use = the > Reason header then I don't think you need an indicator in the request = to > begin with. > > > > > >> Sure, we could invent a grand unifying theory and mechanism, but = would > >> it get deployed? > > > > If there are real interop problems with Alert-Info, and people = really > want to fix them, and it's not much more work... then yes I think it > would. I'm not suggesting a lot of additional work, am I? > > > > I don't think using the Reason header alone instead of both is such = a > big change. Seems simpler to me, in fact. > > > > -hadriel > > _______________________________________________ > > 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 john.elwell@siemens-enterprise.com Tue May 11 23:21:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871C83A6C84 for ; Tue, 11 May 2010 23:21:41 -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.359, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp7Ytsiwz4wg for ; Tue, 11 May 2010 23:21:40 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D0D9B3A68BA for ; Tue, 11 May 2010 23:21:31 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-141645; Wed, 12 May 2010 08:21:20 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 7472223F0278; Wed, 12 May 2010 08:21:20 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 12 May 2010 08:21:20 +0200 From: "Elwell, John" To: Laura Liess , 'Gonzalo Camarillo' , "dispatch@ietf.org" Date: Wed, 12 May 2010 08:21:17 +0200 Thread-Topic: Alert Info Charter Thread-Index: AcrvTGoYP40eXnwsTTWhJb8KYvbW+wB589xwABmlN4A= Message-ID: References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE5418F.1010005@ericsson.com> <4be9bfb1.0338560a.1f23.4128@mx.google.com> In-Reply-To: <4be9bfb1.0338560a.1f23.4128@mx.google.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Liess Laura' , 'Hadriel Kaplan' Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 06:21:41 -0000 This works for me. I think we have had enough charter-bashing and really sh= ould get on and form the group and work on refining the requirements in Lau= ra's I-D. John=20 > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com]=20 > Sent: 11 May 2010 21:36 > To: 'Gonzalo Camarillo'; dispatch@ietf.org > Cc: 'Paul Kyzivat'; 'Hadriel Kaplan'; Elwell, John; 'Liess Laura' > Subject: Alert Info Charter >=20 > Gonzalo, >=20 > I looked again at the mails and it seems to me that there is some > misunderstanding here.=20 >=20 > The identifier in the Alert-Info header contains information=20 > about what the > receiving UA should render to the user. We have two types of=20 > identifiers > which can be used in the Alert-Info-header:=20 >=20 > 1) URIs which refer to a specific rendering (tone,text...).=20 > In this case the > specific rendering is selected by the sending UA and played=20 > to the receiving > UA's user. This is covered by the RFC 3261. =20 > 2) Names, semantic or non-semantic, are not covered by the=20 > RFC 3261. They > shouldbe covered by the Alert-Info URN. Using names instead=20 > of references > allows the receiving UA (or it's service provider) to select=20 > a specific > rendering which is appropriate for its own user. Also in the=20 > "non-semantic" > case we are still dealing with names, e.g.=20 > urn:alert:duration:short and this > is not covered by the RFC 3261.=20 >=20 > I think the text in the charter "... to exchange this type of alerting > information in a semantic way." (first sentence in third paragraph) is > confusing. I propose small changes to this paragraph: >=20 > " These issues can be resolved with a mechanism for user agents to > exchange rendering names instead of references to a=20 > particular renderings. > Rendering names can be resolved by the receiving UA according to local > rules. For example, a user agent client instructed to inform=20 > its user about > a call waiting service can use the personalized renderings=20 > (tones or text) > that were previously configured by the user or the service provider's > renderings." =20 >=20 > The Alert-Info URN being about names, not only about semantic=20 > names, I am > not sure if the semantic/non-semantic issue belongs in the=20 > charter or in the > requirements. If it should be in the charter, what about=20 > replacing the last > sentence" Whenever possible, > the Alert-Info URNs identifiers should be semantic." by the=20 > following text: > " When Alert-Info URNs are bound to a semantic supposed to=20 > be known in > general, e.g. call waiting or French ringback tone, the name=20 > must reflect > this semantic.=20 > The Alert-Info URN scheme also should allow non-semantic=20 > names, e.g. for > ringing tones used in certain environments or when tones from legacy > protocols must be translated to SIP at the edge of a network." >=20 > Thanks a lot, > Laura=20 >=20 > =20 >=20 >=20 >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im > > Auftrag von Gonzalo Camarillo > > Gesendet: Samstag, 8. Mai 2010 12:49 > > An: Hadriel Kaplan > > Cc: DISPATCH > > Betreff: [dispatch] Status codes vs Alert-Info URNs WAS=20 > (Re: Alert Info > > Charter) > >=20 > > Hi, > >=20 > > this is the most important issue we have to resolve before=20 > I revise the > > charter again in order to get it reviewed by the IESG. Let=20 > me try and > > summarize the discussions so far: > >=20 > > RFC3261 defines Alert-Info for non-semantic indications (e.g., you > > should play this particular tone). Extending it to describe those > > non-semantic indications (e.g., play a short tone followed by a long > > one) seems not to be controversial. It seems we want to scope those > > extensions to interworking situations, though. > >=20 > > As Hadriel indicates, semantic indications (i.e., your call is in a > > queue) in SIP have been traditionally provided in status=20 > codes. If we > > decided to use Alert-Info URNs instead, we would need to=20 > explain why in > > the charter. > >=20 > > To make this decision, we also need to agree on which=20 > messages need to > > carry these semantic indications. It is only INVITEs and=20 > 180 responses, > > INVITEs and 1xx responses, or something else? > >=20 > > Another conversation we have had a few times in the context=20 > of allowing > > Reason header fields in responses is what happens when we carry two > > semantic indicators about the status of a given call (e.g.,=20 > the status > > code and a URN, or the status code and another status code=20 > in a Reason > > header field). Thinking of this can be useful in the context of > > chartering this WG as well. > >=20 > > Thanks, > >=20 > > Gonzalo > >=20 > >=20 > > On 07/05/2010 7:42 PM, Hadriel Kaplan wrote: > > > > > >> -----Original Message----- > > >> From: Alan Johnston [mailto:alan.b.johnston@gmail.com] > > >> Sent: Friday, May 07, 2010 11:28 AM > > >> To: Hadriel Kaplan > > >> > > >> The answer is that different entities generate the SIP response > > >> code/Reason value and select the alerting tone. =20 > Alerting is typically > > >> chosen locally, either by a UA or by a proxy/PBX for the=20 > UA, so this > > >> can't use a common mechanism. > > > > > > Right, what you want is the device generating the=20 > response indicates > > the condition, and the UAC receiving the response generates=20 > a locally- > > mapped tone for that condition. I get that, and it makes a=20 > lot of sense > > to me. > > > > > > So ISTM what we want is for the device generating the SIP=20 > response to > > indicate a status code, which the UAC can map to whatever=20 > tones it wants. > > > > > > The funny thing is we already have a way to do that. Two=20 > ways, in fact: > > the message's status-line status-code number, and the Reason header > > value. > > > > > > I'm not actually proposing the SIP message response status-code be > > expanded for this (both because of interop issues and because there > > aren't enough digits in 18x to accommodate all conditions).=20 > But I think > > the Reason header isn't a bad choice. > > > > > > > > >> Also, every vendor implements this today using Alert-Info URI > > >> conventions. Unless you are arguing this is fundamentally broken > > >> somehow, fixing this interop problem by standardizing a=20 > few URNs seems > > >> like a very clean solution. > > > > > > Actually, it *is* broken, in three ways (though they may all be > > fixable): > > > > > > 1) You can't add more URN values later, because you don't=20 > know if the > > UAC understands the new URN. Compare this to a status-code=20 > model, where > > you can treat a new 187 code as a 180 if you don't=20 > understand the 187. > > (although I suppose you could actually just make the URN a=20 > number format, > > or define the format to indicate a default as well, so you=20 > can get this > > property) > > > > > > 2) An Alert-Info header can only appear in 180 responses,=20 > and not 182, > > 183, etc. I suppose 3261 could be extended though to=20 > include it in other > > responses, though. > > > > > > 3) You can't deploy this new URN scheme in a backwards-compatible > > fashion in practice, unless you have an indicator in the=20 > request which > > states the UAC supports it. If you have such an indicator,=20 > you might as > > well put this in a Reason header instead and not have two different > > headers to indicate the same status. And as it turns out,=20 > if you use the > > Reason header then I don't think you need an indicator in=20 > the request to > > begin with. > > > > > > > > >> Sure, we could invent a grand unifying theory and=20 > mechanism, but would > > >> it get deployed? > > > > > > If there are real interop problems with Alert-Info, and=20 > people really > > want to fix them, and it's not much more work... then yes I think it > > would. I'm not suggesting a lot of additional work, am I? > > > > > > I don't think using the Reason header alone instead of=20 > both is such a > > big change. Seems simpler to me, in fact. > > > > > > -hadriel > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 > = From fluffy@cisco.com Wed May 12 05:36:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21A23A6B5A for ; Wed, 12 May 2010 05:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.708 X-Spam-Level: X-Spam-Status: No, score=-108.708 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWZBxQYY4xPF for ; Wed, 12 May 2010 05:36:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 853B53A6B74 for ; Wed, 12 May 2010 05:34:56 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="528547796" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 12 May 2010 12:34:46 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o4CCYjT9024185; Wed, 12 May 2010 12:34:45 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <6DC49EE7-B148-4EE5-B004-5763EEE42B05@softarmor.com> Date: Wed, 12 May 2010 06:34:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CAF342FE1EE34EAC8FB19B765914000D763886@SABRE.InterDigital.com> <4BA0EC7D.6060900@cisco.com> <6DC49EE7-B148-4EE5-B004-5763EEE42B05@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1078) Cc: DISPATCH , "Patel, Milan" Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 12:36:44 -0000 I just like to add I agree with the points Dean and Paul are making here On Mar 17, 2010, at 6:26 PM, Dean Willis wrote: >=20 > On Mar 17, 2010, at 9:51 AM, Paul Kyzivat wrote: >>>=20 >>=20 >> For those that truly describe properties of a URI (if there are any = of those), you may be right. >>=20 >> For those that describe properties of a call, if they were carried as = part of the call rather than as properties of the URI, then it wouldn't = matter if the URI is sip or tel. >>=20 >> But in reality, even the properties that describe the caller aren't = properly properties of the caller's URI. For instance, in principle the = same originating "number" might be used by one phone in a prison and = another in a police station. >>=20 >> ISTM that piggybacking these on the TEL uri is simply a convenient = "ploy", because both phone numbers and these properties are managed by = the ITU. >=20 >=20 > Let's run through them: >=20 > ordinary: the caller has been identified and has no special features. = At least not on this call; they might have some on another call, or = might re-INVITE midstream if they change their mind, so don't count in = it. Property of "call", not "caller". >=20 > Test: This is a test call. If the same guy calls you in 5 minutes, it = might not be a test. Property of "call", not "caller". >=20 > operator: This call was generated by an operator position. Ostensibly, = the caller is an operator? Probably a property of the "caller". One = could envision putting this info in RFC 4474. >=20 > payphone: The calling station is a payphone. Again, a property of the = caller. >=20 > unknown: I don't know what this means. It's probably got nothing to do = with the caller. >=20 > mobile-hplmn/vplmn: The call was generated by a mobile device = (property of the calling device, anyhow) in it's home/visited plmn = (property of this call; doesn't persist if you call it back). >=20 > Some of the ANI II digits are things that are properties of a caller. = Some, like Code 25, are attributes of call and caller. Many seem to = specify specifc route-handling FOR THIS CALL, like not stripping off a = leading "63". >=20 > So I'm not sure this is a useful categorization. >=20 > I'm pretty sure I don't want a "Type 67" modifier attached to A SIP = URI. I'm also sure that most of these parameters make no sense on a TEL = URI when that URI is used as a Request-URI; they don't route a call. = They kindof make sense in a From: URI (or an RFC 4474 Identity header = field), but they lack reversibility: one couldn't store this From: in a = phone book, then turn around and call it back 5 minutes later. = Consequently, the called party MUST understand them, or bad things will = happen. This calls for an option tag, which is messy. >=20 > But I'm at a loss for proposing a better mechanism. Perhaps we could = follow the SIP-T method and define another extension header field = carried in the request? >=20 >=20 > -- > Dean >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed May 12 05:43:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94F83A6B61 for ; Wed, 12 May 2010 05:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.652 X-Spam-Level: X-Spam-Status: No, score=-108.652 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfeUSCYUPfwt for ; Wed, 12 May 2010 05:43:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8A0B33A68A8 for ; Wed, 12 May 2010 05:42:44 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADM/6kurR7Hu/2dsb2JhbACeJ3GgJ5lrglCCQgSDQA X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="255393981" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 12 May 2010 12:42:34 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4CCgXvU013066; Wed, 12 May 2010 12:42:33 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4BE021CA.5060807@ericsson.com> Date: Wed, 12 May 2010 06:42:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <884BF5B6-72E2-4D47-ACD3-46A1E9BEEDD7@cisco.com> References: <4B670809.2010903@nostrum.com> <4BE021CA.5060807@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1078) Cc: IETF Dispatch Subject: Re: [dispatch] draft-mdolly-dispatch-oma-push X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 12:43:54 -0000 I sort of assumed from the Liaison that they did not want a response. If = there is any key feedback to send, it is that the IETF has typically = pushed back on drafts that wold change the review process for defining = future Event packages - particularly approaches that changed i for one = SDO and not for other SDOs. I'd be happy to send them a pointer to the = RAI Review but I suspect they already have that.=20 Thoughts on what we need to send if anything? Thanks,=20 Cullen On May 4, 2010, at 7:31 AM, Gonzalo Camarillo wrote: > Hi, >=20 > I have not seen any activity on this for a relatively long time. Note > also that we received the LS below some time ago: >=20 > https://datatracker.ietf.org/documents/LIAISON/file726.doc >=20 > Where are we with this? >=20 > Thanks, >=20 > Gonzalo >=20 > On 01/02/2010 6:57 PM, Adam Roach wrote: >> The area directors for RAI asked me to review >> draft-mdolly-dispatch-oma-push, specifically as they relate to the >> ongoing revisions to RFCs 3265 and 3427. >>=20 >> While there are some relatively minor issues with some of the 3265 >> concepts used in this document, there is an overarching structural = issue >> that needs to be addressed. >>=20 >> By my reading, what this document seeks to do is open a door for OMA = to >> create new event packages without requiring any IETF review (and, = even >> if such is not the intent, it would certainly be the outcome). This = is >> achieved by using an event package type of "oma-push," and then using = a >> new "Event" header field parameter of "event-app-id" to indicate the >> actual event package. In the language of object-oriented programming, >> this draft seeks to define an event package that is little more than = a >> fa=E7ade to wrap RFC 3265, with the only substantive difference being >> whether IETF review is required. >>=20 >> The nature of this proposed "event package" as a framework (as = opposed >> to an actual event package as RFC 3265 defines that term) is revealed >> substantially by the contents of two of its sections: section 10 and >> section 12. In section 10, the draft tacitly indicates that it is to = be >> applied to a broad range of events: >>=20 >> The durations of push event subscriptions, and in general the >> conditions under which they are terminated, vary widely with the >> nature of the applications as they are assumed to be application- >> specific criteria. >>=20 >>=20 >> Even more tellingly, section 12 simply indicates that the = notification >> bodies can be carried either inline or via indirection, and gives no >> actual definition of body type or of body syntax. By contrast, = consider >> the body of published event packages: >>=20 >> * RFC4575 defines a new application/conference-info+xml for NOTIFY >> * RFC5362 defines a new application/resource-lists+xml for NOTIFY >> * RFC4235 defines a new application/dialog-info+xml for NOTIFY >> * RFC4730 defined a new application/kpml-request+xml for NOTIFY >> * RFC3842 defines a new appcliation/simple-message-summary for = NOTIFY >> * RFC4354 defines a new application/poc-settings+xml for NOTIFY >> * RFC3856 uses application/pidf+xml (which was designed for this >> purpose) for NOTIFY >> * RFC3680 defines a new application/reginfo+xml for NOTIFY >> * RFC3515 uses message/sipfrag to convey the state of the = indicated >> resource in a NOTIFY >> * RFC3910 defines a new application/spirits-event+xml for NOTIFY >> * RFC3857 defines a new application/watcherinfo+xml for NOTIFY >>=20 >>=20 >> A legitimate event package would indicate specifically and completely >> what state is to be conveyed. It will also define or normatively >> reference a formally-defined syntax for conveying the state. The fact >> that the draft cannot provide such a description of state and a = syntax >> for conveying the state is a good indication that it is not an event >> package, but actually an attempt to wrap RFC3265 in a parallel = framework. >>=20 >> If the overall mechanism proposed by the current document is approved = as >> an IETF-sanctioned event package, the net result will be a loophole = that >> effectively eliminates section 4.1 of rfc3427bis entirely. >>=20 >> By my reading of subject matter covered by this document -- and with = the >> caveat that I am not familiar with any of the OMA applications that = the >> mechanism is intended to enable -- the only path forward that both >> achieves the goals stated in this document's problem statement and >> conforms to the restrictions put forth in RFC 3427 (and its draft >> successor) is to define each of the applications as a new event = package. >> Unless I misunderstand the mechanism defined in OMA-TS-SIP_PUSH, = there >> appear to be approximately 23 such applications presently defined = [1]. >> For the sake of expediency, it may be sensible to have a single = document >> that defines the RFC3265 event packages for all of them -- that is, a >> single draft with 23 distinct copies of the sections required by = section >> 4.4 of RFC3265. >>=20 >> /a >>=20 >> [1] A (partial?) list of defined applications appears to be published >> here: http://www.wapforum.org/wina/push-app-id.htm >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed May 12 06:06:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1253928C156 for ; Wed, 12 May 2010 06:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.175 X-Spam-Level: X-Spam-Status: No, score=-109.175 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox30HsHhMgPf for ; Wed, 12 May 2010 06:05:59 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 406553A6C9E for ; Wed, 12 May 2010 06:03:35 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGtD6kurR7H+/2dsb2JhbACeJ3GgJplogm8IghsEg0A X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="128708042" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 12 May 2010 13:03:25 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4CD3OeE018693; Wed, 12 May 2010 13:03:24 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> Date: Wed, 12 May 2010 07:03:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <69EB5FD3-F3CE-463B-A401-3A501F586747@cisco.com> References: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1078) Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 13:06:01 -0000 So I think this could still use a bit more. This describes a solution, = which is fine, but not the problem.=20 What is that being correlated? What are the semantic meaning of two call = legs being correlated? I'm trying to get at if phone A, B and C are all = in talking on the same conference call are they correlated? what if A = and B are in a breakout session? If A calls B and B puts A on hold them = B calls C, are they correlated? If B now conferences all they are they = correlated? If A is calls B and starts one of the many types of transfer = to C? I'm trying to get at what does it mean for two UA's to be in the = same "session" or "message-flow" and who needs to know that and why. If = the only purpose is troubleshooting, the charter should say that. Can a = given SIP call leg be in multiple sessions at once? is correlation a = transitive property?=20 I think we need to get a little crisper about what the problem is in the = charter or this WG is going to have a hard time moving forward. Without = some guiding architecture on this, I think the WG will find it very hard = to produce anything useful. I think we should also consider if we want = this WG to have a separate task of fixing the issues with Call-ID = brought up in Hadriels other draft.=20 On May 8, 2010, at 2:35 PM, Hadriel Kaplan wrote: > Howdy, > I have asked the DISPATCH chairs what to do with Session-ID, given the = feedback I received to make it a standards-track vs. individual = informational submission. There is no obvious current WG for this work, = so they asked me to post a strawman charter proposal, which I propose as = follows: >=20 >=20 > SIP Signaling-COmmunication Troubleshooting with Correlation Header = (SIPSCOTCH) Charter: > ---------------------------------- > The SIPSCOTCH working group is chartered to define a mechanism that = allows operators and monitoring equipment to correlate SIP messages and = dialogs of the same higher-level end-to-end "session" or "message-flow". = In particular, the mechanism must be able to allow such correlation = across SIP B2BUAs of as many functional types as possible, such as = Application Servers, Softswitches, PBXs, SBCs, etc. >=20 > Although other solutions may be possible, this working group will = focus on defining a new SIP Header field for such a purpose, similar to = the Call-ID header field, in order to provide a simple, easily = deployable mechanism which can work across SIP domains. The SIP Call-ID = header field value itself is not usable for such correlation, because = many B2BUAs must create a new Call-ID value on their UAC "side" in order = to function properly, and to comply with the rules of RFC 3261.=20 >=20 > It should be noted that certain SIP B2BUAs perform a "topology-hiding" = function, as described in RFC 5853. The working group will take such = functions into account for the correlation mechanism, as well as provide = guidance for implementers of the mechanism to avoid triggering such a = function for the mechanism's header field value. >=20 > Lastly, although in certain environments such a mechanism may be = usable for dialog correlation in SIP state machines, it is not the goal = of this working group to address that usage. >=20 > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dec 2010 - New header specification to IESG (PS) >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed May 12 06:13:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D79CC3A68BD for ; Wed, 12 May 2010 06:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.916 X-Spam-Level: X-Spam-Status: No, score=-109.916 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUFouLl1ovLH for ; Wed, 12 May 2010 06:13:10 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AD60B28C16C for ; Wed, 12 May 2010 06:10:00 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMJF6kurR7Hu/2dsb2JhbACeJ3GgO5lphRIEg0A X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="196480397" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 12 May 2010 13:09:50 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4CD9nq2006069; Wed, 12 May 2010 13:09:50 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4BE3F08B.7000006@ericsson.com> Date: Wed, 12 May 2010 07:09:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4EE77A9E-E2EB-4534-8911-BC5266131513@cisco.com> References: <4BE3F08B.7000006@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1078) Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 13:13:12 -0000 I'm a bit concerned about the discussion of the call waiting tones. = Assuming we had a "call waiting tone" URN we could put in Alert-Info, = how would this work? when would it be used - I'm wondering what message = in what dialog would cary it? On May 7, 2010, at 4:50 AM, Gonzalo Camarillo wrote: > Folks, >=20 > I have make a few editorial changes to the Alert Info charter proposal > in order to clarify what we want to do (see attachment). Please, let = me > know if you have some comments. I would like to get the whole IESG to > review it relatively soon. >=20 > One thing that still needs a bit of work is the last sentence of the > charter: "Whenever possible, the Alert-Info URNs identifiers should be > semantic." >=20 > The whole charter motivates the use of semantic identifiers but then, = in > the last sentence, it opens the door to non-semantic identifiers = (e.g., > urn:alert:duration:short). >=20 > We need to either focus on working on semantic identifiers only or add > more text explaining the reasons why we also want to define non = semantic > identifiers. Opinions? >=20 > Thanks, >=20 > Gonzalo >=20 > = _________________________________________= ______ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From gao.yang2@zte.com.cn Wed May 12 06:25:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6238D3A6CE0 for ; Wed, 12 May 2010 06:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.331 X-Spam-Level: X-Spam-Status: No, score=-97.331 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV1I41GQlAyh for ; Wed, 12 May 2010 06:25:52 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 3666728C1DE for ; Wed, 12 May 2010 06:16:32 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 36887992332426; Wed, 12 May 2010 21:11:00 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.2996484002; Wed, 12 May 2010 21:16:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4CDGUXj020568; Wed, 12 May 2010 21:16:30 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <69EB5FD3-F3CE-463B-A401-3A501F586747@cisco.com> To: Cullen Jennings MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 12 May 2010 21:13:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-12 21:16:15, Serialize complete at 2010-05-12 21:16:15 Content-Type: multipart/alternative; boundary="=_alternative 0048DDD348257721_=" X-MAIL: mse2.zte.com.cn o4CDGUXj020568 Cc: DISPATCH , Hadriel Kaplan Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 13:25:53 -0000 This is a multipart message in MIME format. --=_alternative 0048DDD348257721_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 KzENCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAw MTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWls IDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQoNCg0KDQpDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBjaXNjby5jb20+IA0Kt6K8/sjLOiAg ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZw0KMjAxMC0wNS0xMiAyMTowMw0KDQrK1bz+yMsNCkhh ZHJpZWwgS2FwbGFuIDxIS2FwbGFuQGFjbWVwYWNrZXQuY29tPg0Ks63LzQ0KRElTUEFUQ0ggPGRp c3BhdGNoQGlldGYub3JnPg0K1vfM4g0KUmU6IFtkaXNwYXRjaF0gU2Vzc2lvbi1JRCBjaGFydGVy IHByb3Bvc2FsDQoNCg0KDQoNCg0KDQoNClNvIEkgdGhpbmsgdGhpcyBjb3VsZCBzdGlsbCB1c2Ug YSBiaXQgbW9yZS4gVGhpcyBkZXNjcmliZXMgYSBzb2x1dGlvbiwgDQp3aGljaCBpcyBmaW5lLCBi dXQgbm90IHRoZSBwcm9ibGVtLiANCg0KV2hhdCBpcyB0aGF0IGJlaW5nIGNvcnJlbGF0ZWQ/IFdo YXQgYXJlIHRoZSBzZW1hbnRpYyBtZWFuaW5nIG9mIHR3byBjYWxsIA0KbGVncyBiZWluZyBjb3Jy ZWxhdGVkPyBJJ20gdHJ5aW5nIHRvIGdldCBhdCBpZiBwaG9uZSBBLCBCIGFuZCBDIGFyZSBhbGwg aW4gDQp0YWxraW5nIG9uIHRoZSBzYW1lIGNvbmZlcmVuY2UgY2FsbCBhcmUgdGhleSBjb3JyZWxh dGVkPyB3aGF0IGlmIEEgYW5kIEIgDQphcmUgaW4gYSBicmVha291dCBzZXNzaW9uPyBJZiBBIGNh bGxzIEIgYW5kIEIgcHV0cyBBIG9uIGhvbGQgdGhlbSBCIGNhbGxzIA0KQywgYXJlIHRoZXkgY29y cmVsYXRlZD8gSWYgQiBub3cgY29uZmVyZW5jZXMgYWxsIHRoZXkgYXJlIHRoZXkgY29ycmVsYXRl ZD8gDQpJZiBBIGlzIGNhbGxzIEIgYW5kIHN0YXJ0cyBvbmUgb2YgdGhlIG1hbnkgdHlwZXMgb2Yg dHJhbnNmZXIgdG8gQz8gIEknbSANCnRyeWluZyB0byBnZXQgYXQgd2hhdCBkb2VzIGl0IG1lYW4g Zm9yIHR3byBVQSdzIHRvIGJlIGluIHRoZSBzYW1lIA0KInNlc3Npb24iIG9yICJtZXNzYWdlLWZs b3ciIGFuZCB3aG8gbmVlZHMgdG8ga25vdyB0aGF0IGFuZCB3aHkuIElmIHRoZSANCm9ubHkgcHVy cG9zZSBpcyB0cm91Ymxlc2hvb3RpbmcsIHRoZSBjaGFydGVyIHNob3VsZCBzYXkgdGhhdC4gQ2Fu IGEgZ2l2ZW4gDQpTSVAgY2FsbCBsZWcgYmUgaW4gbXVsdGlwbGUgc2Vzc2lvbnMgYXQgb25jZT8g aXMgY29ycmVsYXRpb24gYSB0cmFuc2l0aXZlIA0KcHJvcGVydHk/IA0KDQpJIHRoaW5rIHdlIG5l ZWQgdG8gZ2V0IGEgbGl0dGxlIGNyaXNwZXIgYWJvdXQgd2hhdCB0aGUgcHJvYmxlbSBpcyBpbiB0 aGUgDQpjaGFydGVyIG9yIHRoaXMgV0cgaXMgZ29pbmcgdG8gaGF2ZSBhIGhhcmQgdGltZSBtb3Zp bmcgZm9yd2FyZC4gIFdpdGhvdXQgDQpzb21lIGd1aWRpbmcgYXJjaGl0ZWN0dXJlIG9uIHRoaXMs IEkgdGhpbmsgdGhlIFdHIHdpbGwgZmluZCBpdCB2ZXJ5IGhhcmQgDQp0byBwcm9kdWNlIGFueXRo aW5nIHVzZWZ1bC4gSSB0aGluayB3ZSBzaG91bGQgYWxzbyBjb25zaWRlciBpZiB3ZSB3YW50IA0K dGhpcyBXRyB0byBoYXZlIGEgc2VwYXJhdGUgdGFzayBvZiBmaXhpbmcgdGhlIGlzc3VlcyB3aXRo IENhbGwtSUQgYnJvdWdodCANCnVwIGluIEhhZHJpZWxzIG90aGVyIGRyYWZ0LiANCg0KDQoNCk9u IE1heSA4LCAyMDEwLCBhdCAyOjM1IFBNLCBIYWRyaWVsIEthcGxhbiB3cm90ZToNCg0KPiBIb3dk eSwNCj4gSSBoYXZlIGFza2VkIHRoZSBESVNQQVRDSCBjaGFpcnMgd2hhdCB0byBkbyB3aXRoIFNl c3Npb24tSUQsIGdpdmVuIHRoZSANCmZlZWRiYWNrIEkgcmVjZWl2ZWQgdG8gbWFrZSBpdCBhIHN0 YW5kYXJkcy10cmFjayB2cy4gaW5kaXZpZHVhbCANCmluZm9ybWF0aW9uYWwgc3VibWlzc2lvbi4g IFRoZXJlIGlzIG5vIG9idmlvdXMgY3VycmVudCBXRyBmb3IgdGhpcyB3b3JrLCANCnNvIHRoZXkg YXNrZWQgbWUgdG8gcG9zdCBhIHN0cmF3bWFuIGNoYXJ0ZXIgcHJvcG9zYWwsIHdoaWNoIEkgcHJv cG9zZSBhcyANCmZvbGxvd3M6DQo+IA0KPiANCj4gU0lQIFNpZ25hbGluZy1DT21tdW5pY2F0aW9u IFRyb3VibGVzaG9vdGluZyB3aXRoIENvcnJlbGF0aW9uIEhlYWRlciANCihTSVBTQ09UQ0gpIENo YXJ0ZXI6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVGhlIFNJUFND T1RDSCB3b3JraW5nIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZWZpbmUgYSBtZWNoYW5pc20gdGhh dCANCmFsbG93cyBvcGVyYXRvcnMgYW5kIG1vbml0b3JpbmcgZXF1aXBtZW50IHRvIGNvcnJlbGF0 ZSBTSVAgbWVzc2FnZXMgYW5kIA0KZGlhbG9ncyBvZiB0aGUgc2FtZSBoaWdoZXItbGV2ZWwgZW5k LXRvLWVuZCAic2Vzc2lvbiIgb3IgIm1lc3NhZ2UtZmxvdyIuIA0KSW4gcGFydGljdWxhciwgdGhl IG1lY2hhbmlzbSBtdXN0IGJlIGFibGUgdG8gYWxsb3cgc3VjaCBjb3JyZWxhdGlvbiBhY3Jvc3Mg DQpTSVAgQjJCVUFzIG9mIGFzIG1hbnkgZnVuY3Rpb25hbCB0eXBlcyBhcyBwb3NzaWJsZSwgc3Vj aCBhcyBBcHBsaWNhdGlvbiANClNlcnZlcnMsIFNvZnRzd2l0Y2hlcywgUEJYcywgU0JDcywgZXRj Lg0KPiANCj4gQWx0aG91Z2ggb3RoZXIgc29sdXRpb25zIG1heSBiZSBwb3NzaWJsZSwgdGhpcyB3 b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMgDQpvbiBkZWZpbmluZyBhIG5ldyBTSVAgSGVhZGVyIGZp ZWxkIGZvciBzdWNoIGEgcHVycG9zZSwgc2ltaWxhciB0byB0aGUgDQpDYWxsLUlEIGhlYWRlciBm aWVsZCwgaW4gb3JkZXIgdG8gcHJvdmlkZSBhIHNpbXBsZSwgZWFzaWx5IGRlcGxveWFibGUgDQpt ZWNoYW5pc20gd2hpY2ggY2FuIHdvcmsgYWNyb3NzIFNJUCBkb21haW5zLiBUaGUgU0lQIENhbGwt SUQgaGVhZGVyIGZpZWxkIA0KdmFsdWUgaXRzZWxmIGlzIG5vdCB1c2FibGUgZm9yIHN1Y2ggY29y cmVsYXRpb24sIGJlY2F1c2UgbWFueSBCMkJVQXMgbXVzdCANCmNyZWF0ZSBhIG5ldyBDYWxsLUlE IHZhbHVlIG9uIHRoZWlyIFVBQyAic2lkZSIgaW4gb3JkZXIgdG8gZnVuY3Rpb24gDQpwcm9wZXJs eSwgYW5kIHRvIGNvbXBseSB3aXRoIHRoZSBydWxlcyBvZiBSRkMgMzI2MS4gDQo+IA0KPiBJdCBz aG91bGQgYmUgbm90ZWQgdGhhdCBjZXJ0YWluIFNJUCBCMkJVQXMgcGVyZm9ybSBhICJ0b3BvbG9n eS1oaWRpbmciIA0KZnVuY3Rpb24sIGFzIGRlc2NyaWJlZCBpbiBSRkMgNTg1My4gIFRoZSB3b3Jr aW5nIGdyb3VwIHdpbGwgdGFrZSBzdWNoIA0KZnVuY3Rpb25zIGludG8gYWNjb3VudCBmb3IgdGhl IGNvcnJlbGF0aW9uIG1lY2hhbmlzbSwgYXMgd2VsbCBhcyBwcm92aWRlIA0KZ3VpZGFuY2UgZm9y IGltcGxlbWVudGVycyBvZiB0aGUgbWVjaGFuaXNtIHRvIGF2b2lkIHRyaWdnZXJpbmcgc3VjaCBh IA0KZnVuY3Rpb24gZm9yIHRoZSBtZWNoYW5pc20ncyBoZWFkZXIgZmllbGQgdmFsdWUuDQo+IA0K PiBMYXN0bHksIGFsdGhvdWdoIGluIGNlcnRhaW4gZW52aXJvbm1lbnRzIHN1Y2ggYSBtZWNoYW5p c20gbWF5IGJlIHVzYWJsZSANCmZvciBkaWFsb2cgY29ycmVsYXRpb24gaW4gU0lQIHN0YXRlIG1h Y2hpbmVzLCBpdCBpcyBub3QgdGhlIGdvYWwgb2YgdGhpcyANCndvcmtpbmcgZ3JvdXAgdG8gYWRk cmVzcyB0aGF0IHVzYWdlLg0KPiANCj4gR29hbHMgYW5kIE1pbGVzdG9uZXMNCj4gPT09PT09PT09 PT09PT09PT09PT0NCj4gRGVjIDIwMTAgLSBOZXcgaGVhZGVyIHNwZWNpZmljYXRpb24gdG8gSUVT RyAoUFMpDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KDQoNCkN1bGxlbiBK ZW5uaW5ncw0KRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzoNCmh0dHA6Ly93 d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRt bA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h aWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMg bWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92 ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVk IHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJz Lg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZp ZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRo ZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ug b2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQg Zm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0048DDD348257721_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPisxPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJz cDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJy Pg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+PGI+Q3VsbGVuIEplbm5pbmdzICZsdDtmbHVmZnlAY2lzY28uY29tJmd0Ozwv Yj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAm bmJzcDtkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjIwMTAtMDUtMTIgMjE6MDM8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+SGFkcmllbCBLYXBsYW4gJmx0O0hLYXBs YW5AYWNtZXBhY2tldC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5ESVNQQVRDSCAmbHQ7ZGlz cGF0Y2hAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW2Rpc3BhdGNoXSBTZXNz aW9uLUlEIGNoYXJ0ZXIgcHJvcG9zYWw8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NClNvIEkgdGhpbmsgdGhpcyBjb3VsZCBzdGls bCB1c2UgYSBiaXQgbW9yZS4gVGhpcyBkZXNjcmliZXMgYSBzb2x1dGlvbiwNCndoaWNoIGlzIGZp bmUsIGJ1dCBub3QgdGhlIHByb2JsZW0uIDxicj4NCjxicj4NCldoYXQgaXMgdGhhdCBiZWluZyBj b3JyZWxhdGVkPyBXaGF0IGFyZSB0aGUgc2VtYW50aWMgbWVhbmluZyBvZiB0d28gY2FsbA0KbGVn cyBiZWluZyBjb3JyZWxhdGVkPyBJJ20gdHJ5aW5nIHRvIGdldCBhdCBpZiBwaG9uZSBBLCBCIGFu ZCBDIGFyZSBhbGwNCmluIHRhbGtpbmcgb24gdGhlIHNhbWUgY29uZmVyZW5jZSBjYWxsIGFyZSB0 aGV5IGNvcnJlbGF0ZWQ/IHdoYXQgaWYgQSBhbmQNCkIgYXJlIGluIGEgYnJlYWtvdXQgc2Vzc2lv bj8gSWYgQSBjYWxscyBCIGFuZCBCIHB1dHMgQSBvbiBob2xkIHRoZW0gQiBjYWxscw0KQywgYXJl IHRoZXkgY29ycmVsYXRlZD8gSWYgQiBub3cgY29uZmVyZW5jZXMgYWxsIHRoZXkgYXJlIHRoZXkg Y29ycmVsYXRlZD8NCklmIEEgaXMgY2FsbHMgQiBhbmQgc3RhcnRzIG9uZSBvZiB0aGUgbWFueSB0 eXBlcyBvZiB0cmFuc2ZlciB0byBDPyAmbmJzcDtJJ20NCnRyeWluZyB0byBnZXQgYXQgd2hhdCBk b2VzIGl0IG1lYW4gZm9yIHR3byBVQSdzIHRvIGJlIGluIHRoZSBzYW1lICZxdW90O3Nlc3Npb24m cXVvdDsNCm9yICZxdW90O21lc3NhZ2UtZmxvdyZxdW90OyBhbmQgd2hvIG5lZWRzIHRvIGtub3cg dGhhdCBhbmQgd2h5LiBJZiB0aGUNCm9ubHkgcHVycG9zZSBpcyB0cm91Ymxlc2hvb3RpbmcsIHRo ZSBjaGFydGVyIHNob3VsZCBzYXkgdGhhdC4gQ2FuIGEgZ2l2ZW4NClNJUCBjYWxsIGxlZyBiZSBp biBtdWx0aXBsZSBzZXNzaW9ucyBhdCBvbmNlPyBpcyBjb3JyZWxhdGlvbiBhIHRyYW5zaXRpdmUN CnByb3BlcnR5PyA8YnI+DQo8YnI+DQpJIHRoaW5rIHdlIG5lZWQgdG8gZ2V0IGEgbGl0dGxlIGNy aXNwZXIgYWJvdXQgd2hhdCB0aGUgcHJvYmxlbSBpcyBpbiB0aGUNCmNoYXJ0ZXIgb3IgdGhpcyBX RyBpcyBnb2luZyB0byBoYXZlIGEgaGFyZCB0aW1lIG1vdmluZyBmb3J3YXJkLiAmbmJzcDtXaXRo b3V0DQpzb21lIGd1aWRpbmcgYXJjaGl0ZWN0dXJlIG9uIHRoaXMsIEkgdGhpbmsgdGhlIFdHIHdp bGwgZmluZCBpdCB2ZXJ5IGhhcmQNCnRvIHByb2R1Y2UgYW55dGhpbmcgdXNlZnVsLiBJIHRoaW5r IHdlIHNob3VsZCBhbHNvIGNvbnNpZGVyIGlmIHdlIHdhbnQNCnRoaXMgV0cgdG8gaGF2ZSBhIHNl cGFyYXRlIHRhc2sgb2YgZml4aW5nIHRoZSBpc3N1ZXMgd2l0aCBDYWxsLUlEIGJyb3VnaHQNCnVw IGluIEhhZHJpZWxzIG90aGVyIGRyYWZ0LiA8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiBNYXkg OCwgMjAxMCwgYXQgMjozNSBQTSwgSGFkcmllbCBLYXBsYW4gd3JvdGU6PGJyPg0KPGJyPg0KJmd0 OyBIb3dkeSw8YnI+DQomZ3Q7IEkgaGF2ZSBhc2tlZCB0aGUgRElTUEFUQ0ggY2hhaXJzIHdoYXQg dG8gZG8gd2l0aCBTZXNzaW9uLUlELCBnaXZlbg0KdGhlIGZlZWRiYWNrIEkgcmVjZWl2ZWQgdG8g bWFrZSBpdCBhIHN0YW5kYXJkcy10cmFjayB2cy4gaW5kaXZpZHVhbCBpbmZvcm1hdGlvbmFsDQpz dWJtaXNzaW9uLiAmbmJzcDtUaGVyZSBpcyBubyBvYnZpb3VzIGN1cnJlbnQgV0cgZm9yIHRoaXMg d29yaywgc28gdGhleQ0KYXNrZWQgbWUgdG8gcG9zdCBhIHN0cmF3bWFuIGNoYXJ0ZXIgcHJvcG9z YWwsIHdoaWNoIEkgcHJvcG9zZSBhcyBmb2xsb3dzOjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFNJUCBTaWduYWxpbmctQ09tbXVuaWNhdGlvbiBUcm91Ymxlc2hvb3Rpbmcgd2l0aCBD b3JyZWxhdGlvbiBIZWFkZXINCihTSVBTQ09UQ0gpIENoYXJ0ZXI6PGJyPg0KJmd0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBUaGUgU0lQU0NPVENIIHdvcmtp bmcgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0DQphbGxvd3Mg b3BlcmF0b3JzIGFuZCBtb25pdG9yaW5nIGVxdWlwbWVudCB0byBjb3JyZWxhdGUgU0lQIG1lc3Nh Z2VzIGFuZA0KZGlhbG9ncyBvZiB0aGUgc2FtZSBoaWdoZXItbGV2ZWwgZW5kLXRvLWVuZCAmcXVv dDtzZXNzaW9uJnF1b3Q7IG9yICZxdW90O21lc3NhZ2UtZmxvdyZxdW90Oy4NCiZuYnNwO0luIHBh cnRpY3VsYXIsIHRoZSBtZWNoYW5pc20gbXVzdCBiZSBhYmxlIHRvIGFsbG93IHN1Y2ggY29ycmVs YXRpb24NCmFjcm9zcyBTSVAgQjJCVUFzIG9mIGFzIG1hbnkgZnVuY3Rpb25hbCB0eXBlcyBhcyBw b3NzaWJsZSwgc3VjaCBhcyBBcHBsaWNhdGlvbg0KU2VydmVycywgU29mdHN3aXRjaGVzLCBQQlhz LCBTQkNzLCBldGMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFsdGhvdWdoIG90aGVyIHNvbHV0aW9u cyBtYXkgYmUgcG9zc2libGUsIHRoaXMgd29ya2luZyBncm91cCB3aWxsDQpmb2N1cyBvbiBkZWZp bmluZyBhIG5ldyBTSVAgSGVhZGVyIGZpZWxkIGZvciBzdWNoIGEgcHVycG9zZSwgc2ltaWxhciB0 bw0KdGhlIENhbGwtSUQgaGVhZGVyIGZpZWxkLCBpbiBvcmRlciB0byBwcm92aWRlIGEgc2ltcGxl LCBlYXNpbHkgZGVwbG95YWJsZQ0KbWVjaGFuaXNtIHdoaWNoIGNhbiB3b3JrIGFjcm9zcyBTSVAg ZG9tYWlucy4gVGhlIFNJUCBDYWxsLUlEIGhlYWRlciBmaWVsZA0KdmFsdWUgaXRzZWxmIGlzIG5v dCB1c2FibGUgZm9yIHN1Y2ggY29ycmVsYXRpb24sIGJlY2F1c2UgbWFueSBCMkJVQXMgbXVzdA0K Y3JlYXRlIGEgbmV3IENhbGwtSUQgdmFsdWUgb24gdGhlaXIgVUFDICZxdW90O3NpZGUmcXVvdDsg aW4gb3JkZXIgdG8gZnVuY3Rpb24NCnByb3Blcmx5LCBhbmQgdG8gY29tcGx5IHdpdGggdGhlIHJ1 bGVzIG9mIFJGQyAzMjYxLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSXQgc2hvdWxkIGJlIG5vdGVk IHRoYXQgY2VydGFpbiBTSVAgQjJCVUFzIHBlcmZvcm0gYSAmcXVvdDt0b3BvbG9neS1oaWRpbmcm cXVvdDsNCmZ1bmN0aW9uLCBhcyBkZXNjcmliZWQgaW4gUkZDIDU4NTMuICZuYnNwO1RoZSB3b3Jr aW5nIGdyb3VwIHdpbGwgdGFrZSBzdWNoDQpmdW5jdGlvbnMgaW50byBhY2NvdW50IGZvciB0aGUg Y29ycmVsYXRpb24gbWVjaGFuaXNtLCBhcyB3ZWxsIGFzIHByb3ZpZGUNCmd1aWRhbmNlIGZvciBp bXBsZW1lbnRlcnMgb2YgdGhlIG1lY2hhbmlzbSB0byBhdm9pZCB0cmlnZ2VyaW5nIHN1Y2ggYSBm dW5jdGlvbg0KZm9yIHRoZSBtZWNoYW5pc20ncyBoZWFkZXIgZmllbGQgdmFsdWUuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IExhc3RseSwgYWx0aG91Z2ggaW4gY2VydGFpbiBlbnZpcm9ubWVudHMgc3Vj aCBhIG1lY2hhbmlzbSBtYXkgYmUgdXNhYmxlDQpmb3IgZGlhbG9nIGNvcnJlbGF0aW9uIGluIFNJ UCBzdGF0ZSBtYWNoaW5lcywgaXQgaXMgbm90IHRoZSBnb2FsIG9mIHRoaXMNCndvcmtpbmcgZ3Jv dXAgdG8gYWRkcmVzcyB0aGF0IHVzYWdlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBHb2FscyBhbmQg TWlsZXN0b25lczxicj4NCiZndDsgPT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IERlYyAy MDEwIC0gTmV3IGhlYWRlciBzcGVjaWZpY2F0aW9uIHRvIElFU0cgKFBTKTxicj4NCiZndDsgPGJy Pg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgZGlzcGF0Y2ggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBkaXNwYXRjaEBpZXRmLm9y Zzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRj aDxicj4NCjxicj4NCjxicj4NCkN1bGxlbiBKZW5uaW5nczxicj4NCkZvciBjb3Jwb3JhdGUgbGVn YWwgaW5mb3JtYXRpb24gZ28gdG86PGJyPg0KaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0 L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpk aXNwYXRjaCBtYWlsaW5nIGxpc3Q8YnI+DQpkaXNwYXRjaEBpZXRmLm9yZzxicj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2g8YnI+DQo8YnI+DQo8L2ZvbnQ+ PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJp dHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQm bmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9w ZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5i c3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRl bnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJz cDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZu YnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJz cDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24m bmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZu YnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJz cDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2Zv ciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNw O29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNw O2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNw O3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3Rp ZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdl LiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5i c3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRp dmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVu Jm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5i c3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0048DDD348257721_=-- From fluffy@cisco.com Wed May 12 06:48:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997B028C231 for ; Wed, 12 May 2010 06:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.959 X-Spam-Level: X-Spam-Status: No, score=-108.959 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPsMN9Z57uCj for ; Wed, 12 May 2010 06:48:18 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8CF4C28C261 for ; Wed, 12 May 2010 06:37:40 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ9L6ktAaMHG/2dsb2JhbACeKXGgTplkgnaCHASDQA X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="128735560" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 12 May 2010 13:37:29 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4CDbNMX000510; Wed, 12 May 2010 13:37:27 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 12 May 2010 07:37:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0E941E0F-2E51-4545-8CCB-C73A6E32C2C9@cisco.com> References: To: Peter Musgrave X-Mailer: Apple Mail (2.1078) Cc: dispatch mailing list Subject: Re: [dispatch] draft-rosenberg-dispatch-vipr-overview-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 13:48:19 -0000 Hi Peter, It seems to me the SIP call would only reach the same IVR where one = would enter the x1111 inward dialing information. So the experience = would be much the same. On the second call, Alice would dial = 1-800-222-2222, then get the IVR where the 2222 got entered and would = get a SIP call to Bob. I'm not sure I really understood the question you = were asking so if this make no sense, lets figure out how to sort it = out. Cullen On May 9, 2010, at 8:29 AM, Peter Musgrave wrote: > Hi Jonathan/Cullen, >=20 > I have a use-case question for ViPR. >=20 > Scenario: > Alice is at PSTN 1-800-111-1111 x1111 > Bob is at PSTN 1-800-222-2222 x2222 >=20 > Alice and Bob support ViPR and know their PSTN numbers - but may not > be the sole ViPR endpoints for the PSTN number within their > enterprises. > Neither Alice nor Bob's SIP-PSTN connection supports ViPR. >=20 > Alice calls Bob's PSTN number and sends digits 2222 to connect to Bob. > Both parties now have the shared secret of the PSTN call. >=20 > Alice then wants to call Bob again (and ideally ViPR should make this > a SIP call). So if Alice starts with dialing the PSTN number there is > no knowledge that it's Bob she wants to contact. If she learned Bob > has a SIP/ViPR endpoint could she be presented with a direct call > option? >=20 > Can ViPR make this a SIP call? >=20 >=20 > Regards, >=20 > Peter Musgrave Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed May 12 06:48:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2BB328C2D7 for ; Wed, 12 May 2010 06:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.672 X-Spam-Level: X-Spam-Status: No, score=-108.672 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBuKArSm6xjE for ; Wed, 12 May 2010 06:48:27 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 81B9F28C2D8 for ; Wed, 12 May 2010 06:37:50 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ9L6ktAaMHG/2dsb2JhbACeKXGgTplkgmaCLASDQIwF X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="128735681" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 12 May 2010 13:37:39 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4CDbNMY000510; Wed, 12 May 2010 13:37:36 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 12 May 2010 07:37:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100323161249.21FDA3A6A55@core3.amsl.com> <4BAA55A6.6030600@softarmor.com> <1269459664.2149.294.camel@localhost> <9DAF1F09-7EEE-48F7-A0B6-DAE48F87ACC4@cs.columbia.edu> <1269466329.2149.311.camel@localhost> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1078) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 13:48:27 -0000 As far as I can tell, and I was on a few of the sipforum calls, the = primary problem with "not sufficient for needs of commercial service = providers" was that there was no way SIP Forum could bill people a bunch = of money from a number given out by IANA. There was some implications by = at least one person that IANA was not capable of running a registry but = I never got any details on that.=20 On Mar 24, 2010, at 3:37 PM, Henning Schulzrinne wrote: >>=20 >> The attached is a problem statement I drafted for the SIP Forum Board >> that summarized the issues raised in the task group and from some >> external reviewers. >=20 > To quote: >=20 > The administrative and legal infrastructure of using the existing > first-come first-served ITAD registry at IANA is not sufficient > for the needs of commercial service providers. >=20 > * No reasons are given for this determination. >=20 > Using the existing ITAD name and registry may create confusion > regarding whether or not other parts of the protocols and > procedures in the TRIP specification and/or the ISN/Freenum trial > are also applicable (the intent is that no other part of these > other specifications and procedures be used). >=20 > * I admit that I find this speculative. As long as the mechanism is = clear, the users of the DNS record won't care. >=20 > The ITAD number is defined as a 32 bit number. >=20 > * This translates into (roughly) a 9-digit decimal integer. It seems = rather unlikely that we would exceed 4 billion service providers or that = we'd want longer identifiers than 9 digits. >=20 > In general, I agree that the ITAD registry would have to be expanded = and the use clarified, but re-use of the same registry (say, enterprise = numbers) for different purposes is not unusual. >=20 > Henning >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From mary.ietf.barnes@gmail.com Wed May 12 07:33:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D76C128C2D8 for ; Wed, 12 May 2010 07:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.489 X-Spam-Level: X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvnSXivt09Tb for ; Wed, 12 May 2010 07:33:13 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 4DD3D28C1D9 for ; Wed, 12 May 2010 07:13:22 -0700 (PDT) Received: by gxk9 with SMTP id 9so96645gxk.8 for ; Wed, 12 May 2010 07:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=zDribihPcDv1kcJhR4I2559HMcnEmMmS9NAeol5y4Kk=; b=LSujKvhRb8KVLWf0hQuu5PuHoioWfIt5iz0hSul/7dUBCjZsIu3zvsMXblJFHm0BZn L2Ir9uFwxqwlFK8enaqXm4UsuGVUuiWowMhVh6VI0i4Qo5WadoYbXU52G9AqzK+DXoy+ l5q9fbZnZ/rWbADVaLNwDLz/TLkwRTISlSS94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Pmcv/rg+rZukuO93fiz9UtDQzUfop98CNiyzcZgTouG9LDf0/w/5qbmjETKcU+mRIj UrdZygVqsE6Sm84oxcbF9+tDRsHCEJQKBsQVdX2RBM3bbmxpxwx4rTIIHUvXddmXUwao D/h4J5zpC5yBHy2asRKGE9Dzy730J2xR3K2q4= MIME-Version: 1.0 Received: by 10.101.129.23 with SMTP id g23mr4387604ann.68.1273673583407; Wed, 12 May 2010 07:13:03 -0700 (PDT) Received: by 10.100.31.10 with HTTP; Wed, 12 May 2010 07:13:02 -0700 (PDT) In-Reply-To: <20100511214028.087F43A68F3@core3.amsl.com> References: <20100511214028.087F43A68F3@core3.amsl.com> Date: Wed, 12 May 2010 09:13:02 -0500 Message-ID: From: Mary Barnes To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [dispatch] Fwd: [sip-overload] WG Action: SIP Overload Control (soc) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:33:14 -0000 FYI... ---------- Forwarded message ---------- From: IESG Secretary Date: Tue, May 11, 2010 at 4:40 PM Subject: [sip-overload] WG Action: SIP Overload Control (soc) To: IETF Announcement list Cc: volker.hilt@alcatel-lucent.com, sip-overload@ietf.org A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. =A0For additional information, please contact the Area Directors or the WG Chairs. SIP Overload Control (soc) --------------------------- Current Status: Active Working Group Last Modified: 2010-05-06 Chair(s) Volker Hilt Salvatore Loreto Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: sip-overload@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sip-overload Archive: http://www.ietf.org/mail-archive/web/sip-overload/ Description of Working Group: As with any network element, a Session Initiation Protocol (SIP) server can suffer from overload when the number of SIP messages it receives exceeds the number of messages it can process. Overload is said to occur when a SIP server does not have sufficient resources to complete the processing of all incoming SIP messages within the required time. These resources can include CPU, memory, network bandwidth, input/ output, or disk resources. Overload can pose a serious problem for a network of SIP servers. During periods of overload, a network of SIP servers can be significantly degraded with regard to "goodput" (effective application throughput, not counting the overhead of retransmission and redundant data). In fact, overload may lead to a situation in which the goodput drops down to zero or a small fraction of the original processing capacity. The objective of a SIP overload control mechanism is to enable SIP servers to operate close to their capacity limit during times of overload. The SIP protocol provides a limited mechanism for overload control through its 503 (Service Unavailable) response code and the Retry-After header. However, this mechanism cannot fully prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, its on/off behavior may cause traffic to oscillate and shift between SIP servers and thereby worsen an overload condition. A detailed discussion of the SIP overload problem, the problems with the 503 (Service Unavailable) response code and the Retry-After header and the requirements for a SIP overload control mechanism can be found in RFC5390. The objective of the working group is to develop mechanisms for SIP overload control. The problem domain of SIP overload control can be split into overload control between a user agent and a SIP server and overload control between SIP servers. Any specification developed by the working group needs to clearly specify its scope. A specification also needs to clearly state any limitations, in performance or otherwise, the specified overload control mechanism may have. In particular, the working group shall carefully define the deployment considerations for the effective operation of the specified mechanisms and discuss, for example, when a mechanism requires coordinated deployment and operation (if all servers need to deploy the same mechanism, certain configuration values need to be identical on all servers, etc), when a mechanism can become less effective or ineffective under some conditions, or especially if there are cases when a mechanism can reduce goodput compared to no overload protection. The intent of these considerations is to allow potential deployers to make the best use of these mechanism in their particular networks. The working group will consider two complementary approaches for handling overload situations: - The first mechanism aims at preventing overload in SIP servers by adjusting the incoming load to a level that is acceptable for this server. This mechanism uses implicit and/or explicit feedback to determine when an overload condition occurs in a SIP server and a reduction in load is required. - The second mechanism aims at preventing overload in SIP servers by distributing load control filters to SIP servers that throttle calls based on their source or destination domain, telephone number prefix or for a specific user. Such filters can be used, for example, to throttle calls to a hotline during a ticket-giveaway event. The working group will develop the following deliverables: 1. A document describing key design considerations for a SIP overload control mechanism. 2. A specification for an SIP overload control mechanism based on implicit/explicit feedback. 3. A specification for a SIP load filtering mechanism. Milestones: Sep 2010 Design Considerations to IESG for publication as Informational Dec 2010 Specification for a SIP overload control mechanism based on implicit/explicit feedback to IESG for publication as Proposed Standard May 2011 Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From L.Liess@telekom.de Wed May 12 07:36:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5765F28C2D9 for ; Wed, 12 May 2010 07:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l5P3-gGe4YB for ; Wed, 12 May 2010 07:36:12 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 9EAEE3A68DA for ; Wed, 12 May 2010 07:17:30 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 12 May 2010 16:17:15 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 16:17:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 May 2010 16:17:10 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A004417FB9@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [dispatch] Alert Info Charter Thread-Index: Acrx3ati93lBkWvoQIaaHhUL7g1PogAAA4fw From: To: X-OriginalArrivalTime: 12 May 2010 14:17:14.0633 (UTC) FILETIME=[D1F96790:01CAF1DD] Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:36:14 -0000 =20 Cullen, The call waiting Alert Info URN is carried in 180 Ringing. Alice called Bob. Bob is already in a phone call. Bob's UA does not respond with busy ( as it would do without the call waiting feature), but tells Bob (e.g. by a repeated acustic signal) that a second call is waiting and sends to Alice's UA a 180 Ringing with an Alert-Info URN. Alice gets a special ringback tone which tells her that Bob is in another phone call but was informed about the new call. Bob may decide to terminate or put on hold the first call and talk to Alice. Thanks, Laura 2010/5/12 Cullen Jennings : > > I'm a bit concerned about the discussion of the call waiting tones. Assuming we had a "call waiting tone" URN we could put in Alert-Info, how would this work? when would it be used - I'm wondering what message in what dialog would cary it? > > > > On May 7, 2010, at 4:50 AM, Gonzalo Camarillo wrote: > >> Folks, >> >> I have make a few editorial changes to the Alert Info charter proposal >> in order to clarify what we want to do (see attachment). Please, let me >> know if you have some comments. I would like to get the whole IESG to >> review it relatively soon. >> >> One thing that still needs a bit of work is the last sentence of the >> charter: "Whenever possible, the Alert-Info URNs identifiers should be >> semantic." >> >> The whole charter motivates the use of semantic identifiers but then, in >> the last sentence, it opens the door to non-semantic identifiers (e.g., >> urn:alert:duration:short). >> >> We need to either focus on working on semantic identifiers only or add >> more text explaining the reasons why we also want to define non semantic >> identifiers. Opinions? >> >> Thanks, >> >> Gonzalo >> >> _______________________________________ ________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Wed May 12 07:39:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399683A6BB3 for ; Wed, 12 May 2010 07:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.515 X-Spam-Level: X-Spam-Status: No, score=-9.515 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv9iApPB8873 for ; Wed, 12 May 2010 07:39:33 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 484773A6BA2 for ; Wed, 12 May 2010 07:21:43 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="110530003" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 12 May 2010 14:21:31 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4CELVEh021765; Wed, 12 May 2010 14:21:31 GMT Message-ID: <4BEAB96B.1060301@cisco.com> Date: Wed, 12 May 2010 10:21:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Cullen Jennings References: <4BE3F08B.7000006@ericsson.com> <4EE77A9E-E2EB-4534-8911-BC5266131513@cisco.com> In-Reply-To: <4EE77A9E-E2EB-4534-8911-BC5266131513@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:39:34 -0000 Cullen Jennings wrote: > I'm a bit concerned about the discussion of the call waiting tones. Assuming we had a "call waiting tone" URN we could put in Alert-Info, how would this work? when would it be used - I'm wondering what message in what dialog would cary it? My understanding is that this would be used as the A-I in a 180 response to the "second" caller, thus indicating something that some people seem to find interesting. (Personally, I don't get the value of this. The fact that the called party is on another call on a phone that has the "call waiting" feature doesn't really tell me whether I should wait longer, or hang up sooner than if I didn't get it. And I don't know how it differs from a case where the callee is on a different "line" on a business phone, or on an entirely different phone - cases where I gather the call-waiting alert probably would not be used.) Nevertheless, people seem to like this, and who am I to say they shouldn't have it? Thanks, Paul > On May 7, 2010, at 4:50 AM, Gonzalo Camarillo wrote: > >> Folks, >> >> I have make a few editorial changes to the Alert Info charter proposal >> in order to clarify what we want to do (see attachment). Please, let me >> know if you have some comments. I would like to get the whole IESG to >> review it relatively soon. >> >> One thing that still needs a bit of work is the last sentence of the >> charter: "Whenever possible, the Alert-Info URNs identifiers should be >> semantic." >> >> The whole charter motivates the use of semantic identifiers but then, in >> the last sentence, it opens the door to non-semantic identifiers (e.g., >> urn:alert:duration:short). >> >> We need to either focus on working on semantic identifiers only or add >> more text explaining the reasons why we also want to define non semantic >> identifiers. Opinions? >> >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From HKaplan@acmepacket.com Wed May 12 07:55:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB87F28C2A7 for ; Wed, 12 May 2010 07:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH4zq+7JryuV for ; Wed, 12 May 2010 07:55:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A84813A6B82 for ; Wed, 12 May 2010 07:41:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 12 May 2010 10:41:41 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 12 May 2010 10:41:40 -0400 From: Hadriel Kaplan To: "Elwell, John" , Laura Liess , 'Gonzalo Camarillo' , "dispatch@ietf.org" Date: Wed, 12 May 2010 10:41:40 -0400 Thread-Topic: Alert Info Charter Thread-Index: AcrvTGoYP40eXnwsTTWhJb8KYvbW+wB589xwABmlN4AAEZc5kA== Message-ID: <430FC6BDED356B4C8498F634416644A91C13990CFE@mail> References: <4BE3F08B.7000006@ericsson.com> <4BE419CC.7050507@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D759D@mail> <430FC6BDED356B4C8498F634416644A91A8A7D75EE@mail> <4BE43170.2030401@gmail.com> <430FC6BDED356B4C8498F634416644A91A8A7D763E@mail> <4BE5418F.1010005@ericsson.com> <4be9bfb1.0338560a.1f23.4128@mx.google.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 Cc: 'Liess Laura' Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:55:11 -0000 +1. > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, May 12, 2010 2:21 AM > To: Laura Liess; 'Gonzalo Camarillo'; dispatch@ietf.org >=20 > This works for me. I think we have had enough charter-bashing and really > should get on and form the group and work on refining the requirements in > Laura's I-D. >=20 > John >=20 From HKaplan@acmepacket.com Wed May 12 07:55:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D3F28C304 for ; Wed, 12 May 2010 07:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyTQHzTwvwzi for ; Wed, 12 May 2010 07:55:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BA1E03A6CFE for ; Wed, 12 May 2010 07:42:57 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 12 May 2010 10:42:47 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 12 May 2010 10:42:46 -0400 From: Hadriel Kaplan To: Cullen Jennings Date: Wed, 12 May 2010 10:42:47 -0400 Thread-Topic: [dispatch] Session-ID charter proposal Thread-Index: Acrx05egTFfwN+2/S66YisK3xDXlxgAC/diA Message-ID: <430FC6BDED356B4C8498F634416644A91C13990D00@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> <69EB5FD3-F3CE-463B-A401-3A501F586747@cisco.com> In-Reply-To: <69EB5FD3-F3CE-463B-A401-3A501F586747@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:55:59 -0000 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, May 12, 2010 9:03 AM > To: Hadriel Kaplan >=20 > What is that being correlated? What are the semantic meaning of two call > legs being correlated? I'm trying to get at if phone A, B and C are all i= n > talking on the same conference call are they correlated?=20 No, not with respect to this charter's purpose/goal anyway. > what if A and B > are in a breakout session? If A calls B and B puts A on hold them B calls > C, are they correlated?=20 No. > If B now conferences all they are they correlated? No. > If A is calls B and starts one of the many types of transfer to C? No. > I'm > trying to get at what does it mean for two UA's to be in the same > "session" or "message-flow" and who needs to know that and why.=20 OK, I'll try to suggest text for the charter to make it clearer. > If the > only purpose is troubleshooting, the charter should say that.=20 The charter does say that - the charter was modified slightly in a subseque= nt email: http://www.ietf.org/mail-archive/web/dispatch/current/msg01776.ht= ml > Can a given > SIP call leg be in multiple sessions at once? is correlation a transitive > property? No. =20 > I think we need to get a little crisper about what the problem is in the > charter or this WG is going to have a hard time moving forward. Without > some guiding architecture on this, I think the WG will find it very hard > to produce anything useful. I think we should also consider if we want > this WG to have a separate task of fixing the issues with Call-ID brought > up in Hadriels other draft. While I personally would like that, I don't think it's the same problem, no= r same root cause, nor the same people who would care. -hadriel From HKaplan@acmepacket.com Wed May 12 08:09:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5E63A6B7F for ; Wed, 12 May 2010 08:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.039 X-Spam-Level: X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddROVm34h22z for ; Wed, 12 May 2010 08:09:17 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AB9C73A6C9F for ; Wed, 12 May 2010 07:57:24 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 12 May 2010 10:57:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 12 May 2010 10:57:13 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Cullen Jennings Date: Wed, 12 May 2010 10:57:07 -0400 Thread-Topic: [dispatch] Alert Info Charter Thread-Index: Acrx4Pq+yosbfN5oTcyfHBZEHodx6QAAQhgg Message-ID: <430FC6BDED356B4C8498F634416644A91C13990D11@mail> References: <4BE3F08B.7000006@ericsson.com> <4EE77A9E-E2EB-4534-8911-BC5266131513@cisco.com> <4BEAB96B.1060301@cisco.com> In-Reply-To: <4BEAB96B.1060301@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:09:17 -0000 Personally I would really like to know if the person I am calling is on ano= ther call and my call is in a call-waiting state. Because that tells me it= 's more likely the person is there, and I likely *will* wait longer if my c= all is important, or hang up if it's not and I don't want to interrupt them= . -hadriel (Technically it should return a 182 to tell me that anyway, but I'm not ope= ning that can of worms again ;) > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Wednesday, May 12, 2010 10:22 AM >=20 > Cullen Jennings wrote: > > I'm a bit concerned about the discussion of the call waiting tones. > Assuming we had a "call waiting tone" URN we could put in Alert-Info, how > would this work? when would it be used - I'm wondering what message in > what dialog would cary it? >=20 > My understanding is that this would be used as the A-I in a 180 response > to the "second" caller, thus indicating something that some people seem > to find interesting. >=20 > (Personally, I don't get the value of this. The fact that the called > party is on another call on a phone that has the "call waiting" feature > doesn't really tell me whether I should wait longer, or hang up sooner > than if I didn't get it. And I don't know how it differs from a case > where the callee is on a different "line" on a business phone, or on an > entirely different phone - cases where I gather the call-waiting alert > probably would not be used.) >=20 > Nevertheless, people seem to like this, and who am I to say they > shouldn't have it? >=20 From L.Liess@telekom.de Wed May 12 08:19:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A564128C159 for ; Wed, 12 May 2010 08:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-PzNVXJP+uC for ; Wed, 12 May 2010 08:19:45 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id E4AA23A696B for ; Wed, 12 May 2010 08:06:13 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 12 May 2010 17:05:50 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 17:05:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 May 2010 17:05:48 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A004417FF3@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [dispatch] Alert Info Charter Thread-Index: Acrx5Hranw/+D0zZSDKL18FuzE8IOwAAA52Q From: To: X-OriginalArrivalTime: 12 May 2010 15:05:50.0700 (UTC) FILETIME=[9C15EAC0:01CAF1E4] Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:19:47 -0000 =20 Paul, it's just that we had this feature in PSTN and product managers require it when we move to SIP. I supose this is the same for other service providers, because they all decided to specify this feature in 3GPP. And IMS vendors must implement it. We all hope product managers have good reasons when they put money in a feature.... Thanks Laura 2010/5/12 Paul Kyzivat : > > > Cullen Jennings wrote: >> >> I'm a bit concerned about the discussion of the call waiting tones. >> Assuming we had a "call waiting tone" URN we could put in Alert-Info, = how >> would this work? when would it be used - I'm wondering what message = in what >> dialog would cary it? > > My understanding is that this would be used as the A-I in a 180 = response to > the "second" caller, thus indicating something that some people seem = to find > interesting. > > (Personally, I don't get the value of this. The fact that the called = party > is on another call on a phone that has the "call waiting" feature = doesn't > really tell me whether I should wait longer, or hang up sooner than if = I > didn't get it. And I don't know how it differs from a case where the = callee > is on a different "line" on a business phone, or on an entirely = different > phone - cases where I gather the call-waiting alert probably would not = be > used.) > > Nevertheless, people seem to like this, and who am I to say they = shouldn't > have it? > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> On May 7, 2010, at 4:50 AM, Gonzalo Camarillo wrote: >> >>> Folks, >>> >>> I have make a few editorial changes to the Alert Info charter = proposal >>> in order to clarify what we want to do (see attachment). Please, let = me >>> know if you have some comments. I would like to get the whole IESG = to >>> review it relatively soon. >>> >>> One thing that still needs a bit of work is the last sentence of the >>> charter: "Whenever possible, the Alert-Info URNs identifiers should = be >>> semantic." >>> >>> The whole charter motivates the use of semantic identifiers but = then, in >>> the last sentence, it opens the door to non-semantic identifiers = (e.g., >>> urn:alert:duration:short). >>> >>> We need to either focus on working on semantic identifiers only or = add >>> more text explaining the reasons why we also want to define non = semantic >>> identifiers. Opinions? >>> >>> Thanks, >>> >>> Gonzalo >>> >>> >>> = ________________________________________= _______ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From fluffy@cisco.com Wed May 12 09:34:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A626328C35B for ; Wed, 12 May 2010 09:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.961 X-Spam-Level: X-Spam-Status: No, score=-109.961 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNj6CocW3p-B for ; Wed, 12 May 2010 09:34:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 55F4D28C35E for ; Wed, 12 May 2010 09:13:30 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP1v6kurR7H+/2dsb2JhbACeLXGiC5lahRIEg0A X-IronPort-AV: E=Sophos;i="4.53,216,1272844800"; d="scan'208";a="528651387" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 12 May 2010 16:13:20 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4CGDJvb005674; Wed, 12 May 2010 16:13:19 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13990D00@mail> Date: Wed, 12 May 2010 10:13:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <430FC6BDED356B4C8498F634416644A91A8A7D777F@mail> <69EB5FD3-F3CE-463B-A401-3A501F586747@cisco.com> <430FC6BDED356B4C8498F634416644A91C13990D00@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1078) Cc: DISPATCH Subject: Re: [dispatch] Session-ID charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 16:34:12 -0000 inline ... On May 12, 2010, at 8:42 AM, Hadriel Kaplan wrote: >=20 >=20 >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Wednesday, May 12, 2010 9:03 AM >> To: Hadriel Kaplan >>=20 >> What is that being correlated? What are the semantic meaning of two = call >> legs being correlated? I'm trying to get at if phone A, B and C are = all in >> talking on the same conference call are they correlated?=20 >=20 > No, not with respect to this charter's purpose/goal anyway. >=20 >> what if A and B >> are in a breakout session? If A calls B and B puts A on hold them B = calls >> C, are they correlated?=20 >=20 > No. >=20 >> If B now conferences all they are they correlated? >=20 > No. >=20 >> If A is calls B and starts one of the many types of transfer to C? >=20 > No. >=20 >> I'm >> trying to get at what does it mean for two UA's to be in the same >> "session" or "message-flow" and who needs to know that and why.=20 >=20 > OK, I'll try to suggest text for the charter to make it clearer. >=20 >=20 >> If the >> only purpose is troubleshooting, the charter should say that.=20 >=20 > The charter does say that - the charter was modified slightly in a = subsequent email: = http://www.ietf.org/mail-archive/web/dispatch/current/msg01776.html >=20 >=20 >> Can a given >> SIP call leg be in multiple sessions at once? is correlation a = transitive >> property? >=20 > No. OK - so I am getting the idea that the only time two dialogs are = correlated is when they are two sides of an B2BUA and they both = represent exactly the same media flowing over the RTP streams? I'm not = arguing the answer should or should not be this - I just want to be = clear what it is). Can you try and craft some text to put in a charter = about what when two things are correlated and when they are not? >=20 >> I think we need to get a little crisper about what the problem is in = the >> charter or this WG is going to have a hard time moving forward. = Without >> some guiding architecture on this, I think the WG will find it very = hard >> to produce anything useful. I think we should also consider if we = want >> this WG to have a separate task of fixing the issues with Call-ID = brought >> up in Hadriels other draft. >=20 > While I personally would like that, I don't think it's the same = problem, nor same root cause, nor the same people who would care. OK - I'll think about this some more once I have a better idea of what = it is the WG going to do. >=20 > -hadriel Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed May 12 09:37:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8C83A6B78 for ; Wed, 12 May 2010 09:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.986 X-Spam-Level: X-Spam-Status: No, score=-109.986 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlHWZjRq6a18 for ; Wed, 12 May 2010 09:37:28 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4FE7728C2D2 for ; Wed, 12 May 2010 09:17:11 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFpx6kurR7Ht/2dsb2JhbACeLXGiDplZhRIEg0A X-IronPort-AV: E=Sophos;i="4.53,216,1272844800"; d="scan'208";a="128792354" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 12 May 2010 16:17:01 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4CGH0kn010159; Wed, 12 May 2010 16:17:00 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A004417FF3@S4DE9JSAANI.ost.t-com.de> Date: Wed, 12 May 2010 10:16:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3C26958B-735E-46F9-8AE3-9F1D3A0FB657@cisco.com> References: <40FB0FFB97588246A1BEFB05759DC8A004417FF3@S4DE9JSAANI.ost.t-com.de> To: "" X-Mailer: Apple Mail (2.1078) Cc: dispatch@ietf.org Subject: Re: [dispatch] Alert Info Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 16:37:29 -0000 Thank Laura and Paul - I understand now. (I was worried it had to do with playing the tone to the person who was = on the call that there was a new incoming call but I see it does not).=20= On May 12, 2010, at 9:05 AM, = wrote: >=20 >=20 >=20 > Paul, >=20 > it's just that we had this feature in PSTN and product managers > require it when we move to SIP. I supose this is the same for other > service providers, because they all decided to specify this feature in > 3GPP. And IMS vendors must implement it. We all hope product managers > have good reasons when they put money in a feature.... >=20 > Thanks > Laura >=20 >=20 > 2010/5/12 Paul Kyzivat : >>=20 >>=20 >> Cullen Jennings wrote: >>>=20 >>> I'm a bit concerned about the discussion of the call waiting tones. >>> Assuming we had a "call waiting tone" URN we could put in = Alert-Info, how >>> would this work? when would it be used - I'm wondering what message = in what >>> dialog would cary it? >>=20 >> My understanding is that this would be used as the A-I in a 180 = response to >> the "second" caller, thus indicating something that some people seem = to find >> interesting. >>=20 >> (Personally, I don't get the value of this. The fact that the called = party >> is on another call on a phone that has the "call waiting" feature = doesn't >> really tell me whether I should wait longer, or hang up sooner than = if I >> didn't get it. And I don't know how it differs from a case where the = callee >> is on a different "line" on a business phone, or on an entirely = different >> phone - cases where I gather the call-waiting alert probably would = not be >> used.) >>=20 >> Nevertheless, people seem to like this, and who am I to say they = shouldn't >> have it? >>=20 >> Thanks, >> Paul >>=20 >>> On May 7, 2010, at 4:50 AM, Gonzalo Camarillo wrote: >>>=20 >>>> Folks, >>>>=20 >>>> I have make a few editorial changes to the Alert Info charter = proposal >>>> in order to clarify what we want to do (see attachment). Please, = let me >>>> know if you have some comments. I would like to get the whole IESG = to >>>> review it relatively soon. >>>>=20 >>>> One thing that still needs a bit of work is the last sentence of = the >>>> charter: "Whenever possible, the Alert-Info URNs identifiers should = be >>>> semantic." >>>>=20 >>>> The whole charter motivates the use of semantic identifiers but = then, in >>>> the last sentence, it opens the door to non-semantic identifiers = (e.g., >>>> urn:alert:duration:short). >>>>=20 >>>> We need to either focus on working on semantic identifiers only or = add >>>> more text explaining the reasons why we also want to define non = semantic >>>> identifiers. Opinions? >>>>=20 >>>> Thanks, >>>>=20 >>>> Gonzalo >>>>=20 >>>>=20 >>>> = _________________________________________= ______ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>>=20 >>> Cullen Jennings >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From dworley@avaya.com Wed May 12 12:38:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF9A3A68F8 for ; Wed, 12 May 2010 12:38:36 -0700 (PDT) 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.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRESPfsyrHSG for ; Wed, 12 May 2010 12:38:35 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5ED653A6965 for ; Wed, 12 May 2010 12:36:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,217,1272859200"; d="scan'208";a="188396636" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 May 2010 15:35:51 -0400 X-IronPort-AV: E=Sophos;i="4.53,217,1272859200"; d="scan'208";a="474414544" 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; 12 May 2010 15:35:50 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3495::870b:3495]) with mapi; Wed, 12 May 2010 15:35:50 -0400 From: "WORLEY, Dale R (Dale)" To: Cullen Jennings , Henning Schulzrinne Date: Wed, 12 May 2010 15:34:16 -0400 Thread-Topic: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC Thread-Index: Acrx2cmmf8du7gqZTk6YeGMq9Au94wAMFJH6 Message-ID: References: <20100323161249.21FDA3A6A55@core3.amsl.com> <4BAA55A6.6030600@softarmor.com> <1269459664.2149.294.camel@localhost> <9DAF1F09-7EEE-48F7-A0B6-DAE48F87ACC4@cs.columbia.edu> <1269466329.2149.311.camel@localhost> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 19:38:36 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Cu= llen Jennings [fluffy@cisco.com] As far as I can tell, and I was on a few of the sipforum calls, the primary= problem with "not sufficient for needs of commercial service providers" wa= s that there was no way SIP Forum could bill people a bunch of money from a= number given out by IANA. There was some implications by at least one pers= on that IANA was not capable of running a registry but I never got any deta= ils on that. _______________________________________________ There is also the question of how to operate the translation DNS service wi= th sufficient reliability that service providers can rely upon it. Dale From dworley@avaya.com Wed May 12 13:02:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6783A6837 for ; Wed, 12 May 2010 13:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLEnAvYqbzNS for ; Wed, 12 May 2010 13:02:35 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 9316F3A68DC for ; Wed, 12 May 2010 13:02:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,217,1272859200"; d="scan'208";a="217769776" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 May 2010 16:02:24 -0400 X-IronPort-AV: E=Sophos;i="4.53,217,1272859200"; d="scan'208";a="474422849" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 May 2010 16:02:24 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 12 May 2010 16:02:24 -0400 From: "WORLEY, Dale R (Dale)" To: Cullen Jennings , Dean Willis Date: Wed, 12 May 2010 16:02:22 -0400 Thread-Topic: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 Thread-Index: Acrxz8P94eBK2AiCRimwgArFChmn8wAPWN7U Message-ID: References: <61CAF342FE1EE34EAC8FB19B765914000D763886@SABRE.InterDigital.com> <4BA0EC7D.6060900@cisco.com> <6DC49EE7-B148-4EE5-B004-5763EEE42B05@softarmor.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 Cc: DISPATCH , "Patel, Milan" Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 20:02:36 -0000 ________________________________________ On Mar 17, 2010, at 6:26 PM, Dean Willis wrote: But I'm at a loss for proposing a better mechanism. Perhaps we could follow= the SIP-T method and define another extension header field carried in the = request? _______________________________________________ I believe that this is a good solution. If we want to transparently carry = a PSTN-specific indicator through a PSTN -> SIP -> PSTN gateway situation, = and that indicator does not translate well into SIP signaling, we should ha= ve a more or less opaque way of carrying it SIP, to be read by the SIP -> P= STN gateway process. SIP-T already does this, and IIRC, the Q.850 variant = of the Reason header has been proposed for this. So let us define a header= (or header variant) for carrying the OLI parameter. We should also consider if some of the OLI information should be translated= into "real" SIP signaling because SIP systems may need to act on it. But = that mapping does not need to be one-to-one. Dale From pkyzivat@cisco.com Wed May 12 13:22:45 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027243A693E for ; Wed, 12 May 2010 13:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.259 X-Spam-Level: X-Spam-Status: No, score=-10.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+1rpwfRJ36W for ; Wed, 12 May 2010 13:22:43 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 256823A6933 for ; Wed, 12 May 2010 13:21:54 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,217,1272844800"; d="scan'208";a="110510274" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 May 2010 20:21:44 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4CKLiUU022260; Wed, 12 May 2010 20:21:44 GMT Message-ID: <4BEB0DD7.2090609@cisco.com> Date: Wed, 12 May 2010 16:21:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "WORLEY, Dale R (Dale)" References: <61CAF342FE1EE34EAC8FB19B765914000D763886@SABRE.InterDigital.com> <4BA0EC7D.6060900@cisco.com> <6DC49EE7-B148-4EE5-B004-5763EEE42B05@softarmor.com>, In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH , "Patel, Milan" Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 20:22:45 -0000 If this info were only to be tunneled, and ignored by sip systems, then I wouldn't care. The problem is that the ISDN systems are being replaced by SIP systems. And as that happens, those SIP systems need to provide a way to do the same thing. When the definitions of what these things mean are off in some ITU document, and are defined in terms of things that make no sense to a sip implementation, then it becomes very difficult to do the right thing. Thanks, Paul WORLEY, Dale R (Dale) wrote: > ________________________________________ > On Mar 17, 2010, at 6:26 PM, Dean Willis wrote: > > But I'm at a loss for proposing a better mechanism. Perhaps we could follow the SIP-T method and define another extension header field carried in the request? > _______________________________________________ > > I believe that this is a good solution. If we want to transparently carry a PSTN-specific indicator through a PSTN -> SIP -> PSTN gateway situation, and that indicator does not translate well into SIP signaling, we should have a more or less opaque way of carrying it SIP, to be read by the SIP -> PSTN gateway process. SIP-T already does this, and IIRC, the Q.850 variant of the Reason header has been proposed for this. So let us define a header (or header variant) for carrying the OLI parameter. > > We should also consider if some of the OLI information should be translated into "real" SIP signaling because SIP systems may need to act on it. But that mapping does not need to be one-to-one. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From R.Jesske@telekom.de Wed May 12 19:05:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BBD53A67AF for ; Wed, 12 May 2010 19:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWl+-XYL3Qof for ; Wed, 12 May 2010 19:05:44 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id DE92F3A69F0 for ; Wed, 12 May 2010 19:05:42 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 13 May 2010 04:05:28 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 May 2010 04:05:27 +0200 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_01CAF240.C1C182B7" Date: Thu, 13 May 2010 04:05:24 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reason In responses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQ From: To: X-OriginalArrivalTime: 13 May 2010 02:05:27.0977 (UTC) FILETIME=[C1FB2190:01CAF240] Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 02:05:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF240.C1C182B7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I have asked for comments on the two drafts mentioned below. So far I didn't get any. Does that mean that people are happy now with = the content and we could proceed with it? Thank you and Best Regrads Roland > _____________________________________________=20 > Von: Jesske, Roland =20 > Gesendet: Donnerstag, 8. April 2010 09:46 > An: dispatch@ietf.org > Betreff: Reason In responses = (draft-jesske-dispatch-reason-in-responses-02) >=20 > Dear all, > During the discussion concerning the Reason header field in Responses = I was asked to split the document into an requirements part and an = protocol part. > So please feel free to comment on the drafts.=20 >=20 > http://64.170.98.42/html/draft-jesske-dispatch-reason-in-responses-02 >=20 > = http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-responses-00= >=20 > Best regards >=20 > Roland Jesske >=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Roland Jesske > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628-2766 (Tel.) > +49 521 9210-3753 (Fax) > +49 171 8618-445 (Mobil) > E-Mail: r.jesske@telekom.de > www.telekom.com =20 >=20 > Erleben, was verbindet.=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 >=20 > Gro=DFe Ver=E4nderungen fangen klein an > -> Ressourcen schonen und = nicht jede E-Mail drucken. >=20 >=20 ------_=_NextPart_001_01CAF240.C1C182B7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: Reason In responses = (draft-jesske-dispatch-reason-in-responses-02)

Dear all,
I have asked for = comments on the two drafts mentioned below.
So far I didn't get = any. Does that mean that people are happy now with the content and we = could proceed with it?

Thank you and Best = Regrads

Roland


_____________________________________________
Von:    Jesske, Roland 
Gesendet:       = Donnerstag, 8. April 2010 09:46
An:     dispatch@ietf.org
Betreff:       = Reason In responses = (draft-jesske-dispatch-reason-in-responses-02)

Dear all,
During the discussion concerning the = Reason header field in Responses I was asked to split the document into = an requirements part and an protocol part.

So please feel free to comment on the = drafts.

http://64.170.98.42/html/draft-jesske-dispatch-reason-in-r= esponses-02

http://64.170.98.42/html/draft-jesske-dispatch-req-reason-= in-responses-00

Best = regards

Roland = Jesske


Deutsche Telekom Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 = Darmstadt
+49 6151 628-2766 (Tel.)
+49 521 9210-3753  (Fax)
+49 171 8618-445  (Mobil)
E-Mail: r.jesske@telekom.de
www.telekom.com 

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn = (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn = (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr. DE 814645262

Gro=DFe Ver=E4nderungen fangen klein an – Ressourcen schonen und nicht = jede E-Mail drucken.


------_=_NextPart_001_01CAF240.C1C182B7-- From john.elwell@siemens-enterprise.com Thu May 13 00:28:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2813A6AC4 for ; Thu, 13 May 2010 00:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_50=0.001, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUMe5mPrIjhb for ; Thu, 13 May 2010 00:28:10 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8F8463A6BF8 for ; Thu, 13 May 2010 00:23:46 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-158510; Thu, 13 May 2010 09:23:35 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id CE0D71EB82AB; Thu, 13 May 2010 09:23:35 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 13 May 2010 09:23:35 +0200 From: "Elwell, John" To: "R.Jesske@telekom.de" , "dispatch@ietf.org" Date: Thu, 13 May 2010 09:23:33 +0200 Thread-Topic: Reason In responses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQAAoty1A= Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 07:28:12 -0000 Roland, In my view, there is a simple requirement to convey Q.850 causes in SIP res= ponse messages, so that the UAC will receive a more accurate indication of = the reason for rejection when rejection comes from PSTN. The cause mapping = table helps to illustrate this. This is not rocket science, and I am disapp= ointed that we have not found a quick way of dispatching this and just gett= ing the work done. In my opinion the split into separate documents was unne= cessary (take as an example the recently-published RFC 5876, which combines= motivation and solution in one document), but it has been done now. Unfort= unately I don't think it has moved us any further forward. I don't think the requirements in section 3 are particularly well expressed= . REQ-1 can already be met by tunnelling in accordance with SIP-T. I would = not expect the IETF to provide a new solution specifically for that require= ment. I think REQ-2 and REQ-3 boil down to the same thing - it must be possible t= o provide an accurate indication to a UAC, so that the UAC can provide a su= itable indication to the user. Whether this be an announcement, a textual m= essage, an icon, a flashing lamp, a tone, a vibration, an odour or whatever= , is a user interface matter. I also find REQ-4 rather problematic. If we have a solution for PSTN, we wo= uld also have a solution for some other form of gateway into a domain that = provides a "PSTN-like service". Unfortunately, if you try to bring this out= as a separate requirement, it raises the question of what exactly is this = "PSTN-like service", and if it is somehow SIP-based, why it needs to be "PS= TN-like", and so on. Basically I think there is only a single requirement here - provision of a = correct indication to a UAC when rejection comes from the PSTN. I think tha= t is a reasonable requirement and we should just go ahead and do it, rather= like we did with RFC 5876 when we extended the range of messages that PAI/= PPI could be used in. I find the statement in REQ-3 "A inclusion of [Q.850] causes is out of scop= e." very strange. I thought the whole idea was to convey Q.850 causes, so w= hy say they are out of scope? I assume this is some sort of typo. I think one of the consequences of deciding to split requirements and solut= ion into separate drafts is that the requirements draft has to stick to mot= ivation and requirements. I find too much in the draft (particularly the ex= amples) that smells of solution. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de > Sent: 13 May 2010 03:05 > To: dispatch@ietf.org > Subject: Re: [dispatch] Reason In responses=20 > (draft-jesske-dispatch-reason-in-responses-02) >=20 > Dear all,=20 > I have asked for comments on the two drafts mentioned below.=20 > So far I didn't get any. Does that mean that people are happy=20 > now with the content and we could proceed with it?=20 >=20 > Thank you and Best Regrads=20 >=20 > Roland=20 >=20 >=20 > _____________________________________________=20 > Von: Jesske, Roland =20 > Gesendet: Donnerstag, 8. April 2010 09:46=20 > An: dispatch@ietf.org=20 > Betreff: Reason In responses=20 > (draft-jesske-dispatch-reason-in-responses-02)=20 >=20 > Dear all,=20 > During the discussion concerning the Reason header field in=20 > Responses I was asked to split the document into an=20 > requirements part and an protocol part. >=20 > So please feel free to comment on the drafts.=20 >=20 > http://64.170.98.42/html/draft-jesske-dispatch-reason-in-respo > nses-02=20 > onses-02> =20 >=20 > http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-r > esponses-00=20 > responses-00> =20 >=20 > Best regards=20 >=20 > Roland Jesske=20 >=20 >=20 > Deutsche Telekom Netzproduktion GmbH=20 > Zentrum Technik Einf=FChrung=20 > Roland Jesske=20 > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 > +49 6151 628-2766 (Tel.)=20 > +49 521 9210-3753 (Fax)=20 > +49 171 8618-445 (Mobil)=20 > E-Mail: r.jesske@telekom.de =20 > www.telekom.com =20 >=20 > Erleben, was verbindet.=20 >=20 > Deutsche Telekom Netzproduktion GmbH=20 > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)=20 > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > Albert Matheis, Klaus Peren=20 > Handelsregister: Amtsgericht Bonn HRB 14190=20 > Sitz der Gesellschaft: Bonn=20 > USt-IdNr. DE 814645262=20 >=20 > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und=20 > nicht jede E-Mail drucken.=20 >=20 >=20 > = From enrico.marocco@telecomitalia.it Thu May 13 00:50:45 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689933A68C3 for ; Thu, 13 May 2010 00:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.844 X-Spam-Level: * X-Spam-Status: No, score=1.844 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyWTu9gI0iEE for ; Thu, 13 May 2010 00:50:44 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id DCE4E3A6AD2 for ; Thu, 13 May 2010 00:50:37 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 13 May 2010 09:50:25 +0200 Received: from [163.162.173.11] (163.162.173.11) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 13 May 2010 09:50:25 +0200 Message-ID: <4BEBAF4F.8080406@telecomitalia.it> Date: Thu, 13 May 2010 09:50:39 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: "Elwell, John" References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060006050201010601090103" Cc: "dispatch@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 07:50:45 -0000 --------------ms060006050201010601090103 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Elwell, John wrote: > Basically I think there is only a single requirement here - provision > of a correct indication to a UAC when rejection comes from the PSTN. > I think that is a reasonable requirement and we should just go ahead > and do it, rather like we did with RFC 5876 when we extended the > range of messages that PAI/PPI could be used in. Speaking as a service provider, that is indeed what is really needed. The req draft does a decent job at framing it, maybe with a little too much IMS-speak. That said, can we move on and try to agree on simple solution for such a simple problem? -- Ciao, Enrico --------------ms060006050201010601090103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwNTEz MDc1MDM5WjAjBgkqhkiG9w0BCQQxFgQUJP/ZOcbJZc0r5IUlDIqk+/bWkqQwXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBAEMtfIOwZaQMoPJvEb6z l2T7F1bN4U0j3qvMw2T0lonFJwnA/FEEz9bh/X7yyKiD0GNGMN0cazRMSDum+a3FwikaXjmq QmnFSXV+mTAGw9bxWhvkRaMmIxITxhHAs0G4EpWUP76QbaHOzIz0gFqYJsrvJoAVowmyXdok IpNcSjMg2EEy5b+JU7tSa6+mk0dRSkXl1vK5Q0V/NjjxDH+XFOdz9VkTINMTHPiNaZAWGnWr kYrIW6rNaln03z7+k12n2W9AmDZ6scqt93tVOJE8uqDQVo/zEBiVdJXPbeTMeytcpSdJ16mu HDSLul0I5SvfYPy8j41OPQXXWBETseH4SLEAAAAAAAA= --------------ms060006050201010601090103-- From ranjit@motorola.com Thu May 13 03:31:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330C43A6C62 for ; Thu, 13 May 2010 03:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.684 X-Spam-Level: X-Spam-Status: No, score=-4.684 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCHyjltOBmB3 for ; Thu, 13 May 2010 03:31:33 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 697C93A6B1A for ; Thu, 13 May 2010 03:28:26 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-12.tower-55.messagelabs.com!1273746495!99738096!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5061 invoked from network); 13 May 2010 10:28:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 May 2010 10:28:15 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o4DAS9eI010245 for ; Thu, 13 May 2010 03:28:14 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o4DAS9ec003504 for ; Thu, 13 May 2010 05:28:09 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o4DAS8Uc003499 for ; Thu, 13 May 2010 05:28:08 -0500 (CDT) 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, 13 May 2010 18:27:45 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-avasarala-dispatch-comm-barring-notification-00 thread-index: AcryhWzbLdlIO5CLQ9SHlQmzpNqWjwAAB6jQ From: "Avasarala Ranjit-A20990" To: X-CFilter-Loop: Reflected Cc: T Satyanarayana-A12694 Subject: [dispatch] FW: New Version Notification for draft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 10:31:36 -0000 Hi all I have submitted a new I-D on communication barring notification information based on the following Section 8.2.10 Communication Barring - ICB enhancement of dynamic blocking of incoming communications of 3GPP TS 22.173 Section 4.5.2.6.1 Actions for ICB at the terminating AS of 3GPP TS 24.611 The draft can be accessed from: http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-notificatio n-00.txt Please review and comment. Thanks Regards Ranjit -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Thursday, May 13, 2010 3:47 PM To: Avasarala Ranjit-A20990 Cc: r.jesske@telekom.de Subject: New Version Notification for draft-avasarala-dispatch-comm-barring-notification-00=20 A new version of I-D, draft-avasarala-dispatch-comm-barring-notification-00.txt has been successfully submitted by Ranjit Avasarala and posted to the IETF repository. Filename: draft-avasarala-dispatch-comm-barring-notification Revision: 00 Title: A Session Initiation Protocol (SIP) Event Package for Communication Barring Notification Information in support of the Dynamic Incoming Communication Barring (ICB) Notification service Creation_date: 2010-05-13 WG ID: Independent Submission Number_of_pages: 22 Abstract: 3GPP is defining the protocol specification for the Communication Barring (CB) service using IP Multimedia (IM) Core Network (CN) subsystem supplementary service and more particularly the dynamic incoming communication barring service. As part of dynamic incoming communication barring (ICB) service, a SIP based Event package framework is used for notifying users about communication barrings (dynamic and rule based) of their incoming communication sessions. This document proposes a new SIP event package for allowing users to subscribe to and receive such notifications. Users can further define filters to control the rate and content of such notifications. The proposed event package is applicable to the ICB supplementary service in IMS and may not be applicable to the general internet. =20 The IETF Secretariat. From john.elwell@siemens-enterprise.com Thu May 13 05:55:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6FFB3A685B for ; Thu, 13 May 2010 05:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlouHL91BZCR for ; Thu, 13 May 2010 05:55:43 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4C6033A6894 for ; Thu, 13 May 2010 05:54:53 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-161770; Thu, 13 May 2010 14:54:42 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id E8AE71EB82AE; Thu, 13 May 2010 14:54:42 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 13 May 2010 14:54:42 +0200 From: "Elwell, John" To: Avasarala Ranjit-A20990 , "dispatch@ietf.org" Date: Thu, 13 May 2010 14:54:41 +0200 Thread-Topic: [dispatch] FW: New Version Notification for draft-avasarala-dispatch-comm-barring-notification-00 Thread-Index: AcryhWzbLdlIO5CLQ9SHlQmzpNqWjwAAB6jQAAFkdMA= Message-ID: References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.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: T Satyanarayana-A12694 Subject: Re: [dispatch] FW: New Version Notification for draft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 12:55:45 -0000 Ranjit, It is not entirely clear to me what the notifications report. For example, = in 6.7, it says "Typically, it will send one when a communication barring is enacted on behalf of the user." What is meant by "enacted" here? Is it when some entity, on behalf of the u= ser, perhaps through some web page, establishes a communication barring rul= e? Or is it when an inbound communication arrives and is processed in accor= dance with some pre-existing communication barring rule? I thought at first= it was the former, but I am tending towards thinking it is the latter. Som= e clarification would be useful. Assuming it is the latter, there is obviously some synergy with draft-avasa= rala-dispatch-comm-div-notification. Both deal with reporting inbound commu= nications that have been subject to some rule, the rule being conditional o= n certain criteria such as caller ID. Where the conditions are met for a gi= ven call to be subject to a given rule, a notification in accordance with o= ne or the other event package will be triggered. I fail to see the reason f= or having two separate event packages, since this means two separate specif= ications, two different subscriptions, two different formats, etc.. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 > Ranjit-A20990 > Sent: 13 May 2010 11:28 > To: dispatch@ietf.org > Cc: T Satyanarayana-A12694 > Subject: [dispatch] FW: New Version Notification for=20 > draft-avasarala-dispatch-comm-barring-notification-00 >=20 > Hi all >=20 > I have submitted a new I-D on communication barring notification > information based on the following >=20 > Section 8.2.10 Communication Barring - ICB enhancement of dynamic > blocking of incoming communications of 3GPP TS 22.173 >=20 > Section 4.5.2.6.1 Actions for ICB at the terminating AS of 3GPP TS > 24.611 >=20 > The draft can be accessed from: > http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n > otificatio > n-00.txt >=20 > Please review and comment. >=20 > Thanks >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > Sent: Thursday, May 13, 2010 3:47 PM > To: Avasarala Ranjit-A20990 > Cc: r.jesske@telekom.de > Subject: New Version Notification for > draft-avasarala-dispatch-comm-barring-notification-00=20 >=20 >=20 > A new version of I-D, > draft-avasarala-dispatch-comm-barring-notification-00.txt has been > successfully submitted by Ranjit Avasarala and posted to the IETF > repository. >=20 > Filename: draft-avasarala-dispatch-comm-barring-notification > Revision: 00 > Title: A Session Initiation Protocol (SIP)=20 > Event Package for > Communication Barring Notification Information in support of=20 > the Dynamic > Incoming Communication Barring (ICB) Notification service > Creation_date: 2010-05-13 > WG ID: Independent Submission > Number_of_pages: 22 >=20 > Abstract: > 3GPP is defining the protocol specification for the Communication > Barring (CB) service using IP Multimedia (IM) Core Network (CN) > subsystem supplementary service and more particularly the dynamic > incoming communication barring service. As part of dynamic incoming > communication barring (ICB) service, a SIP based Event=20 > package framework > is used for notifying users about communication barrings (dynamic and > rule based) of their incoming communication sessions. > This document proposes a new SIP event package for allowing users to > subscribe to and receive such notifications. Users can further define > filters to control the rate and content of such notifications. > The proposed event package is applicable to the ICB supplementary > service in IMS and may not be applicable to the general internet. > =20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From HKaplan@acmepacket.com Thu May 13 06:48:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69BEF3A6B1E for ; Thu, 13 May 2010 06:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZso2M+YktPG for ; Thu, 13 May 2010 06:48:42 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 659373A6B48 for ; Thu, 13 May 2010 06:48:37 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 13 May 2010 09:48:25 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 13 May 2010 09:48:24 -0400 From: Hadriel Kaplan To: "R.Jesske@telekom.de" , "dispatch@ietf.org" Date: Thu, 13 May 2010 09:48:18 -0400 Thread-Topic: Reason In responses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQABh7EkA= Message-ID: <430FC6BDED356B4C8498F634416644A91C13990F46@mail> References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 13:48:43 -0000 Hi Roland, I wasn't sure if you were still planning on moving forward with this draft,= given the Alert-Info URN draft. I thought maybe instead you were going to= define a mapping of Q.850 response codes to "semantic" URNs. So since you= 're not, can you put some text in your draft (or email) why not, and what t= his Reason header in responses would be used for compared to Alert-Info? I= think it may help implementers to know what's what. -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of R.Jesske@telekom.de > Sent: Wednesday, May 12, 2010 10:05 PM >=20 > Dear all, > I have asked for comments on the two drafts mentioned below. > So far I didn't get any. Does that mean that people are happy now with th= e > content and we could proceed with it? >=20 > Thank you and Best Regrads >=20 > Roland >=20 From dworley@avaya.com Thu May 13 07:25:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840B23A6B4A for ; Thu, 13 May 2010 07:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[AWL=-1.015, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8x7ufMsAeWB for ; Thu, 13 May 2010 07:25:02 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 82ACE3A6B5F for ; Thu, 13 May 2010 07:24:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,222,1272859200"; d="scan'208";a="217891393" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 May 2010 10:23:57 -0400 X-IronPort-AV: E=Sophos;i="4.53,222,1272859200"; d="scan'208";a="462501975" 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; 13 May 2010 10:23:16 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX2.global.avaya.com ([2002:870b:3415::870b:3415]) with mapi; Thu, 13 May 2010 10:23:16 -0400 From: "WORLEY, Dale R (Dale)" To: Enrico Marocco , "Elwell, John" Date: Thu, 13 May 2010 10:21:32 -0400 Thread-Topic: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrycP0lBbQne4/RS9OCo36ibKsjjwANpkMy Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> , <4BEBAF4F.8080406@telecomitalia.it> In-Reply-To: <4BEBAF4F.8080406@telecomitalia.it> 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" , "R.Jesske@telekom.de" Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 14:25:03 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of En= rico Marocco [enrico.marocco@telecomitalia.it] Elwell, John wrote: > Basically I think there is only a single requirement here - provision > of a correct indication to a UAC when rejection comes from the PSTN. > I think that is a reasonable requirement and we should just go ahead > and do it, rather like we did with RFC 5876 when we extended the > range of messages that PAI/PPI could be used in. Speaking as a service provider, that is indeed what is really needed. The req draft does a decent job at framing it, maybe with a little too much IMS-speak. That said, can we move on and try to agree on simple solution for such a simple problem? _______________________________________ I am more of a "SIP bigot", but if the response is ultimately due to a PSTN= (SS7) operation, the Q.850 form of the Reason header seems an excellent wa= y of recording the SS7 response code. As John said, this can be legitimate= d very simply. And I expect many implementors think it is already valid an= d are doing so. Dale From HKaplan@acmepacket.com Thu May 13 08:49:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454863A6877 for ; Thu, 13 May 2010 08:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju+wilPymbrS for ; Thu, 13 May 2010 08:49:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B22A23A6B12 for ; Thu, 13 May 2010 08:49:40 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 13 May 2010 11:49:30 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 13 May 2010 11:49:29 -0400 From: Hadriel Kaplan To: DISPATCH Date: Thu, 13 May 2010 11:49:26 -0400 Thread-Topic: Proposed update to Session-ID charter, round-3 Thread-Index: AcrwbbD3I0kahOGNSc2Kyg+gjSbVgABc9BgQ Message-ID: <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 15:49:42 -0000 Below is a copy of the email with the current proposed charter. Cullen was concerned that without defining what end-to-end session or messa= ge-flow actually means in the charter, that we would not make progress in a= WG. Therefore, I propose the following text be added to the charter, afte= r the first paragraph: [begin] Since the definition of a higher-layer "session" of the same "message-flow"= is not already defined by SIP when it involves a B2BUA, the SIPSCOTCH char= ter's scope is more easily defined in terms of when two SIP dialogs of a B2= BUA are so related. For the purposes of this WG's charter, two or more SIP= dialogs on a B2BUA are the same higher-layer session when the following co= nditions are ALL true: - The B2BUA is a UAS for the dialog-forming transaction of one dialog, and = a UAC for the dialog-forming transaction(s) of the other dialog(s) - The B2BUA generates one or more dialog-forming requests on its UAC side b= ased on receiving the one on its UAS side, before the UAS-based dialog is i= n an established state - The B2BUA ties the fates of the dialogs, such that upon termination of th= e UAS-based dialog, the B2BUA would automatically terminate the UAC-based d= ialog(s); and vice-versa For out-of-dialog SIP requests which do not form dialogs, such as an out-of= -dialog SIP MESSAGE request, the same type of rules as stated above apply, = but only as applicable to a SIP transaction. Any solution documents from this working group may expand the scope of thei= r mechanism's correlation, if the working group so decides. [end] Comments? Good enough for now? -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Monday, May 10, 2010 2:22 PM >=20 > SIP Signaling-COmmunication Troubleshooting with Correlation Header > (SIPSCOTCH) Charter: > ---------------------------------- > The SIPSCOTCH working group is chartered to define a mechanism that allow= s > operators and monitoring equipment to correlate SIP messages and dialogs > of the same higher-level end-to-end "session" across multiple SIP device > hops for the same "message-flow", for the purpose of troubleshooting. In > particular, the mechanism must be able to allow such correlation across > SIP B2BUAs of as many functional types as possible, such as Application > Servers, Softswitches, PBXs, SBCs, etc. >=20 > Although other solutions may be possible, this working group will focus o= n > defining a new SIP Header field for such a purpose, similar to the Call-I= D > header field, in order to provide a simple, easily deployable mechanism > which can work across SIP domains. The SIP Call-ID header field value > itself is not usable for such correlation, because many B2BUAs must creat= e > a new Call-ID value on their UAC "side" in order to function properly, an= d > to comply with the rules of RFC 3261. >=20 > It should be noted that certain SIP B2BUAs perform a "topology-hiding" > function, as described in RFC 5853. The working group will take such > functions into account for the correlation mechanism, as well as provide > guidance for implementers of the mechanism to avoid triggering such a > function for the mechanism's header field value. >=20 > Lastly, although in certain environments such a mechanism may be usable > for dialog correlation in SIP state machines, it is not the goal of this > working group to address that usage. >=20 > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dec 2010 - New header specification to IESG (PS) >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From kpfleming@digium.com Thu May 13 09:30:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48FB3A683C for ; Thu, 13 May 2010 09:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.239 X-Spam-Level: X-Spam-Status: No, score=-104.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIvDxx94-QLt for ; Thu, 13 May 2010 09:30:10 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id C32E03A6B7F for ; Thu, 13 May 2010 09:29:45 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1OCbHz-0007V5-76 for dispatch@ietf.org; Thu, 13 May 2010 11:29:35 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 29E28D8026 for ; Thu, 13 May 2010 11:29:35 -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 Wlg1rY5ZTyF9 for ; Thu, 13 May 2010 11:29:34 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 97408D8023 for ; Thu, 13 May 2010 11:29:34 -0500 (CDT) Message-ID: <4BEC28EE.4060707@digium.com> Date: Thu, 13 May 2010 11:29:34 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: dispatch@ietf.org References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> X-Enigmail-Version: 1.0.1 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 16:30:11 -0000 On 05/13/2010 10:49 AM, Hadriel Kaplan wrote: > [begin] > Since the definition of a higher-layer "session" of the same "message-flow" is not already defined by SIP when it involves a B2BUA, the SIPSCOTCH charter's scope is more easily defined in terms of when two SIP dialogs of a B2BUA are so related. For the purposes of this WG's charter, two or more SIP dialogs on a B2BUA are the same higher-layer session when the following conditions are ALL true: > - The B2BUA is a UAS for the dialog-forming transaction of one dialog, and a UAC for the dialog-forming transaction(s) of the other dialog(s) > - The B2BUA generates one or more dialog-forming requests on its UAC side based on receiving the one on its UAS side, before the UAS-based dialog is in an established state > - The B2BUA ties the fates of the dialogs, such that upon termination of the UAS-based dialog, the B2BUA would automatically terminate the UAC-based dialog(s); and vice-versa This may not be true; a B2BUA that is really a PBX may not terminate the leftover dialog when it receives a termination indication for one of them. If you replaced 'would automatically terminate' with 'would be likely to terminate', that would probably take care of it. > For out-of-dialog SIP requests which do not form dialogs, such as an out-of-dialog SIP MESSAGE request, the same type of rules as stated above apply, but only as applicable to a SIP transaction. > > Any solution documents from this working group may expand the scope of their mechanism's correlation, if the working group so decides. > [end] -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From HKaplan@acmepacket.com Thu May 13 09:44:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95173A6C11 for ; Thu, 13 May 2010 09:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3D17k8x8TSK for ; Thu, 13 May 2010 09:44:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1D8B53A6B7F for ; Thu, 13 May 2010 09:44:25 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 13 May 2010 12:44:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 13 May 2010 12:44:14 -0400 From: Hadriel Kaplan To: "Kevin P. Fleming" , "dispatch@ietf.org" Date: Thu, 13 May 2010 12:44:08 -0400 Thread-Topic: [dispatch] Proposed update to Session-ID charter, round-3 Thread-Index: AcryuZNBJt88Gey5QaajjtO0WTnV7wAATGtA Message-ID: <430FC6BDED356B4C8498F634416644A91C13991009@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <4BEC28EE.4060707@digium.com> In-Reply-To: <4BEC28EE.4060707@digium.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 16:44:26 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Kevin P. Fleming > Sent: Thursday, May 13, 2010 12:30 PM >=20 > This may not be true; a B2BUA that is really a PBX may not terminate the > leftover dialog when it receives a termination indication for one of > them. If you replaced 'would automatically terminate' with 'would be > likely to terminate', that would probably take care of it. Can you describe such a case? =20 -hadriel From adam@nostrum.com Thu May 13 09:56:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324F53A68E8 for ; Thu, 13 May 2010 09:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HSxPFvikcar for ; Thu, 13 May 2010 09:56:42 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id AC8E63A68C0 for ; Thu, 13 May 2010 09:56:41 -0700 (PDT) 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 o4DGuRgY028795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 11:56:27 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BEC2F3A.9020309@nostrum.com> Date: Thu, 13 May 2010 11:56:26 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <4BEC28EE.4060707@digium.com> <430FC6BDED356B4C8498F634416644A91C13991009@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13991009@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 16:56:46 -0000 On 5/13/10 11:44 AM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Kevin P. Fleming >> Sent: Thursday, May 13, 2010 12:30 PM >> >> This may not be true; a B2BUA that is really a PBX may not terminate the >> leftover dialog when it receives a termination indication for one of >> them. If you replaced 'would automatically terminate' with 'would be >> likely to terminate', that would probably take care of it. >> > Can you describe such a case? Think about how this kind of system would handle intra-PBX call transfer. Alice (from outside of Bob's company) calls Bob through Bob's PBX (which is acting as a SIP B2BUA). You have two dialogs (Alice <-> PBX, PBX <-> Bob). Bob decides to transfer the call to Carol (who is served by the same PBX as Bob). While this could be done by REFERing all the way back to Alice, what I've seen PBXes typically do in these circumstances is to simply set up a new dialog with Carol (PBX <-> Carol), and associate it with the original Alice <-> PBX dialog. So, while the PBX <-> Bob dialog has terminated, the PBX does not "automatically terminate" the associated Alice <-> PBX dialog. See, this is the difficulty in specifying anything about protocol behavior *across* a B2BUA: in order to serve their purposes, B2BUAs inherently do whatever the heck they want. Positive statements about what they will or will not do (e.g., "would automatically terminate") are pretty much assured to be wrong for some subset of B2BUAs. /a From mperumal@cisco.com Thu May 13 10:32:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23ADA3A6C91 for ; Thu, 13 May 2010 10:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.626 X-Spam-Level: X-Spam-Status: No, score=-8.626 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0Q+DxEXw1N1 for ; Thu, 13 May 2010 10:32:05 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1470B3A6BA1 for ; Thu, 13 May 2010 10:30:23 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH/T60tAaHte/2dsb2JhbACeIXGkHZlBhRIEgz4 X-IronPort-AV: E=Sophos;i="4.53,223,1272844800"; d="scan'208";a="255734505" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-2.cisco.com with ESMTP; 13 May 2010 17:30:12 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4DHUBTr027237; Thu, 13 May 2010 17:30:12 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 May 2010 23:00:12 +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, 13 May 2010 23:00:09 +0530 Message-ID: <1D062974A4845E4D8A343C653804920202B879FE@XMB-BGL-414.cisco.com> In-Reply-To: <4BEC2F3A.9020309@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposed update to Session-ID charter, round-3 Thread-Index: AcryvUOD6v8IfflgQaWpA6ChQVgfEAAAusMA References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <4BEC28EE.4060707@digium.com><430FC6BDED356B4C8498F634416644A91C13991009@mail> <4BEC2F3A.9020309@nostrum.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Adam Roach" , "Hadriel Kaplan" X-OriginalArrivalTime: 13 May 2010 17:30:12.0027 (UTC) FILETIME=[F10D48B0:01CAF2C1] Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 17:32:06 -0000 Here is another use-case that typically happens in center use-case:=20 - A customer call lands on a B2BUA that runs an Interactive Voice Response (IVR) application. - The application presents a number of options to the user to reach different departments. - The customer selects a particular option. The B2BUA places an outbound call to an agent and associates the two dialogs. - The agent provides some information to the customer and disconnects. - The application once again presents a number of options to the customer to reach other departments. A calling card application running on a B2BUA that provides an option for the customer to press long '#' anytime during the call and connect with a different person would be another use-case. Muthu |-----Original Message----- |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf |Of Adam Roach |Sent: Thursday, May 13, 2010 10:26 PM |To: Hadriel Kaplan |Cc: dispatch@ietf.org |Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 | |On 5/13/10 11:44 AM, Hadriel Kaplan wrote: |> |>> -----Original Message----- |>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On |>> Behalf Of Kevin P. Fleming |>> Sent: Thursday, May 13, 2010 12:30 PM |>> |>> This may not be true; a B2BUA that is really a PBX may not terminate the |>> leftover dialog when it receives a termination indication for one of |>> them. If you replaced 'would automatically terminate' with 'would be |>> likely to terminate', that would probably take care of it. |>> |> Can you describe such a case? | |Think about how this kind of system would handle intra-PBX call transfer. | |Alice (from outside of Bob's company) calls Bob through Bob's PBX (which |is acting as a SIP B2BUA). You have two dialogs (Alice <-> PBX, PBX <-> |Bob). Bob decides to transfer the call to Carol (who is served by the |same PBX as Bob). While this could be done by REFERing all the way back |to Alice, what I've seen PBXes typically do in these circumstances is to |simply set up a new dialog with Carol (PBX <-> Carol), and associate it |with the original Alice <-> PBX dialog. | |So, while the PBX <-> Bob dialog has terminated, the PBX does not |"automatically terminate" the associated Alice <-> PBX dialog. | |See, this is the difficulty in specifying anything about protocol |behavior *across* a B2BUA: in order to serve their purposes, B2BUAs |inherently do whatever the heck they want. Positive statements about |what they will or will not do (e.g., "would automatically terminate") |are pretty much assured to be wrong for some subset of B2BUAs. | |/a |_______________________________________________ |dispatch mailing list |dispatch@ietf.org |https://www.ietf.org/mailman/listinfo/dispatch From mperumal@cisco.com Thu May 13 10:36:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4EB3A6C7D for ; Thu, 13 May 2010 10:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.813 X-Spam-Level: X-Spam-Status: No, score=-9.813 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKuzrw+rc-8B for ; Thu, 13 May 2010 10:36:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9C5FD3A6C6E for ; Thu, 13 May 2010 10:36:06 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANbV60tAaHte/2dsb2JhbACeIXGkG5k+hRIEgz4 X-IronPort-AV: E=Sophos;i="4.53,223,1272844800"; d="scan'208";a="325727699" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-1.cisco.com with ESMTP; 13 May 2010 17:35:56 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4DHZt01028246; Thu, 13 May 2010 17:35:55 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 May 2010 23:04:48 +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, 13 May 2010 23:04:47 +0530 Message-ID: <1D062974A4845E4D8A343C653804920202B87A00@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920202B879FE@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposed update to Session-ID charter, round-3 Thread-Index: AcryvUOD6v8IfflgQaWpA6ChQVgfEAAAusMAAACGe+A= References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <4BEC28EE.4060707@digium.com><430FC6BDED356B4C8498F634416644A91C13991009@mail><4BEC2F3A.9020309@nostrum.com> <1D062974A4845E4D8A343C653804920202B879FE@XMB-BGL-414.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Adam Roach" , "Hadriel Kaplan" X-OriginalArrivalTime: 13 May 2010 17:34:48.0421 (UTC) FILETIME=[95CBA950:01CAF2C2] Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 17:36:40 -0000 missed a word -:) typically happens in 'contact' center.. Muthu |-----Original Message----- |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf |Of Muthu ArulMozhi Perumal (mperumal) |Sent: Thursday, May 13, 2010 11:00 PM |To: Adam Roach; Hadriel Kaplan |Cc: dispatch@ietf.org |Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 | |Here is another use-case that typically happens in center use-case: |- A customer call lands on a B2BUA that runs an Interactive Voice |Response (IVR) application. |- The application presents a number of options to the user to reach |different departments. |- The customer selects a particular option. The B2BUA places an outbound |call to an agent and associates the two dialogs. |- The agent provides some information to the customer and disconnects. |- The application once again presents a number of options to the |customer to reach other departments. | |A calling card application running on a B2BUA that provides an option |for the customer to press long '#' anytime during the call and connect |with a different person would be another use-case. | |Muthu | ||-----Original Message----- ||From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On |Behalf ||Of Adam Roach ||Sent: Thursday, May 13, 2010 10:26 PM ||To: Hadriel Kaplan ||Cc: dispatch@ietf.org ||Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 || ||On 5/13/10 11:44 AM, Hadriel Kaplan wrote: ||> ||>> -----Original Message----- ||>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] |On ||>> Behalf Of Kevin P. Fleming ||>> Sent: Thursday, May 13, 2010 12:30 PM ||>> ||>> This may not be true; a B2BUA that is really a PBX may not terminate |the ||>> leftover dialog when it receives a termination indication for one of ||>> them. If you replaced 'would automatically terminate' with 'would be ||>> likely to terminate', that would probably take care of it. ||>> ||> Can you describe such a case? || ||Think about how this kind of system would handle intra-PBX call |transfer. || ||Alice (from outside of Bob's company) calls Bob through Bob's PBX |(which ||is acting as a SIP B2BUA). You have two dialogs (Alice <-> PBX, PBX <-> ||Bob). Bob decides to transfer the call to Carol (who is served by the ||same PBX as Bob). While this could be done by REFERing all the way back ||to Alice, what I've seen PBXes typically do in these circumstances is |to ||simply set up a new dialog with Carol (PBX <-> Carol), and associate it ||with the original Alice <-> PBX dialog. || ||So, while the PBX <-> Bob dialog has terminated, the PBX does not ||"automatically terminate" the associated Alice <-> PBX dialog. || ||See, this is the difficulty in specifying anything about protocol ||behavior *across* a B2BUA: in order to serve their purposes, B2BUAs ||inherently do whatever the heck they want. Positive statements about ||what they will or will not do (e.g., "would automatically terminate") ||are pretty much assured to be wrong for some subset of B2BUAs. || ||/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 kpfleming@digium.com Thu May 13 11:30:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812C03A6C32 for ; Thu, 13 May 2010 11:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.512 X-Spam-Level: X-Spam-Status: No, score=-105.512 tagged_above=-999 required=5 tests=[AWL=1.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbtxG9DfqeBY for ; Thu, 13 May 2010 11:30:16 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id CC96C3A684F for ; Thu, 13 May 2010 11:29:39 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1OCdA1-0000dm-8i; Thu, 13 May 2010 13:29:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 2C24CD8023; Thu, 13 May 2010 13:29:29 -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 greBthZOYx7F; Thu, 13 May 2010 13:29:28 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id B0F32D8025; Thu, 13 May 2010 13:29:28 -0500 (CDT) Message-ID: <4BEC4508.6030506@digium.com> Date: Thu, 13 May 2010 13:29:28 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Adam Roach References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <4BEC28EE.4060707@digium.com> <430FC6BDED356B4C8498F634416644A91C13991009@mail> <4BEC2F3A.9020309@nostrum.com> In-Reply-To: <4BEC2F3A.9020309@nostrum.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 18:30:18 -0000 On 05/13/2010 11:56 AM, Adam Roach wrote: > On 5/13/10 11:44 AM, Hadriel Kaplan wrote: >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Kevin P. Fleming >>> Sent: Thursday, May 13, 2010 12:30 PM >>> >>> This may not be true; a B2BUA that is really a PBX may not terminate the >>> leftover dialog when it receives a termination indication for one of >>> them. If you replaced 'would automatically terminate' with 'would be >>> likely to terminate', that would probably take care of it. >>> >> Can you describe such a case? > > Think about how this kind of system would handle intra-PBX call transfer. > > Alice (from outside of Bob's company) calls Bob through Bob's PBX (which > is acting as a SIP B2BUA). You have two dialogs (Alice <-> PBX, PBX <-> > Bob). Bob decides to transfer the call to Carol (who is served by the > same PBX as Bob). While this could be done by REFERing all the way back > to Alice, what I've seen PBXes typically do in these circumstances is to > simply set up a new dialog with Carol (PBX <-> Carol), and associate it > with the original Alice <-> PBX dialog. > > So, while the PBX <-> Bob dialog has terminated, the PBX does not > "automatically terminate" the associated Alice <-> PBX dialog. > > See, this is the difficulty in specifying anything about protocol > behavior *across* a B2BUA: in order to serve their purposes, B2BUAs > inherently do whatever the heck they want. Positive statements about > what they will or will not do (e.g., "would automatically terminate") > are pretty much assured to be wrong for some subset of B2BUAs. Yes, Adam hit it right on the nose. There are other cases as well... Alice calls Bob's PBX, the PBX calls Bob, he answers, he chats her up for a while, and then he hangs up and the PBX keeps Alice's dialog alive to connect her call to a post-call 'customer service survey'. This sort of thing happens without Alice's UA being involved except as part of the initial dialog creation, partly because these devices have provided this behavior for decades prior to the invention of SIP, when the calling endpoint wasn't able to be REFERed to a different URI, and there's been no particular reason to change the implementation of the mechanism just because SIP endpoints are involved. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From laura.liess.dt@googlemail.com Thu May 13 12:09:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39883A68F9 for ; Thu, 13 May 2010 12:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usFC3iERlS0q for ; Thu, 13 May 2010 12:09:46 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id A34653A6B5B for ; Thu, 13 May 2010 12:09:45 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so988803fgb.13 for ; Thu, 13 May 2010 12:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=0gf66YZSSx90kTBh/ulFvIRAYpzQLAIFFvbWN2221Xk=; b=rypw5rB3yfzgY8kLKMhzR6FFbq19cg8byChiX2eRHCrgRtn7ut5X1EqnopomyvOOcD 8bTmBl9mxgn4YY4qmRHeWxJky0uHrpRSvXC3Oc+nRkUrWyduyCQ1TAvcPCIhdx1ilWWM 9ov6StUSIK9hr1Dca44qQ1TxbdSj1KNI/UTeU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=xl+LWxsM+cTlkvpoKBWKHchvPMdBKhO59GEtHpJ1UTuUV8n4ZsV4cGqIcCpBZyoSnk PiZF9EkE8tRHKSFpKAr6mq27PrgZ/r6wGhxkONcHQ7M/XJJVi6ot3yI95SZr6V9xN4Rc jBADFeYu69U/JwOAv6+5/gmwIlcjL/nywx6Pk= Received: by 10.87.50.37 with SMTP id c37mr1175551fgk.68.1273777763834; Thu, 13 May 2010 12:09:23 -0700 (PDT) Received: from LauraLiess (p54A7F629.dip.t-dialin.net [84.167.246.41]) by mx.google.com with ESMTPS id l12sm11974281fgb.22.2010.05.13.12.09.22 (version=SSLv3 cipher=RC4-MD5); Thu, 13 May 2010 12:09:22 -0700 (PDT) From: Laura Liess To: "'Hadriel Kaplan'" , , References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <430FC6BDED356B4C8498F634416644A91C13990F46@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13990F46@mail> Date: Thu, 13 May 2010 21:09:22 +0200 Message-ID: <4bec4e62.0c58560a.188d.ffff9205@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQABh7EkAABBtS0A== Content-Language: de Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 19:09:50 -0000 Hadriel, Alert-Info URNs and Reason in responses are two different things.=20 Alert-Info URNs are names for ring tones which has to be rendered to the users. They can be carried in INVITE or 18x responses and resolved by = SIP end devices according to local rules into a specific tones or text. They = are not involved in applications logic neither in SIP nor in PSTN. =20 Reason in responses is about extending the usage of the Reason header defined in RFC3326 to SIP responses. The RFC 3326 currently allows it = only in SIP requests. Typical use cases are to carry it in CANCEL or BYE = requests (see 3326 message flows) or in error responses. A typical message flows = for Reason in responses is shown in an earlier version of Roland's draft, = e.g. http://tools.ietf.org/id/draft-jesske-sipping-etsi-ngn-reason-04.txt, = where the reason is sent in 603 Decline. You can't do this with the Alert-Info header. Thanks, Laura -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im > Auftrag von Hadriel Kaplan > Gesendet: Donnerstag, 13. Mai 2010 15:48 > An: R.Jesske@telekom.de; dispatch@ietf.org > Betreff: Re: [dispatch] Reason In responses (draft-jesske-dispatch- > reason-in-responses-02) >=20 >=20 > Hi Roland, > I wasn't sure if you were still planning on moving forward with this > draft, given the Alert-Info URN draft. I thought maybe instead you = were > going to define a mapping of Q.850 response codes to "semantic" URNs. = So > since you're not, can you put some text in your draft (or email) why = not, > and what this Reason header in responses would be used for compared to > Alert-Info? I think it may help implementers to know what's what. >=20 > -hadriel >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On > > Behalf Of R.Jesske@telekom.de > > Sent: Wednesday, May 12, 2010 10:05 PM > > > > Dear all, > > I have asked for comments on the two drafts mentioned below. > > So far I didn't get any. Does that mean that people are happy now = with > the > > content and we could proceed with it? > > > > Thank you and Best Regrads > > > > Roland > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Thu May 13 12:35:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D151A3A6A1B for ; Thu, 13 May 2010 12:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohQ758C4c8O9 for ; Thu, 13 May 2010 12:35:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2DE043A62C1 for ; Thu, 13 May 2010 12:35:55 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 13 May 2010 15:35:44 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 13 May 2010 15:35:44 -0400 From: Hadriel Kaplan To: Adam Roach Date: Thu, 13 May 2010 15:35:42 -0400 Thread-Topic: [dispatch] Proposed update to Session-ID charter, round-3 Thread-Index: AcryvVPRB9QvvJD6SSqYH2Bi83AVCgAAn6zw Message-ID: <430FC6BDED356B4C8498F634416644A91C1399109D@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <4BEC28EE.4060707@digium.com> <430FC6BDED356B4C8498F634416644A91C13991009@mail> <4BEC2F3A.9020309@nostrum.com> In-Reply-To: <4BEC2F3A.9020309@nostrum.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] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 19:35:56 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, May 13, 2010 12:56 PM > To: Hadriel Kaplan >=20 > Think about how this kind of system would handle intra-PBX call transfer. >=20 > Alice (from outside of Bob's company) calls Bob through Bob's PBX (which > is acting as a SIP B2BUA). You have two dialogs (Alice <-> PBX, PBX <-> > Bob). Bob decides to transfer the call to Carol (who is served by the > same PBX as Bob). While this could be done by REFERing all the way back > to Alice, what I've seen PBXes typically do in these circumstances is to > simply set up a new dialog with Carol (PBX <-> Carol), and associate it > with the original Alice <-> PBX dialog. >=20 > So, while the PBX <-> Bob dialog has terminated, the PBX does not > "automatically terminate" the associated Alice <-> PBX dialog. Ahh, but I *did* take that case into account (or at least I meant to).=20 I'm explicitly ruling the new transferred-to dialog *out*, as not the same = high-level session. I'd argue that if Bob sent a REFER (or pressed some bu= tton, whatever) and the PBX created a new dialog to Carol out of it, it's n= ot logically different for that new Carol-dialog than if the REFER went all= the way back to Alice and she had created a new dialog to Carol from it. = It's not the same session, from the perspective of SIPSCOTCH's correlation = scope.=20 But it's true that the proposed charter rules wouldn't quite work for even = the original dialog pair (Alice-PBX-Bob), because of the rule: "-The B2BUA ties the fates of the dialogs, such that upon termination of th= e UAS-based dialog, the B2BUA would automatically terminate the UAC-based d= ialog(s); and vice-versa" The problem is the word "upon" and "automatically" which imply instantaneou= sly and under any condition, as Kevin was pointing out. Maybe the rule wou= ld be better phrased as: "-The B2BUA ties the fates of the dialogs, such that upon termination of th= e UAS-based dialog, the B2BUA would by-default terminate the UAC-based dial= og(s), if it did not have any additional user-input; and vice-versa"? -hadriel From adam@nostrum.com Thu May 13 12:45:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538993A694F for ; Thu, 13 May 2010 12:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKNJpV8oVWQC for ; Thu, 13 May 2010 12:45:15 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D18653A6A27 for ; Thu, 13 May 2010 12:45:13 -0700 (PDT) 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 o4DJiv82041809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 14:44:58 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BEC56B9.7070208@nostrum.com> Date: Thu, 13 May 2010 14:44:57 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <4BEC28EE.4060707@digium.com> <430FC6BDED356B4C8498F634416644A91C13991009@mail> <4BEC2F3A.9020309@nostrum.com> <430FC6BDED356B4C8498F634416644A91C1399109D@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C1399109D@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 19:45:16 -0000 On 5/13/10 2:35 PM, Hadriel Kaplan wrote: > Ahh, but I *did* take that case into account (or at least I meant to). > I'm explicitly ruling the new transferred-to dialog *out*, as not the same high-level session. I'd argue that if Bob sent a REFER (or pressed some button, whatever) and the PBX created a new dialog to Carol out of it, it's not logically different for that new Carol-dialog than if the REFER went all the way back to Alice and she had created a new dialog to Carol from it. It's not the same session, from the perspective of SIPSCOTCH's correlation scope. > > But it's true that the proposed charter rules wouldn't quite work for even the original dialog pair (Alice-PBX-Bob), because of the rule: > "-The B2BUA ties the fates of the dialogs, such that upon termination of the UAS-based dialog, the B2BUA would automatically terminate the UAC-based dialog(s); and vice-versa" > > The problem is the word "upon" and "automatically" which imply instantaneously and under any condition, as Kevin was pointing out. Maybe the rule would be better phrased as: > "-The B2BUA ties the fates of the dialogs, such that upon termination of the UAS-based dialog, the B2BUA would by-default terminate the UAC-based dialog(s), if it did not have any additional user-input; and vice-versa"? > Actually, I think the most important part of my email was the part you chose not to address: once you start constraining what B2BUAs do, you've strayed off into territory that makes you automatically wrong. You can keep patching your description to try to accommodate the use cases people come up with over the next few days or weeks -- but unless your crystal ball is a whole heck of a lot more magic than everyone else's [1], you're going to miss some. /a [1] And if it is, I gander you'd have retired on stock market earnings by now. From HKaplan@acmepacket.com Thu May 13 12:47:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906FA3A6C87 for ; Thu, 13 May 2010 12:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgMdD9i7hIXS for ; Thu, 13 May 2010 12:47:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8BBA63A6C02 for ; Thu, 13 May 2010 12:47:23 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 13 May 2010 15:47:13 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 13 May 2010 15:47:13 -0400 From: Hadriel Kaplan To: "Muthu ArulMozhi Perumal (mperumal)" , Adam Roach Date: Thu, 13 May 2010 15:47:11 -0400 Thread-Topic: [dispatch] Proposed update to Session-ID charter, round-3 Thread-Index: AcryvUOD6v8IfflgQaWpA6ChQVgfEAAAusMAAATW2UA= Message-ID: <430FC6BDED356B4C8498F634416644A91C139910A6@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <4BEC28EE.4060707@digium.com><430FC6BDED356B4C8498F634416644A91C13991009@mail> <4BEC2F3A.9020309@nostrum.com> <1D062974A4845E4D8A343C653804920202B879FE@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920202B879FE@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 19:47:27 -0000 > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Thursday, May 13, 2010 1:30 PM > To: Adam Roach; Hadriel Kaplan >=20 > Here is another use-case that typically happens in center use-case: > - A customer call lands on a B2BUA that runs an Interactive Voice > Response (IVR) application. > - The application presents a number of options to the user to reach > different departments. > - The customer selects a particular option. The B2BUA places an outbound > call to an agent and associates the two dialogs. > - The agent provides some information to the customer and disconnects. > - The application once again presents a number of options to the > customer to reach other departments. >=20 > A calling card application running on a B2BUA that provides an option > for the customer to press long '#' anytime during the call and connect > with a different person would be another use-case. Right, and my current proposal rules those cases out of being the same corr= elated "session". (the same session for purposes of SIPSCOTCH that is) Because the original dialog would have gotten to the established state befo= re making those other calls from the App server, and because of the automat= ic tear-down rule. Is that an actual problem, though? I mean do we need to be able to correla= te such calls to every new dialog using a SIP header? -hadriel From adam@nostrum.com Thu May 13 12:49:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5653A6A27 for ; Thu, 13 May 2010 12:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NRWKPgwLqnX for ; Thu, 13 May 2010 12:49:20 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 03F633A694F for ; Thu, 13 May 2010 12:49:11 -0700 (PDT) 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 o4DJmtOq042167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 14:48:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BEC57A7.3010708@nostrum.com> Date: Thu, 13 May 2010 14:48:55 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <4BEC28EE.4060707@digium.com> <430FC6BDED356B4C8498F634416644A91C13991009@mail> <4BEC2F3A.9020309@nostrum.com> <430FC6BDED356B4C8498F634416644A91C1399109D@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C1399109D@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 19:49:21 -0000 On 5/13/10 2:35 PM, Hadriel Kaplan wrote: > I'm explicitly ruling the new transferred-to dialog *out*, as not the > same high-level session. I'd argue that if Bob sent a REFER (or > pressed some button, whatever) and the PBX created a new dialog to > Carol out of it, it's not logically different for that new > Carol-dialog than if the REFER went all the way back to Alice and she > had created a new dialog to Carol from it. It's not the same session, > from the perspective of SIPSCOTCH's correlation scope. And, upon further inspection, this seems extremely artificial also. What if the thing that Alice reaches first isn't Bob, but a "parked call queue server" that routes to Carol only when she becomes available? Without the PBX having some pretty intimate knowledge about what each extension does, I don't think you're going to be able to have any sane bright line between what is and what isn't semantically the "same session" (unless it is completely inclusive). /a From HKaplan@acmepacket.com Thu May 13 12:52:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78993A6BF3 for ; Thu, 13 May 2010 12:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u6cGMmYe+ux for ; Thu, 13 May 2010 12:52:43 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B6FEE3A6CE0 for ; Thu, 13 May 2010 12:52:20 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 13 May 2010 15:52:10 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 13 May 2010 15:52:10 -0400 From: Hadriel Kaplan To: Adam Roach Date: Thu, 13 May 2010 15:52:08 -0400 Thread-Topic: [dispatch] Proposed update to Session-ID charter, round-3 Thread-Index: Acry1NM5718PUOySTrqiUxffAPWN5gAAEqMQ Message-ID: <430FC6BDED356B4C8498F634416644A91C139910AA@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <4BEC28EE.4060707@digium.com> <430FC6BDED356B4C8498F634416644A91C13991009@mail> <4BEC2F3A.9020309@nostrum.com> <430FC6BDED356B4C8498F634416644A91C1399109D@mail> <4BEC56B9.7070208@nostrum.com> In-Reply-To: <4BEC56B9.7070208@nostrum.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] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 19:52:44 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: Thursday, May 13, 2010 3:45 PM >=20 > Actually, I think the most important part of my email was the part you > chose not to address: once you start constraining what B2BUAs do, you've > strayed off into territory that makes you automatically wrong. You can > keep patching your description to try to accommodate the use cases > people come up with over the next few days or weeks -- but unless your > crystal ball is a whole heck of a lot more magic than everyone else's > [1], you're going to miss some. Nope, I was going to respond to it separately, because it seemed to me to b= e a more general problem. But I'll use this email as the vehicle. :) Right, so we can either give up entirely, or live with not covering every p= ossible thing. Note that I'm not "constraining" what B2BAU's do - I know t= hey do anything - I'm just constraining when the mechanism needs to be able= correlate multiple dialogs. I'm not preventing B2BAU's from doing whateve= r they want (nor could I). This is to help troubleshooting - it's not a SI= P state-machine dialog correlation. Maybe a better alternative is to actually get rid of such rules and say "Tw= o or more dialogs of a B2BUA are correlated under whatever conditions they = feel would aid in troubleshooting the dialogs"? (or something along those l= ines) -hadriel From adam@nostrum.com Thu May 13 12:55:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546E63A6D10 for ; Thu, 13 May 2010 12:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rczTcePDw5-6 for ; Thu, 13 May 2010 12:55:37 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A6B583A6D0D for ; Thu, 13 May 2010 12:55:34 -0700 (PDT) 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 o4DJtMld042686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 14:55:22 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BEC592A.3010705@nostrum.com> Date: Thu, 13 May 2010 14:55:22 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <4BEC28EE.4060707@digium.com> <430FC6BDED356B4C8498F634416644A91C13991009@mail> <4BEC2F3A.9020309@nostrum.com> <430FC6BDED356B4C8498F634416644A91C1399109D@mail> <4BEC56B9.7070208@nostrum.com> <430FC6BDED356B4C8498F634416644A91C139910AA@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C139910AA@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 19:55:38 -0000 On 5/13/10 2:52 PM, Hadriel Kaplan wrote: > Maybe a better alternative is to actually get rid of such rules and > say "Two or more dialogs of a B2BUA are correlated under whatever > conditions they feel would aid in troubleshooting the dialogs"? (or > something along those lines) If we're going to do this work, that seems the most reasonable direction to take it to me. /a From dworley@avaya.com Thu May 13 13:38:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB6A3A68ED for ; Thu, 13 May 2010 13:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cP6hYE3N+gO for ; Thu, 13 May 2010 13:38:43 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 40B3A3A6837 for ; Thu, 13 May 2010 13:38:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,224,1272859200"; d="scan'208";a="217957159" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 May 2010 16:38:33 -0400 X-IronPort-AV: E=Sophos;i="4.53,224,1272859200"; d="scan'208";a="474800386" 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; 13 May 2010 16:38:33 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX2.global.avaya.com ([2002:870b:3415::870b:3415]) with mapi; Thu, 13 May 2010 16:38:32 -0400 From: "WORLEY, Dale R (Dale)" To: "dispatch@ietf.org" Date: Thu, 13 May 2010 16:38:32 -0400 Thread-Topic: Alert-Info thoughts Thread-Index: AQHK8tmpCT7jN9cbHkeK4KOTMVPknQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Alert-Info thoughts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 20:38:44 -0000 The charter is probably well enough baked. We can adjust the details of wh= at we do later, regardless of what the charter says. It might be useful to replace the terms "semantic" and "non-semantic", as t= hey're not very clear. I've been thinking of "intentional" vs. "rendering"= : An "intentional URN" tells something about the status of the dialog, a "= rendering URN" tells something about how the alert/ringback signal is to be= rendered. The critical difference between "Alert URNs" (whatever SIP syntax we use to= carry them) and status codes is that we expect there to be a small set of = status codes so that automata can act upon them reliably. The space of Ale= rt URNs is expected to be broad and extensible, and likely to have numerous= extensions that are proprietary or for use in specific applications (e.g.,= IMS). In particular, there is a market need for the Alert URN mechanism t= o support forward compatibility of the signaling features of existing non-S= IP telephone systems. To prevent chaos, Alert URNs do *not* control the ac= tions of automata. It is also assumed that almost all UAs can render disti= nctly only a small subset of Alert URNs, and the mechanism should permit an= d support such "best efforts" rendering. Conversely, if these two categories of signal (SIP response codes and Alert= URNs) are not distinct enough, we should not create an "Alert URN" mechani= sm. It is probably open-ended the set of messages that could carry Alert URNs. = INVITE is obvious, but for the same reason MESSAGE or any dialog-forming m= essage could potentially carry one. Similarly, re-INVITE and UPDATE and an= y other request that performs a "major" change to a dialog might need to ca= rry one. In regard to responses, we can probably safely restrict Alert URN= s to the 18x family among provisional responses, though we might want to al= low them in *any* final response. We can generalize slightly the current proposals to create a framework that= will allow almost unlimited flexibility, with a standardized algorithm for= UAs to choose the "best fit" rendering from the small set of renderings th= at they support. That is, let the marketers go wild without bothering anyo= ne. More about that later... Dale From laura.liess.dt@googlemail.com Thu May 13 13:52:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683993A6958 for ; Thu, 13 May 2010 13:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMU7OeKJCExf for ; Thu, 13 May 2010 13:52:41 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 1680C3A6927 for ; Thu, 13 May 2010 13:52:39 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so1026002fgb.13 for ; Thu, 13 May 2010 13:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=tsuDRgp7XV6MAxSDOdUR6MmrFR/tdTJGp995FuAeYKg=; b=U/Q9eoW3UdaXKJbuNRmbCTsFMJ4jUYzDr5mEaOQr7a2z5n/x8ne354Zolhtl9zpflp 0aupznCXkZfx1wk2ST+Du1iwlucVMSUAXHPHT/orjSOOI0w0TFej15lOlirMqfDA0Guh 7eAIlqNPY0IE+xlOOYFM/KjeuLArtGyUtp9eo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=hHPSw8o11RsdF05tIu4GcNq1A6kDJ+BMTilfu/k56lFylXMlwixLSIFEmTw9rNKgvD FgWE9AdIL/Rza7pgbS94HcHyNIufgsu4n31pZi3TfO2wpl71/IDv3bX6fPi3y/lz9thK 09vUHesCVm2MhnBHY9LGF4PKTvkc/uKcfznPY= Received: by 10.87.49.36 with SMTP id b36mr1346956fgk.57.1273783946931; Thu, 13 May 2010 13:52:26 -0700 (PDT) Received: from LauraLiess (p54A7F629.dip.t-dialin.net [84.167.246.41]) by mx.google.com with ESMTPS id 4sm6264895fgg.22.2010.05.13.13.52.25 (version=SSLv3 cipher=RC4-MD5); Thu, 13 May 2010 13:52:26 -0700 (PDT) From: Laura Liess To: "'Hadriel Kaplan'" References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <4BEC28EE.4060707@digium.com> <430FC6BDED356B4C8498F634416644A91C13991009@mail> <4BEC2F3A.9020309@nostrum.com> <430FC6BDED356B4C8498F634416644A91C1399109D@mail> <4BEC56B9.7070208@nostrum.com> <430FC6BDED356B4C8498F634416644A91C139910AA@mail> <4BEC592A.3010705@nostrum.com> In-Reply-To: <4BEC592A.3010705@nostrum.com> Date: Thu, 13 May 2010 22:52:25 +0200 Message-ID: <4bec668a.0407560a.4889.ffffa7aa@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acry1j6PUGyMs+u3QPKmK5/hqsMgEAAB4czw Content-Language: de Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 20:52:42 -0000 +1 Laura=20 > -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im > Auftrag von Adam Roach > Gesendet: Donnerstag, 13. Mai 2010 21:55 > An: Hadriel Kaplan > Cc: dispatch@ietf.org > Betreff: Re: [dispatch] Proposed update to Session-ID charter, round-3 >=20 > On 5/13/10 2:52 PM, Hadriel Kaplan wrote: > > Maybe a better alternative is to actually get rid of such rules and > > say "Two or more dialogs of a B2BUA are correlated under whatever > > conditions they feel would aid in troubleshooting the dialogs"? (or > > something along those lines) >=20 > If we're going to do this work, that seems the most reasonable = direction > to take it to me. >=20 > /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Thu May 13 14:40:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73583A684C for ; Thu, 13 May 2010 14:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZwaChE-04xO for ; Thu, 13 May 2010 14:40:24 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BF2A63A63C9 for ; Thu, 13 May 2010 14:40:21 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 13 May 2010 17:40:11 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 13 May 2010 17:40:11 -0400 From: Hadriel Kaplan To: DISPATCH Date: Thu, 13 May 2010 17:40:10 -0400 Thread-Topic: Proposed update to Session-ID charter, round-4 Thread-Index: AcrwbbD3I0kahOGNSc2Kyg+gjSbVgABc9BgQAECa43A= Message-ID: <430FC6BDED356B4C8498F634416644A91C139910E5@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Proposed update to Session-ID charter, round-4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 21:40:25 -0000 How about this... SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCO= TCH) Charter: ---------------------------------- The SIPSCOTCH working group is chartered to define a mechanism that allows = operators and monitoring equipment to correlate SIP messages and dialogs of= the same higher-level end-to-end "session" across multiple SIP device hops= for the same "message-flow", for the purpose of troubleshooting. In parti= cular, the mechanism must be able to allow such correlation across SIP B2BU= As of as many functional types as possible, such as Application Servers, So= ftswitches, PBXs, SBCs, etc. The definition of a higher-layer "session" of the same "message-flow" is no= t defined by SIP when it involves a B2BUA, and is difficult to normatively = define in practice. For the purposes of this WG charter's scope, two or mo= re dialogs of a B2BUA are correlated under whatever conditions they feel wo= uld aid in troubleshooting the dialogs, by identifying them as belonging to= the same higher-level session. Any solution documents from this working g= roup may expand or constrain the scope of their mechanism's correlation, if= the working group so decides. Although other solutions may be possible, this working group will focus on = defining a new SIP Header field for such a purpose, similar to the Call-ID = header field, in order to provide a simple, easily deployable mechanism whi= ch can work across SIP domains. The SIP Call-ID header field value itself i= s not usable for such correlation, because many B2BUAs must create a new Ca= ll-ID value on their UAC "side" in order to function properly, and to compl= y with the rules of RFC 3261.=20 It should be noted that certain SIP B2BUAs perform a "topology-hiding" func= tion, as described in RFC 5853. The working group will take such functions= into account for the correlation mechanism, as well as provide guidance fo= r implementers of the mechanism to avoid triggering such a function for the= mechanism's header field value. Lastly, although in certain environments such a mechanism may be usable for= dialog correlation in SIP state machines, it is not the goal of this worki= ng group to address that usage. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dec 2010 - New header specification to IESG (PS) From kpfleming@digium.com Thu May 13 15:28:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B003A6881 for ; Thu, 13 May 2010 15:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.6 X-Spam-Level: X-Spam-Status: No, score=-105.6 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e55+jUQLQ3TN for ; Thu, 13 May 2010 15:28:14 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id CDD853A67FA for ; Thu, 13 May 2010 15:28:13 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1OCgst-0003CK-Nb for dispatch@ietf.org; Thu, 13 May 2010 17:28:03 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id A3F6AD8025 for ; Thu, 13 May 2010 17:28:03 -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 utBe1RmTCPFd for ; Thu, 13 May 2010 17:28:03 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 2ADCED8023 for ; Thu, 13 May 2010 17:28:03 -0500 (CDT) Message-ID: <4BEC7CEE.2050503@digium.com> Date: Thu, 13 May 2010 17:27:58 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: dispatch@ietf.org References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <430FC6BDED356B4C8498F634416644A91C139910E5@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C139910E5@mail> X-Enigmail-Version: 1.0.1 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Proposed update to Session-ID charter, round-4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 22:28:14 -0000 On 05/13/2010 04:40 PM, Hadriel Kaplan wrote: > How about this... > > > SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCOTCH) Charter: > ---------------------------------- > The SIPSCOTCH working group is chartered to define a mechanism that allows operators and monitoring equipment to correlate SIP messages and dialogs of the same higher-level end-to-end "session" across multiple SIP device hops for the same "message-flow", for the purpose of troubleshooting. In particular, the mechanism must be able to allow such correlation across SIP B2BUAs of as many functional types as possible, such as Application Servers, Softswitches, PBXs, SBCs, etc. > > The definition of a higher-layer "session" of the same "message-flow" is not defined by SIP when it involves a B2BUA, and is difficult to normatively define in practice. For the purposes of this WG charter's scope, two or more dialogs of a B2BUA are correlated under whatever conditions they feel would aid in troubleshooting the dialogs, by identifying them as belonging to the same higher-level session. Any solution documents from this working group may expand or constrain the scope of their mechanism's correlation, if the working group so decides. > > Although other solutions may be possible, this working group will focus on defining a new SIP Header field for such a purpose, similar to the Call-ID header field, in order to provide a simple, easily deployable mechanism which can work across SIP domains. The SIP Call-ID header field value itself is not usable for such correlation, because many B2BUAs must create a new Call-ID value on their UAC "side" in order to function properly, and to comply with the rules of RFC 3261. > > It should be noted that certain SIP B2BUAs perform a "topology-hiding" function, as described in RFC 5853. The working group will take such functions into account for the correlation mechanism, as well as provide guidance for implementers of the mechanism to avoid triggering such a function for the mechanism's header field value. > > Lastly, although in certain environments such a mechanism may be usable for dialog correlation in SIP state machines, it is not the goal of this working group to address that usage. > > Goals and Milestones > ==================== > Dec 2010 - New header specification to IESG (PS) This works for me. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From HKaplan@acmepacket.com Thu May 13 16:39:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 089E53A6858 for ; Thu, 13 May 2010 16:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAtXviV30wlb for ; Thu, 13 May 2010 16:39:42 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D9FBA3A67D6 for ; Thu, 13 May 2010 16:39:41 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 13 May 2010 19:39:31 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 13 May 2010 19:39:28 -0400 From: Hadriel Kaplan To: Laura Liess , "R.Jesske@telekom.de" , "dispatch@ietf.org" Date: Thu, 13 May 2010 19:39:26 -0400 Thread-Topic: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQABh7EkAABBtS0AAMljVw Message-ID: <430FC6BDED356B4C8498F634416644A91C139910F0@mail> References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <430FC6BDED356B4C8498F634416644A91C13990F46@mail> <4bec4e62.0c58560a.188d.ffff9205@mx.google.com> In-Reply-To: <4bec4e62.0c58560a.188d.ffff9205@mx.google.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] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 23:39:43 -0000 Hi Laura, Just to be clear: I'm fine with having both Alert-Info "semantic" URNs and = Reason-header codes in responses. I'm just asking that the drafts explain = in their text why they are necessary to be separate, what they're used for = that's "different", etc. Basically, I'm trying to avoid confusion for impl= ementers and operators if both of these become RFCs. > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: Thursday, May 13, 2010 3:09 PM > To: Hadriel Kaplan; R.Jesske@telekom.de; dispatch@ietf.org >=20 > Alert-Info URNs and Reason in responses are two different things. > Alert-Info URNs are names for ring tones which has to be rendered to the > users. They can be carried in INVITE or 18x responses and resolved by SIP > end devices according to local rules into a specific tones or text. They > are > not involved in applications logic neither in SIP nor in PSTN. Well, to be nit-picky the proposed Alert-Info URN *is* involved in applicat= ion logic in SIP: application logic to resolve a URN, render a tone, displa= y a message, or whatever. And in theory I assumed that if a PSTN SIT-signa= l was received on a PSTN-SIP gateway, it would convert it to an Alert-Info = URN like "short-long-long"; and if that SIP response message hit another SI= P-PSTN gateway to go back into PSTN, that it would convert it back to a SIT= . So it applies to that SIP-PSTN inter-working application logic as well. So I suppose one question would be what _other_ logic a SIP UA or SIP-PSTN = gateway would be doing with a Q.850 Reason-header cause-code that it couldn= 't be doing with a "semantic" Alert-Info URN which represented a cause-code= .=20 BTW, in the PSTN aren't those Q.850 codes also used for "rendering"? Doesn= 't the PSTN-switch or PBX getting the response code use the Q.850 code to p= ick a specific tone sequence to play to a handset in some cases? > Reason in responses is about extending the usage of the Reason header > defined in RFC3326 to SIP responses. The RFC 3326 currently allows it onl= y > in SIP requests. Typical use cases are to carry it in CANCEL or BYE > requests > (see 3326 message flows) or in error responses. A typical message flows > for > Reason in responses is shown in an earlier version of Roland's draft, e.g= . > http://tools.ietf.org/id/draft-jesske-sipping-etsi-ngn-reason-04.txt, > where > the reason is sent in 603 Decline. You can't do this with the Alert-Info > header. I would think you'd want Alert-Info to apply to such failure responses too,= no? For example, there is a different tone presented today for a user-bus= y, vs. an all-circuits-busy, vs. an incorrect number. Or do you mean an Alert-Info URN would only be used for rendering decisions= of 18x, and a Reason-header would be used for rendering decisions of other= SIP responses? -hadriel From peter.musgrave@magorcorp.com Thu May 13 16:55:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE513A6960 for ; Thu, 13 May 2010 16:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.341 X-Spam-Level: X-Spam-Status: No, score=0.341 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZol6Du+6Oko for ; Thu, 13 May 2010 16:55:19 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 3811B3A67D6 for ; Thu, 13 May 2010 16:55:18 -0700 (PDT) Received: by gwb19 with SMTP id 19so1029723gwb.31 for ; Thu, 13 May 2010 16:55:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.18.12 with SMTP id v12mr1206207ybi.153.1273794904900; Thu, 13 May 2010 16:55:04 -0700 (PDT) Received: by 10.150.58.14 with HTTP; Thu, 13 May 2010 16:55:04 -0700 (PDT) In-Reply-To: <4BEC7CEE.2050503@digium.com> References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <430FC6BDED356B4C8498F634416644A91C139910E5@mail> <4BEC7CEE.2050503@digium.com> Date: Thu, 13 May 2010 19:55:04 -0400 Message-ID: From: Peter Musgrave To: "Kevin P. Fleming" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposed update to Session-ID charter, round-4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 23:55:20 -0000 +1 On Thu, May 13, 2010 at 6:27 PM, Kevin P. Fleming wr= ote: > On 05/13/2010 04:40 PM, Hadriel Kaplan wrote: >> How about this... >> >> >> SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIP= SCOTCH) Charter: >> ---------------------------------- >> The SIPSCOTCH working group is chartered to define a mechanism that allo= ws operators and monitoring equipment to correlate SIP messages and dialogs= of the same higher-level end-to-end "session" across multiple SIP device h= ops for the same "message-flow", for the purpose of troubleshooting. =A0In = particular, the mechanism must be able to allow such correlation across SIP= B2BUAs of as many functional types as possible, such as Application Server= s, Softswitches, PBXs, SBCs, etc. >> >> The definition of a higher-layer "session" of the same "message-flow" is= not defined by SIP when it involves a B2BUA, and is difficult to normative= ly define in practice. =A0For the purposes of this WG charter's scope, two = or more dialogs of a B2BUA are correlated under whatever conditions they fe= el would aid in troubleshooting the dialogs, by identifying them as belongi= ng to the same higher-level session. =A0Any solution documents from this wo= rking group may expand or constrain the scope of their mechanism's correlat= ion, if the working group so decides. >> >> Although other solutions may be possible, this working group will focus = on defining a new SIP Header field for such a purpose, similar to the Call-= ID header field, in order to provide a simple, easily deployable mechanism = which can work across SIP domains. The SIP Call-ID header field value itsel= f is not usable for such correlation, because many B2BUAs must create a new= Call-ID value on their UAC "side" in order to function properly, and to co= mply with the rules of RFC 3261. >> >> It should be noted that certain SIP B2BUAs perform a "topology-hiding" f= unction, as described in RFC 5853. =A0The working group will take such func= tions into account for the correlation mechanism, as well as provide guidan= ce for implementers of the mechanism to avoid triggering such a function fo= r the mechanism's header field value. >> >> Lastly, although in certain environments such a mechanism may be usable = for dialog correlation in SIP state machines, it is not the goal of this wo= rking group to address that usage. >> >> Goals and Milestones >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Dec 2010 - New header specification to IESG (PS) > > This works for me. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From laura.liess.dt@googlemail.com Thu May 13 22:36:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2673A67A1 for ; Thu, 13 May 2010 22:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5+Tm4lTt4oq for ; Thu, 13 May 2010 22:36:04 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 96EE73A6407 for ; Thu, 13 May 2010 22:36:03 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so61687fge.13 for ; Thu, 13 May 2010 22:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=ZPMM3oid26GojVfoCWcOWNxqBMPf/jahVQxCqzBr2Ic=; b=hJR3c7Em40ESyzXlWuKzF6K9SijmmEQy4+h3loed0VtNWa7E9vULnyVIQ0ZTsks3Zb KpAIBqeXxaPdcb3S3AlhWqa8O5Rpp/YWgE39owLJyvhH9V3JasXGkpOSokPByvivi1C7 66aZNisw/P+Kf02BvZcKVMfp8MUo3BXGdDR5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=aN4SBcSIr2h4OzZaBe1l8HeZEcuBH2vgIV/xerb1RE5kz/Fuw0TFGfHMpARhaeD0lh WC2IgnDOA/rSs7zsHmwDBsqxea/dp67eDe7ik4z07RM4a6gPvtZCqxmNj44oHSD2Vn4O 63S2+7HXilH2wGqjpdotBlXyCgj7tGZCxLa1A= Received: by 10.87.63.21 with SMTP id q21mr1915655fgk.52.1273815351016; Thu, 13 May 2010 22:35:51 -0700 (PDT) Received: from LauraLiess (p54A7F6B7.dip.t-dialin.net [84.167.246.183]) by mx.google.com with ESMTPS id d4sm6718702fga.15.2010.05.13.22.35.49 (version=SSLv3 cipher=RC4-MD5); Thu, 13 May 2010 22:35:49 -0700 (PDT) From: Laura Liess To: "'Hadriel Kaplan'" , "'Laura Liess'" , , References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <430FC6BDED356B4C8498F634416644A91C13990F46@mail> <4bec4e62.0c58560a.188d.ffff9205@mx.google.com> <430FC6BDED356B4C8498F634416644A91C139910F0@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C139910F0@mail> Date: Fri, 14 May 2010 07:35:46 +0200 Message-ID: <4bece135.0437560a.5ee3.ffffcf84@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQABh7EkAABBtS0AAMljVwABCHB0A= Content-Language: de Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 05:36:06 -0000 Hi Hadriel, I am fine with this.=20 Laura > -----Urspr=FCngliche Nachricht----- > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Gesendet: Freitag, 14. Mai 2010 01:39 > An: Laura Liess; R.Jesske@telekom.de; dispatch@ietf.org > Betreff: RE: [dispatch] Reason In responses (draft-jesske-dispatch- > reason-in-responses-02) >=20 >=20 > Hi Laura, > Just to be clear: I'm fine with having both Alert-Info "semantic" URNs > and Reason-header codes in responses. I'm just asking that the drafts > explain in their text why they are necessary to be separate, what = they're > used for that's "different", etc. Basically, I'm trying to avoid > confusion for implementers and operators if both of these become RFCs. >=20 >=20 > > -----Original Message----- > > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > > Sent: Thursday, May 13, 2010 3:09 PM > > To: Hadriel Kaplan; R.Jesske@telekom.de; dispatch@ietf.org > > > > Alert-Info URNs and Reason in responses are two different things. > > Alert-Info URNs are names for ring tones which has to be rendered to > the > > users. They can be carried in INVITE or 18x responses and resolved = by > SIP > > end devices according to local rules into a specific tones or text. > They > > are > > not involved in applications logic neither in SIP nor in PSTN. >=20 > Well, to be nit-picky the proposed Alert-Info URN *is* involved in > application logic in SIP: application logic to resolve a URN, render a > tone, display a message, or whatever. And in theory I assumed that if = a > PSTN SIT-signal was received on a PSTN-SIP gateway, it would convert = it > to an Alert-Info URN like "short-long-long"; and if that SIP response > message hit another SIP-PSTN gateway to go back into PSTN, that it = would > convert it back to a SIT. So it applies to that SIP-PSTN = inter-working > application logic as well. >=20 > So I suppose one question would be what _other_ logic a SIP UA or SIP- > PSTN gateway would be doing with a Q.850 Reason-header cause-code that = it > couldn't be doing with a "semantic" Alert-Info URN which represented a > cause-code. >=20 > BTW, in the PSTN aren't those Q.850 codes also used for "rendering"? > Doesn't the PSTN-switch or PBX getting the response code use the Q.850 > code to pick a specific tone sequence to play to a handset in some = cases? >=20 >=20 > > Reason in responses is about extending the usage of the Reason = header > > defined in RFC3326 to SIP responses. The RFC 3326 currently allows = it > only > > in SIP requests. Typical use cases are to carry it in CANCEL or BYE > > requests > > (see 3326 message flows) or in error responses. A typical message = flows > > for > > Reason in responses is shown in an earlier version of Roland's = draft, > e.g. > > = http://tools.ietf.org/id/draft-jesske-sipping-etsi-ngn-reason-04.txt, > > where > > the reason is sent in 603 Decline. You can't do this with the Alert- > Info > > header. >=20 > I would think you'd want Alert-Info to apply to such failure responses > too, no? For example, there is a different tone presented today for a > user-busy, vs. an all-circuits-busy, vs. an incorrect number. >=20 > Or do you mean an Alert-Info URN would only be used for rendering > decisions of 18x, and a Reason-header would be used for rendering > decisions of other SIP responses? >=20 > -hadriel From ranjit@motorola.com Thu May 13 23:19:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A093A659A for ; Thu, 13 May 2010 23:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3BNbR2m3yPO for ; Thu, 13 May 2010 23:19:50 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id B57DA3A6821 for ; Thu, 13 May 2010 23:19:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1273817978!16470079!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 27502 invoked from network); 14 May 2010 06:19:39 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-7.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 May 2010 06:19:39 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id o4E6Ja4v007760 for ; Thu, 13 May 2010 23:19:38 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o4E6JaA9005118 for ; Fri, 14 May 2010 01:19:36 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o4E6JYvp005082 for ; Fri, 14 May 2010 01:19:35 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 May 2010 14:19:12 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] FW: New Version Notification fordraft-avasarala-dispatch-comm-barring-notification-00 thread-index: AcryhWzbLdlIO5CLQ9SHlQmzpNqWjwAAB6jQAAFkdMAAKFcIIA== References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> From: "Avasarala Ranjit-A20990" To: "Elwell, John" , X-CFilter-Loop: Reflected Subject: Re: [dispatch] FW: New Version Notification fordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 06:19:52 -0000 Hi John This I-D on communication barring notification talks about an event package for reporting the notification information of communication barrings (call blocking) that happen in the network on behalf of the users. For e.g if Alice sets a call blocking rule that all calls from Bob need to be blocked, then the network blocks all calls from Bob towards Alice. So here The notification information will include the details of the call block - i.e (1) the identity of caller (Bob) (2) time of block (2) reason for block, etc Yes I agree with you that there is synergy between this I-D and the one on CDIV, since both of them deal with reporting of events that occur in the network. While CDIV deals with communication diversion, this one deals with ICB service. Though both the event packages are similar in terms of subscriptions and format, their execution and user preference may vary. So they need to be looked at differently and standardized seperately. Regards Ranjit -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Thursday, May 13, 2010 6:25 PM To: Avasarala Ranjit-A20990; dispatch@ietf.org Cc: T Satyanarayana-A12694 Subject: RE: [dispatch] FW: New Version Notification fordraft-avasarala-dispatch-comm-barring-notification-00 Ranjit, It is not entirely clear to me what the notifications report. For example, in 6.7, it says "Typically, it will send one when a communication barring is enacted on behalf of the user." What is meant by "enacted" here? Is it when some entity, on behalf of the user, perhaps through some web page, establishes a communication barring rule? Or is it when an inbound communication arrives and is processed in accordance with some pre-existing communication barring rule? I thought at first it was the former, but I am tending towards thinking it is the latter. Some clarification would be useful. Assuming it is the latter, there is obviously some synergy with draft-avasarala-dispatch-comm-div-notification. Both deal with reporting inbound communications that have been subject to some rule, the rule being conditional on certain criteria such as caller ID. Where the conditions are met for a given call to be subject to a given rule, a notification in accordance with one or the other event package will be triggered. I fail to see the reason for having two separate event packages, since this means two separate specifications, two different subscriptions, two different formats, etc.. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 > Ranjit-A20990 > Sent: 13 May 2010 11:28 > To: dispatch@ietf.org > Cc: T Satyanarayana-A12694 > Subject: [dispatch] FW: New Version Notification for=20 > draft-avasarala-dispatch-comm-barring-notification-00 >=20 > Hi all >=20 > I have submitted a new I-D on communication barring notification=20 > information based on the following >=20 > Section 8.2.10 Communication Barring - ICB enhancement of dynamic=20 > blocking of incoming communications of 3GPP TS 22.173 >=20 > Section 4.5.2.6.1 Actions for ICB at the terminating AS of 3GPP TS > 24.611 >=20 > The draft can be accessed from: > http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n > otificatio > n-00.txt >=20 > Please review and comment. >=20 > Thanks >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Thursday, May 13, 2010 3:47 PM > To: Avasarala Ranjit-A20990 > Cc: r.jesske@telekom.de > Subject: New Version Notification for > draft-avasarala-dispatch-comm-barring-notification-00 >=20 >=20 > A new version of I-D, > draft-avasarala-dispatch-comm-barring-notification-00.txt has been=20 > successfully submitted by Ranjit Avasarala and posted to the IETF=20 > repository. >=20 > Filename: draft-avasarala-dispatch-comm-barring-notification > Revision: 00 > Title: A Session Initiation Protocol (SIP)=20 > Event Package for > Communication Barring Notification Information in support of the=20 > Dynamic Incoming Communication Barring (ICB) Notification service > Creation_date: 2010-05-13 > WG ID: Independent Submission > Number_of_pages: 22 >=20 > Abstract: > 3GPP is defining the protocol specification for the Communication=20 > Barring (CB) service using IP Multimedia (IM) Core Network (CN)=20 > subsystem supplementary service and more particularly the dynamic=20 > incoming communication barring service. As part of dynamic incoming=20 > communication barring (ICB) service, a SIP based Event package=20 > framework is used for notifying users about communication barrings=20 > (dynamic and rule based) of their incoming communication sessions. > This document proposes a new SIP event package for allowing users to=20 > subscribe to and receive such notifications. Users can further define > filters to control the rate and content of such notifications. > The proposed event package is applicable to the ICB supplementary=20 > service in IMS and may not be applicable to the general internet. > =20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From john.elwell@siemens-enterprise.com Thu May 13 23:59:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2C33A69D6 for ; Thu, 13 May 2010 23:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTkfr05U9Qps for ; Thu, 13 May 2010 23:59:41 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 825EE3A67B4 for ; Thu, 13 May 2010 23:59:41 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-169460; Fri, 14 May 2010 08:59:30 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id C8A1E23F0292; Fri, 14 May 2010 08:59:30 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 14 May 2010 08:59:30 +0200 From: "Elwell, John" To: Hadriel Kaplan , DISPATCH Date: Fri, 14 May 2010 08:59:28 +0200 Thread-Topic: Proposed update to Session-ID charter, round-4 Thread-Index: AcrwbbD3I0kahOGNSc2Kyg+gjSbVgABc9BgQAECa43AAE511AA== Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <430FC6BDED356B4C8498F634416644A91C139910E5@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C139910E5@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Proposed update to Session-ID charter, round-4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 06:59:42 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 13 May 2010 22:40 > To: DISPATCH > Subject: [dispatch] Proposed update to Session-ID charter, round-4 >=20 > How about this... >=20 >=20 > SIP Signaling-COmmunication Troubleshooting with Correlation=20 > Header (SIPSCOTCH) Charter: > ---------------------------------- > The SIPSCOTCH working group is chartered to define a=20 > mechanism that allows operators and monitoring equipment to=20 > correlate SIP messages and dialogs of the same higher-level=20 > end-to-end "session" across multiple SIP device hops for the=20 > same "message-flow", for the purpose of troubleshooting. In=20 > particular, the mechanism must be able to allow such=20 > correlation across SIP B2BUAs of as many functional types as=20 > possible, such as Application Servers, Softswitches, PBXs, SBCs, etc. >=20 > The definition of a higher-layer "session" of the same=20 > "message-flow" is not defined by SIP when it involves a=20 > B2BUA, and is difficult to normatively define in practice. =20 > For the purposes of this WG charter's scope, two or more=20 > dialogs of a B2BUA are correlated under whatever conditions=20 > they feel would aid in troubleshooting the dialogs, [JRE] So dialogs have feelings? I would suggest rewording "....under any conditions where correlation might= aid troubleshooting." John > by=20 > identifying them as belonging to the same higher-level=20 > session. Any solution documents from this working group may=20 > expand or constrain the scope of their mechanism's=20 > correlation, if the working group so decides. >=20 > Although other solutions may be possible, this working group=20 > will focus on defining a new SIP Header field for such a=20 > purpose, similar to the Call-ID header field, in order to=20 > provide a simple, easily deployable mechanism which can work=20 > across SIP domains. The SIP Call-ID header field value itself=20 > is not usable for such correlation, because many B2BUAs must=20 > create a new Call-ID value on their UAC "side" in order to=20 > function properly, and to comply with the rules of RFC 3261.=20 >=20 > It should be noted that certain SIP B2BUAs perform a=20 > "topology-hiding" function, as described in RFC 5853. The=20 > working group will take such functions into account for the=20 > correlation mechanism, as well as provide guidance for=20 > implementers of the mechanism to avoid triggering such a=20 > function for the mechanism's header field value. >=20 > Lastly, although in certain environments such a mechanism may=20 > be usable for dialog correlation in SIP state machines, it is=20 > not the goal of this working group to address that usage. >=20 > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dec 2010 - New header specification to IESG (PS) >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From mperumal@cisco.com Fri May 14 00:32:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42C13A6A30 for ; Fri, 14 May 2010 00:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.64 X-Spam-Level: X-Spam-Status: No, score=-8.64 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo9Hx7fethBP for ; Fri, 14 May 2010 00:32:13 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id ED4993A6A1F for ; Fri, 14 May 2010 00:32:13 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJGZ7EtAaHte/2dsb2JhbACeAnGjPZkthRAEgz4 X-IronPort-AV: E=Sophos;i="4.53,227,1272844800"; d="scan'208";a="325916466" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-1.cisco.com with ESMTP; 14 May 2010 07:32:03 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4E7W2cV003367; Fri, 14 May 2010 07:32:03 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 May 2010 13:02:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 May 2010 13:02:00 +0530 Message-ID: <1D062974A4845E4D8A343C653804920202B87B3C@XMB-BGL-414.cisco.com> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C139910A6@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposed update to Session-ID charter, round-3 Thread-Index: AcryvUOD6v8IfflgQaWpA6ChQVgfEAAAusMAAATW2UAAGCeM4A== References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail><430FC6BDED356B4C8498F634416644A91C13990FC6@mail><4BEC28EE.4060707@digium.com><430FC6BDED356B4C8498F634416644A91C13991009@mail> <4BEC2F3A.9020309@nostrum.com> <1D062974A4845E4D8A343C653804920202B879FE@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A91C139910A6@mail> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Hadriel Kaplan" , "Adam Roach" X-OriginalArrivalTime: 14 May 2010 07:32:02.0722 (UTC) FILETIME=[8BC5B020:01CAF337] Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 07:32:15 -0000 Yes, the domain of the problem is the same irrespective of whether the initial dialog goes to an established state or not before the SBC/3PCC initiates a new dialog and associates them -- we need a uniform SIP header to correlate/associate all dialogs that are part of a multimedia communication session and derive the sequence of messages/events that lead to the problem. Muthu |-----Original Message----- |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |Sent: Friday, May 14, 2010 1:17 AM |To: Muthu ArulMozhi Perumal (mperumal); Adam Roach |Cc: dispatch@ietf.org |Subject: RE: [dispatch] Proposed update to Session-ID charter, round-3 | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: Thursday, May 13, 2010 1:30 PM |> To: Adam Roach; Hadriel Kaplan |> |> Here is another use-case that typically happens in center use-case: |> - A customer call lands on a B2BUA that runs an Interactive Voice |> Response (IVR) application. |> - The application presents a number of options to the user to reach |> different departments. |> - The customer selects a particular option. The B2BUA places an outbound |> call to an agent and associates the two dialogs. |> - The agent provides some information to the customer and disconnects. |> - The application once again presents a number of options to the |> customer to reach other departments. |> |> A calling card application running on a B2BUA that provides an option |> for the customer to press long '#' anytime during the call and connect |> with a different person would be another use-case. | |Right, and my current proposal rules those cases out of being the same |correlated "session". (the same session for purposes of SIPSCOTCH that is) |Because the original dialog would have gotten to the established state |before making those other calls from the App server, and because of the |automatic tear-down rule. | |Is that an actual problem, though? I mean do we need to be able to |correlate such calls to every new dialog using a SIP header? | |-hadriel From mperumal@cisco.com Fri May 14 01:02:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48E63A6A5D for ; Fri, 14 May 2010 01:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.828 X-Spam-Level: X-Spam-Status: No, score=-9.828 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0hl-t3r3S7U for ; Fri, 14 May 2010 01:02:20 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id ED3EE3A6A60 for ; Fri, 14 May 2010 01:02:12 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFag7EtAaHte/2dsb2JhbACeAnGjHpkyhRAEgz4 X-IronPort-AV: E=Sophos;i="4.53,227,1272844800"; d="scan'208";a="129638790" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 14 May 2010 08:02:02 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4E821Zt012879; Fri, 14 May 2010 08:02:02 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 May 2010 13:32:01 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 May 2010 13:31:59 +0530 Message-ID: <1D062974A4845E4D8A343C653804920202B87B57@XMB-BGL-414.cisco.com> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C139910AA@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposed update to Session-ID charter, round-3 Thread-Index: Acry1NM5718PUOySTrqiUxffAPWN5gAAEqMQABlOaUA= References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail><430FC6BDED356B4C8498F634416644A91C13990FC6@mail><4BEC28EE.4060707@digium.com><430FC6BDED356B4C8498F634416644A91C13991009@mail><4BEC2F3A.9020309@nostrum.com><430FC6BDED356B4C8498F634416644A91C1399109D@mail><4BEC56B9.7070208@nostrum.com> <430FC6BDED356B4C8498F634416644A91C139910AA@mail> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Hadriel Kaplan" , "Adam Roach" X-OriginalArrivalTime: 14 May 2010 08:02:01.0807 (UTC) FILETIME=[BC1C45F0:01CAF33B] Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 08:02:22 -0000 |Maybe a better alternative is to actually get rid of such rules and=20 |say "Two or more dialogs of a B2BUA are correlated under whatever=20 |conditions they feel would aid in troubleshooting the dialogs"?=20 |(or something along those lines) Sounds more reasonable. I've a feeling that we should RECOMMEND that this header be used for troubleshooting. However, if someone wants to extent it in future and use it for some other purpose other than troubleshooting, we shouldn't block it. Muthu |-----Original Message----- |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf |Of Hadriel Kaplan |Sent: Friday, May 14, 2010 1:22 AM |To: Adam Roach |Cc: dispatch@ietf.org |Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 | |> -----Original Message----- |> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On |> Behalf Of Adam Roach |> Sent: Thursday, May 13, 2010 3:45 PM |> |> Actually, I think the most important part of my email was the part you |> chose not to address: once you start constraining what B2BUAs do, you've |> strayed off into territory that makes you automatically wrong. You can |> keep patching your description to try to accommodate the use cases |> people come up with over the next few days or weeks -- but unless your |> crystal ball is a whole heck of a lot more magic than everyone else's |> [1], you're going to miss some. | |Nope, I was going to respond to it separately, because it seemed to me to be |a more general problem. But I'll use this email as the vehicle. :) | |Right, so we can either give up entirely, or live with not covering every |possible thing. Note that I'm not "constraining" what B2BAU's do - I know |they do anything - I'm just constraining when the mechanism needs to be able |correlate multiple dialogs. I'm not preventing B2BAU's from doing whatever |they want (nor could I). This is to help troubleshooting - it's not a SIP |state-machine dialog correlation. | |Maybe a better alternative is to actually get rid of such rules and say "Two |or more dialogs of a B2BUA are correlated under whatever conditions they |feel would aid in troubleshooting the dialogs"? (or something along those |lines) | |-hadriel |_______________________________________________ |dispatch mailing list |dispatch@ietf.org |https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Fri May 14 08:01:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC873A6841 for ; Fri, 14 May 2010 08:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeF9xsOc0Eiz for ; Fri, 14 May 2010 08:01:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B416D3A6B01 for ; Fri, 14 May 2010 08:01:50 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 14 May 2010 11:01:40 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 14 May 2010 11:01:40 -0400 From: Hadriel Kaplan To: Laura Liess , "R.Jesske@telekom.de" , "dispatch@ietf.org" Date: Fri, 14 May 2010 11:01:39 -0400 Thread-Topic: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQABh7EkAABBtS0AAMljVw Message-ID: <430FC6BDED356B4C8498F634416644A91C1399121F@mail> References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <430FC6BDED356B4C8498F634416644A91C13990F46@mail> <4bec4e62.0c58560a.188d.ffff9205@mx.google.com> In-Reply-To: <4bec4e62.0c58560a.188d.ffff9205@mx.google.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] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 15:01:52 -0000 [Argh - I should have said "Other comments inline...", so re-sending the em= ail corrected] Hi Laura, Just to be clear: I'm fine with having both Alert-Info "semantic" URNs and = Reason-header codes in responses. I'm just asking that the drafts explain = in their text why they are necessary to be separate, what they're used for = that's "different", etc. Basically, I'm trying to avoid confusion for impl= ementers and operators if both of these become RFCs. Other comments inline... > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: Thursday, May 13, 2010 3:09 PM > To: Hadriel Kaplan; R.Jesske@telekom.de; dispatch@ietf.org >=20 > Alert-Info URNs and Reason in responses are two different things. > Alert-Info URNs are names for ring tones which has to be rendered to the > users. They can be carried in INVITE or 18x responses and resolved by SIP > end devices according to local rules into a specific tones or text. They > are > not involved in applications logic neither in SIP nor in PSTN. Well, to be nit-picky the proposed Alert-Info URN *is* involved in applicat= ion logic in SIP: application logic to resolve a URN, render a tone, displa= y a message, or whatever. And in theory I assumed that if a PSTN SIT-signa= l was received on a PSTN-SIP gateway, it would convert it to an Alert-Info = URN like "short-long-long"; and if that SIP response message hit another SI= P-PSTN gateway to go back into PSTN, that it would convert it back to a SIT= . So it applies to that SIP-PSTN inter-working application logic as well. So I suppose one question would be what _other_ logic a SIP UA or SIP-PSTN = gateway would be doing with a Q.850 Reason-header cause-code that it couldn= 't be doing with a "semantic" Alert-Info URN which represented a cause-code= .=20 BTW, in the PSTN aren't those Q.850 codes also used for "rendering"? Doesn= 't the PSTN-switch or PBX getting the response code use the Q.850 code to p= ick a specific tone sequence to play to a handset in some cases? > Reason in responses is about extending the usage of the Reason header > defined in RFC3326 to SIP responses. The RFC 3326 currently allows it onl= y > in SIP requests. Typical use cases are to carry it in CANCEL or BYE > requests > (see 3326 message flows) or in error responses. A typical message flows > for > Reason in responses is shown in an earlier version of Roland's draft, e.g= . > http://tools.ietf.org/id/draft-jesske-sipping-etsi-ngn-reason-04.txt, > where > the reason is sent in 603 Decline. You can't do this with the Alert-Info > header. I would think you'd want Alert-Info to apply to such failure responses too,= no? For example, there is a different tone presented today for a user-bus= y, vs. an all-circuits-busy, vs. an incorrect number. Or do you mean an Alert-Info URN would only be used for rendering decisions= of 18x, and a Reason-header would be used for rendering decisions of other= SIP responses? -hadriel From pkyzivat@cisco.com Fri May 14 09:08:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581623A6AEA for ; Fri, 14 May 2010 09:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.534 X-Spam-Level: X-Spam-Status: No, score=-9.534 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFWvAzrNtmGn for ; Fri, 14 May 2010 09:08:20 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F08783A69D2 for ; Fri, 14 May 2010 09:08:14 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,231,1272844800"; d="scan'208";a="111279653" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 May 2010 16:08:05 +0000 Received: from [10.86.240.27] (che-vpn-cluster-1-27.cisco.com [10.86.240.27]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4EG84rP013644; Fri, 14 May 2010 16:08:05 GMT Message-ID: <4BED7565.9040203@cisco.com> Date: Fri, 14 May 2010 12:08:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Muthu ArulMozhi Perumal (mperumal)" References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail><430FC6BDED356B4C8498F634416644A91C13990FC6@mail><4BEC28EE.4060707@digium.com><430FC6BDED356B4C8498F634416644A91C13991009@mail><4BEC2F3A.9020309@nostrum.com><430FC6BDED356B4C8498F634416644A91C1399109D@mail><4BEC56B9.7070208@nostrum.com> <430FC6BDED356B4C8498F634416644A91C139910AA@mail> <1D062974A4845E4D8A343C653804920202B87B57@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920202B87B57@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 16:08:21 -0000 There are tradeoffs here. If the decision is to say that B2BUAs can use the same session id to correlate dialogs whenever they feel that would correlate troubleshooting, then it is going to be very difficult to determine when it may also be suitable for any other purpose. Even for troubleshooting, it will only be useful for the sort of troubleshooting that the B2BUAs that did the marking had in mind. For instance, for some troubleshooting purposes you would want to correlate all the call legs in Adam's example. But somebody else might not want to. It might be just as useful to say this can be associated with multiple dialogs when the thing doing the marking thinks it would be useful to correlate those things. (For whatever purpose.) But of course that will only be useful if you control all the things that do the marking. IMO, to be generally useful in an interoperable way without explicit configuration, I think the criteria for applying the same session id to multiple dialogs will need to be defined in a more precise way. Hadriel wants this to be for "troubleshooting", so perhaps that purpose can be refined into some specific criteria. Thanks, Paul Muthu ArulMozhi Perumal (mperumal) wrote: > |Maybe a better alternative is to actually get rid of such rules and > |say "Two or more dialogs of a B2BUA are correlated under whatever > |conditions they feel would aid in troubleshooting the dialogs"? > |(or something along those lines) > > Sounds more reasonable. I've a feeling that we should RECOMMEND that > this header be used for troubleshooting. However, if someone wants to > extent it in future and use it for some other purpose other than > troubleshooting, we shouldn't block it. > > Muthu > > |-----Original Message----- > |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf > |Of Hadriel Kaplan > |Sent: Friday, May 14, 2010 1:22 AM > |To: Adam Roach > |Cc: dispatch@ietf.org > |Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3 > | > |> -----Original Message----- > |> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > |> Behalf Of Adam Roach > |> Sent: Thursday, May 13, 2010 3:45 PM > |> > |> Actually, I think the most important part of my email was the part > you > |> chose not to address: once you start constraining what B2BUAs do, > you've > |> strayed off into territory that makes you automatically wrong. You > can > |> keep patching your description to try to accommodate the use cases > |> people come up with over the next few days or weeks -- but unless > your > |> crystal ball is a whole heck of a lot more magic than everyone else's > |> [1], you're going to miss some. > | > |Nope, I was going to respond to it separately, because it seemed to me > to be > |a more general problem. But I'll use this email as the vehicle. :) > | > |Right, so we can either give up entirely, or live with not covering > every > |possible thing. Note that I'm not "constraining" what B2BAU's do - I > know > |they do anything - I'm just constraining when the mechanism needs to be > able > |correlate multiple dialogs. I'm not preventing B2BAU's from doing > whatever > |they want (nor could I). This is to help troubleshooting - it's not a > SIP > |state-machine dialog correlation. > | > |Maybe a better alternative is to actually get rid of such rules and say > "Two > |or more dialogs of a B2BUA are correlated under whatever conditions > they > |feel would aid in troubleshooting the dialogs"? (or something along > those > |lines) > | > |-hadriel > |_______________________________________________ > |dispatch mailing list > |dispatch@ietf.org > |https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Fri May 14 09:19:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AE53A6B4E for ; Fri, 14 May 2010 09:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.908 X-Spam-Level: X-Spam-Status: No, score=-8.908 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfjfptXXGv+R for ; Fri, 14 May 2010 09:19:11 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E37A03A6B4F for ; Fri, 14 May 2010 09:18:55 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANQU7UtAZnwM/2dsb2JhbACdeXGkNpkvhRAE X-IronPort-AV: E=Sophos;i="4.53,231,1272844800"; d="scan'208";a="111145751" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 May 2010 16:18:39 +0000 Received: from [10.86.240.27] (che-vpn-cluster-1-27.cisco.com [10.86.240.27]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4EGId8W019454; Fri, 14 May 2010 16:18:39 GMT Message-ID: <4BED77DF.5090907@cisco.com> Date: Fri, 14 May 2010 12:18:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "WORLEY, Dale R (Dale)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Alert-Info thoughts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 16:19:12 -0000 I like the direction Dale is going here. Thanks, Paul WORLEY, Dale R (Dale) wrote: > The charter is probably well enough baked. We can adjust the details of what we do later, regardless of what the charter says. > > It might be useful to replace the terms "semantic" and "non-semantic", as they're not very clear. I've been thinking of "intentional" vs. "rendering": An "intentional URN" tells something about the status of the dialog, a "rendering URN" tells something about how the alert/ringback signal is to be rendered. > > The critical difference between "Alert URNs" (whatever SIP syntax we use to carry them) and status codes is that we expect there to be a small set of status codes so that automata can act upon them reliably. The space of Alert URNs is expected to be broad and extensible, and likely to have numerous extensions that are proprietary or for use in specific applications (e.g., IMS). In particular, there is a market need for the Alert URN mechanism to support forward compatibility of the signaling features of existing non-SIP telephone systems. To prevent chaos, Alert URNs do *not* control the actions of automata. It is also assumed that almost all UAs can render distinctly only a small subset of Alert URNs, and the mechanism should permit and support such "best efforts" rendering. > > Conversely, if these two categories of signal (SIP response codes and Alert URNs) are not distinct enough, we should not create an "Alert URN" mechanism. > > It is probably open-ended the set of messages that could carry Alert URNs. INVITE is obvious, but for the same reason MESSAGE or any dialog-forming message could potentially carry one. Similarly, re-INVITE and UPDATE and any other request that performs a "major" change to a dialog might need to carry one. In regard to responses, we can probably safely restrict Alert URNs to the 18x family among provisional responses, though we might want to allow them in *any* final response. > > We can generalize slightly the current proposals to create a framework that will allow almost unlimited flexibility, with a standardized algorithm for UAs to choose the "best fit" rendering from the small set of renderings that they support. That is, let the marketers go wild without bothering anyone. More about that later... > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dworley@avaya.com Fri May 14 11:03:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F226B3A6C03 for ; Fri, 14 May 2010 11:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.982 X-Spam-Level: X-Spam-Status: No, score=-0.982 tagged_above=-999 required=5 tests=[AWL=-0.983, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJFIR9fJYE5R for ; Fri, 14 May 2010 11:03:24 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9F4733A6BFE for ; Fri, 14 May 2010 11:03:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,232,1272859200"; d="scan'208";a="188728586" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 May 2010 14:03:12 -0400 X-IronPort-AV: E=Sophos;i="4.53,232,1272859200"; d="scan'208";a="462980788" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 May 2010 14:03:11 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 14 May 2010 14:03:11 -0400 From: "WORLEY, Dale R (Dale)" To: "Elwell, John" , Hadriel Kaplan , DISPATCH Date: Fri, 14 May 2010 14:03:11 -0400 Thread-Topic: Proposed update to Session-ID charter, round-4 Thread-Index: AcrwbbD3I0kahOGNSc2Kyg+gjSbVgABc9BgQAECa43AAE511AAAXFe+L Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <430FC6BDED356B4C8498F634416644A91C139910E5@mail>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Proposed update to Session-ID charter, round-4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 18:03:25 -0000 The basic intention of Hadriel's original proposal is actually easy to stat= e (although every significant term in the statement is not well defined): >> Session-Id is what Call-Id would be if a SIP purist replaced every B2BUA= with a proper proxy. In particular, two dialogs with the same Session-Id would carry the same me= dia (possibly with transcoding). So it is clear that the three legs coming= from a conference focus would have different Session-Id. This is a particularly narrow relationship, but is thus quite useful in the= very common case where a dialog effectively passes through an SBC. The opposite approach is used in the "References" header (draft-worley-refe= rences), marking dialogs as being related if there is any relationship at a= ll between them. But of course, that can lead to large clusters of dialogs= being related in ways that don't form a linear string. (This is made easi= er by relating dialogs by naming their Call-Ids rather than marking them wi= th the same token.) In any case, the current charter proposal moves in the right direction by l= eaving the decision of the concept and scope of "relatedness" to the workin= g group. Dale From HKaplan@acmepacket.com Fri May 14 12:18:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5118C3A683F for ; Fri, 14 May 2010 12:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_50=0.001, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Aqw0NTeOttw for ; Fri, 14 May 2010 12:18:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 99E3428C151 for ; Fri, 14 May 2010 12:17:03 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 14 May 2010 15:16:53 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 14 May 2010 15:16:53 -0400 From: Hadriel Kaplan To: "WORLEY, Dale R (Dale)" , "Elwell, John" , DISPATCH Date: Fri, 14 May 2010 15:16:51 -0400 Thread-Topic: Proposed update to Session-ID charter, round-4 Thread-Index: AcrwbbD3I0kahOGNSc2Kyg+gjSbVgABc9BgQAECa43AAE511AAAXFe+LAADXhGA= Message-ID: <430FC6BDED356B4C8498F634416644A91C139912FE@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <430FC6BDED356B4C8498F634416644A91C139910E5@mail>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Proposed update to Session-ID charter, round-4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 19:18:10 -0000 I disagree. :) If people feel this is only going to be usable across SBCs, they should say= so right now - because the problem for just correlating across SBCs would = be simpler, and the solution different I think. The *intention* is to correlate dialogs that cross through other B2BUA's th= an just SBC's. A classic example would be a PBX or Softswitch, which while= arguably could be Proxies in theory, in practice are often B2BUA's and cha= nge the Call-ID. Likewise App Servers, Feature Servers, and such which res= ide in the path of the initial "call". =20 For media-based sessions, such B2BUA's actually can and do represent differ= ent media sources at different points in the call; for example app servers = which generate specific tones/music to the UAC while they hunt for the call= ed party. I guess we could say "carry only one media session at any given = time", as long as it's clear the intent is also to cover SUBSCRIBE-based di= alogs and other transactions which have no associated media. As for the conference server - that's the one I think where we really disag= ree the most. Obviously to a human all the dialogs of a conference are "re= lated", but I think that relationship is at a _much_ higher layer than a no= rmal "call" (if one could describe such things in layers). For example, ea= ch person makes an individual call to the server and can come and go withou= t the conference "session" ending. In fact, it seems to me that in practic= e most conference calls in SIP are not conference-aware at a SIP layer; I k= now some that are, and maybe it's more popular to do so in Enterprises, but= there're a ton of conference calls which are just SIP calls, made to a com= mon number, and all the "conferencing" is handled at a higher layer, purely= through DTMF presses and media. In theory they can even switch which conf= erence they're in, during the same SIP session. In some ways there really are different "layers" or "levels" of correlation= /relationships. I'm not convinced any one correlation mechanism can handle= them all, or should. -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of WORLEY, Dale R (Dale) > Sent: Friday, May 14, 2010 2:03 PM >=20 > The basic intention of Hadriel's original proposal is actually easy to > state (although every significant term in the statement is not well > defined): >=20 > >> Session-Id is what Call-Id would be if a SIP purist replaced every > B2BUA with a proper proxy. >=20 > In particular, two dialogs with the same Session-Id would carry the same > media (possibly with transcoding). So it is clear that the three legs > coming from a conference focus would have different Session-Id. >=20 > This is a particularly narrow relationship, but is thus quite useful in > the very common case where a dialog effectively passes through an SBC. >=20 > The opposite approach is used in the "References" header (draft-worley- > references), marking dialogs as being related if there is any relationshi= p > at all between them. But of course, that can lead to large clusters of > dialogs being related in ways that don't form a linear string. (This is > made easier by relating dialogs by naming their Call-Ids rather than > marking them with the same token.) >=20 > In any case, the current charter proposal moves in the right direction by > leaving the decision of the concept and scope of "relatedness" to the > working group. >=20 > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Fri May 14 13:28:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33EFE3A684B for ; Fri, 14 May 2010 13:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SBjUAGAjdlm for ; Fri, 14 May 2010 13:28:19 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id D06BE3A6403 for ; Fri, 14 May 2010 13:28:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,232,1272859200"; d="scan'208";a="188749398" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 May 2010 16:28:07 -0400 X-IronPort-AV: E=Sophos;i="4.53,232,1272859200"; d="scan'208";a="475140272" 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; 14 May 2010 16:28:07 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Fri, 14 May 2010 16:28:06 -0400 From: "WORLEY, Dale R (Dale)" To: Hadriel Kaplan , "Elwell, John" , DISPATCH Date: Fri, 14 May 2010 16:23:31 -0400 Thread-Topic: Proposed update to Session-ID charter, round-4 Thread-Index: AcrwbbD3I0kahOGNSc2Kyg+gjSbVgABc9BgQAECa43AAE511AAAXFe+LAADXhGAABE5Qrw== Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <430FC6BDED356B4C8498F634416644A91C139910E5@mail>, , <430FC6BDED356B4C8498F634416644A91C139912FE@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C139912FE@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Proposed update to Session-ID charter, round-4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 20:28:20 -0000 From: Hadriel Kaplan [HKaplan@acmepacket.com] > I disagree. :) >=20 > If people feel this is only going to be usable across SBCs, they > should say so right now - because the problem for just correlating > across SBCs would be simpler, and the solution different I think. >=20 > The *intention* is to correlate dialogs that cross through other > B2BUA's than just SBC's. A classic example would be a PBX or > Softswitch, which while arguably could be Proxies in theory, in > practice are often B2BUA's and change the Call-ID. Likewise App > Servers, Feature Servers, and such which reside in the path of the > initial "call". I thought that was covered in: >> Session-Id is what Call-Id would be if a SIP purist replaced every >> B2BUA with a proper proxy. > For media-based sessions, such B2BUA's actually can and do represent > different media sources at different points in the call; for example > app servers which generate specific tones/music to the UAC while they > hunt for the called party. I guess we could say "carry only one media > session at any given time", as long as it's clear the intent is also > to cover SUBSCRIBE-based dialogs and other transactions which have no > associated media. That's an interesting point -- despite all of the dialogs in a chain being "the same call", they might not always carry the same media. Dale From pkyzivat@cisco.com Fri May 14 16:55:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA77B3A6829 for ; Fri, 14 May 2010 16:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.778 X-Spam-Level: X-Spam-Status: No, score=-8.778 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l15PgZnZ+Y1 for ; Fri, 14 May 2010 16:55:44 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 31B6F3A691B for ; Fri, 14 May 2010 16:55:42 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHZ/7UtAZnwM/2dsb2JhbACeBXGlBZkghRAE X-IronPort-AV: E=Sophos;i="4.53,234,1272844800"; d="scan'208";a="111257673" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 May 2010 23:55:32 +0000 Received: from [10.86.240.27] (che-vpn-cluster-1-27.cisco.com [10.86.240.27]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4ENtWBO026310; Fri, 14 May 2010 23:55:32 GMT Message-ID: <4BEDE2F4.7080201@cisco.com> Date: Fri, 14 May 2010 19:55:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <430FC6BDED356B4C8498F634416644A91C139910E5@mail>, <430FC6BDED356B4C8498F634416644A91C139912FE@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C139912FE@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Proposed update to Session-ID charter, round-4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 23:55:44 -0000 Hadriel Kaplan wrote: > I disagree. :) > > If people feel this is only going to be usable across SBCs, they should say so right now - because the problem for just correlating across SBCs would be simpler, and the solution different I think. > > The *intention* is to correlate dialogs that cross through other B2BUA's than just SBC's. A classic example would be a PBX or Softswitch, which while arguably could be Proxies in theory, in practice are often B2BUA's and change the Call-ID. Likewise App Servers, Feature Servers, and such which reside in the path of the initial "call". > > For media-based sessions, such B2BUA's actually can and do represent different media sources at different points in the call; for example app servers which generate specific tones/music to the UAC while they hunt for the called party. I find very little difference between this scenario and one where the call is first answered by a secretary and then transferred to the intended callee. (Does it matter that the secretary is automated?) I'm a bit confused about how things should work if the transfer case does *not* share the same session-id: A ----------- B ----------- C | |------------ D Initially from A via B2BUA B to C, and gets Session-ID X applied to both the A-B leg and the B-C leg. Then B replaces the B-C "leg" with the B-D "leg". If the B-D leg doesn't get session-id X, and instead gets session-ID Y, does A-B then also get a new session-id of Y??? It seems it must if the correlation is to work for that. That then means that a single dialog, A-B has more than one session-id: X and Y. Is that what is intended??? Thanks, Paul From HKaplan@acmepacket.com Fri May 14 18:18:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 664983A6876 for ; Fri, 14 May 2010 18:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIp6RsYHePlB for ; Fri, 14 May 2010 18:18:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D57003A6897 for ; Fri, 14 May 2010 18:18:26 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 14 May 2010 21:18:17 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 14 May 2010 21:18:16 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Fri, 14 May 2010 21:18:14 -0400 Thread-Topic: [dispatch] Proposed update to Session-ID charter, round-4 Thread-Index: AcrzwPE9Mh2l3d0uR9mDEoWL1kwyZAABvvCg Message-ID: <430FC6BDED356B4C8498F634416644A91C13991392@mail> References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <430FC6BDED356B4C8498F634416644A91C139910E5@mail>, <430FC6BDED356B4C8498F634416644A91C139912FE@mail> <4BEDE2F4.7080201@cisco.com> In-Reply-To: <4BEDE2F4.7080201@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Proposed update to Session-ID charter, round-4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 01:18:28 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, May 14, 2010 7:56 PM >=20 > Hadriel Kaplan wrote: > > > > For media-based sessions, such B2BUA's actually can and do represent > different media sources at different points in the call; for example app > servers which generate specific tones/music to the UAC while they hunt fo= r > the called party. >=20 > I find very little difference between this scenario and one where the > call is first answered by a secretary and then transferred to the > intended callee. (Does it matter that the secretary is automated?) In the case I was describing, the first dialog leg doesn't reach an establi= shed state until the party is found. If it *did*, which happens in some fi= nd-me-follow-me app servers, then I would think they're really separate ses= sion-ids. I'm not super-tide to that position, just seems logical to me fo= r some reason. =20 > I'm a bit confused about how things should work if the transfer case > does *not* share the same session-id: >=20 > A ----------- B ----------- C > | > |------------ D >=20 > Initially from A via B2BUA B to C, and gets Session-ID X applied to both > the A-B leg and the B-C leg. Then B replaces the B-C "leg" with the B-D > "leg". If the B-D leg doesn't get session-id X, and instead gets > session-ID Y, does A-B then also get a new session-id of Y??? It seems > it must if the correlation is to work for that. > That then means that a single dialog, A-B has more than one session-id: > X and Y. Is that what is intended??? In the current Session-ID draft, it makes no statement about that, iirc. =20 I think that's one of the things the SIPSCOTCH WG must decide: whether A-B-= D is in fact the same session-id as A-B-C. If it *is*, then I'd argue a tr= ansferred call from A directly to D, replacing A-B-C, is also the same sess= ion-id. I can see it both ways. Arguably, if A-B-C got to the established state, t= hat was higher-layer Call-1. If B-C gets replaced with B-D, then A-B-D is = Call-2. On the other hand, from a troubleshooting perspective it would be = nice to know those dialogs are all related. Note that once you open the door for the session-id to go beyond the initia= l established call, it can get weird and complicated. For example, what happens if you call a public-announcement broadcaster ser= ver; you press some special codes, record an announcement, and press "broad= cast"; do the sessions it creates for you use the same session-id as your c= all? Or take your example above, B-D could have replaced B-C by *D* sending an I= NVITE with replaces to *B*. So we'd have to get the Session-ID value to D = so it can use it in its INVITE to B, like by C passing it in the Refer-To o= f a REFER to D. OK, so now imagine if B parked the call and Referred D to = C, and you ended up with 2 dialogs A-B, C-D as below. But they'd be using = the same session-id. Is that legit? (maybe, I dunno) A ----------- B C | D -hadriel From pkyzivat@cisco.com Fri May 14 21:18:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9833A68A4 for ; Fri, 14 May 2010 21:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESC9d3CCVP6Z for ; Fri, 14 May 2010 21:18:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 105B13A6862 for ; Fri, 14 May 2010 21:18:04 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOi87UurRN+K/2dsb2JhbACeBHGjWZkuhRAE X-IronPort-AV: E=Sophos;i="4.53,234,1272844800"; d="scan'208";a="197804905" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 15 May 2010 04:00:39 +0000 Received: from [10.86.240.27] (che-vpn-cluster-1-27.cisco.com [10.86.240.27]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o4F40bNw016042; Sat, 15 May 2010 04:00:38 GMT Message-ID: <4BEE1C65.1090507@cisco.com> Date: Sat, 15 May 2010 00:00:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91A8A7D799F@mail> <430FC6BDED356B4C8498F634416644A91C13990FC6@mail> <430FC6BDED356B4C8498F634416644A91C139910E5@mail>, <430FC6BDED356B4C8498F634416644A91C139912FE@mail> <4BEDE2F4.7080201@cisco.com> <430FC6BDED356B4C8498F634416644A91C13991392@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13991392@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Proposed update to Session-ID charter, round-4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 04:18:07 -0000 Hadriel, I don't disagree with anything you say below. But it is also what is troubling to me. It seems there is no one obvious definition for which dialogs should be related - there are good reasons for each of several possible definitions. Yet its hard to imagine supporting them all. And leaving it to the discretion of each server seems even worse. So I don't see how to decide on a definition. Thanks, Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, May 14, 2010 7:56 PM >> >> Hadriel Kaplan wrote: >>> For media-based sessions, such B2BUA's actually can and do represent >> different media sources at different points in the call; for example app >> servers which generate specific tones/music to the UAC while they hunt for >> the called party. >> >> I find very little difference between this scenario and one where the >> call is first answered by a secretary and then transferred to the >> intended callee. (Does it matter that the secretary is automated?) > > In the case I was describing, the first dialog leg doesn't reach an established state until the party is found. If it *did*, which happens in some find-me-follow-me app servers, then I would think they're really separate session-ids. I'm not super-tide to that position, just seems logical to me for some reason. > > >> I'm a bit confused about how things should work if the transfer case >> does *not* share the same session-id: >> >> A ----------- B ----------- C >> | >> |------------ D >> >> Initially from A via B2BUA B to C, and gets Session-ID X applied to both >> the A-B leg and the B-C leg. Then B replaces the B-C "leg" with the B-D >> "leg". If the B-D leg doesn't get session-id X, and instead gets >> session-ID Y, does A-B then also get a new session-id of Y??? It seems >> it must if the correlation is to work for that. >> That then means that a single dialog, A-B has more than one session-id: >> X and Y. Is that what is intended??? > > In the current Session-ID draft, it makes no statement about that, iirc. > I think that's one of the things the SIPSCOTCH WG must decide: whether A-B-D is in fact the same session-id as A-B-C. If it *is*, then I'd argue a transferred call from A directly to D, replacing A-B-C, is also the same session-id. > > I can see it both ways. Arguably, if A-B-C got to the established state, that was higher-layer Call-1. If B-C gets replaced with B-D, then A-B-D is Call-2. On the other hand, from a troubleshooting perspective it would be nice to know those dialogs are all related. > > Note that once you open the door for the session-id to go beyond the initial established call, it can get weird and complicated. > > For example, what happens if you call a public-announcement broadcaster server; you press some special codes, record an announcement, and press "broadcast"; do the sessions it creates for you use the same session-id as your call? > > Or take your example above, B-D could have replaced B-C by *D* sending an INVITE with replaces to *B*. So we'd have to get the Session-ID value to D so it can use it in its INVITE to B, like by C passing it in the Refer-To of a REFER to D. OK, so now imagine if B parked the call and Referred D to C, and you ended up with 2 dialogs A-B, C-D as below. But they'd be using the same session-id. Is that legit? (maybe, I dunno) > > A ----------- B C > | > D > > -hadriel > > From xavier.marjou@gmail.com Mon May 17 02:11:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC283A68F7 for ; Mon, 17 May 2010 02:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3bUBb7dMAKx for ; Mon, 17 May 2010 02:11:39 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 619113A6899 for ; Mon, 17 May 2010 02:11:30 -0700 (PDT) Received: by gxk9 with SMTP id 9so3077869gxk.8 for ; Mon, 17 May 2010 02:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=kmqEqUddneACKcli+Y4z8LoEevZIqMGG1kod5P/Zvxw=; b=En/90O5UffdpOdTix6ESGUA4CSClnfYekhR1IgKH/IklwcZ1R5veyNc3H1/WxSPcyT 3noNC+PqvTluy4WEtRQzqpoDIA+6tZvhby1QcyyHXT8ejbB0AxyJwdFIeAiU2HzFUAvk 4o9Ctvv7QIZ4heU0JXbjcUHDOOuLaRdI2CfW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=BIfnWLQZZ47uo6D7f88+Rfag3Vb7Wy1ZvEKauUrG38zK0lfv/bu6bIr2AiBKomqdRH pXol+Zaf1lk7WSUheUeecbK7FPvCw5FA0vWEbwyS3HL3zGMk5a/x7LUrPj21uwGkCN1q kfyLPnNg0trsv26GSZ1xxmG/iRuqHqWg++RTA= MIME-Version: 1.0 Received: by 10.151.20.11 with SMTP id x11mr3699040ybi.216.1274087477321; Mon, 17 May 2010 02:11:17 -0700 (PDT) Sender: xavier.marjou@gmail.com Received: by 10.150.91.8 with HTTP; Mon, 17 May 2010 02:11:17 -0700 (PDT) In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> Date: Mon, 17 May 2010 11:11:17 +0200 X-Google-Sender-Auth: BagcZzyGHrVdBAVP6pWdOCWlwNY Message-ID: From: Xavier Marjou To: R.Jesske@telekom.de Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 09:11:41 -0000 Hi, I support the overall proposal of the two drafts. Cheers, Xavier 2010/5/13 : > Dear all, > I have asked for comments on the two drafts mentioned below. > So far I didn't get any. Does that mean that people are happy now with th= e > content and we could proceed with it? > > Thank you and Best Regrads > > Roland > > _____________________________________________ > Von: =A0=A0 Jesske, Roland > Gesendet:=A0=A0=A0=A0=A0=A0 Donnerstag, 8. April 2010 09:46 > An:=A0=A0=A0=A0 dispatch@ietf.org > Betreff:=A0=A0=A0=A0=A0=A0=A0 Reason In responses > (draft-jesske-dispatch-reason-in-responses-02) > > Dear all, > During the discussion concerning the Reason header field in Responses I w= as > asked to split the document into an requirements part and an protocol par= t. > > So please feel free to comment on the drafts. > > http://64.170.98.42/html/draft-jesske-dispatch-reason-in-responses-02 > > http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-responses-00 > > Best regards > > Roland Jesske > > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Roland Jesske > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628-2766 (Tel.) > +49 521 9210-3753=A0 (Fax) > +49 171 8618-445=A0 (Mobil) > E-Mail: r.jesske@telekom.de > www.telekom.com > > Erleben, was verbindet. > > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mat= heis, > Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 > > Gro=DFe Ver=E4nderungen fangen klein an =96 Ressourcen schonen und nicht = jede > E-Mail drucken. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From laura.liess.dt@googlemail.com Mon May 17 06:22:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD973A67F8 for ; Mon, 17 May 2010 06:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.102 X-Spam-Level: X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvgjj-313cIx for ; Mon, 17 May 2010 06:22:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 386E13A6A06 for ; Mon, 17 May 2010 06:18:33 -0700 (PDT) Received: by wyb42 with SMTP id 42so2575268wyb.31 for ; Mon, 17 May 2010 06:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EM8iko3s4s8bFVnYfi+twkmFFcE0itxgwA+LvS94+gQ=; b=tNN28xvF8kkrCLY4gfh42G4u07LvP8LRvymko05xL2J4Eu1BMO4nZd6mQLGbbRfpto N99LzXU5ub0ynIykULcXCv5ICzINiaeDTA2hyNRENiTHqnBOntoLx+ONeewwUsdgdg/w dR+NzAYa6NUQdbg5XtbnIn2HfTTlkWfJ7jIek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MEIBHnKH7TdwFDWO7gEsnQjuWXtBIcXb3G45uzLTYpAyE7oMPNBOX0hAdtQiWcZoV4 eS+KAvWmxPjSpKg5xLk/UFDtuciQ88l+n+rTyh056+0Vi0aZJ74wZI5YOgulmKlqs0iu VJNx1MLG3OcfALQtmtLpEHhjMkJwqueWXJmuk= MIME-Version: 1.0 Received: by 10.216.85.21 with SMTP id t21mr3138266wee.151.1274102300637; Mon, 17 May 2010 06:18:20 -0700 (PDT) Received: by 10.216.178.133 with HTTP; Mon, 17 May 2010 06:18:20 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91C1399121F@mail> References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <430FC6BDED356B4C8498F634416644A91C13990F46@mail> <4bec4e62.0c58560a.188d.ffff9205@mx.google.com> <430FC6BDED356B4C8498F634416644A91C1399121F@mail> Date: Mon, 17 May 2010 15:18:20 +0200 Message-ID: From: Laura Liess To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 13:22:17 -0000 Hi Hadriel, I did some digging about how the Q.850 RELEASE causes are handled in the DT PSTN and the Reason-Header in NGN. Please find comments inline.. Also 2010/5/14 Hadriel Kaplan : > > [Argh - I should have said "Other comments inline...", so re-sending the = email corrected] > > > Hi Laura, > Just to be clear: I'm fine with having both Alert-Info "semantic" URNs an= d Reason-header codes in responses. =A0I'm just asking that the drafts expl= ain in their text why they are necessary to be separate, what they're used = for that's "different", etc. =A0Basically, I'm trying to avoid confusion fo= r implementers and operators if both of these become RFCs. > > Other comments inline... > >> -----Original Message----- >> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >> Sent: Thursday, May 13, 2010 3:09 PM >> To: Hadriel Kaplan; R.Jesske@telekom.de; dispatch@ietf.org >> >> Alert-Info URNs and Reason in responses are two different things. >> Alert-Info URNs are names for ring tones which has to be rendered to the >> users. They can be carried in INVITE or 18x responses and resolved by SI= P >> end devices according to local rules into a specific tones or text. They >> are >> not involved in applications logic neither in SIP nor in PSTN. > > Well, to be nit-picky the proposed Alert-Info URN *is* involved in applic= ation logic in SIP: application logic to resolve a URN, render a tone, disp= lay a message, or whatever. =A0And in theory I assumed that if a PSTN SIT-s= ignal was received on a PSTN-SIP gateway, it would convert it to an Alert-I= nfo URN like "short-long-long"; and if that SIP response message hit anothe= r SIP-PSTN gateway to go back into PSTN, that it would convert it back to a= SIT. =A0So it applies to that SIP-PSTN inter-working application logic as = well. > > So I suppose one question would be what _other_ logic a SIP UA or SIP-PST= N gateway would be doing with a Q.850 Reason-header cause-code that it coul= dn't be doing with a "semantic" Alert-Info URN which represented a cause-co= de. > > BTW, in the PSTN aren't those Q.850 codes also used for "rendering"? >=A0Doesn't the PSTN-switch or PBX getting the response code use the Q.850 = code to pick a specific tone sequence to play to a >handset in some cases? > [LL] It depends on the Cause-code. Some cause- code result in a user announcement, other result in a network action. E.g. causes 34 "no circuit available" and 42 "switching equipment congestion" result in rerouting due to congestion, not in a user tone or announcement. I like really very much Dale's text on this issue (3.rd paragraph in his "Alert-Info thoughts"-mail). Reason in responses are used for interworlking with PSTN. They are in principle about extending the 3261 response code set to cover also respose codes needed by PSTN. The difference between Alert Info URN and reason codes is, from my point of view, similar to the difference between Alert-Info URN and SIP response codes. > > >> Reason in responses is about extending the usage of the Reason header >> defined in RFC3326 to SIP responses. The RFC 3326 currently allows it on= ly >> in SIP requests. Typical use cases are to carry it in CANCEL or BYE >> requests >> (see 3326 message flows) or in error responses. A typical message flows >> for >> Reason in responses is shown in an earlier version of Roland's draft, e.= g. >> http://tools.ietf.org/id/draft-jesske-sipping-etsi-ngn-reason-04.txt, >> where >> the reason is sent in 603 Decline. You can't do this with the Alert-Info >> header. > > I would think you'd want Alert-Info to apply to such failure responses to= o, no? =A0For example, there is a different tone presented today for a user= -busy, vs. an all-circuits-busy, vs. an incorrect number. [LL] PSTN users get a special tone for all-circuits-busy, in SIP we don't need this. For the other two we have SIP response codes in 3261. > Or do you mean an Alert-Info URN would only be used for rendering decisio= ns of 18x, and a Reason-header would be used for rendering decisions of oth= er SIP responses? We have the reason in reaponses *only* for interworking with ISUP REL message cause-codes. It never occures in connection setup messages or responses (INVITE, 18x, OK ). Network elements may check the reason header and take call control decisions as rerouting the call, without any information to the user. Alert-Info URNs represent tones. The receiving end device only resolves it to a tone and plays the tone. Nothing else. The end device does not look at what the Alert-Info URN means, but only if it has rules to resolve it to a concrete tone. If it has, it resolves the URN, otherwise the URN is discarded. It can be call waiting or Bethoven Fifth or the combination internal+short. The network will not use the Alert-info URNs for the call control logic. The RFC 3261 allows Alert-Info in INVITE and 180. People agreed on the ML to exten this to 18x. Thanks Laura > > -hadriel > From R.Jesske@telekom.de Tue May 18 07:57:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18F43A69B2 for ; Tue, 18 May 2010 07:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, HELO_EQ_DE=0.35, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JlZ-WLYFzAZ for ; Tue, 18 May 2010 07:57:37 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 2748C3A6861 for ; Tue, 18 May 2010 07:57:35 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 18 May 2010 16:57:24 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 May 2010 16:57:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 May 2010 16:57:22 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reason In responses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQAAoty1ABCq4IQA== References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> From: To: , X-OriginalArrivalTime: 18 May 2010 14:57:23.0766 (UTC) FILETIME=[6C686D60:01CAF69A] Subject: Re: [dispatch] Reason In responses(draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 14:57:39 -0000 Hi John, Thank you for your comments.=20 It was asked to split the draft into requirements and at least = procedures. You are right that within the requirements draft is more that = requirements. It is also the motivation, justification and examples. I = can change the title if people are happy with it. Question is if such a = draft is also needed as RFC or if it only seen as a temporary document = during the discussion. With regard to REQ-1 I propose the following re-wording: It should be possible to support within native SIP environment = PSTN-SIP-PSTN scenarios where the reason of a call release can be = transferred though the SIP domain without any loss of information and no change of reason. I think this was discussed lengthy during the last meeting and email = discussion. Not each PSTN GW will support ISUP MIME encapsulation. At least the 3GPP = IMS has no SIP. The IMS is not using SIP-T. REQ-2 and REQ-3 Yes it looks similar. REQ-3 was added because it was seen from user device perspective that = the Device have the possibility to show the Q.850 cause but that such a = End Device does not include Q.850 causes. Of course a MGC should have = this possibility. I would be happy to shrink REQ-2 and 3 to your proposed text. REQ-2 It must be possible to provide an accurate indication to a UAC, so that = the UAC can provide a suitable indication to the user. Whether this be = an announcement, a textual message, an icon, a flashing lamp, a tone, a = vibration, an odour or whatever, is a user interface matter. REQ-4 was the consequence of REQ-3 where we do not allow the inclusion = of a Q850 cause by a end device. So the trick is not allow the SIP end device to include a Q850 cause and = in some certain cases to allow an service provider controlled = application server to include a Reason header with a Q.850 cause. But it = should not be done generally by SIP applications. So normally a ISUP = implementation will use ISUP causes but not SIP implementations. But there are SIP Application servers out in the world that will have a = ISUP application (or ISUP like application that reacts and behaves as = within a ISUP network). Question is now how to proceed further. Are people happy to have the documents split or put again together with = striking out the examples ect? Or to have the documents as they are with some transfer of text to the = draft-jesske-dispatch-reason-in-responses-02 draft? Comments? Thank you and Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Gesendet: Donnerstag, 13. Mai 2010 09:24 An: Jesske, Roland; dispatch@ietf.org Betreff: RE: Reason In = responses(draft-jesske-dispatch-reason-in-responses-02) Roland, In my view, there is a simple requirement to convey Q.850 causes in SIP = response messages, so that the UAC will receive a more accurate = indication of the reason for rejection when rejection comes from PSTN. = The cause mapping table helps to illustrate this. This is not rocket = science, and I am disappointed that we have not found a quick way of = dispatching this and just getting the work done. In my opinion the split = into separate documents was unnecessary (take as an example the = recently-published RFC 5876, which combines motivation and solution in = one document), but it has been done now. Unfortunately I don't think it = has moved us any further forward. I don't think the requirements in section 3 are particularly well = expressed. REQ-1 can already be met by tunnelling in accordance with = SIP-T. I would not expect the IETF to provide a new solution = specifically for that requirement. I think REQ-2 and REQ-3 boil down to the same thing - it must be = possible to provide an accurate indication to a UAC, so that the UAC can = provide a suitable indication to the user. Whether this be an = announcement, a textual message, an icon, a flashing lamp, a tone, a = vibration, an odour or whatever, is a user interface matter. I also find REQ-4 rather problematic. If we have a solution for PSTN, we = would also have a solution for some other form of gateway into a domain = that provides a "PSTN-like service". Unfortunately, if you try to bring = this out as a separate requirement, it raises the question of what = exactly is this "PSTN-like service", and if it is somehow SIP-based, why = it needs to be "PSTN-like", and so on. Basically I think there is only a single requirement here - provision of = a correct indication to a UAC when rejection comes from the PSTN. I = think that is a reasonable requirement and we should just go ahead and = do it, rather like we did with RFC 5876 when we extended the range of = messages that PAI/PPI could be used in. I find the statement in REQ-3 "A inclusion of [Q.850] causes is out of = scope." very strange. I thought the whole idea was to convey Q.850 = causes, so why say they are out of scope? I assume this is some sort of = typo. I think one of the consequences of deciding to split requirements and = solution into separate drafts is that the requirements draft has to = stick to motivation and requirements. I find too much in the draft = (particularly the examples) that smells of solution. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de > Sent: 13 May 2010 03:05 > To: dispatch@ietf.org > Subject: Re: [dispatch] Reason In responses=20 > (draft-jesske-dispatch-reason-in-responses-02) >=20 > Dear all,=20 > I have asked for comments on the two drafts mentioned below.=20 > So far I didn't get any. Does that mean that people are happy=20 > now with the content and we could proceed with it?=20 >=20 > Thank you and Best Regrads=20 >=20 > Roland=20 >=20 >=20 > _____________________________________________=20 > Von: Jesske, Roland =20 > Gesendet: Donnerstag, 8. April 2010 09:46=20 > An: dispatch@ietf.org=20 > Betreff: Reason In responses=20 > (draft-jesske-dispatch-reason-in-responses-02)=20 >=20 > Dear all,=20 > During the discussion concerning the Reason header field in=20 > Responses I was asked to split the document into an=20 > requirements part and an protocol part. >=20 > So please feel free to comment on the drafts.=20 >=20 > http://64.170.98.42/html/draft-jesske-dispatch-reason-in-respo > nses-02=20 > onses-02> =20 >=20 > http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-r > esponses-00=20 > responses-00> =20 >=20 > Best regards=20 >=20 > Roland Jesske=20 >=20 >=20 > Deutsche Telekom Netzproduktion GmbH=20 > Zentrum Technik Einf=FChrung=20 > Roland Jesske=20 > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 > +49 6151 628-2766 (Tel.)=20 > +49 521 9210-3753 (Fax)=20 > +49 171 8618-445 (Mobil)=20 > E-Mail: r.jesske@telekom.de =20 > www.telekom.com =20 >=20 > Erleben, was verbindet.=20 >=20 > Deutsche Telekom Netzproduktion GmbH=20 > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)=20 > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > Albert Matheis, Klaus Peren=20 > Handelsregister: Amtsgericht Bonn HRB 14190=20 > Sitz der Gesellschaft: Bonn=20 > USt-IdNr. DE 814645262=20 >=20 > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und=20 > nicht jede E-Mail drucken.=20 >=20 >=20 >=20 From allyn@cisco.com Tue May 18 11:35:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F61B3A6A8C for ; Tue, 18 May 2010 11:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxcMoqVLXbgI for ; Tue, 18 May 2010 11:35:22 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2EF3828C22A for ; Tue, 18 May 2010 11:30:20 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAAl68kurR7Hu/2dsb2JhbACBPpxFcaUkmXyCWYI3BIJ5Rw X-IronPort-AV: E=Sophos;i="4.53,256,1272844800"; d="scan'208,217";a="131366748" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 18 May 2010 18:30:08 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4IIU8O7002981 for ; Tue, 18 May 2010 18:30:08 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 11:30:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AKTf AdiX Ag04 A2mF Bne0 Bzuo CiLK Cmnr F3q1 HOVk JqBl JtuZ JulV J/Wy Lcyl MOFo; 1; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {68D84D3B-FECB-4A0E-AA65-8C9E0B5AEA15}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Tue, 18 May 2010 18:30:02 GMT; TQB1AGwAdABpAC0AcwB0AHIAZQBhAG0AcwAgAGYAbwByACAAdABlAGwAZQBwAHIAZQBzAGUAbgBjAGUAIABkAGUAcwBjAHIAaQBwAHQAaQBvAG4AIABvAGYAIAB3AG8AcgBrAA== MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAF6B8.24856E47" x-cr-puzzleid: {68D84D3B-FECB-4A0E-AA65-8C9E0B5AEA15} Content-class: urn:content-classes:message Date: Tue, 18 May 2010 11:30:02 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multi-streams for telepresence description of work Thread-Index: Acr2uCFZ+eckhAOrTo2gjbFeNJpM3Q== From: "Allyn Romanow (allyn)" To: "IETF DISPATCH list" X-OriginalArrivalTime: 18 May 2010 18:30:08.0154 (UTC) FILETIME=[249377A0:01CAF6B8] Subject: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 18:35:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF6B8.24856E47 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 Many of you are aware of telepresence systems (video conferencing on steroids..:), fewer probably are aware of the fact that the current systems are not interoperable with each other. After talking with Mary and Cullen, we have a rough draft of a charter to work on this problem in DISPATCH, for discussion on the mailing list. =20 We don't yet know whether a working group would need to be spun out or not - that will be clarified as we go. =20 We think there is enough background info in the work description to start a discussion, and plan to send out use cases for discussion shortly. =20 Who is the we? Several makers and providers of telepresence systems have gotten together to define the main problem in interoperability - the handling of multi-streams. =20 Thanks for your thoughts- Allyn =20 =20 Multi-streams for Telepresence Description of Work =20 =20 =20 Background One branch of video conferencing has evolved that is focused on immersive "being there" experience. Referred to in various ways such as virtual conferencing, telepresence or media spaces, early systems were mainly research projects or business systems with limited deployments. In recent years telepresence systems have seen considerable market success. Following the model of early systems, the first wave of commercial systems have been typically located in specially designed single-purpose rooms with multiple relatively large displays permitting life size image reproduction, multiple cameras, encoders, decoders and microphones. These systems have several important characteristics that are different from more traditional video conferencing systems. =20 =20 The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential group meeting characteristics such as eye contact, group gestures, seating order and spatial audio by carefully orchestrating the miking and camera angles at each of the sites . This is distinct from the more traditional approach where the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics. =20 =20 A second difference is manipulation of the environment to improve immersion. With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating and lighting so that when combined with large high quality displays, a strong sense of a "trompe l'oeil" or "being there" immersive experience is created. Typical video conference systems do not include these considerations. =20 As telepresence video systems have become successful in the market, manufacturers have started exploring delivery of the nonverbal communication and immersive values of telepresence via smaller, less expensive and more flexible video conferencing systems for a variety of venues, such as individual offices, homes and kiosks. These are also telepresence systems, since the audio and video quality is high enough to allow clear image reproduction for nonverbal communication, they are able to send and receive multiple media streams, and large coordinated multi image displays are available for immersive installations. As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly available. =20 Problem Although telepresence systems are based on open standards such as RTP, SIP, H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one vendor to another. It would be like having to make sure all parties are on the same equipment (and network) when making a telephone call. A major factor in the inability of Telepresence systems to work with each other is that there is no standard description of the multiple streams that comprise the media flows.=20 =20 For example, in a multiple screen conference, the video and audio streams sent from remote participants must be understood by receivers so that they can be presented in a coherent and life-like manner. This includes the ability to present the remote participants at their true size for their apparent distance, while maintaining correct eye contact, gesticular cues, and simultaneously providing a spatial audio sound stage consistent with the video presentation. The receiving device that decides how to display the incoming information needs to understand a number of variables such as the spatial position of the speaker, the field of view of the cameras, the camera zoom, which media stream is related to each of the displays, etc.=20 =20 Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to define and specify the content of media multi-stream messages and the way these will be transported.=20 This work is aimed at providing a standard for the exchange of media semantics information that will foster interoperable end stations and conference bridges. This work item will specify the variables that describe the semantics of the media streams and the recommended behavior to achieve interoperability. =20 =20 This requires considering current widely deployed use cases, such as single and multiple screens, multi-point, Scalable Video Coding (SVC), as well as cases that are expected to be implemented using the protocol framework produced by this work item. The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young technology and may have use cases that are not currently considered. =20 The work item will identify use cases, define requirements, and define a method for describing and transporting information about multiple media streams, including a specification of variables required to support the use cases. This work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols required to be implemented to support this functionality. The document will identify any enhancements required to existing protocols as well as describing new protocol(s) for interoperable multi-streams negotiation that may be required. =20 Scope The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. =20 The focus of this work is on audio and video multiple streams, however other media types may be considered. Definition of new application protocols is not within the scope of this work =20 [Is there anything else we need to explicitly say is out of scope?] =20 The group will produce - Requirements and use cases =20 - Architectural Framework describing the protocols required to be implemented to support this functionality and identifying existing protocol enhancements and new protocol functionality required =20 - Specification of a new protocol to support telepresence multi-streams [if required] =20 Goals and Milestones Nov 2010=20 Use Cases and Requirements to IESG as Informational RFC=20 March 2011=20 Architecture to IESG as Informational RFC=20 March 2011 Revise Charter [IF new protocol is not required] Nov 2011=20 Submit protocol draft to IESG as Proposed Standard RFC=20 =20 =20 =20 =20 ------_=_NextPart_001_01CAF6B8.24856E47 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

Many of you are aware of telepresence systems = (video conferencing on steroids..:), fewer probably are aware of the fact that = the current systems are not interoperable with each other. After talking with Mary = and Cullen, we have a rough draft of a charter to work on this problem in DISPATCH, =  for discussion on the mailing list.

 

We don’t yet know whether a working group = would need to be spun out or not – that will be clarified as we = go.

 

We think there is enough background info in the = work description to start a discussion, and plan to send out use cases for discussion shortly.

 

Who is the we? Several makers and providers of = telepresence systems have gotten together to define the main problem in = interoperability – the handling of multi-streams.

 

Thanks for your thoughts-

Allyn

 

 

Multi-streams for = Telepresence Description of Work

 

 

 

Background

One branch of video conferencing has evolved that is focused on immersive “being there” experience.  Referred to in various ways such as = virtual conferencing, telepresence or media spaces, early systems were mainly = research projects or business systems with limited deployments.  In recent = years telepresence systems have seen considerable market success.  Following the model = of early systems, the first wave of commercial systems have been typically = located in specially designed single-purpose rooms with multiple relatively = large displays permitting life size image reproduction, multiple cameras, = encoders, decoders and microphones.  These systems have several important characteristics that are different from more traditional video = conferencing systems. 

 

The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential = group meeting characteristics such as eye contact, group gestures, seating = order and spatial audio by carefully orchestrating the miking and camera angles at = each of the sites . This is distinct from the more traditional approach where = the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics. 

 

A = second difference is manipulation of the environment to improve = immersion.  With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating = and lighting so that when combined with large high quality displays, a = strong sense of a "trompe l'oeil" or "being there" immersive = experience is created.  Typical video conference systems do not include these considerations.

 

As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal communication and = immersive values of telepresence via smaller, less expensive and more flexible = video conferencing systems for a variety of venues, such as individual = offices, homes and kiosks. These are also  telepresence systems, since the audio = and video quality is high enough to allow clear image reproduction for = nonverbal communication, they are able to send and receive multiple media streams, = and large coordinated multi image displays are available for immersive installations.   As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly = available.

 

Problem<= /p>

Although telepresence systems are based on open standards such as RTP, SIP, = H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one = vendor to another. It would be like having to make sure all parties are on the = same equipment (and network) when making a telephone call.  A major = factor in the inability of Telepresence systems to work with each other is that = there is no standard description of the multiple streams that comprise the media = flows.

 

For example, in a multiple screen conference, the video and audio streams sent from = remote participants must be understood by receivers so that they can be = presented in a coherent and life-like manner. This includes the ability to present the = remote participants at their true size for their apparent distance, while = maintaining correct eye contact, gesticular cues, and simultaneously providing a = spatial audio sound stage consistent with the video presentation.  The = receiving device that decides how to display the incoming information needs to = understand a number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is related to = each of the displays, etc.

 

Charter<= /p>

The Telepresence Multi-Streams work item in DISPATCH is chartered to define = and specify the content of media multi-stream messages and the way these = will be transported.

This work is aimed at providing a standard for the exchange of media = semantics information that will foster interoperable end stations and conference = bridges. This work item = will specify the variables that describe the semantics of the media streams = and the recommended behavior to achieve interoperability.  =

 

This requires considering current widely deployed use cases, such as single = and multiple screens, multi-point, Scalable Video Coding (SVC), as well as = cases that are expected to be implemented using the protocol framework = produced by this work item.  The methodology for describing the variables must = allow extensibility of the variables, since telepresence is still a young = technology and may have use cases that are not currently = considered.

 

The work item will identify use cases, define requirements, and define a = method for describing and transporting information about multiple media streams, = including a specification of variables required to support the use cases. This = work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols = required to be implemented to support this functionality.  The document will = identify any enhancements required to existing protocols as well as describing = new protocol(s) for interoperable multi-streams negotiation that may be = required.

 

Scope

The scope includes both systems that provide a fully immersive experience, and = systems that interwork with them and therefore need to understand the same = multiple stream semantics.

 

The focus of this work is on audio and video multiple streams, however other = media types may be considered.  Definition of new application protocols = is not within the scope of this work

 

[Is there anything else we need to explicitly say is out of = scope?]

 

The group will produce

- Requirements and use cases

 

- Architectural Framework describing the protocols required to be = implemented to support this functionality and identifying existing protocol = enhancements and new protocol functionality required

 

- Specification of a new protocol to support telepresence multi-streams = [if required]

 

Goals and Milestones

Nov 2010

Use Cases and Requirements to IESG as Informational RFC

March 2011

Architecture to IESG as Informational RFC

March 2011

Revise Charter [IF new protocol is not required]

Nov 2011

Submit protocol draft to IESG as Proposed Standard RFC

 

 

 

 

------_=_NextPart_001_01CAF6B8.24856E47-- From john.elwell@siemens-enterprise.com Tue May 18 12:37:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE563A6A84 for ; Tue, 18 May 2010 12:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOb6MYWwQaue for ; Tue, 18 May 2010 12:37:11 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 7E8653A699C for ; Tue, 18 May 2010 12:37:04 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-214161; Tue, 18 May 2010 21:36:56 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 4D7A51EB82AB; Tue, 18 May 2010 21:36:56 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 18 May 2010 21:36:56 +0200 From: "Elwell, John" To: "R.Jesske@telekom.de" , "dispatch@ietf.org" Date: Tue, 18 May 2010 21:36:54 +0200 Thread-Topic: Reason In responses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQAAoty1ABCq4IQAAKTKog Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Reason In responses(draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 19:37:13 -0000 Roland,=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: 18 May 2010 15:57 > To: Elwell, John; dispatch@ietf.org > Subject: AW: Reason In=20 > responses(draft-jesske-dispatch-reason-in-responses-02) >=20 > Hi John, > Thank you for your comments.=20 > It was asked to split the draft into requirements and at=20 > least procedures. >=20 > You are right that within the requirements draft is more that=20 > requirements. It is also the motivation, justification and=20 > examples. I can change the title if people are happy with it.=20 > Question is if such a draft is also needed as RFC or if it=20 > only seen as a temporary document during the discussion. [JRE] I was not proposing a title change, and I have no problem combining m= otivation with requirements, although I do feel the examples look too much = like solution and are unnecessary. Although some people asked you to split = the draft, in my opinion it was wasted effort, but it is done now. >=20 > With regard to REQ-1 I propose the following re-wording: >=20 > It should be possible to support within native SIP=20 > environment PSTN-SIP-PSTN scenarios where the reason of a=20 > call release can be transferred though the SIP domain > without any loss of information and no change of reason. >=20 > I think this was discussed lengthy during the last meeting=20 > and email discussion. > Not each PSTN GW will support ISUP MIME encapsulation. At=20 > least the 3GPP IMS has no SIP. The IMS is not using SIP-T. [JRE] I don't think the new wording makes any difference. SIP-T is a means = for tunnelling a Q.850 cause through a native SIP domain. The IETF already = defines SIP-T as the solution, and if this solution is not sufficient, you = need to cite reasons why not and identify a requirement that cannot be met = using SIP-T. Just saying that IMS does not use SIP-T doesn't sound like a s= ufficient reason to me, because clearly IMS could be made to use SIP-T. To be clear, I am not saying that the Reason header field should not be use= d in this situation, if the header field is defined for use in responses in= general in order meet other requirements. I am simply saying that REQ-1 is= not sufficient justification for allowing the Reason header field in respo= nses, since REQ-1 can be satisfied using an existing mechanism. >=20 > REQ-2 and REQ-3 > Yes it looks similar. >=20 > REQ-3 was added because it was seen from user device=20 > perspective that the Device have the possibility to show the=20 > Q.850 cause but that such a End Device does not include Q.850=20 > causes. Of course a MGC should have this possibility. >=20 > I would be happy to shrink REQ-2 and 3 to your proposed text. >=20 > REQ-2 > It must be possible to provide an accurate indication to a=20 > UAC, so that the UAC can provide a suitable indication to the=20 > user. Whether this be an announcement, a textual message, an=20 > icon, a flashing lamp, a tone, a vibration, an odour or=20 > whatever, is a user interface matter. [JRE] I did not intend the second sentence to be part of the requirement - = it was just for illustration of why the existing text, which focused on tex= tual display, was inadequate. >=20 > REQ-4 was the consequence of REQ-3 where we do not allow the=20 > inclusion of a Q850 cause by a end device. >=20 > So the trick is not allow the SIP end device to include a=20 > Q850 cause and in some certain cases to allow an service=20 > provider controlled application server to include a Reason=20 > header with a Q.850 cause. But it should not be done=20 > generally by SIP applications. So normally a ISUP=20 > implementation will use ISUP causes but not SIP implementations. > But there are SIP Application servers out in the world that=20 > will have a ISUP application (or ISUP like application that=20 > reacts and behaves as within a ISUP network). [JRE] I found REQ-3 rather confusing. On re-reading it, the first sentence = is a requirement concerning reception, and the second sentence seems (if I = understand correctly) to be a statement about sending. Assuming my understa= nding is correct, making a statement, within a requirement, that something = is out of scope seems to suggest it is not part of the requirement. In addition, the way SIP is specified, there is no real distinction between= different types of UA. In other words, SIP procedures for UAs apply to UAs= in general, not to specific types of UA like ASs. So writing a requirement= that tries to distinguish between different types of UA does not seem to m= ake sense. >=20 > Question is now how to proceed further. >=20 > Are people happy to have the documents split or put again=20 > together with striking out the examples ect? > Or to have the documents as they are with some transfer of=20 > text to the draft-jesske-dispatch-reason-in-responses-02 draft? [JRE] I don't have a strong opinion about document structure, although my p= ersonal preference would have been to leave it as one document, as it was o= riginally. My main concern is trying to come up with a meaningful set of re= quirements, and in my opinion it reduces to a single requirement - being ab= le to convey a Q.850 cause from PSTN (or similar) to a UAC so that the UAC = can render meaningful information to the user. John >=20 > Comments? >=20 > Thank you and Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Gesendet: Donnerstag, 13. Mai 2010 09:24 > An: Jesske, Roland; dispatch@ietf.org > Betreff: RE: Reason In=20 > responses(draft-jesske-dispatch-reason-in-responses-02) >=20 > Roland, >=20 > In my view, there is a simple requirement to convey Q.850=20 > causes in SIP response messages, so that the UAC will receive=20 > a more accurate indication of the reason for rejection when=20 > rejection comes from PSTN. The cause mapping table helps to=20 > illustrate this. This is not rocket science, and I am=20 > disappointed that we have not found a quick way of=20 > dispatching this and just getting the work done. In my=20 > opinion the split into separate documents was unnecessary=20 > (take as an example the recently-published RFC 5876, which=20 > combines motivation and solution in one document), but it has=20 > been done now. Unfortunately I don't think it has moved us=20 > any further forward. >=20 > I don't think the requirements in section 3 are particularly=20 > well expressed. REQ-1 can already be met by tunnelling in=20 > accordance with SIP-T. I would not expect the IETF to provide=20 > a new solution specifically for that requirement. >=20 > I think REQ-2 and REQ-3 boil down to the same thing - it must=20 > be possible to provide an accurate indication to a UAC, so=20 > that the UAC can provide a suitable indication to the user.=20 > Whether this be an announcement, a textual message, an icon,=20 > a flashing lamp, a tone, a vibration, an odour or whatever,=20 > is a user interface matter. >=20 > I also find REQ-4 rather problematic. If we have a solution=20 > for PSTN, we would also have a solution for some other form=20 > of gateway into a domain that provides a "PSTN-like service".=20 > Unfortunately, if you try to bring this out as a separate=20 > requirement, it raises the question of what exactly is this=20 > "PSTN-like service", and if it is somehow SIP-based, why it=20 > needs to be "PSTN-like", and so on. >=20 > Basically I think there is only a single requirement here -=20 > provision of a correct indication to a UAC when rejection=20 > comes from the PSTN. I think that is a reasonable requirement=20 > and we should just go ahead and do it, rather like we did=20 > with RFC 5876 when we extended the range of messages that=20 > PAI/PPI could be used in. >=20 > I find the statement in REQ-3 "A inclusion of [Q.850] causes=20 > is out of scope." very strange. I thought the whole idea was=20 > to convey Q.850 causes, so why say they are out of scope? I=20 > assume this is some sort of typo. >=20 > I think one of the consequences of deciding to split=20 > requirements and solution into separate drafts is that the=20 > requirements draft has to stick to motivation and=20 > requirements. I find too much in the draft (particularly the=20 > examples) that smells of solution. >=20 > John >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > > [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de > > Sent: 13 May 2010 03:05 > > To: dispatch@ietf.org > > Subject: Re: [dispatch] Reason In responses=20 > > (draft-jesske-dispatch-reason-in-responses-02) > >=20 > > Dear all,=20 > > I have asked for comments on the two drafts mentioned below.=20 > > So far I didn't get any. Does that mean that people are happy=20 > > now with the content and we could proceed with it?=20 > >=20 > > Thank you and Best Regrads=20 > >=20 > > Roland=20 > >=20 > >=20 > > _____________________________________________=20 > > Von: Jesske, Roland =20 > > Gesendet: Donnerstag, 8. April 2010 09:46=20 > > An: dispatch@ietf.org=20 > > Betreff: Reason In responses=20 > > (draft-jesske-dispatch-reason-in-responses-02)=20 > >=20 > > Dear all,=20 > > During the discussion concerning the Reason header field in=20 > > Responses I was asked to split the document into an=20 > > requirements part and an protocol part. > >=20 > > So please feel free to comment on the drafts.=20 > >=20 > > http://64.170.98.42/html/draft-jesske-dispatch-reason-in-respo > > nses-02=20 > > > onses-02> =20 > >=20 > > http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-r > > esponses-00=20 > > > responses-00> =20 > >=20 > > Best regards=20 > >=20 > > Roland Jesske=20 > >=20 > >=20 > > Deutsche Telekom Netzproduktion GmbH=20 > > Zentrum Technik Einf=FChrung=20 > > Roland Jesske=20 > > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 > > +49 6151 628-2766 (Tel.)=20 > > +49 521 9210-3753 (Fax)=20 > > +49 171 8618-445 (Mobil)=20 > > E-Mail: r.jesske@telekom.de =20 > > www.telekom.com =20 > >=20 > > Erleben, was verbindet.=20 > >=20 > > Deutsche Telekom Netzproduktion GmbH=20 > > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)=20 > > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > > Albert Matheis, Klaus Peren=20 > > Handelsregister: Amtsgericht Bonn HRB 14190=20 > > Sitz der Gesellschaft: Bonn=20 > > USt-IdNr. DE 814645262=20 > >=20 > > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und=20 > > nicht jede E-Mail drucken.=20 > >=20 > >=20 > >=20 > = From peter.musgrave@magorcorp.com Tue May 18 21:22:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA743A6AEA for ; Tue, 18 May 2010 21:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.34 X-Spam-Level: X-Spam-Status: No, score=0.34 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhjA7BmSTptq for ; Tue, 18 May 2010 21:22:09 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id ACF7D3A6AF4 for ; Tue, 18 May 2010 21:21:58 -0700 (PDT) Received: by gyh4 with SMTP id 4so3509769gyh.31 for ; Tue, 18 May 2010 21:21:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.213.15 with SMTP id l15mr8855679ybg.202.1274242906097; Tue, 18 May 2010 21:21:46 -0700 (PDT) Received: by 10.150.58.14 with HTTP; Tue, 18 May 2010 21:21:46 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> Date: Wed, 19 May 2010 06:21:46 +0200 Message-ID: From: Peter Musgrave To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=000e0cd378f6c688ef0486eacb25 Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 04:22:13 -0000 --000e0cd378f6c688ef0486eacb25 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Allyn, I am interested in having this work start. I suspect it will likely warrant a working group at the appropriate time. The charter as written is VERY general. I would suspect that SIP/SDP is going to be the common ground. Is it worth making this explicit in the charter? If not perhaps the reasons why not could be stated in the charter. (My understanding is that most of these systems do use SIP but that they differ in number of sessions per endpoint and how the media is packaged int= o RTP streams etc.) Is there other IETF work which we can see has relevance and should be mentioned as tools which can be brought to bear? (xcon? mediactrl?) Is there interest in ensuring interop of TP with legacy SIP video conferencing systems as part of this work? Should that be part of the charter? Regards, Peter Musgrave On Tue, May 18, 2010 at 8:30 PM, Allyn Romanow (allyn) wro= te: > Hi Folks, > > > > Many of you are aware of telepresence systems (video conferencing on > steroids..:), fewer probably are aware of the fact that the current syste= ms > are not interoperable with each other. After talking with Mary and Cullen= , > we have a rough draft of a charter to work on this problem in DISPATCH, = for > discussion on the mailing list. > > > > We don=92t yet know whether a working group would need to be spun out or = not > =96 that will be clarified as we go. > > > > We think there is enough background info in the work description to start= a > discussion, and plan to send out use cases for discussion shortly. > > > > Who is the we? Several makers and providers of telepresence systems have > gotten together to define the main problem in interoperability =96 the > handling of multi-streams. > > > > Thanks for your thoughts- > > Allyn > > > > > > *Multi-streams for Telepresence Description of Work* > > * * > > * * > > * * > > *Background* > > One branch of video conferencing has evolved that is focused on immersive > =93being there=94 experience. Referred to in various ways such as virtua= l > conferencing, telepresence or media spaces, early systems were mainly > research projects or business systems with limited deployments. In recen= t > years telepresence systems have seen considerable market success. Follow= ing > the model of early systems, the first wave of commercial systems have bee= n > typically located in specially designed single-purpose rooms with multipl= e > relatively large displays permitting life size image reproduction, multip= le > cameras, encoders, decoders and microphones. These systems have several > important characteristics that are different from more traditional video > conferencing systems. > > > > The first difference concerns controlling the visual viewpoint in order t= o > improve participant nonverbal communication. These systems preserve > essential group meeting characteristics such as eye contact, group gestur= es, > seating order and spatial audio by carefully orchestrating the miking and > camera angles at each of the sites . This is distinct from the more > traditional approach where the geometric relationship between media strea= ms > is not used to preserve inter-stream communication aspects such as eye > contact and group dynamics. > > > > A second difference is manipulation of the environment to improve > immersion. With telepresence systems, cinematographic aspects of the loc= al > environment reproduction are carefully planned including color, table sha= pe, > seating and lighting so that when combined with large high quality displa= ys, > a strong sense of a "trompe l'oeil" or "being there" immersive experience= is > created. Typical video conference systems do not include these > considerations. > > > > As telepresence video systems have become successful in the market, > manufacturers have started exploring delivery of the nonverbal communicat= ion > and immersive values of telepresence via smaller, less expensive and more > flexible video conferencing systems for a variety of venues, such as > individual offices, homes and kiosks. These are also telepresence system= s, > since the audio and video quality is high enough to allow clear image > reproduction for nonverbal communication, they are able to send and recei= ve > multiple media streams, and large coordinated multi image displays are > available for immersive installations. As the industry develops, the li= ne > between telepresence and video conferencing may become blurred as nonverb= al > communication and immersive installations become broadly available. > > > > *Problem* > > Although telepresence systems are based on open standards such as RTP, SI= P, > H.264, H.323 suite, they cannot easily interoperate with each other witho= ut > operator assistance and expensive additional equipment that translates fr= om > one vendor to another. It would be like having to make sure all parties a= re > on the same equipment (and network) when making a telephone call. A majo= r > factor in the inability of Telepresence systems to work with each other i= s > that there is no standard description of the multiple streams that compri= se > the media flows. > > > > For example, in a multiple screen conference, the video and audio streams > sent from remote participants must be understood by receivers so that the= y > can be presented in a coherent and life-like manner. This includes the > ability to present the remote participants at their true size for their > apparent distance, while maintaining correct eye contact, gesticular cues= , > and simultaneously providing a spatial audio sound stage consistent with = the > video presentation. The receiving device that decides how to display the > incoming information needs to understand a number of variables such as th= e > spatial position of the speaker, the field of view of the cameras, the > camera zoom, which media stream is related to each of the displays, etc. > > > > *Charter* > > The Telepresence Multi-Streams work item in DISPATCH is chartered to defi= ne > and specify the content of media multi-stream messages and the way these > will be transported. > > This work is aimed at providing a standard for the exchange of media > semantics information that will foster interoperable end stations and > conference bridges. This work item will specify the variables that > describe the semantics of the media streams and the recommended behavior = to > achieve interoperability. > > > > This requires considering current widely deployed use cases, such as sing= le > and multiple screens, multi-point, Scalable Video Coding (SVC), as well a= s > cases that are expected to be implemented using the protocol framework > produced by this work item. The methodology for describing the variables > must allow extensibility of the variables, since telepresence is still a > young technology and may have use cases that are not currently considered= . > > > > The work item will identify use cases, define requirements, and define a > method for describing and transporting information about multiple media > streams, including a specification of variables required to support the u= se > cases. This work item will consider the reuse of existing IETF protocols = and > produce an architecture/protocol framework document describing the protoc= ols > required to be implemented to support this functionality. The document w= ill > identify any enhancements required to existing protocols as well as > describing new protocol(s) for interoperable multi-streams negotiation th= at > may be required. > > > > *Scope* > > The scope includes both systems that provide a fully immersive experience= , > and systems that interwork with them and therefore need to understand the > same multiple stream semantics. > > > > The focus of this work is on audio and video multiple streams, however > other media types may be considered. Definition of new application > protocols is not within the scope of this work > > > > [Is there anything else we need to explicitly say is out of scope?]** > > > > *The group will produce* > > - Requirements and use cases > > > > - Architectural Framework describing the protocols required to be > implemented to support this functionality and identifying existing protoc= ol > enhancements and new protocol functionality required > > > > - Specification of a new protocol to support telepresence multi-streams [= if > required] > > > > *Goals and Milestones* > > Nov 2010 > > Use Cases and Requirements to IESG as Informational RFC > > March 2011 > > Architecture to IESG as Informational RFC > > March 2011 > > Revise Charter [IF new protocol is not required] > > Nov 2011 > > Submit protocol draft to IESG as Proposed Standard RFC > > > > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --000e0cd378f6c688ef0486eacb25 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Allyn,=A0

I am interested in having this work start. = I suspect it will likely warrant a working group at the appropriate time. = =A0

The charter as written is VERY general. I woul= d suspect that SIP/SDP is going to be the common ground. Is it worth making= this explicit in the charter? If not perhaps the reasons why not could be = stated in the charter. (My understanding is that most of these systems do u= se SIP but that they differ in number of sessions per endpoint and how the = media is packaged into RTP streams etc.)

Is there other IETF work which we can see has relevance= and should be mentioned as tools which can be brought to bear? (xcon? medi= actrl?)

Is there interest in ensuring interop of T= P with legacy SIP video conferencing systems as part of this work? Should t= hat be part of the charter?

Regards,=A0

Peter Musgrave



On Tue,= May 18, 2010 at 8:30 PM, Allyn Romanow (allyn) <allyn@cisco.com> wrote:

Hi Folks,

=A0

Many of you are aware of telepresence systems (video conferencing on steroids..:), fewer probably are aware of the fact that the= current systems are not interoperable with each other. After talking with Mary and = Cullen, we have a rough draft of a charter to work on this problem in DISPATCH, =A0= for discussion on the mailing list.

=A0

We don=92t yet know whether a working group would ne= ed to be spun out or not =96 that will be clarified as we go.

=A0

We think there is enough background info in the work description to start a discussion, and plan to send out use cases for discussion shortly.

=A0

Who is the we? Several makers and providers of telep= resence systems have gotten together to define the main problem in interoperability= =96 the handling of multi-streams.

=A0

Thanks for your thoughts-

Allyn

=A0

=A0

Multi-streams for Telepresence Description of Work

=A0

=A0

=A0

Background

One branch of video conferencing has evolved that is focused on immersive =93being there=94 experience.=A0 Referred to in various ways such as virtual conferencing, telepresence or media spaces, early systems were mainly resea= rch projects or business systems with limited deployments.=A0 In recent years t= elepresence systems have seen considerable market success.=A0 Following the model of early systems, the first wave of commercial systems have been typically loc= ated in specially designed single-purpose rooms with multiple relatively large displays permitting life size image reproduction, multiple cameras, encoder= s, decoders and microphones.=A0 These systems have several important characteristics that are different from more traditional video conferencing systems.=A0

=A0

The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential group meeting characteristics such as eye contact, group gestures, seating order = and spatial audio by carefully orchestrating the miking and camera angles at ea= ch of the sites . This is distinct from the more traditional approach where th= e geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics.=A0

=A0

A second difference is manipulation of the environment to improve immersion.=A0 With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating an= d lighting so that when combined with large high quality displays, a strong s= ense of a "trompe l'oeil" or "being there" immersive exp= erience is created.=A0 Typical video conference systems do not include these considerations.

=A0

As telepresence video systems have become successful in the market, manufactur= ers have started exploring delivery of the nonverbal communication and immersiv= e values of telepresence via smaller, less expensive and more flexible video conferencing systems for a variety of venues, such as individual offices, h= omes and kiosks. These are also=A0 telepresence systems, since the audio and video quality is high enough to allow clear image reproduction for nonverba= l communication, they are able to send and receive multiple media streams, an= d large coordinated multi image displays are available for immersive installations.=A0=A0 As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly available.<= /p>

=A0

Problem

Although telepresence systems are based on open standards such as RTP, SIP, H.264, H= .323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one vend= or to another. It would be like having to make sure all parties are on the sam= e equipment (and network) when making a telephone call. =A0A major factor in the inability of Telepresence systems to work with each other is that there= is no standard description of the multiple streams that comprise the media flo= ws.

=A0

For example, in a multiple screen conference, the video and audio streams sent from remo= te participants must be understood by receivers so that they can be presented = in a coherent and life-like manner. This includes the ability to present the rem= ote participants at their true size for their apparent distance, while maintain= ing correct eye contact, gesticular cues, and simultaneously providing a spatia= l audio sound stage consistent with the video presentation.=A0 The receiving device that decides how to display the incoming information needs to unders= tand a number of variables such as the spatial position of the speaker, the fiel= d of view of the cameras, the camera zoom, which media stream is related to each= of the displays, etc.

=A0

Charter

The Telepresence Multi-Streams work item in DISPATCH is chartered to define and specify the content of media multi-stream messages and the way these will b= e transported.

This work is aimed at providing a standard for the exchange of media semantics information that will foster interoperable end stations and conference brid= ges. This work item will specify the variables that describe the semantics of the media streams and = the recommended behavior to achieve interoperability.=A0

=A0

This requires considering current widely deployed use cases, such as single and multiple screens, multi-point, Scalable Video Coding (SVC), as well as case= s that are expected to be implemented using the protocol framework produced b= y this work item.=A0 The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young technol= ogy and may have use cases that are not currently considered.

=A0

The work item will identify use cases, define requirements, and define a method= for describing and transporting information about multiple media streams, inclu= ding a specification of variables required to support the use cases. This work i= tem will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols required = to be implemented to support this functionality.=A0 The document will identify any enhancements required to existing protocols as well as describing new protocol(s) for interoperable multi-streams negotiation that may be require= d.

=A0

Scope<= /b>

The scope includes both systems that provide a fully immersive experience, and system= s that interwork with them and therefore need to understand the same multiple stream semantics.

=A0

The focus of this work is on audio and video multiple streams, however other me= dia types may be considered.=A0 Definition of new application protocols is not within the scope of this work

=A0

[Is there anything else we need to explicitly say is out of scope?]

=A0

The group will produce

- Requirements and use cases

=A0

- Architectural Framework describing the protocols required to be implemented= to support this functionality and identifying existing protocol enhancements a= nd new protocol functionality required

=A0

- Specification of a new protocol to support telepresence multi-streams [if required]

=A0

Goals and Milestones

Nov 2010

Use Cases and Requirements to IESG as Informational RFC

March 2011

Architecture to IESG as Informational RFC

March 2011

 Revise Charter [IF new protocol is not required]

Nov 2011

Submit protocol draft to IESG as Proposed Standard RFC

=A0

=A0

=A0

=A0


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


--000e0cd378f6c688ef0486eacb25-- From allyn@cisco.com Tue May 18 21:50:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1813A6B0C for ; Tue, 18 May 2010 21:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHfogz1klo0K for ; Tue, 18 May 2010 21:50:32 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9EBAA3A6964 for ; Tue, 18 May 2010 21:50:32 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAE8L80urR7H+/2dsb2JhbACBPpxKcaNsmWGCWYI3BIJ5Rw X-IronPort-AV: E=Sophos;i="4.53,260,1272844800"; d="scan'208,217";a="199312985" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 19 May 2010 04:50:25 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4J4oPkO005054; Wed, 19 May 2010 04:50:25 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 21:50:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAF70E.CB5C69C7" Date: Tue, 18 May 2010 21:50:23 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0160CE8B@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Multi-streams for telepresence description of work Thread-Index: Acr3CszqWD8M9WwFQzSh4EzuDt1cFQAANKnA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> From: "Allyn Romanow (allyn)" To: "Peter Musgrave" X-OriginalArrivalTime: 19 May 2010 04:50:25.0122 (UTC) FILETIME=[CB9E1C20:01CAF70E] Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 04:50:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF70E.CB5C69C7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, You've raised excellent points. See inline for a few brief comments, and I'll look to others to elaborate (or disagree). =20 best, Allyn ________________________________ From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 Sent: Tuesday, May 18, 2010 9:22 PM To: Allyn Romanow (allyn) Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work =09 =09 Hi Allyn, =20 I am interested in having this work start. I suspect it will likely warrant a working group at the appropriate time. =20 The charter as written is VERY general. I would suspect that SIP/SDP is going to be the common ground. Is it worth making this explicit in the charter? If not perhaps the reasons why not could be stated in the charter. (My understanding is that most of these systems do use SIP but that they differ in number of sessions per endpoint and how the media is packaged into RTP streams etc.) [alr] Certainly RTP is used without question, and there has been discussion about limiting to RTP streams only, not other types of data. This is still an open issue to be discussed. =20 Although I (and some others) initially assumed that we would use SDP for signaling, after further thought Steve Botsko and others suggested we might want to consider another protocol such as XMPP in light of the nature of the messages we want to send. I think that it's premature to specify this in the charter as I consider it part of the the solution, and think it will become clear what protocol to use as we specify requirements. Is there other IETF work which we can see has relevance and should be mentioned as tools which can be brought to bear? (xcon? mediactrl?) [alr] Good point. We definitely want to consider existing work, and look to the experts in DISPATCH to help with this. As above, I'm not sure if we can go there yet without requirements first- but centainly we can be begin to look at potential tools. Is there interest in ensuring interop of TP with legacy SIP video conferencing systems as part of this work? Should that be part of the charter? [alr] My personal view is not too much, that it's more a matter of going forward with a common technology that allows us to interoperate. I don't want us to be in the position of needing to tie together systems that we already have, as that would too much limit our approach. That said, people will want to incorporate the best of their current technology. What do folks think?=20 Regards,=20 Peter Musgrave On Tue, May 18, 2010 at 8:30 PM, Allyn Romanow (allyn) wrote: =09 Hi Folks, =20 Many of you are aware of telepresence systems (video conferencing on steroids..:), fewer probably are aware of the fact that the current systems are not interoperable with each other. After talking with Mary and Cullen, we have a rough draft of a charter to work on this problem in DISPATCH, for discussion on the mailing list. =20 We don't yet know whether a working group would need to be spun out or not - that will be clarified as we go. =20 We think there is enough background info in the work description to start a discussion, and plan to send out use cases for discussion shortly. =20 Who is the we? Several makers and providers of telepresence systems have gotten together to define the main problem in interoperability - the handling of multi-streams. =20 Thanks for your thoughts- Allyn =20 =20 Multi-streams for Telepresence Description of Work =20 =20 =20 Background One branch of video conferencing has evolved that is focused on immersive "being there" experience. Referred to in various ways such as virtual conferencing, telepresence or media spaces, early systems were mainly research projects or business systems with limited deployments. In recent years telepresence systems have seen considerable market success. Following the model of early systems, the first wave of commercial systems have been typically located in specially designed single-purpose rooms with multiple relatively large displays permitting life size image reproduction, multiple cameras, encoders, decoders and microphones. These systems have several important characteristics that are different from more traditional video conferencing systems. =20 =20 The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential group meeting characteristics such as eye contact, group gestures, seating order and spatial audio by carefully orchestrating the miking and camera angles at each of the sites . This is distinct from the more traditional approach where the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics. =20 =20 A second difference is manipulation of the environment to improve immersion. With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating and lighting so that when combined with large high quality displays, a strong sense of a "trompe l'oeil" or "being there" immersive experience is created. Typical video conference systems do not include these considerations. =20 As telepresence video systems have become successful in the market, manufacturers have started exploring delivery of the nonverbal communication and immersive values of telepresence via smaller, less expensive and more flexible video conferencing systems for a variety of venues, such as individual offices, homes and kiosks. These are also telepresence systems, since the audio and video quality is high enough to allow clear image reproduction for nonverbal communication, they are able to send and receive multiple media streams, and large coordinated multi image displays are available for immersive installations. As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly available. =20 Problem Although telepresence systems are based on open standards such as RTP, SIP, H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one vendor to another. It would be like having to make sure all parties are on the same equipment (and network) when making a telephone call. A major factor in the inability of Telepresence systems to work with each other is that there is no standard description of the multiple streams that comprise the media flows.=20 =20 For example, in a multiple screen conference, the video and audio streams sent from remote participants must be understood by receivers so that they can be presented in a coherent and life-like manner. This includes the ability to present the remote participants at their true size for their apparent distance, while maintaining correct eye contact, gesticular cues, and simultaneously providing a spatial audio sound stage consistent with the video presentation. The receiving device that decides how to display the incoming information needs to understand a number of variables such as the spatial position of the speaker, the field of view of the cameras, the camera zoom, which media stream is related to each of the displays, etc.=20 =20 Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to define and specify the content of media multi-stream messages and the way these will be transported.=20 This work is aimed at providing a standard for the exchange of media semantics information that will foster interoperable end stations and conference bridges. This work item will specify the variables that describe the semantics of the media streams and the recommended behavior to achieve interoperability. =20 =20 This requires considering current widely deployed use cases, such as single and multiple screens, multi-point, Scalable Video Coding (SVC), as well as cases that are expected to be implemented using the protocol framework produced by this work item. The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young technology and may have use cases that are not currently considered. =20 The work item will identify use cases, define requirements, and define a method for describing and transporting information about multiple media streams, including a specification of variables required to support the use cases. This work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols required to be implemented to support this functionality. The document will identify any enhancements required to existing protocols as well as describing new protocol(s) for interoperable multi-streams negotiation that may be required. =20 Scope The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. =20 The focus of this work is on audio and video multiple streams, however other media types may be considered. Definition of new application protocols is not within the scope of this work =20 [Is there anything else we need to explicitly say is out of scope?] =20 The group will produce - Requirements and use cases =20 - Architectural Framework describing the protocols required to be implemented to support this functionality and identifying existing protocol enhancements and new protocol functionality required =20 - Specification of a new protocol to support telepresence multi-streams [if required] =20 Goals and Milestones Nov 2010=20 Use Cases and Requirements to IESG as Informational RFC=20 March 2011=20 Architecture to IESG as Informational RFC=20 March 2011 Revise Charter [IF new protocol is not required] Nov 2011=20 Submit protocol draft to IESG as Proposed Standard RFC=20 =20 =20 =20 =20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =09 =09 ------_=_NextPart_001_01CAF70E.CB5C69C7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Peter,
You've raised excellent points. See = inline for a=20 few brief comments, and I'll look to others to elaborate (or=20 disagree).
 
best,
Allyn

From: Peter Musgrave=20 [mailto:peter.musgrave@magorcorp.com]
Sent: Tuesday, May = 18, 2010=20 9:22 PM
To: Allyn Romanow (allyn)
Cc: IETF = DISPATCH=20 list
Subject: Re: [dispatch] Multi-streams for telepresence=20 description of work

Hi Allyn, 

I am interested in having this work start. I suspect it will = likely=20 warrant a working group at the appropriate time.  

The charter as written is VERY general. I would suspect that = SIP/SDP is=20 going to be the common ground. Is it worth making this explicit in the = charter? If not perhaps the reasons why not could be stated in the = charter.=20 (My understanding is that most of these systems do use SIP but that = they=20 differ in number of sessions per endpoint and how the media is = packaged into=20 RTP streams etc.)
[alr] Certainly RTP is used without = question,=20 and there has been discussion about limiting to RTP streams only, = not=20 other types of data. This is still an open issue to be=20 discussed.
 
Although I (and some others) initially assumed that = we would use SDP for signaling, after further thought = Steve=20 Botsko and  others suggested we might want to consider=20 another protocol such as XMPP in light of the nature of the = messages we=20 want to send. I think that it's premature to specify this in the = charter=20 as I consider it part of the the solution, and think it will = become clear=20 what protocol to use as we specify requirements.

Is there other IETF work which we can see has relevance and = should be=20 mentioned as tools which can be brought to bear? (xcon? = mediactrl?)
[alr] Good=20 point. We definitely want to consider existing work, and look to = the=20 experts in DISPATCH to help with this. As above, I'm not sure if we = can go=20 there yet without requirements first- but centainly we can be begin to = look at=20 potential tools.

Is there interest in ensuring interop of TP with legacy SIP video = conferencing systems as part of this work? Should that be part of the=20 charter?
[alr] My personal view is not too much, that it's more a = matter of=20 going forward with a  common technology that allows us = to=20 interoperate. I don't want us to be in the position of needing to tie = together=20 systems that we already have, as that would too much limit our=20 approach. That said, people will want to incorporate the best of = their=20 current technology. What do folks = think? 

Regards, 

Peter Musgrave



On Tue, May 18, 2010 at 8:30 PM, Allyn = Romanow (allyn)=20 <allyn@cisco.com> = wrote:

Hi Folks,

 

Many of you are aware of telepresence systems = (video=20 conferencing on steroids..:), fewer probably are aware of the fact = that the=20 current systems are not interoperable with each other. After talking = with=20 Mary and Cullen, we have a rough draft of a charter to work on this = problem=20 in DISPATCH,  for discussion on the mailing list.

 

We don’t yet know whether a working group = would need to=20 be spun out or not – that will be clarified as we go.

 

We think there is enough background info in the = work=20 description to start a discussion, and plan to send out use cases = for=20 discussion shortly.

 

Who is the we? Several makers and providers of=20 telepresence systems have gotten together to define the main problem = in=20 interoperability – the handling of multi-streams.

 

Thanks for your thoughts-

Allyn

 

 

Multi-streams for Telepresence Description = of=20 Work

 

 

 

Background

One branch of video conferencing has = evolved that=20 is focused on immersive “being there” experience.  = Referred to in=20 various ways such as virtual conferencing, telepresence or media = spaces,=20 early systems were mainly research projects or business systems with = limited=20 deployments.  In recent years telepresence systems have seen=20 considerable market success.  Following the model of early = systems, the=20 first wave of commercial systems have been typically located in = specially=20 designed single-purpose rooms with multiple relatively large = displays=20 permitting life size image reproduction, multiple cameras, encoders, = decoders and microphones.  These systems have several important = characteristics that are different from more traditional video = conferencing=20 systems. 

 

The first difference concerns controlling = the=20 visual viewpoint in order to improve participant nonverbal = communication.=20 These systems preserve essential group meeting characteristics such = as eye=20 contact, group gestures, seating order and spatial audio by = carefully=20 orchestrating the miking and camera angles at each of the sites . = This is=20 distinct from the more traditional approach where the geometric = relationship=20 between media streams is not used to preserve inter-stream = communication=20 aspects such as eye contact and group dynamics. 

 

A second difference is manipulation of = the=20 environment to improve immersion.  With telepresence systems,=20 cinematographic aspects of the local environment reproduction are = carefully=20 planned including color, table shape, seating and lighting so that = when=20 combined with large high quality displays, a strong sense of a = "trompe=20 l'oeil" or "being there" immersive experience is created.  = Typical=20 video conference systems do not include these = considerations.

 

As telepresence video systems have become = successful in the market, manufacturers have started exploring = delivery of=20 the nonverbal communication and immersive values of telepresence via = smaller, less expensive and more flexible video conferencing systems = for a=20 variety of venues, such as individual offices, homes and kiosks. = These are=20 also  telepresence systems, since the audio and video quality = is high=20 enough to allow clear image reproduction for nonverbal = communication, they=20 are able to send and receive multiple media streams, and large = coordinated=20 multi image displays are available for immersive = installations.  =20 As the industry develops, the line between telepresence and video=20 conferencing may become blurred as nonverbal communication and = immersive=20 installations become broadly available.

 

Problem

Although telepresence systems are based = on open=20 standards such as RTP, SIP, H.264, H.323 suite, they cannot easily=20 interoperate with each other without operator assistance and = expensive=20 additional equipment that translates from one vendor to another. It = would be=20 like having to make sure all parties are on the same equipment (and = network)=20 when making a telephone call.  A major factor in the inability = of=20 Telepresence systems to work with each other is that there is no = standard=20 description of the multiple streams that comprise the media flows.=20

 

For example, in a multiple screen = conference, the=20 video and audio streams sent from remote participants must be = understood by=20 receivers so that they can be presented in a coherent and life-like = manner.=20 This includes the ability to present the remote participants at = their true=20 size for their apparent distance, while maintaining correct eye = contact,=20 gesticular cues, and simultaneously providing a spatial audio sound = stage=20 consistent with the video presentation.  The receiving device = that=20 decides how to display the incoming information needs to understand = a number=20 of variables such as the spatial position of the speaker, the field = of view=20 of the cameras, the camera zoom, which media stream is related to = each of=20 the displays, etc.

 

Charter

The Telepresence Multi-Streams work item = in=20 DISPATCH is chartered to define and specify the content of media=20 multi-stream messages and the way these will be transported. =

This work is aimed at providing a = standard for the=20 exchange of media semantics information that will foster = interoperable end=20 stations and conference bridges. This work item will = specify=20 the variables that describe the semantics of the media streams and = the=20 recommended behavior to achieve interoperability. 

 

This requires considering current widely = deployed=20 use cases, such as single and multiple screens, multi-point, = Scalable Video=20 Coding (SVC), as well as cases that are expected to be implemented = using the=20 protocol framework produced by this work item.  The methodology = for=20 describing the variables must allow extensibility of the variables, = since=20 telepresence is still a young technology and may have use cases that = are not=20 currently considered.

 

The work item will identify use cases, = define=20 requirements, and define a method for describing and transporting=20 information about multiple media streams, including a specification = of=20 variables required to support the use cases. This work item will = consider=20 the reuse of existing IETF protocols and produce an = architecture/protocol=20 framework document describing the protocols required to be = implemented to=20 support this functionality.  The document will identify any=20 enhancements required to existing protocols as well as describing = new=20 protocol(s) for interoperable multi-streams negotiation that may be=20 required.

 

Scope

The scope includes both systems that = provide a=20 fully immersive experience, and systems that interwork with them and = therefore need to understand the same multiple stream=20 semantics.

 

The focus of this work is on audio and = video=20 multiple streams, however other media types may be considered.  = Definition of new application protocols is not within the scope of = this=20 work

 

[Is there anything else we need to = explicitly say=20 is out of scope?]

 

The group will produce

- Requirements and use cases

 

- Architectural Framework describing the = protocols=20 required to be implemented to support this functionality and = identifying=20 existing protocol enhancements and new protocol functionality=20 required

 

- Specification of a new protocol to = support=20 telepresence multi-streams [if required]

 

Goals and Milestones

Nov 2010

Use Cases and Requirements to IESG = as=20 Informational RFC

March 2011

Architecture to IESG as = Informational RFC=20

March 2011

Revise Charter [IF new protocol is = not=20 required]

Nov 2011

Submit protocol draft to IESG as = Proposed=20 Standard RFC

 

 

 

 


_____________________________= __________________
dispatch=20 mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

------_=_NextPart_001_01CAF70E.CB5C69C7-- From gao.yang2@zte.com.cn Tue May 18 22:36:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9EC3A67E2 for ; Tue, 18 May 2010 22:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.694 X-Spam-Level: X-Spam-Status: No, score=-95.694 tagged_above=-999 required=5 tests=[AWL=-1.259, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaQZ5fDwHMD6 for ; Tue, 18 May 2010 22:36:41 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id C2CEE3A6964 for ; Tue, 18 May 2010 22:36:39 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 58071992332426; Wed, 19 May 2010 13:31:06 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 17030.1142583116; Wed, 19 May 2010 13:31:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4J5aQDe077123; Wed, 19 May 2010 13:36:27 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> To: "Allyn Romanow (allyn)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 19 May 2010 13:33:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-19 13:36:21, Serialize complete at 2010-05-19 13:36:21 Content-Type: multipart/alternative; boundary="=_alternative 001EC0EB48257728_=" X-MAIL: mse2.zte.com.cn o4J5aQDe077123 Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 05:36:43 -0000 This is a multipart message in MIME format. --=_alternative 001EC0EB48257728_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSB0d28gbGV2ZWwgb2YgY29tbWVudHMsDQoNCjEuIEZlZWxpbmcgZm9yIHRo ZSB0b3BpYw0KVGVjaG5pY2FsbHksIEkgYW0gcXVpdCBnbGFkIHRvIHNlZSBzdWNoIGRpc2N1c3Np b24gYWJvdXQgdGVsZXByZXNlbmNlLCANCndoaWNoIGlzIHRyYWlsYmxhemVyIGZvciBWUihWaXJ0 dWFsIFJlYWxpdHkpIHByb2R1Y3Rpb24uIA0KDQoyLiBBYm91dCB0aGUgY2hhcnRlciBXRw0KT25l IHJldm9sdXRpb25hcnkgYXBwbGljYXRpb24sIHN1Y2ggdGVsZXByZXNlbmNlLCB3b3VsZCBjb3Zl ciBiYXNpYyANCnByb3RvY29sIGxldmVsLCBhcHBsaWNhdGlvbiBjb250cm9sIGxldmVsLCBhbmQg aW50ZXJ3b3JraW5nIGlzc3VlLiANCg0KSWYgdGhlIHdvcmsgaXMganVzdCBmb2N1c2VkIG9uIHB1 cmUgaW50ZXJ3b3JraW5nIGlzc3VlLCB0aGVuIHRoZSB0b3BpY3MgDQpjYW4gYmUgZGl2aWRlZCBp bnRvIHNtYWxsZXIgb25lLCB3aGljaCBtaWdodCBiZSBpbiBvdGhlciBiYXNpYyBwcm90b2NvbHMn IA0KV0cncyBzY29wZS4gQnV0IGlmIHRoZSBhcHBsaWNhdGlvbiBpdHNlbGYgaXMgbmV3LCBhbmQg aGFzIHNvbWUgbmV3IA0KY2hhcmFjdGVyaXN0aWMsIG1vcmUgd29yayBzaG91bGQgYmUgcHJvcG9z ZWQuIA0KDQpJZiB0aGUgd29yayBpcyBhbHNvIGZvY3VzZWQgb24gdGVsZXByZXNlbmNlIGFwcGxp Y2F0aW9uLCB3aGljaCBpcyBhIA0KY29uZmVyZW5jaW5nIHN5c3RlbSwgdGhlIHhjb24gV0cgbWln aHQgYmUgcHJvcGVyIG9uZSBmb3IgYXBwbGljYXRpb24gbGV2ZWwgDQpkZWZpbml0aW9uLg0KDQpJ ZiB0aGUgY2hhcnRlciBhbHNvIHdhbnQgdG8gdGFsayB0aGUgZXNlbnRpYWwgYXNwZWN0IG9mIHRl bGVwcmVzZW5jZShvciANCm1vcmUgYWJzdHJhY3RseSwgYWJvdXQgVlIpLCBzdWNoIGFzIGhvdyB0 byB1c2luZyBTRFAsIG9yIHJlbGF0aXZlIHByb3RvY29sIA0KdG8gZGVzY3JpYmUgdGhlIHN0cmVh bXMgYW5kIGl0J3MgY29sbGFib3JhdGlvbiwgaXQgd291bGQgYmUgcXVpdGUgbmV3IA0KdG9waWMu IE9uZSBuZXcgV0cgbWlnaHQgYmUgYmV0dGVyLg0KDQoNCkkgZmluZCB0aGUgY2hhcnRlciBzZWVt cyBjb3ZlcnMgYWxsIHRoZSB0aHJlZSB0aGluZy4gU28sIEkgc3VnZ2VzdCB5b3UgDQpjbGFzc2lm eSBzdWNoIGRpZmZlcmVudCBsZXZlbCByZXF1aXJlbWVudC4gVGhlbiwgd2UgbWF5IGZpbmQgd2hp Y2ggcGFydCBpcyANCnByb3BlciBmb3Igd2hpY2ggV0csIGFuZCB3aGljaCBwYXJ0IHNob3VsZCBi ZSBjb3ZlcmVkIGJ5IG5ldyBXRy4NCg0KVGhhbmtzLA0KDQpHYW8NCg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0K IFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20u Y24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQoiQWxseW4gUm9t YW5vdyAoYWxseW4pIiA8YWxseW5AY2lzY28uY29tPiANCreivP7IyzogIGRpc3BhdGNoLWJvdW5j ZXNAaWV0Zi5vcmcNCjIwMTAtMDUtMTkgMDI6MzANCg0KytW8/sjLDQoiSUVURiBESVNQQVRDSCBs aXN0IiA8ZGlzcGF0Y2hAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINCltkaXNwYXRjaF0gTXVsdGkt c3RyZWFtcyBmb3IgdGVsZXByZXNlbmNlIGRlc2NyaXB0aW9uIG9mIHdvcmsNCg0KDQoNCg0KDQoN CkhpIEZvbGtzLA0KIA0KTWFueSBvZiB5b3UgYXJlIGF3YXJlIG9mIHRlbGVwcmVzZW5jZSBzeXN0 ZW1zICh2aWRlbyBjb25mZXJlbmNpbmcgb24gDQpzdGVyb2lkcy4uOiksIGZld2VyIHByb2JhYmx5 IGFyZSBhd2FyZSBvZiB0aGUgZmFjdCB0aGF0IHRoZSBjdXJyZW50IA0Kc3lzdGVtcyBhcmUgbm90 IGludGVyb3BlcmFibGUgd2l0aCBlYWNoIG90aGVyLiBBZnRlciB0YWxraW5nIHdpdGggTWFyeSBh bmQgDQpDdWxsZW4sIHdlIGhhdmUgYSByb3VnaCBkcmFmdCBvZiBhIGNoYXJ0ZXIgdG8gd29yayBv biB0aGlzIHByb2JsZW0gaW4gDQpESVNQQVRDSCwgIGZvciBkaXNjdXNzaW9uIG9uIHRoZSBtYWls aW5nIGxpc3QuDQogDQpXZSBkb26hr3QgeWV0IGtub3cgd2hldGhlciBhIHdvcmtpbmcgZ3JvdXAg d291bGQgbmVlZCB0byBiZSBzcHVuIG91dCBvciANCm5vdCCoQyB0aGF0IHdpbGwgYmUgY2xhcmlm aWVkIGFzIHdlIGdvLg0KIA0KV2UgdGhpbmsgdGhlcmUgaXMgZW5vdWdoIGJhY2tncm91bmQgaW5m byBpbiB0aGUgd29yayBkZXNjcmlwdGlvbiB0byBzdGFydCANCmEgZGlzY3Vzc2lvbiwgYW5kIHBs YW4gdG8gc2VuZCBvdXQgdXNlIGNhc2VzIGZvciBkaXNjdXNzaW9uIHNob3J0bHkuDQogDQpXaG8g aXMgdGhlIHdlPyBTZXZlcmFsIG1ha2VycyBhbmQgcHJvdmlkZXJzIG9mIHRlbGVwcmVzZW5jZSBz eXN0ZW1zIGhhdmUgDQpnb3R0ZW4gdG9nZXRoZXIgdG8gZGVmaW5lIHRoZSBtYWluIHByb2JsZW0g aW4gaW50ZXJvcGVyYWJpbGl0eSCoQyB0aGUgDQpoYW5kbGluZyBvZiBtdWx0aS1zdHJlYW1zLg0K IA0KVGhhbmtzIGZvciB5b3VyIHRob3VnaHRzLQ0KQWxseW4NCiANCiANCk11bHRpLXN0cmVhbXMg Zm9yIFRlbGVwcmVzZW5jZSBEZXNjcmlwdGlvbiBvZiBXb3JrDQogDQogDQogDQpCYWNrZ3JvdW5k DQpPbmUgYnJhbmNoIG9mIHZpZGVvIGNvbmZlcmVuY2luZyBoYXMgZXZvbHZlZCB0aGF0IGlzIGZv Y3VzZWQgb24gaW1tZXJzaXZlIA0KobBiZWluZyB0aGVyZaGxIGV4cGVyaWVuY2UuICBSZWZlcnJl ZCB0byBpbiB2YXJpb3VzIHdheXMgc3VjaCBhcyB2aXJ0dWFsIA0KY29uZmVyZW5jaW5nLCB0ZWxl cHJlc2VuY2Ugb3IgbWVkaWEgc3BhY2VzLCBlYXJseSBzeXN0ZW1zIHdlcmUgbWFpbmx5IA0KcmVz ZWFyY2ggcHJvamVjdHMgb3IgYnVzaW5lc3Mgc3lzdGVtcyB3aXRoIGxpbWl0ZWQgZGVwbG95bWVu dHMuICBJbiByZWNlbnQgDQp5ZWFycyB0ZWxlcHJlc2VuY2Ugc3lzdGVtcyBoYXZlIHNlZW4gY29u c2lkZXJhYmxlIG1hcmtldCBzdWNjZXNzLiANCkZvbGxvd2luZyB0aGUgbW9kZWwgb2YgZWFybHkg c3lzdGVtcywgdGhlIGZpcnN0IHdhdmUgb2YgY29tbWVyY2lhbCBzeXN0ZW1zIA0KaGF2ZSBiZWVu IHR5cGljYWxseSBsb2NhdGVkIGluIHNwZWNpYWxseSBkZXNpZ25lZCBzaW5nbGUtcHVycG9zZSBy b29tcyANCndpdGggbXVsdGlwbGUgcmVsYXRpdmVseSBsYXJnZSBkaXNwbGF5cyBwZXJtaXR0aW5n IGxpZmUgc2l6ZSBpbWFnZSANCnJlcHJvZHVjdGlvbiwgbXVsdGlwbGUgY2FtZXJhcywgZW5jb2Rl cnMsIGRlY29kZXJzIGFuZCBtaWNyb3Bob25lcy4gIFRoZXNlIA0Kc3lzdGVtcyBoYXZlIHNldmVy YWwgaW1wb3J0YW50IGNoYXJhY3RlcmlzdGljcyB0aGF0IGFyZSBkaWZmZXJlbnQgZnJvbSANCm1v cmUgdHJhZGl0aW9uYWwgdmlkZW8gY29uZmVyZW5jaW5nIHN5c3RlbXMuIA0KIA0KVGhlIGZpcnN0 IGRpZmZlcmVuY2UgY29uY2VybnMgY29udHJvbGxpbmcgdGhlIHZpc3VhbCB2aWV3cG9pbnQgaW4g b3JkZXIgdG8gDQppbXByb3ZlIHBhcnRpY2lwYW50IG5vbnZlcmJhbCBjb21tdW5pY2F0aW9uLiBU aGVzZSBzeXN0ZW1zIHByZXNlcnZlIA0KZXNzZW50aWFsIGdyb3VwIG1lZXRpbmcgY2hhcmFjdGVy aXN0aWNzIHN1Y2ggYXMgZXllIGNvbnRhY3QsIGdyb3VwIA0KZ2VzdHVyZXMsIHNlYXRpbmcgb3Jk ZXIgYW5kIHNwYXRpYWwgYXVkaW8gYnkgY2FyZWZ1bGx5IG9yY2hlc3RyYXRpbmcgdGhlIA0KbWlr aW5nIGFuZCBjYW1lcmEgYW5nbGVzIGF0IGVhY2ggb2YgdGhlIHNpdGVzIC4gVGhpcyBpcyBkaXN0 aW5jdCBmcm9tIHRoZSANCm1vcmUgdHJhZGl0aW9uYWwgYXBwcm9hY2ggd2hlcmUgdGhlIGdlb21l dHJpYyByZWxhdGlvbnNoaXAgYmV0d2VlbiBtZWRpYSANCnN0cmVhbXMgaXMgbm90IHVzZWQgdG8g cHJlc2VydmUgaW50ZXItc3RyZWFtIGNvbW11bmljYXRpb24gYXNwZWN0cyBzdWNoIGFzIA0KZXll IGNvbnRhY3QgYW5kIGdyb3VwIGR5bmFtaWNzLiANCiANCkEgc2Vjb25kIGRpZmZlcmVuY2UgaXMg bWFuaXB1bGF0aW9uIG9mIHRoZSBlbnZpcm9ubWVudCB0byBpbXByb3ZlIA0KaW1tZXJzaW9uLiAg V2l0aCB0ZWxlcHJlc2VuY2Ugc3lzdGVtcywgY2luZW1hdG9ncmFwaGljIGFzcGVjdHMgb2YgdGhl IA0KbG9jYWwgZW52aXJvbm1lbnQgcmVwcm9kdWN0aW9uIGFyZSBjYXJlZnVsbHkgcGxhbm5lZCBp bmNsdWRpbmcgY29sb3IsIA0KdGFibGUgc2hhcGUsIHNlYXRpbmcgYW5kIGxpZ2h0aW5nIHNvIHRo YXQgd2hlbiBjb21iaW5lZCB3aXRoIGxhcmdlIGhpZ2ggDQpxdWFsaXR5IGRpc3BsYXlzLCBhIHN0 cm9uZyBzZW5zZSBvZiBhICJ0cm9tcGUgbCdvZWlsIiBvciAiYmVpbmcgdGhlcmUiIA0KaW1tZXJz aXZlIGV4cGVyaWVuY2UgaXMgY3JlYXRlZC4gIFR5cGljYWwgdmlkZW8gY29uZmVyZW5jZSBzeXN0 ZW1zIGRvIG5vdCANCmluY2x1ZGUgdGhlc2UgY29uc2lkZXJhdGlvbnMuDQogDQpBcyB0ZWxlcHJl c2VuY2UgdmlkZW8gc3lzdGVtcyBoYXZlIGJlY29tZSBzdWNjZXNzZnVsIGluIHRoZSBtYXJrZXQs IA0KbWFudWZhY3R1cmVycyBoYXZlIHN0YXJ0ZWQgZXhwbG9yaW5nIGRlbGl2ZXJ5IG9mIHRoZSBu b252ZXJiYWwgDQpjb21tdW5pY2F0aW9uIGFuZCBpbW1lcnNpdmUgdmFsdWVzIG9mIHRlbGVwcmVz ZW5jZSB2aWEgc21hbGxlciwgbGVzcyANCmV4cGVuc2l2ZSBhbmQgbW9yZSBmbGV4aWJsZSB2aWRl byBjb25mZXJlbmNpbmcgc3lzdGVtcyBmb3IgYSB2YXJpZXR5IG9mIA0KdmVudWVzLCBzdWNoIGFz IGluZGl2aWR1YWwgb2ZmaWNlcywgaG9tZXMgYW5kIGtpb3Nrcy4gVGhlc2UgYXJlIGFsc28gDQp0 ZWxlcHJlc2VuY2Ugc3lzdGVtcywgc2luY2UgdGhlIGF1ZGlvIGFuZCB2aWRlbyBxdWFsaXR5IGlz IGhpZ2ggZW5vdWdoIHRvIA0KYWxsb3cgY2xlYXIgaW1hZ2UgcmVwcm9kdWN0aW9uIGZvciBub252 ZXJiYWwgY29tbXVuaWNhdGlvbiwgdGhleSBhcmUgYWJsZSANCnRvIHNlbmQgYW5kIHJlY2VpdmUg bXVsdGlwbGUgbWVkaWEgc3RyZWFtcywgYW5kIGxhcmdlIGNvb3JkaW5hdGVkIG11bHRpIA0KaW1h Z2UgZGlzcGxheXMgYXJlIGF2YWlsYWJsZSBmb3IgaW1tZXJzaXZlIGluc3RhbGxhdGlvbnMuICAg QXMgdGhlIA0KaW5kdXN0cnkgZGV2ZWxvcHMsIHRoZSBsaW5lIGJldHdlZW4gdGVsZXByZXNlbmNl IGFuZCB2aWRlbyBjb25mZXJlbmNpbmcgDQptYXkgYmVjb21lIGJsdXJyZWQgYXMgbm9udmVyYmFs IGNvbW11bmljYXRpb24gYW5kIGltbWVyc2l2ZSBpbnN0YWxsYXRpb25zIA0KYmVjb21lIGJyb2Fk bHkgYXZhaWxhYmxlLg0KIA0KUHJvYmxlbQ0KQWx0aG91Z2ggdGVsZXByZXNlbmNlIHN5c3RlbXMg YXJlIGJhc2VkIG9uIG9wZW4gc3RhbmRhcmRzIHN1Y2ggYXMgUlRQLCANClNJUCwgSC4yNjQsIEgu MzIzIHN1aXRlLCB0aGV5IGNhbm5vdCBlYXNpbHkgaW50ZXJvcGVyYXRlIHdpdGggZWFjaCBvdGhl ciANCndpdGhvdXQgb3BlcmF0b3IgYXNzaXN0YW5jZSBhbmQgZXhwZW5zaXZlIGFkZGl0aW9uYWwg ZXF1aXBtZW50IHRoYXQgDQp0cmFuc2xhdGVzIGZyb20gb25lIHZlbmRvciB0byBhbm90aGVyLiBJ dCB3b3VsZCBiZSBsaWtlIGhhdmluZyB0byBtYWtlIA0Kc3VyZSBhbGwgcGFydGllcyBhcmUgb24g dGhlIHNhbWUgZXF1aXBtZW50IChhbmQgbmV0d29yaykgd2hlbiBtYWtpbmcgYSANCnRlbGVwaG9u ZSBjYWxsLiAgQSBtYWpvciBmYWN0b3IgaW4gdGhlIGluYWJpbGl0eSBvZiBUZWxlcHJlc2VuY2Ug c3lzdGVtcyANCnRvIHdvcmsgd2l0aCBlYWNoIG90aGVyIGlzIHRoYXQgdGhlcmUgaXMgbm8gc3Rh bmRhcmQgZGVzY3JpcHRpb24gb2YgdGhlIA0KbXVsdGlwbGUgc3RyZWFtcyB0aGF0IGNvbXByaXNl IHRoZSBtZWRpYSBmbG93cy4gDQogDQpGb3IgZXhhbXBsZSwgaW4gYSBtdWx0aXBsZSBzY3JlZW4g Y29uZmVyZW5jZSwgdGhlIHZpZGVvIGFuZCBhdWRpbyBzdHJlYW1zIA0Kc2VudCBmcm9tIHJlbW90 ZSBwYXJ0aWNpcGFudHMgbXVzdCBiZSB1bmRlcnN0b29kIGJ5IHJlY2VpdmVycyBzbyB0aGF0IHRo ZXkgDQpjYW4gYmUgcHJlc2VudGVkIGluIGEgY29oZXJlbnQgYW5kIGxpZmUtbGlrZSBtYW5uZXIu IFRoaXMgaW5jbHVkZXMgdGhlIA0KYWJpbGl0eSB0byBwcmVzZW50IHRoZSByZW1vdGUgcGFydGlj aXBhbnRzIGF0IHRoZWlyIHRydWUgc2l6ZSBmb3IgdGhlaXIgDQphcHBhcmVudCBkaXN0YW5jZSwg d2hpbGUgbWFpbnRhaW5pbmcgY29ycmVjdCBleWUgY29udGFjdCwgZ2VzdGljdWxhciBjdWVzLCAN CmFuZCBzaW11bHRhbmVvdXNseSBwcm92aWRpbmcgYSBzcGF0aWFsIGF1ZGlvIHNvdW5kIHN0YWdl IGNvbnNpc3RlbnQgd2l0aCANCnRoZSB2aWRlbyBwcmVzZW50YXRpb24uICBUaGUgcmVjZWl2aW5n IGRldmljZSB0aGF0IGRlY2lkZXMgaG93IHRvIGRpc3BsYXkgDQp0aGUgaW5jb21pbmcgaW5mb3Jt YXRpb24gbmVlZHMgdG8gdW5kZXJzdGFuZCBhIG51bWJlciBvZiB2YXJpYWJsZXMgc3VjaCBhcyAN CnRoZSBzcGF0aWFsIHBvc2l0aW9uIG9mIHRoZSBzcGVha2VyLCB0aGUgZmllbGQgb2YgdmlldyBv ZiB0aGUgY2FtZXJhcywgdGhlIA0KY2FtZXJhIHpvb20sIHdoaWNoIG1lZGlhIHN0cmVhbSBpcyBy ZWxhdGVkIHRvIGVhY2ggb2YgdGhlIGRpc3BsYXlzLCBldGMuIA0KIA0KQ2hhcnRlcg0KVGhlIFRl bGVwcmVzZW5jZSBNdWx0aS1TdHJlYW1zIHdvcmsgaXRlbSBpbiBESVNQQVRDSCBpcyBjaGFydGVy ZWQgdG8gDQpkZWZpbmUgYW5kIHNwZWNpZnkgdGhlIGNvbnRlbnQgb2YgbWVkaWEgbXVsdGktc3Ry ZWFtIG1lc3NhZ2VzIGFuZCB0aGUgd2F5IA0KdGhlc2Ugd2lsbCBiZSB0cmFuc3BvcnRlZC4gDQpU aGlzIHdvcmsgaXMgYWltZWQgYXQgcHJvdmlkaW5nIGEgc3RhbmRhcmQgZm9yIHRoZSBleGNoYW5n ZSBvZiBtZWRpYSANCnNlbWFudGljcyBpbmZvcm1hdGlvbiB0aGF0IHdpbGwgZm9zdGVyIGludGVy b3BlcmFibGUgZW5kIHN0YXRpb25zIGFuZCANCmNvbmZlcmVuY2UgYnJpZGdlcy4gVGhpcyB3b3Jr IGl0ZW0gd2lsbCBzcGVjaWZ5IHRoZSB2YXJpYWJsZXMgdGhhdCANCmRlc2NyaWJlIHRoZSBzZW1h bnRpY3Mgb2YgdGhlIG1lZGlhIHN0cmVhbXMgYW5kIHRoZSByZWNvbW1lbmRlZCBiZWhhdmlvciAN CnRvIGFjaGlldmUgaW50ZXJvcGVyYWJpbGl0eS4gDQogDQpUaGlzIHJlcXVpcmVzIGNvbnNpZGVy aW5nIGN1cnJlbnQgd2lkZWx5IGRlcGxveWVkIHVzZSBjYXNlcywgc3VjaCBhcyANCnNpbmdsZSBh bmQgbXVsdGlwbGUgc2NyZWVucywgbXVsdGktcG9pbnQsIFNjYWxhYmxlIFZpZGVvIENvZGluZyAo U1ZDKSwgYXMgDQp3ZWxsIGFzIGNhc2VzIHRoYXQgYXJlIGV4cGVjdGVkIHRvIGJlIGltcGxlbWVu dGVkIHVzaW5nIHRoZSBwcm90b2NvbCANCmZyYW1ld29yayBwcm9kdWNlZCBieSB0aGlzIHdvcmsg aXRlbS4gIFRoZSBtZXRob2RvbG9neSBmb3IgZGVzY3JpYmluZyB0aGUgDQp2YXJpYWJsZXMgbXVz dCBhbGxvdyBleHRlbnNpYmlsaXR5IG9mIHRoZSB2YXJpYWJsZXMsIHNpbmNlIHRlbGVwcmVzZW5j ZSBpcyANCnN0aWxsIGEgeW91bmcgdGVjaG5vbG9neSBhbmQgbWF5IGhhdmUgdXNlIGNhc2VzIHRo YXQgYXJlIG5vdCBjdXJyZW50bHkgDQpjb25zaWRlcmVkLg0KIA0KVGhlIHdvcmsgaXRlbSB3aWxs IGlkZW50aWZ5IHVzZSBjYXNlcywgZGVmaW5lIHJlcXVpcmVtZW50cywgYW5kIGRlZmluZSBhIA0K bWV0aG9kIGZvciBkZXNjcmliaW5nIGFuZCB0cmFuc3BvcnRpbmcgaW5mb3JtYXRpb24gYWJvdXQg bXVsdGlwbGUgbWVkaWEgDQpzdHJlYW1zLCBpbmNsdWRpbmcgYSBzcGVjaWZpY2F0aW9uIG9mIHZh cmlhYmxlcyByZXF1aXJlZCB0byBzdXBwb3J0IHRoZSANCnVzZSBjYXNlcy4gVGhpcyB3b3JrIGl0 ZW0gd2lsbCBjb25zaWRlciB0aGUgcmV1c2Ugb2YgZXhpc3RpbmcgSUVURiANCnByb3RvY29scyBh bmQgcHJvZHVjZSBhbiBhcmNoaXRlY3R1cmUvcHJvdG9jb2wgZnJhbWV3b3JrIGRvY3VtZW50IA0K ZGVzY3JpYmluZyB0aGUgcHJvdG9jb2xzIHJlcXVpcmVkIHRvIGJlIGltcGxlbWVudGVkIHRvIHN1 cHBvcnQgdGhpcyANCmZ1bmN0aW9uYWxpdHkuICBUaGUgZG9jdW1lbnQgd2lsbCBpZGVudGlmeSBh bnkgZW5oYW5jZW1lbnRzIHJlcXVpcmVkIHRvIA0KZXhpc3RpbmcgcHJvdG9jb2xzIGFzIHdlbGwg YXMgZGVzY3JpYmluZyBuZXcgcHJvdG9jb2wocykgZm9yIGludGVyb3BlcmFibGUgDQptdWx0aS1z dHJlYW1zIG5lZ290aWF0aW9uIHRoYXQgbWF5IGJlIHJlcXVpcmVkLg0KIA0KU2NvcGUNClRoZSBz Y29wZSBpbmNsdWRlcyBib3RoIHN5c3RlbXMgdGhhdCBwcm92aWRlIGEgZnVsbHkgaW1tZXJzaXZl IGV4cGVyaWVuY2UsIA0KYW5kIHN5c3RlbXMgdGhhdCBpbnRlcndvcmsgd2l0aCB0aGVtIGFuZCB0 aGVyZWZvcmUgbmVlZCB0byB1bmRlcnN0YW5kIHRoZSANCnNhbWUgbXVsdGlwbGUgc3RyZWFtIHNl bWFudGljcy4NCiANClRoZSBmb2N1cyBvZiB0aGlzIHdvcmsgaXMgb24gYXVkaW8gYW5kIHZpZGVv IG11bHRpcGxlIHN0cmVhbXMsIGhvd2V2ZXIgDQpvdGhlciBtZWRpYSB0eXBlcyBtYXkgYmUgY29u c2lkZXJlZC4gIERlZmluaXRpb24gb2YgbmV3IGFwcGxpY2F0aW9uIA0KcHJvdG9jb2xzIGlzIG5v dCB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoaXMgd29yaw0KIA0KW0lzIHRoZXJlIGFueXRoaW5nIGVs c2Ugd2UgbmVlZCB0byBleHBsaWNpdGx5IHNheSBpcyBvdXQgb2Ygc2NvcGU/XQ0KIA0KVGhlIGdy b3VwIHdpbGwgcHJvZHVjZQ0KLSBSZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlcw0KIA0KLSBBcmNo aXRlY3R1cmFsIEZyYW1ld29yayBkZXNjcmliaW5nIHRoZSBwcm90b2NvbHMgcmVxdWlyZWQgdG8g YmUgDQppbXBsZW1lbnRlZCB0byBzdXBwb3J0IHRoaXMgZnVuY3Rpb25hbGl0eSBhbmQgaWRlbnRp ZnlpbmcgZXhpc3RpbmcgDQpwcm90b2NvbCBlbmhhbmNlbWVudHMgYW5kIG5ldyBwcm90b2NvbCBm dW5jdGlvbmFsaXR5IHJlcXVpcmVkDQogDQotIFNwZWNpZmljYXRpb24gb2YgYSBuZXcgcHJvdG9j b2wgdG8gc3VwcG9ydCB0ZWxlcHJlc2VuY2UgbXVsdGktc3RyZWFtcyANCltpZiByZXF1aXJlZF0N CiANCkdvYWxzIGFuZCBNaWxlc3RvbmVzDQoNCk5vdiAyMDEwIA0KVXNlIENhc2VzIGFuZCBSZXF1 aXJlbWVudHMgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsIFJGQyANCk1hcmNoIDIwMTEgDQpBcmNo aXRlY3R1cmUgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsIFJGQyANCk1hcmNoIDIwMTENClJldmlz ZSBDaGFydGVyIFtJRiBuZXcgcHJvdG9jb2wgaXMgbm90IHJlcXVpcmVkXQ0KTm92IDIwMTEgDQpT dWJtaXQgcHJvdG9jb2wgZHJhZnQgdG8gSUVTRyBhcyBQcm9wb3NlZCBTdGFuZGFyZCBSRkMgDQog DQogDQogDQogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1h aWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0 byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4N ClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRl bnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUg bWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZv ciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 001EC0EB48257728_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBoYXZlIHR3byBsZXZlbCBvZiBjb21t ZW50cyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEu IEZlZWxpbmcgZm9yIHRoZSB0b3BpYzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+VGVjaG5pY2FsbHksIEkgYW0gcXVpdCBnbGFkIHRvIHNlZSBzdWNoDQpkaXNjdXNz aW9uIGFib3V0IHRlbGVwcmVzZW5jZSwgd2hpY2ggaXMgdHJhaWxibGF6ZXIgZm9yIFZSKFZpcnR1 YWwgUmVhbGl0eSkNCnByb2R1Y3Rpb24uIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Mi4gQWJvdXQgdGhlIGNoYXJ0ZXIgV0c8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9uZSByZXZvbHV0aW9uYXJ5IGFwcGxpY2F0aW9u LCBzdWNoDQp0ZWxlcHJlc2VuY2UsIHdvdWxkIGNvdmVyIGJhc2ljIHByb3RvY29sIGxldmVsLCBh cHBsaWNhdGlvbiBjb250cm9sIGxldmVsLA0KYW5kIGludGVyd29ya2luZyBpc3N1ZS4gPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiB0aGUgd29yayBp cyBqdXN0IGZvY3VzZWQgb24gcHVyZQ0KaW50ZXJ3b3JraW5nIGlzc3VlLCB0aGVuIHRoZSB0b3Bp Y3MgY2FuIGJlIGRpdmlkZWQgaW50byBzbWFsbGVyIG9uZSwgd2hpY2gNCm1pZ2h0IGJlIGluIG90 aGVyIGJhc2ljIHByb3RvY29scycgV0cncyBzY29wZS4gQnV0IGlmIHRoZSBhcHBsaWNhdGlvbiBp dHNlbGYNCmlzIG5ldywgYW5kIGhhcyBzb21lIG5ldyBjaGFyYWN0ZXJpc3RpYywgbW9yZSB3b3Jr IHNob3VsZCBiZSBwcm9wb3NlZC4NCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+SWYgdGhlIHdvcmsgaXMgYWxzbyBmb2N1c2VkIG9uIHRlbGVwcmVzZW5j ZQ0KYXBwbGljYXRpb24sIHdoaWNoIGlzIGEgY29uZmVyZW5jaW5nIHN5c3RlbSwgdGhlIHhjb24g V0cgbWlnaHQgYmUgcHJvcGVyDQpvbmUgZm9yIGFwcGxpY2F0aW9uIGxldmVsIGRlZmluaXRpb24u PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiB0aGUg Y2hhcnRlciBhbHNvIHdhbnQgdG8gdGFsayB0aGUNCmVzZW50aWFsIGFzcGVjdCBvZiB0ZWxlcHJl c2VuY2Uob3IgbW9yZSBhYnN0cmFjdGx5LCBhYm91dCBWUiksIHN1Y2ggYXMNCmhvdyB0byB1c2lu ZyBTRFAsIG9yIHJlbGF0aXZlIHByb3RvY29sIHRvIGRlc2NyaWJlIHRoZSBzdHJlYW1zIGFuZCBp dCdzDQpjb2xsYWJvcmF0aW9uLCBpdCB3b3VsZCBiZSBxdWl0ZSBuZXcgdG9waWMuIE9uZSBuZXcg V0cgbWlnaHQgYmUgYmV0dGVyLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+SSBmaW5kIHRoZSBjaGFydGVyIHNlZW1zIGNvdmVycyBhbGwNCnRo ZSB0aHJlZSB0aGluZy4gU28sIEkgc3VnZ2VzdCB5b3UgY2xhc3NpZnkgc3VjaCBkaWZmZXJlbnQg bGV2ZWwgcmVxdWlyZW1lbnQuDQpUaGVuLCB3ZSBtYXkgZmluZCB3aGljaCBwYXJ0IGlzIHByb3Bl ciBmb3Igd2hpY2ggV0csIGFuZCB3aGljaCBwYXJ0IHNob3VsZA0KYmUgY292ZXJlZCBieSBuZXcg V0cuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFu a3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAw MTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2 KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtBbGx5biBSb21hbm93IChhbGx5 bikmcXVvdDsNCiZsdDthbGx5bkBjaXNjby5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7ZGlzcGF0Y2gtYm91bmNlc0Bp ZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA1 LTE5IDAyOjMwPC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPiZxdW90O0lFVEYgRElTUEFUQ0ggbGlzdCZxdW90OyAmbHQ7ZGlzcGF0Y2hAaWV0 Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5bZGlzcGF0Y2hdIE11bHRpLXN0cmVhbXMgZm9yIHRlbGVwcmVzZW5jZQ0KZGVz Y3JpcHRpb24gb2Ygd29yazwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5IaSBGb2xrcyw8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+TWFueSBvZiB5b3UgYXJlIGF3YXJlIG9mIHRlbGVwcmVzZW5j ZQ0Kc3lzdGVtcyAodmlkZW8gY29uZmVyZW5jaW5nIG9uIHN0ZXJvaWRzLi46KSwgZmV3ZXIgcHJv YmFibHkgYXJlIGF3YXJlIG9mDQp0aGUgZmFjdCB0aGF0IHRoZSBjdXJyZW50IHN5c3RlbXMgYXJl IG5vdCBpbnRlcm9wZXJhYmxlIHdpdGggZWFjaCBvdGhlci4NCkFmdGVyIHRhbGtpbmcgd2l0aCBN YXJ5IGFuZCBDdWxsZW4sIHdlIGhhdmUgYSByb3VnaCBkcmFmdCBvZiBhIGNoYXJ0ZXINCnRvIHdv cmsgb24gdGhpcyBwcm9ibGVtIGluIERJU1BBVENILCAmbmJzcDtmb3IgZGlzY3Vzc2lvbiBvbiB0 aGUgbWFpbGluZw0KbGlzdC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2Ug ZG9uoa90IHlldCBrbm93IHdoZXRoZXIgYSB3b3JraW5nDQpncm91cCB3b3VsZCBuZWVkIHRvIGJl IHNwdW4gb3V0IG9yIG5vdCCoQyB0aGF0IHdpbGwgYmUgY2xhcmlmaWVkIGFzIHdlDQpnby48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2UgdGhpbmsgdGhlcmUgaXMgZW5vdWdo IGJhY2tncm91bmQNCmluZm8gaW4gdGhlIHdvcmsgZGVzY3JpcHRpb24gdG8gc3RhcnQgYSBkaXNj dXNzaW9uLCBhbmQgcGxhbiB0byBzZW5kIG91dA0KdXNlIGNhc2VzIGZvciBkaXNjdXNzaW9uIHNo b3J0bHkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldobyBpcyB0aGUgd2U/ IFNldmVyYWwgbWFrZXJzIGFuZCBwcm92aWRlcnMNCm9mIHRlbGVwcmVzZW5jZSBzeXN0ZW1zIGhh dmUgZ290dGVuIHRvZ2V0aGVyIHRvIGRlZmluZSB0aGUgbWFpbiBwcm9ibGVtDQppbiBpbnRlcm9w ZXJhYmlsaXR5IKhDIHRoZSBoYW5kbGluZyBvZiBtdWx0aS1zdHJlYW1zLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHlvdXIgdGhvdWdodHMtPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BbGx5bjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8ZGl2IGFsaWduPWNlbnRlcj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxiPk11bHRpLXN0cmVhbXMgZm9yIFRlbGVwcmVz ZW5jZSBEZXNjcmlwdGlvbg0Kb2YgV29yazwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj48Yj4mbmJzcDs8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+PGI+Jm5ic3A7PC9iPjwvZm9udD48L2Rpdj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPjxiPiZuYnNwOzwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48Yj5CYWNrZ3JvdW5kPC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi Pk9uZSBicmFuY2ggb2YgdmlkZW8gY29uZmVyZW5jaW5nIGhhcyBldm9sdmVkDQp0aGF0IGlzIGZv Y3VzZWQgb24gaW1tZXJzaXZlIKGwYmVpbmcgdGhlcmWhsSBleHBlcmllbmNlLiAmbmJzcDtSZWZl cnJlZA0KdG8gaW4gdmFyaW91cyB3YXlzIHN1Y2ggYXMgdmlydHVhbCBjb25mZXJlbmNpbmcsIHRl bGVwcmVzZW5jZSBvciBtZWRpYQ0Kc3BhY2VzLCBlYXJseSBzeXN0ZW1zIHdlcmUgbWFpbmx5IHJl c2VhcmNoIHByb2plY3RzIG9yIGJ1c2luZXNzIHN5c3RlbXMNCndpdGggbGltaXRlZCBkZXBsb3lt ZW50cy4gJm5ic3A7SW4gcmVjZW50IHllYXJzIHRlbGVwcmVzZW5jZSBzeXN0ZW1zIGhhdmUNCnNl ZW4gY29uc2lkZXJhYmxlIG1hcmtldCBzdWNjZXNzLiAmbmJzcDtGb2xsb3dpbmcgdGhlIG1vZGVs IG9mIGVhcmx5IHN5c3RlbXMsDQp0aGUgZmlyc3Qgd2F2ZSBvZiBjb21tZXJjaWFsIHN5c3RlbXMg aGF2ZSBiZWVuIHR5cGljYWxseSBsb2NhdGVkIGluIHNwZWNpYWxseQ0KZGVzaWduZWQgc2luZ2xl LXB1cnBvc2Ugcm9vbXMgd2l0aCBtdWx0aXBsZSByZWxhdGl2ZWx5IGxhcmdlIGRpc3BsYXlzIHBl cm1pdHRpbmcNCmxpZmUgc2l6ZSBpbWFnZSByZXByb2R1Y3Rpb24sIG11bHRpcGxlIGNhbWVyYXMs IGVuY29kZXJzLCBkZWNvZGVycyBhbmQNCm1pY3JvcGhvbmVzLiAmbmJzcDtUaGVzZSBzeXN0ZW1z IGhhdmUgc2V2ZXJhbCBpbXBvcnRhbnQgY2hhcmFjdGVyaXN0aWNzDQp0aGF0IGFyZSBkaWZmZXJl bnQgZnJvbSBtb3JlIHRyYWRpdGlvbmFsIHZpZGVvIGNvbmZlcmVuY2luZyBzeXN0ZW1zLiAmbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5UaGUgZmlyc3QgZGlmZmVyZW5jZSBjb25jZXJu cyBjb250cm9sbGluZw0KdGhlIHZpc3VhbCB2aWV3cG9pbnQgaW4gb3JkZXIgdG8gaW1wcm92ZSBw YXJ0aWNpcGFudCBub252ZXJiYWwgY29tbXVuaWNhdGlvbi4NClRoZXNlIHN5c3RlbXMgcHJlc2Vy dmUgZXNzZW50aWFsIGdyb3VwIG1lZXRpbmcgY2hhcmFjdGVyaXN0aWNzIHN1Y2ggYXMNCmV5ZSBj b250YWN0LCBncm91cCBnZXN0dXJlcywgc2VhdGluZyBvcmRlciBhbmQgc3BhdGlhbCBhdWRpbyBi eSBjYXJlZnVsbHkNCm9yY2hlc3RyYXRpbmcgdGhlIG1pa2luZyBhbmQgY2FtZXJhIGFuZ2xlcyBh dCBlYWNoIG9mIHRoZSBzaXRlcyAuIFRoaXMNCmlzIGRpc3RpbmN0IGZyb20gdGhlIG1vcmUgdHJh ZGl0aW9uYWwgYXBwcm9hY2ggd2hlcmUgdGhlIGdlb21ldHJpYyByZWxhdGlvbnNoaXANCmJldHdl ZW4gbWVkaWEgc3RyZWFtcyBpcyBub3QgdXNlZCB0byBwcmVzZXJ2ZSBpbnRlci1zdHJlYW0gY29t bXVuaWNhdGlvbg0KYXNwZWN0cyBzdWNoIGFzIGV5ZSBjb250YWN0IGFuZCBncm91cCBkeW5hbWlj cy4gJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+QSBzZWNvbmQgZGlmZmVyZW5jZSBp cyBtYW5pcHVsYXRpb24gb2YgdGhlDQplbnZpcm9ubWVudCB0byBpbXByb3ZlIGltbWVyc2lvbi4g Jm5ic3A7V2l0aCB0ZWxlcHJlc2VuY2Ugc3lzdGVtcywgY2luZW1hdG9ncmFwaGljDQphc3BlY3Rz IG9mIHRoZSBsb2NhbCBlbnZpcm9ubWVudCByZXByb2R1Y3Rpb24gYXJlIGNhcmVmdWxseSBwbGFu bmVkIGluY2x1ZGluZw0KY29sb3IsIHRhYmxlIHNoYXBlLCBzZWF0aW5nIGFuZCBsaWdodGluZyBz byB0aGF0IHdoZW4gY29tYmluZWQgd2l0aCBsYXJnZQ0KaGlnaCBxdWFsaXR5IGRpc3BsYXlzLCBh IHN0cm9uZyBzZW5zZSBvZiBhICZxdW90O3Ryb21wZSBsJ29laWwmcXVvdDsgb3INCiZxdW90O2Jl aW5nIHRoZXJlJnF1b3Q7IGltbWVyc2l2ZSBleHBlcmllbmNlIGlzIGNyZWF0ZWQuICZuYnNwO1R5 cGljYWwNCnZpZGVvIGNvbmZlcmVuY2Ugc3lzdGVtcyBkbyBub3QgaW5jbHVkZSB0aGVzZSBjb25z aWRlcmF0aW9ucy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5BcyB0ZWxlcHJlc2VuY2Ugdmlk ZW8gc3lzdGVtcyBoYXZlIGJlY29tZQ0Kc3VjY2Vzc2Z1bCBpbiB0aGUgbWFya2V0LCBtYW51ZmFj dHVyZXJzIGhhdmUgc3RhcnRlZCBleHBsb3JpbmcgZGVsaXZlcnkNCm9mIHRoZSBub252ZXJiYWwg Y29tbXVuaWNhdGlvbiBhbmQgaW1tZXJzaXZlIHZhbHVlcyBvZiB0ZWxlcHJlc2VuY2UgdmlhDQpz bWFsbGVyLCBsZXNzIGV4cGVuc2l2ZSBhbmQgbW9yZSBmbGV4aWJsZSB2aWRlbyBjb25mZXJlbmNp bmcgc3lzdGVtcyBmb3INCmEgdmFyaWV0eSBvZiB2ZW51ZXMsIHN1Y2ggYXMgaW5kaXZpZHVhbCBv ZmZpY2VzLCBob21lcyBhbmQga2lvc2tzLiBUaGVzZQ0KYXJlIGFsc28gJm5ic3A7dGVsZXByZXNl bmNlIHN5c3RlbXMsIHNpbmNlIHRoZSBhdWRpbyBhbmQgdmlkZW8gcXVhbGl0eQ0KaXMgaGlnaCBl bm91Z2ggdG8gYWxsb3cgY2xlYXIgaW1hZ2UgcmVwcm9kdWN0aW9uIGZvciBub252ZXJiYWwgY29t bXVuaWNhdGlvbiwNCnRoZXkgYXJlIGFibGUgdG8gc2VuZCBhbmQgcmVjZWl2ZSBtdWx0aXBsZSBt ZWRpYSBzdHJlYW1zLCBhbmQgbGFyZ2UgY29vcmRpbmF0ZWQNCm11bHRpIGltYWdlIGRpc3BsYXlz IGFyZSBhdmFpbGFibGUgZm9yIGltbWVyc2l2ZSBpbnN0YWxsYXRpb25zLiAmbmJzcDsNCkFzIHRo ZSBpbmR1c3RyeSBkZXZlbG9wcywgdGhlIGxpbmUgYmV0d2VlbiB0ZWxlcHJlc2VuY2UgYW5kIHZp ZGVvIGNvbmZlcmVuY2luZw0KbWF5IGJlY29tZSBibHVycmVkIGFzIG5vbnZlcmJhbCBjb21tdW5p Y2F0aW9uIGFuZCBpbW1lcnNpdmUgaW5zdGFsbGF0aW9ucw0KYmVjb21lIGJyb2FkbHkgYXZhaWxh YmxlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxiPlByb2JsZW08L2I+PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+QWx0aG91Z2ggdGVsZXByZXNlbmNlIHN5c3RlbXMg YXJlIGJhc2VkIG9uDQpvcGVuIHN0YW5kYXJkcyBzdWNoIGFzIFJUUCwgU0lQLCBILjI2NCwgSC4z MjMgc3VpdGUsIHRoZXkgY2Fubm90IGVhc2lseQ0KaW50ZXJvcGVyYXRlIHdpdGggZWFjaCBvdGhl ciB3aXRob3V0IG9wZXJhdG9yIGFzc2lzdGFuY2UgYW5kIGV4cGVuc2l2ZQ0KYWRkaXRpb25hbCBl cXVpcG1lbnQgdGhhdCB0cmFuc2xhdGVzIGZyb20gb25lIHZlbmRvciB0byBhbm90aGVyLiBJdCB3 b3VsZA0KYmUgbGlrZSBoYXZpbmcgdG8gbWFrZSBzdXJlIGFsbCBwYXJ0aWVzIGFyZSBvbiB0aGUg c2FtZSBlcXVpcG1lbnQgKGFuZA0KbmV0d29yaykgd2hlbiBtYWtpbmcgYSB0ZWxlcGhvbmUgY2Fs bC4gJm5ic3A7QSBtYWpvciBmYWN0b3IgaW4gdGhlIGluYWJpbGl0eQ0Kb2YgVGVsZXByZXNlbmNl IHN5c3RlbXMgdG8gd29yayB3aXRoIGVhY2ggb3RoZXIgaXMgdGhhdCB0aGVyZSBpcyBubyBzdGFu ZGFyZA0KZGVzY3JpcHRpb24gb2YgdGhlIG11bHRpcGxlIHN0cmVhbXMgdGhhdCBjb21wcmlzZSB0 aGUgbWVkaWEgZmxvd3MuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPkZvciBleGFtcGxlLCBp biBhIG11bHRpcGxlIHNjcmVlbiBjb25mZXJlbmNlLA0KdGhlIHZpZGVvIGFuZCBhdWRpbyBzdHJl YW1zIHNlbnQgZnJvbSByZW1vdGUgcGFydGljaXBhbnRzIG11c3QgYmUgdW5kZXJzdG9vZA0KYnkg cmVjZWl2ZXJzIHNvIHRoYXQgdGhleSBjYW4gYmUgcHJlc2VudGVkIGluIGEgY29oZXJlbnQgYW5k IGxpZmUtbGlrZQ0KbWFubmVyLiBUaGlzIGluY2x1ZGVzIHRoZSBhYmlsaXR5IHRvIHByZXNlbnQg dGhlIHJlbW90ZSBwYXJ0aWNpcGFudHMgYXQNCnRoZWlyIHRydWUgc2l6ZSBmb3IgdGhlaXIgYXBw YXJlbnQgZGlzdGFuY2UsIHdoaWxlIG1haW50YWluaW5nIGNvcnJlY3QNCmV5ZSBjb250YWN0LCBn ZXN0aWN1bGFyIGN1ZXMsIGFuZCBzaW11bHRhbmVvdXNseSBwcm92aWRpbmcgYSBzcGF0aWFsIGF1 ZGlvDQpzb3VuZCBzdGFnZSBjb25zaXN0ZW50IHdpdGggdGhlIHZpZGVvIHByZXNlbnRhdGlvbi4g Jm5ic3A7VGhlIHJlY2VpdmluZw0KZGV2aWNlIHRoYXQgZGVjaWRlcyBob3cgdG8gZGlzcGxheSB0 aGUgaW5jb21pbmcgaW5mb3JtYXRpb24gbmVlZHMgdG8gdW5kZXJzdGFuZA0KYSBudW1iZXIgb2Yg dmFyaWFibGVzIHN1Y2ggYXMgdGhlIHNwYXRpYWwgcG9zaXRpb24gb2YgdGhlIHNwZWFrZXIsIHRo ZQ0KZmllbGQgb2YgdmlldyBvZiB0aGUgY2FtZXJhcywgdGhlIGNhbWVyYSB6b29tLCB3aGljaCBt ZWRpYSBzdHJlYW0gaXMgcmVsYXRlZA0KdG8gZWFjaCBvZiB0aGUgZGlzcGxheXMsIGV0Yy4gPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGI+Q2hhcnRlcjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj5UaGUgVGVsZXByZXNlbmNlIE11bHRpLVN0cmVhbXMgd29yayBp dGVtDQppbiBESVNQQVRDSCBpcyBjaGFydGVyZWQgdG8gZGVmaW5lIGFuZCBzcGVjaWZ5IHRoZSBj b250ZW50IG9mIG1lZGlhIG11bHRpLXN0cmVhbQ0KbWVzc2FnZXMgYW5kIHRoZSB3YXkgdGhlc2Ug d2lsbCBiZSB0cmFuc3BvcnRlZC4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+VGhpcyB3b3JrIGlzIGFpbWVkIGF0IHByb3ZpZGluZyBhIHN0YW5kYXJkDQpmb3IgdGhlIGV4 Y2hhbmdlIG9mIG1lZGlhIHNlbWFudGljcyBpbmZvcm1hdGlvbiB0aGF0IHdpbGwgZm9zdGVyIGlu dGVyb3BlcmFibGUNCmVuZCBzdGF0aW9ucyBhbmQgY29uZmVyZW5jZSBicmlkZ2VzLiBUaGlzIHdv cmsgaXRlbSB3aWxsIHNwZWNpZnkgdGhlIHZhcmlhYmxlcw0KdGhhdCBkZXNjcmliZSB0aGUgc2Vt YW50aWNzIG9mIHRoZSBtZWRpYSBzdHJlYW1zIGFuZCB0aGUgcmVjb21tZW5kZWQgYmVoYXZpb3IN CnRvIGFjaGlldmUgaW50ZXJvcGVyYWJpbGl0eS4gJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+VGhpcyByZXF1aXJlcyBjb25zaWRlcmluZyBjdXJyZW50IHdpZGVseQ0KZGVwbG95ZWQg dXNlIGNhc2VzLCBzdWNoIGFzIHNpbmdsZSBhbmQgbXVsdGlwbGUgc2NyZWVucywgbXVsdGktcG9p bnQsIFNjYWxhYmxlDQpWaWRlbyBDb2RpbmcgKFNWQyksIGFzIHdlbGwgYXMgY2FzZXMgdGhhdCBh cmUgZXhwZWN0ZWQgdG8gYmUgaW1wbGVtZW50ZWQNCnVzaW5nIHRoZSBwcm90b2NvbCBmcmFtZXdv cmsgcHJvZHVjZWQgYnkgdGhpcyB3b3JrIGl0ZW0uICZuYnNwO1RoZSBtZXRob2RvbG9neQ0KZm9y IGRlc2NyaWJpbmcgdGhlIHZhcmlhYmxlcyBtdXN0IGFsbG93IGV4dGVuc2liaWxpdHkgb2YgdGhl IHZhcmlhYmxlcywNCnNpbmNlIHRlbGVwcmVzZW5jZSBpcyBzdGlsbCBhIHlvdW5nIHRlY2hub2xv Z3kgYW5kIG1heSBoYXZlIHVzZSBjYXNlcyB0aGF0DQphcmUgbm90IGN1cnJlbnRseSBjb25zaWRl cmVkLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPlRoZSB3b3JrIGl0ZW0gd2lsbCBpZGVudGlm eSB1c2UgY2FzZXMsIGRlZmluZQ0KcmVxdWlyZW1lbnRzLCBhbmQgZGVmaW5lIGEgbWV0aG9kIGZv ciBkZXNjcmliaW5nIGFuZCB0cmFuc3BvcnRpbmcgaW5mb3JtYXRpb24NCmFib3V0IG11bHRpcGxl IG1lZGlhIHN0cmVhbXMsIGluY2x1ZGluZyBhIHNwZWNpZmljYXRpb24gb2YgdmFyaWFibGVzIHJl cXVpcmVkDQp0byBzdXBwb3J0IHRoZSB1c2UgY2FzZXMuIFRoaXMgd29yayBpdGVtIHdpbGwgY29u c2lkZXIgdGhlIHJldXNlIG9mIGV4aXN0aW5nDQpJRVRGIHByb3RvY29scyBhbmQgcHJvZHVjZSBh biBhcmNoaXRlY3R1cmUvcHJvdG9jb2wgZnJhbWV3b3JrIGRvY3VtZW50DQpkZXNjcmliaW5nIHRo ZSBwcm90b2NvbHMgcmVxdWlyZWQgdG8gYmUgaW1wbGVtZW50ZWQgdG8gc3VwcG9ydCB0aGlzIGZ1 bmN0aW9uYWxpdHkuDQombmJzcDtUaGUgZG9jdW1lbnQgd2lsbCBpZGVudGlmeSBhbnkgZW5oYW5j ZW1lbnRzIHJlcXVpcmVkIHRvIGV4aXN0aW5nDQpwcm90b2NvbHMgYXMgd2VsbCBhcyBkZXNjcmli aW5nIG5ldyBwcm90b2NvbChzKSBmb3IgaW50ZXJvcGVyYWJsZSBtdWx0aS1zdHJlYW1zDQpuZWdv dGlhdGlvbiB0aGF0IG1heSBiZSByZXF1aXJlZC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48 Yj5TY29wZTwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5UaGUgc2Nv cGUgaW5jbHVkZXMgYm90aCBzeXN0ZW1zIHRoYXQgcHJvdmlkZQ0KYSBmdWxseSBpbW1lcnNpdmUg ZXhwZXJpZW5jZSwgYW5kIHN5c3RlbXMgdGhhdCBpbnRlcndvcmsgd2l0aCB0aGVtIGFuZA0KdGhl cmVmb3JlIG5lZWQgdG8gdW5kZXJzdGFuZCB0aGUgc2FtZSBtdWx0aXBsZSBzdHJlYW0gc2VtYW50 aWNzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPlRoZSBmb2N1cyBvZiB0aGlzIHdvcmsgaXMg b24gYXVkaW8gYW5kIHZpZGVvDQptdWx0aXBsZSBzdHJlYW1zLCBob3dldmVyIG90aGVyIG1lZGlh IHR5cGVzIG1heSBiZSBjb25zaWRlcmVkLiAmbmJzcDtEZWZpbml0aW9uDQpvZiBuZXcgYXBwbGlj YXRpb24gcHJvdG9jb2xzIGlzIG5vdCB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoaXMgd29yazwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPltJcyB0aGVyZSBhbnl0aGluZyBlbHNlIHdlIG5lZWQgdG8g ZXhwbGljaXRseQ0Kc2F5IGlzIG91dCBvZiBzY29wZT9dPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jMDA4MmJmIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48Yj5UaGUgZ3JvdXAgd2lsbCBwcm9kdWNlPC9iPjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPi0gUmVxdWlyZW1lbnRzIGFuZCB1c2UgY2FzZXM8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4tIEFyY2hpdGVjdHVyYWwgRnJhbWV3b3JrIGRlc2Ny aWJpbmcgdGhlDQpwcm90b2NvbHMgcmVxdWlyZWQgdG8gYmUgaW1wbGVtZW50ZWQgdG8gc3VwcG9y dCB0aGlzIGZ1bmN0aW9uYWxpdHkgYW5kDQppZGVudGlmeWluZyBleGlzdGluZyBwcm90b2NvbCBl bmhhbmNlbWVudHMgYW5kIG5ldyBwcm90b2NvbCBmdW5jdGlvbmFsaXR5DQpyZXF1aXJlZDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPi0gU3BlY2lmaWNhdGlvbiBvZiBhIG5ldyBwcm90b2NvbCB0 byBzdXBwb3J0DQp0ZWxlcHJlc2VuY2UgbXVsdGktc3RyZWFtcyBbaWYgcmVxdWlyZWRdPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+PGI+R29hbHMgYW5kIE1pbGVzdG9uZXM8L2I+PC9mb250Pg0K PHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0cj4NCjx0ZCB3aWR0aD0yMCU+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj5Ob3YgMjAxMCA8L2ZvbnQ+DQo8dGQgd2lkdGg9NzklPjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+VXNlIENhc2VzIGFuZCBSZXF1aXJlbWVudHMgdG8gSUVTRw0KYXMgSW5m b3JtYXRpb25hbCBSRkMgPC9mb250Pg0KPHRyPg0KPHRkPjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+TWFyY2ggMjAxMSA8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5BcmNo aXRlY3R1cmUgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsIFJGQw0KPC9mb250Pg0KPHRyPg0KPHRk Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+TWFyY2ggMjAxMTwvZm9udD4NCjx0ZD48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPlJldmlzZSBDaGFydGVyIFtJRiBuZXcgcHJvdG9jb2wgaXMgbm90 IHJlcXVpcmVkXTwvZm9udD4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPk5v diAyMDExIDwvZm9udD4NCjx0ZD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPlN1Ym1pdCBwcm90 b2NvbCBkcmFmdCB0byBJRVNHIGFzIFByb3Bvc2VkDQpTdGFuZGFyZCBSRkMgPC9mb250PjwvdGFi bGU+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7PC9mb250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkaXNwYXRjaCBtYWlsaW5nIGxpc3Q8 YnI+DQpkaXNwYXRjaEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGlzcGF0Y2g8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5i c3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWls Jm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21t dW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNw O25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21h aW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1p dHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29m Jm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMm bmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQm bmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJz cDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJz cDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lv dSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5i c3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9y Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7 ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Ro b3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZu YnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNw O3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNw YW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 001EC0EB48257728_=-- From stephen.botzko@gmail.com Wed May 19 03:57:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CDB43A6BF1 for ; Wed, 19 May 2010 03:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1PrQn1bj-y1 for ; Wed, 19 May 2010 03:57:21 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C8BCD3A69BF for ; Wed, 19 May 2010 03:56:29 -0700 (PDT) Received: by wwb24 with SMTP id 24so522362wwb.31 for ; Wed, 19 May 2010 03:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=vRKxSqAmslMfnW1JMNSJf03oLXoD+5cCdLKvLaZJzaQ=; b=XlN6QwS4RIOubjRHfMBHxb/k5wK+HH8q+VYw4yG6k3gc+pXf3Or2hHTG/vI3e53dm1 n53EAEEW5bL44YJ7HG30ZHLiOy2SQEfk80KwufISxLIoplbwBqLw8OUnprx/gM6XANfJ KL0dSXOGIVUC3leUhLi4x7otZN/405l/jC45s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kJ0nMBPYFVX2ABLS5OBt5KW+ktM0sd+fhFkYZEwLlUjmieY2zjB+x2VLN2P2Cj+TIY T0sQYpURMz4sl64HYRL1C/cUk8ycCkKD8zV2ZCoa2w/gWiDQxz8Yd8PYRNG6Ize72T87 16+autiivBBvhfa4SuPEC11uFj+axb1CEtmGw= MIME-Version: 1.0 Received: by 10.227.135.203 with SMTP id o11mr7056062wbt.229.1274266082837; Wed, 19 May 2010 03:48:02 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Wed, 19 May 2010 03:48:02 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0160CE8B@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0160CE8B@xmb-sjc-221.amer.cisco.com> Date: Wed, 19 May 2010 06:48:02 -0400 Message-ID: From: stephen botzko To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=001636832fe637850f0486f0315b Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 10:57:24 -0000 --001636832fe637850f0486f0315b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Peter I am one of the "we" that Allyn refers to. See inline for a comment. Regards. Stephen Botzko On Wed, May 19, 2010 at 12:50 AM, Allyn Romanow (allyn) wr= ote: > Hi Peter, > You've raised excellent points. See inline for a few brief comments, and > I'll look to others to elaborate (or disagree). > > best, > Allyn > > ------------------------------ > *From:* Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > *Sent:* Tuesday, May 18, 2010 9:22 PM > *To:* Allyn Romanow (allyn) > *Cc:* IETF DISPATCH list > *Subject:* Re: [dispatch] Multi-streams for telepresence description of > work > > Hi Allyn, > > I am interested in having this work start. I suspect it will likely warra= nt > a working group at the appropriate time. > > The charter as written is VERY general. I would suspect that SIP/SDP is > going to be the common ground. Is it worth making this explicit in the > charter? If not perhaps the reasons why not could be stated in the charte= r. > (My understanding is that most of these systems do use SIP but that they > differ in number of sessions per endpoint and how the media is packaged i= nto > RTP streams etc.) > [alr] Certainly RTP is used without question, and there has been discussi= on > about limiting to RTP streams only, not other types of data. This is stil= l > an open issue to be discussed. > > Although I (and some others) initially assumed that we would use SDP for > signaling, after further thought Steve Botsko and others suggested we mi= ght > want to consider another protocol such as XMPP in light of the nature of = the > messages we want to send. I think that it's premature to specify this in = the > charter as I consider it part of the the solution, and think it will beco= me > clear what protocol to use as we specify requirements. > > Is there other IETF work which we can see has relevance and should be > mentioned as tools which can be brought to bear? (xcon? mediactrl?) > [alr] Good point. We definitely want to consider existing work, and look = to > the experts in DISPATCH to help with this. As above, I'm not sure if we c= an > go there yet without requirements first- but centainly we can be begin to > look at potential tools. > > Is there interest in ensuring interop of TP with legacy SIP video > conferencing systems as part of this work? Should that be part of the > charter? > [alr] My personal view is not too much, that it's more a matter of going > forward with a common technology that allows us to interoperate. I don't > want us to be in the position of needing to tie together systems that we > already have, as that would too much limit our approach. That said, peopl= e > will want to incorporate the best of their current technology. What do fo= lks > think? > > [scb] Personally I think it is essential that TP devices be able to use SIP/SDP to interoperate with traditional videoconferencing systems. So I think it is a requirement that this work *not preclude* SIP/SDP interoperability, either with videoconferencing or ordinary phones. Also, I think that TP calls will need to be be carried on existing [possibl= y upgraded] infrastructure, including SIP proxies, SBCs, etc, as it is undesirable to deploy a parallel infrastructure for TP. I do not think it is a requirement for this work to fully accommodate existing TP systems. While it would be a nice outcome if these systems coul= d be easily retrofitted to support this new work, it is much more important t= o have a solid basis to go forward. > > Regards, > > Peter Musgrave > > > > On Tue, May 18, 2010 at 8:30 PM, Allyn Romanow (allyn) w= rote: > >> Hi Folks, >> >> >> >> Many of you are aware of telepresence systems (video conferencing on >> steroids..:), fewer probably are aware of the fact that the current syst= ems >> are not interoperable with each other. After talking with Mary and Culle= n, >> we have a rough draft of a charter to work on this problem in DISPATCH, = for >> discussion on the mailing list. >> >> >> >> We don=92t yet know whether a working group would need to be spun out or= not >> =96 that will be clarified as we go. >> >> >> >> We think there is enough background info in the work description to star= t >> a discussion, and plan to send out use cases for discussion shortly. >> >> >> >> Who is the we? Several makers and providers of telepresence systems have >> gotten together to define the main problem in interoperability =96 the >> handling of multi-streams. >> >> >> >> Thanks for your thoughts- >> >> Allyn >> >> >> >> >> >> *Multi-streams for Telepresence Description of Work* >> >> ** >> >> ** >> >> ** >> >> *Background* >> >> One branch of video conferencing has evolved that is focused on immersiv= e >> =93being there=94 experience. Referred to in various ways such as virtu= al >> conferencing, telepresence or media spaces, early systems were mainly >> research projects or business systems with limited deployments. In rece= nt >> years telepresence systems have seen considerable market success. Follo= wing >> the model of early systems, the first wave of commercial systems have be= en >> typically located in specially designed single-purpose rooms with multip= le >> relatively large displays permitting life size image reproduction, multi= ple >> cameras, encoders, decoders and microphones. These systems have several >> important characteristics that are different from more traditional video >> conferencing systems. >> >> >> >> The first difference concerns controlling the visual viewpoint in order = to >> improve participant nonverbal communication. These systems preserve >> essential group meeting characteristics such as eye contact, group gestu= res, >> seating order and spatial audio by carefully orchestrating the miking an= d >> camera angles at each of the sites . This is distinct from the more >> traditional approach where the geometric relationship between media stre= ams >> is not used to preserve inter-stream communication aspects such as eye >> contact and group dynamics. >> >> >> >> A second difference is manipulation of the environment to improve >> immersion. With telepresence systems, cinematographic aspects of the lo= cal >> environment reproduction are carefully planned including color, table sh= ape, >> seating and lighting so that when combined with large high quality displ= ays, >> a strong sense of a "trompe l'oeil" or "being there" immersive experienc= e is >> created. Typical video conference systems do not include these >> considerations. >> >> >> >> As telepresence video systems have become successful in the market, >> manufacturers have started exploring delivery of the nonverbal communica= tion >> and immersive values of telepresence via smaller, less expensive and mor= e >> flexible video conferencing systems for a variety of venues, such as >> individual offices, homes and kiosks. These are also telepresence syste= ms, >> since the audio and video quality is high enough to allow clear image >> reproduction for nonverbal communication, they are able to send and rece= ive >> multiple media streams, and large coordinated multi image displays are >> available for immersive installations. As the industry develops, the l= ine >> between telepresence and video conferencing may become blurred as nonver= bal >> communication and immersive installations become broadly available. >> >> >> >> *Problem* >> >> Although telepresence systems are based on open standards such as RTP, >> SIP, H.264, H.323 suite, they cannot easily interoperate with each other >> without operator assistance and expensive additional equipment that >> translates from one vendor to another. It would be like having to make s= ure >> all parties are on the same equipment (and network) when making a teleph= one >> call. A major factor in the inability of Telepresence systems to work w= ith >> each other is that there is no standard description of the multiple stre= ams >> that comprise the media flows. >> >> >> >> For example, in a multiple screen conference, the video and audio stream= s >> sent from remote participants must be understood by receivers so that th= ey >> can be presented in a coherent and life-like manner. This includes the >> ability to present the remote participants at their true size for their >> apparent distance, while maintaining correct eye contact, gesticular cue= s, >> and simultaneously providing a spatial audio sound stage consistent with= the >> video presentation. The receiving device that decides how to display th= e >> incoming information needs to understand a number of variables such as t= he >> spatial position of the speaker, the field of view of the cameras, the >> camera zoom, which media stream is related to each of the displays, etc. >> >> >> >> *Charter* >> >> The Telepresence Multi-Streams work item in DISPATCH is chartered to >> define and specify the content of media multi-stream messages and the wa= y >> these will be transported. >> >> This work is aimed at providing a standard for the exchange of media >> semantics information that will foster interoperable end stations and >> conference bridges. This work item will specify the variables that >> describe the semantics of the media streams and the recommended behavior= to >> achieve interoperability. >> >> >> >> This requires considering current widely deployed use cases, such as >> single and multiple screens, multi-point, Scalable Video Coding (SVC), a= s >> well as cases that are expected to be implemented using the protocol >> framework produced by this work item. The methodology for describing th= e >> variables must allow extensibility of the variables, since telepresence = is >> still a young technology and may have use cases that are not currently >> considered. >> >> >> >> The work item will identify use cases, define requirements, and define a >> method for describing and transporting information about multiple media >> streams, including a specification of variables required to support the = use >> cases. This work item will consider the reuse of existing IETF protocols= and >> produce an architecture/protocol framework document describing the proto= cols >> required to be implemented to support this functionality. The document = will >> identify any enhancements required to existing protocols as well as >> describing new protocol(s) for interoperable multi-streams negotiation t= hat >> may be required. >> >> >> >> *Scope* >> >> The scope includes both systems that provide a fully immersive experienc= e, >> and systems that interwork with them and therefore need to understand th= e >> same multiple stream semantics. >> >> >> >> The focus of this work is on audio and video multiple streams, however >> other media types may be considered. Definition of new application >> protocols is not within the scope of this work >> >> >> >> [Is there anything else we need to explicitly say is out of scope?]** >> >> >> >> *The group will produce* >> >> - Requirements and use cases >> >> >> >> - Architectural Framework describing the protocols required to be >> implemented to support this functionality and identifying existing proto= col >> enhancements and new protocol functionality required >> >> >> >> - Specification of a new protocol to support telepresence multi-streams >> [if required] >> >> >> >> *Goals and Milestones* >> >> Nov 2010 >> >> Use Cases and Requirements to IESG as Informational RFC >> >> March 2011 >> >> Architecture to IESG as Informational RFC >> >> March 2011 >> >> Revise Charter [IF new protocol is not required] >> >> Nov 2011 >> >> Submit protocol draft to IESG as Proposed Standard RFC >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > > --001636832fe637850f0486f0315b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Peter

I am one of the "we" that Allyn refers to.=A0 See= inline for a comment.=A0

Regards.
Stephen Botzko

On Wed, May 19, 2010 at 12:50 AM, Allyn Romanow (allyn)= <allyn@cisco.com> wrote:
Hi Peter,
You've raised=A0excellent points.=A0See inline for a=20 few brief comments, and I'll look to others to elaborate (or=20 disagree).
=A0
best,
Allyn

From: Peter Musgrave=20 [mailto:peter.musgrave@magorcorp.com]
Sent: Tuesday, May 18, 2010= =20 9:22 PM
To: Allyn Romanow (allyn)
Cc: IETF DISPATCH= =20 list
Subject: Re: [dispatch] Multi-streams for telepresence=20 description of work

Hi Allyn,=A0

I am interested in having this work start. I suspect it will likely= =20 warrant a working group at the appropriate time. =A0

The charter as written is VERY general. I wo= uld suspect that SIP/SDP is=20 going to be the common ground. Is it worth making this explicit in the=20 charter? If not perhaps the reasons why not could be stated in the charte= r.=20 (My understanding is that most of these systems do use SIP but that they= =20 differ in number of sessions per endpoint and how the media is packaged i= nto=20 RTP streams etc.)
[alr]=A0Certainly RTP is used without question,=20 and=A0there has been discussion about limiting to RTP streams only, not= =20 other types of data. This is still an open issue to be=20 discussed.
=A0
Although=A0I= =A0(and some others) initially assumed that=20 we=A0would use=A0SDP for signaling, after=A0further thought Steve=20 Botsko and=A0 others suggested we might want to consider=20 another=A0protocol such as XMPP in light of the nature of the messages we= =20 want to send. I think that it's premature to specify this in the char= ter=20 as=A0I consider it part of the the solution, and think it will become cle= ar=20 what protocol to use as we specify requirements.

Is there other IETF work which we can see has rele= vance and should be=20 mentioned as tools which can be brought to bear? (xcon? mediactrl?)
[alr]=A0Good=20 point.=A0We definitely want to consider existing work, and look to the=20 experts in DISPATCH to help with this. As above, I'm not sure if we c= an go=20 there yet without requirements first- but centainly we can be begin to lo= ok at=20 potential tools.

Is there interest in ensuring interop of TP with l= egacy SIP video=20 conferencing systems as part of this work? Should that be part of the=20 charter?
[alr]=A0My personal view is not too much, that it's more a matter of= =20 going forward with a=A0 common=A0technology that=A0allows us to=20 interoperate. I don't want us to be in the position of needing to tie= together=20 systems that we already have, as that would too much limit our=20 approach.=A0That said, people will want to incorporate the best of their= =20 current=A0technology. What do=A0folks think?=A0
[scb] Personally I think it is essential tha= t TP devices be able to use SIP/SDP to interoperate with traditional videoc= onferencing systems.=A0 So I think it is a requirement that this work no= t preclude SIP/SDP interoperability, either with videoconferencing or o= rdinary phones.

Also, I think that TP calls will need to be be carried on existing [pos= sibly upgraded] infrastructure, including SIP proxies, SBCs, etc, as it is = undesirable to deploy a parallel infrastructure for TP.

I do not thi= nk it is a requirement for this work to fully accommodate existing TP syste= ms. While it would be a nice outcome if these systems could be easily retro= fitted to support this new work, it is much more important to have a solid = basis to go forward.

Regards,=A0

Peter Musgrave



On Tue, May 18, 2010 at 8:30 PM, Allyn Romanow= (allyn)=20 <allyn@cisco.com> wrote:

Hi Folks,

=A0

Many of you are aware of telepresence systems (v= ideo=20 conferencing on steroids..:), fewer probably are aware of the fact that= the=20 current systems are not interoperable with each other. After talking wi= th=20 Mary and Cullen, we have a rough draft of a charter to work on this pro= blem=20 in DISPATCH, =A0for discussion on the mailing list.

=A0

We don=92t yet know whether a working group woul= d need to=20 be spun out or not =96 that will be clarified as we go.

=A0

We think there is enough background info in the = work=20 description to start a discussion, and plan to send out use cases for= =20 discussion shortly.

=A0

Who is the we? Several makers and providers of= =20 telepresence systems have gotten together to define the main problem in= =20 interoperability =96 the handling of multi-streams.

=A0

Thanks for your thoughts-

Allyn

=A0

=A0

<= b>Multi-streams for Telepresence Description of=20 Work

<= b>=A0

<= b>=A0

=A0

Background

One branch of video conferencing has evolv= ed that=20 is focused on immersive =93being there=94 experience.=A0 Referred to in= =20 various ways such as virtual conferencing, telepresence or media spaces= ,=20 early systems were mainly research projects or business systems with li= mited=20 deployments.=A0 In recent years telepresence systems have seen=20 considerable market success.=A0 Following the model of early systems, t= he=20 first wave of commercial systems have been typically located in special= ly=20 designed single-purpose rooms with multiple relatively large displays= =20 permitting life size image reproduction, multiple cameras, encoders,=20 decoders and microphones.=A0 These systems have several important=20 characteristics that are different from more traditional video conferen= cing=20 systems.=A0

=A0

The first difference concerns controlling = the=20 visual viewpoint in order to improve participant nonverbal communicatio= n.=20 These systems preserve essential group meeting characteristics such as = eye=20 contact, group gestures, seating order and spatial audio by carefully= =20 orchestrating the miking and camera angles at each of the sites . This = is=20 distinct from the more traditional approach where the geometric relatio= nship=20 between media streams is not used to preserve inter-stream communicatio= n=20 aspects such as eye contact and group dynamics.=A0

=A0

A second difference is manipulation of the= =20 environment to improve immersion.=A0 With telepresence systems,=20 cinematographic aspects of the local environment reproduction are caref= ully=20 planned including color, table shape, seating and lighting so that when= =20 combined with large high quality displays, a strong sense of a "tr= ompe=20 l'oeil" or "being there" immersive experience is cre= ated.=A0 Typical=20 video conference systems do not include these considerations.

=A0

As telepresence video systems have become= =20 successful in the market, manufacturers have started exploring delivery= of=20 the nonverbal communication and immersive values of telepresence via=20 smaller, less expensive and more flexible video conferencing systems fo= r a=20 variety of venues, such as individual offices, homes and kiosks. These = are=20 also=A0 telepresence systems, since the audio and video quality is high= =20 enough to allow clear image reproduction for nonverbal communication, t= hey=20 are able to send and receive multiple media streams, and large coordina= ted=20 multi image displays are available for immersive installations.=A0=A0= =20 As the industry develops, the line between telepresence and video=20 conferencing may become blurred as nonverbal communication and immersiv= e=20 installations become broadly available.

=A0

Problem

Although telepresence systems are based on= open=20 standards such as RTP, SIP, H.264, H.323 suite, they cannot easily=20 interoperate with each other without operator assistance and expensive= =20 additional equipment that translates from one vendor to another. It wou= ld be=20 like having to make sure all parties are on the same equipment (and net= work)=20 when making a telephone call. =A0A major factor in the inability of=20 Telepresence systems to work with each other is that there is no standa= rd=20 description of the multiple streams that comprise the media flows.=20

=A0

For example, in a multiple screen conferen= ce, the=20 video and audio streams sent from remote participants must be understoo= d by=20 receivers so that they can be presented in a coherent and life-like man= ner.=20 This includes the ability to present the remote participants at their t= rue=20 size for their apparent distance, while maintaining correct eye contact= ,=20 gesticular cues, and simultaneously providing a spatial audio sound sta= ge=20 consistent with the video presentation.=A0 The receiving device that=20 decides how to display the incoming information needs to understand a n= umber=20 of variables such as the spatial position of the speaker, the field of = view=20 of the cameras, the camera zoom, which media stream is related to each = of=20 the displays, etc.

=A0

Charter

The Telepresence Multi-Streams work item i= n=20 DISPATCH is chartered to define and specify the content of media=20 multi-stream messages and the way these will be transported.

This work is aimed at providing a standard= for the=20 exchange of media semantics information that will foster interoperable = end=20 stations and conference bridges. This work item will speci= fy=20 the variables that describe the semantics of the media streams and the= =20 recommended behavior to achieve interoperability.=A0

=A0

This requires considering current widely d= eployed=20 use cases, such as single and multiple screens, multi-point, Scalable V= ideo=20 Coding (SVC), as well as cases that are expected to be implemented usin= g the=20 protocol framework produced by this work item.=A0 The methodology for= =20 describing the variables must allow extensibility of the variables, sin= ce=20 telepresence is still a young technology and may have use cases that ar= e not=20 currently considered.

=A0

The work item will identify use cases, def= ine=20 requirements, and define a method for describing and transporting=20 information about multiple media streams, including a specification of= =20 variables required to support the use cases. This work item will consid= er=20 the reuse of existing IETF protocols and produce an architecture/protoc= ol=20 framework document describing the protocols required to be implemented = to=20 support this functionality.=A0 The document will identify any=20 enhancements required to existing protocols as well as describing new= =20 protocol(s) for interoperable multi-streams negotiation that may be=20 required.

=A0

Scope

The scope includes both systems that provi= de a=20 fully immersive experience, and systems that interwork with them and=20 therefore need to understand the same multiple stream=20 semantics.

=A0

The focus of this work is on audio and vid= eo=20 multiple streams, however other media types may be considered.=A0=20 Definition of new application protocols is not within the scope of this= =20 work

=A0

[Is there anything else we need to explici= tly say=20 is out of scope?]

= =A0

The group will produce

- Requirements and use cases

=A0

- Architectural Framework describing the p= rotocols=20 required to be implemented to support this functionality and identifyin= g=20 existing protocol enhancements and new protocol functionality=20 required

=A0

- Specification of a new protocol to suppo= rt=20 telepresence multi-streams [if required]

=A0

Goals and Milestones

=

Nov 2010

Use Cases and Requirements to IESG a= s=20 Informational RFC =

March 2011

Architecture to IESG as Informationa= l RFC=20

March 2011

Revise Charter [IF new protocol is n= ot=20 required]

Nov 2011

Submit protocol draft to IESG as Pro= posed=20 Standard RFC

<= /td>

=A0

=A0

=A0

=A0


_________________________= ______________________
dispatch=20 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


--001636832fe637850f0486f0315b-- From Markus.Isomaki@nokia.com Wed May 19 04:05:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB18F3A6BB0 for ; Wed, 19 May 2010 04:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.937 X-Spam-Level: X-Spam-Status: No, score=-4.937 tagged_above=-999 required=5 tests=[AWL=-0.939, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIDpjnIx1sGi for ; Wed, 19 May 2010 04:05:47 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 825943A6970 for ; Wed, 19 May 2010 04:05:44 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4JB54R8020550; Wed, 19 May 2010 14:05:31 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 May 2010 14:05:17 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 May 2010 14:05:17 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 19 May 2010 13:05:03 +0200 From: To: , Date: Wed, 19 May 2010 13:05:01 +0200 Thread-Topic: Multi-streams for telepresence description of work Thread-Index: Acr2uCFZ+eckhAOrTo2gjbFeNJpM3QAh4QeQ Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B3F72E5548B10A4A8E6F4795430F8418320D5C4414NOKEUMSG02mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 19 May 2010 11:05:17.0055 (UTC) FILETIME=[29DAB8F0:01CAF743] X-Nokia-AV: Clean Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 11:06:00 -0000 --_000_B3F72E5548B10A4A8E6F4795430F8418320D5C4414NOKEUMSG02mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Allyn, Cisco has recently open sourced under Apache license a protocol called Tele= presence Interoperability Protocol. Also IMTC (International Multimedia Tel= ecommunications Consortium) has setup an activity around TIP and Telepresen= ce [1]. Would this proposed IETF work be overlapping or orthogonal to TIP a= nd what IMTC is doing? It's natural that IETF RAI area is a good fit for this type of standards, e= specially if we can take RTP, SIP, XMPP as the baseline. On the other hand,= if a reasonable solution that is backed up by some major vendors is alread= y being developed elsewhere, that will significantly shrik the succes chanc= es of IETF being able to do something that will get deployed. Regards, Markus [1] http://blog.imtc.org/index.php/2010/03/09/announcing-the-creation-of-im= tc-telepresence-multi-streaming-activity-group/ ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Allyn Romanow (allyn) Sent: 18 May, 2010 21:30 To: IETF DISPATCH list Subject: [dispatch] Multi-streams for telepresence description of work Hi Folks, Many of you are aware of telepresence systems (video conferencing on steroi= ds..:), fewer probably are aware of the fact that the current systems are n= ot interoperable with each other. After talking with Mary and Cullen, we ha= ve a rough draft of a charter to work on this problem in DISPATCH, for dis= cussion on the mailing list. We don't yet know whether a working group would need to be spun out or not = - that will be clarified as we go. We think there is enough background info in the work description to start a= discussion, and plan to send out use cases for discussion shortly. Who is the we? Several makers and providers of telepresence systems have go= tten together to define the main problem in interoperability - the handling= of multi-streams. Thanks for your thoughts- Allyn Multi-streams for Telepresence Description of Work Background One branch of video conferencing has evolved that is focused on immersive "= being there" experience. Referred to in various ways such as virtual confe= rencing, telepresence or media spaces, early systems were mainly research p= rojects or business systems with limited deployments. In recent years tele= presence systems have seen considerable market success. Following the mode= l of early systems, the first wave of commercial systems have been typicall= y located in specially designed single-purpose rooms with multiple relative= ly large displays permitting life size image reproduction, multiple cameras= , encoders, decoders and microphones. These systems have several important= characteristics that are different from more traditional video conferencin= g systems. The first difference concerns controlling the visual viewpoint in order to = improve participant nonverbal communication. These systems preserve essenti= al group meeting characteristics such as eye contact, group gestures, seati= ng order and spatial audio by carefully orchestrating the miking and camera= angles at each of the sites . This is distinct from the more traditional a= pproach where the geometric relationship between media streams is not used = to preserve inter-stream communication aspects such as eye contact and grou= p dynamics. A second difference is manipulation of the environment to improve immersion= . With telepresence systems, cinematographic aspects of the local environm= ent reproduction are carefully planned including color, table shape, seatin= g and lighting so that when combined with large high quality displays, a st= rong sense of a "trompe l'oeil" or "being there" immersive experience is cr= eated. Typical video conference systems do not include these consideration= s. As telepresence video systems have become successful in the market, manufac= turers have started exploring delivery of the nonverbal communication and i= mmersive values of telepresence via smaller, less expensive and more flexib= le video conferencing systems for a variety of venues, such as individual o= ffices, homes and kiosks. These are also telepresence systems, since the a= udio and video quality is high enough to allow clear image reproduction for= nonverbal communication, they are able to send and receive multiple media = streams, and large coordinated multi image displays are available for immer= sive installations. As the industry develops, the line between telepresen= ce and video conferencing may become blurred as nonverbal communication and= immersive installations become broadly available. Problem Although telepresence systems are based on open standards such as RTP, SIP,= H.264, H.323 suite, they cannot easily interoperate with each other withou= t operator assistance and expensive additional equipment that translates fr= om one vendor to another. It would be like having to make sure all parties = are on the same equipment (and network) when making a telephone call. A ma= jor factor in the inability of Telepresence systems to work with each other= is that there is no standard description of the multiple streams that comp= rise the media flows. For example, in a multiple screen conference, the video and audio streams s= ent from remote participants must be understood by receivers so that they c= an be presented in a coherent and life-like manner. This includes the abili= ty to present the remote participants at their true size for their apparent= distance, while maintaining correct eye contact, gesticular cues, and simu= ltaneously providing a spatial audio sound stage consistent with the video = presentation. The receiving device that decides how to display the incomin= g information needs to understand a number of variables such as the spatial= position of the speaker, the field of view of the cameras, the camera zoom= , which media stream is related to each of the displays, etc. Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to define= and specify the content of media multi-stream messages and the way these w= ill be transported. This work is aimed at providing a standard for the exchange of media semant= ics information that will foster interoperable end stations and conference = bridges. This work item will specify the variables that describe the semant= ics of the media streams and the recommended behavior to achieve interopera= bility. This requires considering current widely deployed use cases, such as single= and multiple screens, multi-point, Scalable Video Coding (SVC), as well as= cases that are expected to be implemented using the protocol framework pro= duced by this work item. The methodology for describing the variables must= allow extensibility of the variables, since telepresence is still a young = technology and may have use cases that are not currently considered. The work item will identify use cases, define requirements, and define a me= thod for describing and transporting information about multiple media strea= ms, including a specification of variables required to support the use case= s. This work item will consider the reuse of existing IETF protocols and pr= oduce an architecture/protocol framework document describing the protocols = required to be implemented to support this functionality. The document wil= l identify any enhancements required to existing protocols as well as descr= ibing new protocol(s) for interoperable multi-streams negotiation that may = be required. Scope The scope includes both systems that provide a fully immersive experience, = and systems that interwork with them and therefore need to understand the s= ame multiple stream semantics. The focus of this work is on audio and video multiple streams, however othe= r media types may be considered. Definition of new application protocols i= s not within the scope of this work [Is there anything else we need to explicitly say is out of scope?] The group will produce - Requirements and use cases - Architectural Framework describing the protocols required to be implement= ed to support this functionality and identifying existing protocol enhancem= ents and new protocol functionality required - Specification of a new protocol to support telepresence multi-streams [if= required] Goals and Milestones Nov 2010 Use Cases and Requirements to IESG as Informational RFC March 2011 Architecture to IESG as Informational RFC March 2011 Revise Charter [IF new protocol is not required] Nov 2011 Submit protocol draft to IESG as Proposed Standard RFC --_000_B3F72E5548B10A4A8E6F4795430F8418320D5C4414NOKEUMSG02mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Allyn,
 
Cisco has recently open sourced under Apache lic= ense a=20 protocol called Telepresence Interoperability Protocol. Also IMTC (Internat= ional=20 Multimedia Telecommunications Consortium) has setup an activity around= TIP=20 and Telepresence [1]. Would this proposed IETF work be overlapping or ortho= gonal=20 to TIP and what IMTC is doing?
 
It's natural that IETF RAI area is a good fit fo= r this=20 type of standards, especially if we can take RTP, SIP, XMPP as the baseline= . On=20 the other hand, if a reasonable solution that is backed up by some major ve= ndors=20 is already being developed elsewhere, that will significantly shrik the suc= ces=20 chances of IETF being able to do something that will get deployed.=20
 
Regards,
    Markus
 
[1] http://blog.imtc.org/i= ndex.php/2010/03/09/announcing-the-creation-of-imtc-telepresence-multi-stre= aming-activity-group/
&nbs= p;

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Allyn Romanow= =20 (allyn)
Sent: 18 May, 2010 21:30
To: IETF DISPATCH=20 list
Subject: [dispatch] Multi-streams for telepresence descrip= tion=20 of work

Hi Folks,

 

Many of you are aware of telepresence systems (video= =20 conferencing on steroids..:), fewer probably are aware of the fact that t= he=20 current systems are not interoperable with each other. After talking with= Mary=20 and Cullen, we have a rough draft of a charter to work on this problem in= =20 DISPATCH,  for discussion on the mailing list.

 

We don’t yet know whether a working group woul= d need to be=20 spun out or not – that will be clarified as we go.

 

We think there is enough background info in the work= =20 description to start a discussion, and plan to send out use cases for=20 discussion shortly.

 

Who is the we? Several makers and providers of telep= resence=20 systems have gotten together to define the main problem in interoperabili= ty –=20 the handling of multi-streams.

 

Thanks for your thoughts-

Allyn

 

 

Multi-streams for Telepresenc= e=20 Description of Work

 <= /P>

 <= /P>

 <= /P>

Background<= /B>

On= e branch=20 of video conferencing has evolved that is focused on immersive “bei= ng there”=20 experience.  Referred to in various ways such as virtual conferencin= g,=20 telepresence or media spaces, early systems were mainly research projects= or=20 business systems with limited deployments.  In recent years telepres= ence=20 systems have seen considerable market success.  Following the model = of=20 early systems, the first wave of commercial systems have been typically=20 located in specially designed single-purpose rooms with multiple relative= ly=20 large displays permitting life size image reproduction, multiple cameras,= =20 encoders, decoders and microphones.  These systems have several impo= rtant=20 characteristics that are different from more traditional video conferenci= ng=20 systems. 

 

Th= e first=20 difference concerns controlling the visual viewpoint in order to improve= =20 participant nonverbal communication. These systems preserve essential gro= up=20 meeting characteristics such as eye contact, group gestures, seating orde= r and=20 spatial audio by carefully orchestrating the miking and camera angles at = each=20 of the sites . This is distinct from the more traditional approach where = the=20 geometric relationship between media streams is not used to preserve=20 inter-stream communication aspects such as eye contact and group=20 dynamics. 

 

A = second=20 difference is manipulation of the environment to improve immersion. = With=20 telepresence systems, cinematographic aspects of the local environment=20 reproduction are carefully planned including color, table shape, seating = and=20 lighting so that when combined with large high quality displays, a strong= =20 sense of a "trompe l'oeil" or "being there" immersive experience is=20 created.  Typical video conference systems do not include these=20 considerations.

 

As= =20 telepresence video systems have become successful in the market, manufact= urers=20 have started exploring delivery of the nonverbal communication and immers= ive=20 values of telepresence via smaller, less expensive and more flexible vide= o=20 conferencing systems for a variety of venues, such as individual offices,= =20 homes and kiosks. These are also  telepresence systems, since the au= dio=20 and video quality is high enough to allow clear image reproduction for=20 nonverbal communication, they are able to send and receive multiple media= =20 streams, and large coordinated multi image displays are available for=20 immersive installations.   As the industry develops, the line=20 between telepresence and video conferencing may become blurred as nonverb= al=20 communication and immersive installations become broadly=20 available.

 

Problem=

Al= though=20 telepresence systems are based on open standards such as RTP, SIP, H.264,= =20 H.323 suite, they cannot easily interoperate with each other without oper= ator=20 assistance and expensive additional equipment that translates from one ve= ndor=20 to another. It would be like having to make sure all parties are on the s= ame=20 equipment (and network) when making a telephone call.  A major facto= r in=20 the inability of Telepresence systems to work with each other is that the= re is=20 no standard description of the multiple streams that comprise the media f= lows.=20

 

Fo= r=20 example, in a multiple screen conference, the video and audio streams sen= t=20 from remote participants must be understood by receivers so that they can= be=20 presented in a coherent and life-like manner. This includes the ability t= o=20 present the remote participants at their true size for their apparent=20 distance, while maintaining correct eye contact, gesticular cues, and=20 simultaneously providing a spatial audio sound stage consistent with the = video=20 presentation.  The receiving device that decides how to display the= =20 incoming information needs to understand a number of variables such as th= e=20 spatial position of the speaker, the field of view of the cameras, the ca= mera=20 zoom, which media stream is related to each of the displays, etc.=20

 

Charter=

Th= e=20 Telepresence Multi-Streams work item in DISPATCH is chartered to define a= nd=20 specify the content of media multi-stream messages and the way these will= be=20 transported.

Th= is work=20 is aimed at providing a standard for the exchange of media semantics=20 information that will foster interoperable end stations and conference=20 bridges. This wo= rk item=20 will specify the variables that describe the semantics of the media strea= ms=20 and the recommended behavior to achieve interoperability. =20

 

Th= is=20 requires considering current widely deployed use cases, such as single an= d=20 multiple screens, multi-point, Scalable Video Coding (SVC), as well as ca= ses=20 that are expected to be implemented using the protocol framework produced= by=20 this work item.  The methodology for describing the variables must a= llow=20 extensibility of the variables, since telepresence is still a young techn= ology=20 and may have use cases that are not currently=20 considered.

 

Th= e work=20 item will identify use cases, define requirements, and define a method fo= r=20 describing and transporting information about multiple media streams,=20 including a specification of variables required to support the use cases.= This=20 work item will consider the reuse of existing IETF protocols and produce = an=20 architecture/protocol framework document describing the protocols require= d to=20 be implemented to support this functionality.  The document will ide= ntify=20 any enhancements required to existing protocols as well as describing new= =20 protocol(s) for interoperable multi-streams negotiation that may be=20 required.

 

Scope

Th= e scope=20 includes both systems that provide a fully immersive experience, and syst= ems=20 that interwork with them and therefore need to understand the same multip= le=20 stream semantics.

 

Th= e focus=20 of this work is on audio and video multiple streams, however other media = types=20 may be considered.  Definition of new application protocols is not w= ithin=20 the scope of this work

 

[I= s there=20 anything else we need to explicitly say is out of scope?]

 

The=20 group will produce

-= =20 Requirements and use cases

 

-= =20 Architectural Framework describing the protocols required to be implement= ed to=20 support this functionality and identifying existing protocol enhancements= and=20 new protocol functionality required

 

-= =20 Specification of a new protocol to support telepresence multi-streams [if= =20 required]

 

Goals=20 and Milestones

Nov=20 2010 <= /o:p>

Use=20 Cases and Requirements to IESG as Informational RFC <= /o:p>

March=20 2011 <= /o:p>

Architecture to IESG as= =20 Informational RFC <= /o:p>

March=20 2011<= /o:p>

Revise Charter [IF new= =20 protocol is not required]<= /o:p>

Nov=20 2011 <= /o:p>

Submit protocol draft t= o IESG=20 as Proposed Standard RFC <= /o:p>

 

 

 

 

--_000_B3F72E5548B10A4A8E6F4795430F8418320D5C4414NOKEUMSG02mgd_-- From peter.musgrave@magorcorp.com Wed May 19 04:23:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7ED3A6B1D for ; Wed, 19 May 2010 04:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.442 X-Spam-Level: X-Spam-Status: No, score=0.442 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I74RXhgnTThw for ; Wed, 19 May 2010 04:23:28 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 8B8963A69A3 for ; Wed, 19 May 2010 04:18:02 -0700 (PDT) Received: by gwb19 with SMTP id 19so3910161gwb.31 for ; Wed, 19 May 2010 04:17:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.235.15 with SMTP id i15mr9145275ybh.80.1274267871039; Wed, 19 May 2010 04:17:51 -0700 (PDT) Received: by 10.150.58.14 with HTTP; Wed, 19 May 2010 04:17:50 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0160CE8B@xmb-sjc-221.amer.cisco.com> Date: Wed, 19 May 2010 13:17:50 +0200 Message-ID: From: Peter Musgrave To: stephen botzko Content-Type: multipart/alternative; boundary=000e0cd292a6cd53c90486f09bb6 Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 11:23:30 -0000 --000e0cd292a6cd53c90486f09bb6 Content-Type: text/plain; charset=ISO-8859-1 Hi Stephen, I agree that backwards compatibility with existing TP systems should not be required. It seems we agree that SIP/SDP to talk to legacy video-conferencing is required, as is RTP for media transport. If you are thinking in terms of XMPP - would this be based on Jingle? Or is XMPP just for 'meta-data'? I struggle to see how the answer for the transport stuff could not be SIP based - since that allows the solution to build on the NAT traversal, TLS, SRTP stuff etc. which comes with that (unless you're thinking along the lines of ViPR type NAT-avoidance and p2p SIP). However, I don't see a need to restrict the charter to that if there are strong beliefs that other approaches need to be considered. However, the more the scope can be constrained at the start - the sooner protocol work would get done. I agree that there is a bunch of meta-data which may require dedicated connections. In general I'm finding that adding e.g. TCP in SDP for this fails since most SBCs do not relay TCP media. So some kind of conveyance for high rate metadata (speaker changes, view changes etc., collaboration material) needs to get solved. Maybe XMPP can fit here? (There is a charter floating around for a WG to address UAs which do both SIP and XMPP - not sure if this can be used here). Peter Musgrave [trimmed previous part of thread] --000e0cd292a6cd53c90486f09bb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Stephen,=A0

I agree that backwards compati= bility with existing TP systems should not be required. It seems we agree t= hat SIP/SDP to talk to legacy video-conferencing is required, as is RTP for= media transport.=A0

If you are thinking in terms of XMPP - would this be ba= sed on Jingle? Or is XMPP just for 'meta-data'?

I struggle to see how the answer for the transport stuff could not be= SIP based - since that allows the solution to build on the NAT traversal, = TLS, SRTP stuff etc. which comes with that (unless you're thinking alon= g the lines of ViPR type NAT-avoidance and p2p SIP). However, I don't s= ee a need to restrict the charter to that if there are strong beliefs that = other approaches need to be considered. However, the more the scope can be = constrained at the start - the sooner protocol work would get done.=A0

I agree that there is a bunch of meta-data which may re= quire dedicated connections. In general I'm finding that adding e.g. TC= P in SDP for this fails since most SBCs do not relay TCP media. So some kin= d of conveyance for high rate metadata (speaker changes, view changes etc.,= collaboration material) needs to get solved. Maybe XMPP can fit here? (The= re is a charter floating around for a WG to address UAs which do both SIP a= nd XMPP - not sure if this can be used here).=A0

Peter Musgrave


[trim= med previous part of thread]


--000e0cd292a6cd53c90486f09bb6-- From stephen.botzko@gmail.com Wed May 19 04:25:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B74928C150 for ; Wed, 19 May 2010 04:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKpyRF8mx7Bi for ; Wed, 19 May 2010 04:25:10 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id CE58F3A6C97 for ; Wed, 19 May 2010 04:19:34 -0700 (PDT) Received: by wwb24 with SMTP id 24so537031wwb.31 for ; Wed, 19 May 2010 04:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+y2f8vXyoc204C+Ju4cxJyBWObGxANCQr8t6Iy+338o=; b=WIDr3Bptl2Up9uhOYBnjzI5hHUWtUZLMCdWPcZvTXUcKHTtxfgi94y9Lw8a/9MUU1e 1eX1y57NhTSiaoyvn8uDdK4oAMqVMTHncAc4LMGHq4lN09UqUsllWjrpXiP9M/Ye7IVE vEo6laDC/6tHZmDbMVxdVmtdU7Qr8gJvsvzyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YO9JkuhkNkYRTBzMSYulbys9jTWGKn7Gn68B9dUnNwNctXWy9IjQCSVeEAwaejFaDP ErHVJ3RC66AaidNkROCBp8eFrx4MfdJcuV4htj/7VxaDofIWvG2hRSJ8Uuu5G5X6kOtL OE2sm/kthDwmIw5wJkl24BNZP6bSGYNBiMFPA= MIME-Version: 1.0 Received: by 10.216.90.13 with SMTP id d13mr1608464wef.18.1274267963899; Wed, 19 May 2010 04:19:23 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Wed, 19 May 2010 04:19:23 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> Date: Wed, 19 May 2010 07:19:23 -0400 Message-ID: From: stephen botzko To: Markus.Isomaki@nokia.com Content-Type: multipart/alternative; boundary=0016e6d7dff556402c0486f0a109 Cc: dispatch@ietf.org Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 11:25:13 -0000 --0016e6d7dff556402c0486f0a109 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Allyn and I co-chair the IMTC multi-streaming group. The IMTC would be delighted if the IETF takes on this work item. Regards Stephen Botzko On Wed, May 19, 2010 at 7:05 AM, wrote: > Hi Allyn, > > Cisco has recently open sourced under Apache license a protocol called > Telepresence Interoperability Protocol. Also IMTC (International Multimed= ia > Telecommunications Consortium) has setup an activity around TIP and > Telepresence [1]. Would this proposed IETF work be overlapping or orthogo= nal > to TIP and what IMTC is doing? > > It's natural that IETF RAI area is a good fit for this type of standards, > especially if we can take RTP, SIP, XMPP as the baseline. On the other ha= nd, > if a reasonable solution that is backed up by some major vendors is alrea= dy > being developed elsewhere, that will significantly shrik the succes chanc= es > of IETF being able to do something that will get deployed. > > Regards, > Markus > > [1] > http://blog.imtc.org/index.php/2010/03/09/announcing-the-creation-of-imtc= -telepresence-multi-streaming-activity-group/ > > > > ------------------------------ > *From:* dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] *On > Behalf Of *ext Allyn Romanow (allyn) > *Sent:* 18 May, 2010 21:30 > *To:* IETF DISPATCH list > *Subject:* [dispatch] Multi-streams for telepresence description of work > > Hi Folks, > > > > Many of you are aware of telepresence systems (video conferencing on > steroids..:), fewer probably are aware of the fact that the current syste= ms > are not interoperable with each other. After talking with Mary and Cullen= , > we have a rough draft of a charter to work on this problem in DISPATCH, = for > discussion on the mailing list. > > > > We don=92t yet know whether a working group would need to be spun out or = not > =96 that will be clarified as we go. > > > > We think there is enough background info in the work description to start= a > discussion, and plan to send out use cases for discussion shortly. > > > > Who is the we? Several makers and providers of telepresence systems have > gotten together to define the main problem in interoperability =96 the > handling of multi-streams. > > > > Thanks for your thoughts- > > Allyn > > > > > > *Multi-streams for Telepresence Description of Work* > > * * > > * * > > * * > > *Background* > > One branch of video conferencing has evolved that is focused on immersive > =93being there=94 experience. Referred to in various ways such as virtua= l > conferencing, telepresence or media spaces, early systems were mainly > research projects or business systems with limited deployments. In recen= t > years telepresence systems have seen considerable market success. Follow= ing > the model of early systems, the first wave of commercial systems have bee= n > typically located in specially designed single-purpose rooms with multipl= e > relatively large displays permitting life size image reproduction, multip= le > cameras, encoders, decoders and microphones. These systems have several > important characteristics that are different from more traditional video > conferencing systems. > > > > The first difference concerns controlling the visual viewpoint in order t= o > improve participant nonverbal communication. These systems preserve > essential group meeting characteristics such as eye contact, group gestur= es, > seating order and spatial audio by carefully orchestrating the miking and > camera angles at each of the sites . This is distinct from the more > traditional approach where the geometric relationship between media strea= ms > is not used to preserve inter-stream communication aspects such as eye > contact and group dynamics. > > > > A second difference is manipulation of the environment to improve > immersion. With telepresence systems, cinematographic aspects of the loc= al > environment reproduction are carefully planned including color, table sha= pe, > seating and lighting so that when combined with large high quality displa= ys, > a strong sense of a "trompe l'oeil" or "being there" immersive experience= is > created. Typical video conference systems do not include these > considerations. > > > > As telepresence video systems have become successful in the market, > manufacturers have started exploring delivery of the nonverbal communicat= ion > and immersive values of telepresence via smaller, less expensive and more > flexible video conferencing systems for a variety of venues, such as > individual offices, homes and kiosks. These are also telepresence system= s, > since the audio and video quality is high enough to allow clear image > reproduction for nonverbal communication, they are able to send and recei= ve > multiple media streams, and large coordinated multi image displays are > available for immersive installations. As the industry develops, the li= ne > between telepresence and video conferencing may become blurred as nonverb= al > communication and immersive installations become broadly available. > > > > *Problem* > > Although telepresence systems are based on open standards such as RTP, SI= P, > H.264, H.323 suite, they cannot easily interoperate with each other witho= ut > operator assistance and expensive additional equipment that translates fr= om > one vendor to another. It would be like having to make sure all parties a= re > on the same equipment (and network) when making a telephone call. A majo= r > factor in the inability of Telepresence systems to work with each other i= s > that there is no standard description of the multiple streams that compri= se > the media flows. > > > > For example, in a multiple screen conference, the video and audio streams > sent from remote participants must be understood by receivers so that the= y > can be presented in a coherent and life-like manner. This includes the > ability to present the remote participants at their true size for their > apparent distance, while maintaining correct eye contact, gesticular cues= , > and simultaneously providing a spatial audio sound stage consistent with = the > video presentation. The receiving device that decides how to display the > incoming information needs to understand a number of variables such as th= e > spatial position of the speaker, the field of view of the cameras, the > camera zoom, which media stream is related to each of the displays, etc. > > > > *Charter* > > The Telepresence Multi-Streams work item in DISPATCH is chartered to defi= ne > and specify the content of media multi-stream messages and the way these > will be transported. > > This work is aimed at providing a standard for the exchange of media > semantics information that will foster interoperable end stations and > conference bridges. This work item will specify the variables that > describe the semantics of the media streams and the recommended behavior = to > achieve interoperability. > > > > This requires considering current widely deployed use cases, such as sing= le > and multiple screens, multi-point, Scalable Video Coding (SVC), as well a= s > cases that are expected to be implemented using the protocol framework > produced by this work item. The methodology for describing the variables > must allow extensibility of the variables, since telepresence is still a > young technology and may have use cases that are not currently considered= . > > > > The work item will identify use cases, define requirements, and define a > method for describing and transporting information about multiple media > streams, including a specification of variables required to support the u= se > cases. This work item will consider the reuse of existing IETF protocols = and > produce an architecture/protocol framework document describing the protoc= ols > required to be implemented to support this functionality. The document w= ill > identify any enhancements required to existing protocols as well as > describing new protocol(s) for interoperable multi-streams negotiation th= at > may be required. > > > > *Scope* > > The scope includes both systems that provide a fully immersive experience= , > and systems that interwork with them and therefore need to understand the > same multiple stream semantics. > > > > The focus of this work is on audio and video multiple streams, however > other media types may be considered. Definition of new application > protocols is not within the scope of this work > > > > [Is there anything else we need to explicitly say is out of scope?]** > > > > *The group will produce* > > - Requirements and use cases > > > > - Architectural Framework describing the protocols required to be > implemented to support this functionality and identifying existing protoc= ol > enhancements and new protocol functionality required > > > > - Specification of a new protocol to support telepresence multi-streams [= if > required] > > > > *Goals and Milestones* > > Nov 2010 > > Use Cases and Requirements to IESG as Informational RFC > > March 2011 > > Architecture to IESG as Informational RFC > > March 2011 > > Revise Charter [IF new protocol is not required] > > Nov 2011 > > Submit protocol draft to IESG as Proposed Standard RFC > > > > > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --0016e6d7dff556402c0486f0a109 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Allyn and I co-chair the IMTC multi-streaming group.=A0 The IMTC would be d= elighted if the IETF takes on this work item.

Regards
Stephen Bot= zko

On Wed, May 19, 2010 at 7:05 AM, <Markus.Isoma= ki@nokia.com> wrote:
Hi Allyn,
=A0
Cisco has recently open sourced under Apache license a=20 protocol called Telepresence Interoperability Protocol. Also IMTC (Internat= ional=20 Multimedia Telecommunications Consortium) has setup=A0an activity around TI= P=20 and Telepresence [1]. Would this proposed IETF work be overlapping or ortho= gonal=20 to TIP and what IMTC is doing?
=A0
It's natural that IETF RAI area is a good fit for this=20 type of standards, especially if we can take RTP, SIP, XMPP as the baseline= . On=20 the other hand, if a reasonable solution that is backed up by some major ve= ndors=20 is already being developed elsewhere, that will significantly shrik the suc= ces=20 chances of IETF being able to=A0do something that will get deployed.=20
=A0
Regards,
=A0=A0=A0 Markus
=A0
=A0

From: dispatch-bounces@ietf.org=20 [mailto:di= spatch-bounces@ietf.org] On Behalf Of ext Allyn Romanow=20 (allyn)
Sent: 18 May, 2010 21:30
To: IETF DISPATCH=20 list
Subject: [dispatch] Multi-streams for telepresence descrip= tion=20 of work

Hi Folks,

=A0

Many of you are aware of telepresence systems (vid= eo=20 conferencing on steroids..:), fewer probably are aware of the fact that t= he=20 current systems are not interoperable with each other. After talking with= Mary=20 and Cullen, we have a rough draft of a charter to work on this problem in= =20 DISPATCH, =A0for discussion on the mailing list.

=A0

We don=92t yet know whether a working group would = need to be=20 spun out or not =96 that will be clarified as we go.

=A0

We think there is enough background info in the wo= rk=20 description to start a discussion, and plan to send out use cases for=20 discussion shortly.

=A0

Who is the we? Several makers and providers of tel= epresence=20 systems have gotten together to define the main problem in interoperabili= ty =96=20 the handling of multi-streams.

=A0

Thanks for your thoughts-

Allyn

=A0

=A0

= Multi-streams for Telepresence=20 Description of Work

= =A0

= =A0

=A0

Background

One branch=20 of video conferencing has evolved that is focused on immersive =93being t= here=94=20 experience.=A0 Referred to in various ways such as virtual conferencing,= =20 telepresence or media spaces, early systems were mainly research projects= or=20 business systems with limited deployments.=A0 In recent years telepresenc= e=20 systems have seen considerable market success.=A0 Following the model of= =20 early systems, the first wave of commercial systems have been typically= =20 located in specially designed single-purpose rooms with multiple relative= ly=20 large displays permitting life size image reproduction, multiple cameras,= =20 encoders, decoders and microphones.=A0 These systems have several importa= nt=20 characteristics that are different from more traditional video conferenci= ng=20 systems.=A0

=A0

The first=20 difference concerns controlling the visual viewpoint in order to improve= =20 participant nonverbal communication. These systems preserve essential gro= up=20 meeting characteristics such as eye contact, group gestures, seating orde= r and=20 spatial audio by carefully orchestrating the miking and camera angles at = each=20 of the sites . This is distinct from the more traditional approach where = the=20 geometric relationship between media streams is not used to preserve=20 inter-stream communication aspects such as eye contact and group=20 dynamics.=A0

=A0

A second=20 difference is manipulation of the environment to improve immersion.=A0 Wi= th=20 telepresence systems, cinematographic aspects of the local environment=20 reproduction are carefully planned including color, table shape, seating = and=20 lighting so that when combined with large high quality displays, a strong= =20 sense of a "trompe l'oeil" or "being there" immer= sive experience is=20 created.=A0 Typical video conference systems do not include these=20 considerations.

=A0

As=20 telepresence video systems have become successful in the market, manufact= urers=20 have started exploring delivery of the nonverbal communication and immers= ive=20 values of telepresence via smaller, less expensive and more flexible vide= o=20 conferencing systems for a variety of venues, such as individual offices,= =20 homes and kiosks. These are also=A0 telepresence systems, since the audio= =20 and video quality is high enough to allow clear image reproduction for=20 nonverbal communication, they are able to send and receive multiple media= =20 streams, and large coordinated multi image displays are available for=20 immersive installations.=A0=A0 As the industry develops, the line=20 between telepresence and video conferencing may become blurred as nonverb= al=20 communication and immersive installations become broadly=20 available.

=A0

Problem

Although=20 telepresence systems are based on open standards such as RTP, SIP, H.264,= =20 H.323 suite, they cannot easily interoperate with each other without oper= ator=20 assistance and expensive additional equipment that translates from one ve= ndor=20 to another. It would be like having to make sure all parties are on the s= ame=20 equipment (and network) when making a telephone call. =A0A major factor i= n=20 the inability of Telepresence systems to work with each other is that the= re is=20 no standard description of the multiple streams that comprise the media f= lows.=20

=A0

For=20 example, in a multiple screen conference, the video and audio streams sen= t=20 from remote participants must be understood by receivers so that they can= be=20 presented in a coherent and life-like manner. This includes the ability t= o=20 present the remote participants at their true size for their apparent=20 distance, while maintaining correct eye contact, gesticular cues, and=20 simultaneously providing a spatial audio sound stage consistent with the = video=20 presentation.=A0 The receiving device that decides how to display the=20 incoming information needs to understand a number of variables such as th= e=20 spatial position of the speaker, the field of view of the cameras, the ca= mera=20 zoom, which media stream is related to each of the displays, etc.=20

=A0

Charter

The=20 Telepresence Multi-Streams work item in DISPATCH is chartered to define a= nd=20 specify the content of media multi-stream messages and the way these will= be=20 transported.

This work=20 is aimed at providing a standard for the exchange of media semantics=20 information that will foster interoperable end stations and conference=20 bridges. This work item=20 will specify the variables that describe the semantics of the media strea= ms=20 and the recommended behavior to achieve interoperability.=A0=20

=A0

This=20 requires considering current widely deployed use cases, such as single an= d=20 multiple screens, multi-point, Scalable Video Coding (SVC), as well as ca= ses=20 that are expected to be implemented using the protocol framework produced= by=20 this work item.=A0 The methodology for describing the variables must allo= w=20 extensibility of the variables, since telepresence is still a young techn= ology=20 and may have use cases that are not currently=20 considered.

=A0

The work=20 item will identify use cases, define requirements, and define a method fo= r=20 describing and transporting information about multiple media streams,=20 including a specification of variables required to support the use cases.= This=20 work item will consider the reuse of existing IETF protocols and produce = an=20 architecture/protocol framework document describing the protocols require= d to=20 be implemented to support this functionality.=A0 The document will identi= fy=20 any enhancements required to existing protocols as well as describing new= =20 protocol(s) for interoperable multi-streams negotiation that may be=20 required.

=A0

Scope

The scope=20 includes both systems that provide a fully immersive experience, and syst= ems=20 that interwork with them and therefore need to understand the same multip= le=20 stream semantics.

=A0

The focus=20 of this work is on audio and video multiple streams, however other media = types=20 may be considered.=A0 Definition of new application protocols is not with= in=20 the scope of this work

=A0

[Is there=20 anything else we need to explicitly say is out of scope?]=

=A0

The=20 group will produce

-=20 Requirements and use cases

=A0

-=20 Architectural Framework describing the protocols required to be implement= ed to=20 support this functionality and identifying existing protocol enhancements= and=20 new protocol functionality required

=A0

-=20 Specification of a new protocol to support telepresence multi-streams [if= =20 required]

=A0

Goals=20 and Milestones

Nov=20 2010

Use=20 Cases and Requirements to IESG as Informational RFC

March=20 2011

Architecture to IESG as=20 Informational RFC

March=20 2011

Revise Charter [IF new=20 protocol is not required]

Nov=20 2011

Submit protocol draft to IESG=20 as Proposed Standard RFC

=A0

=A0

=A0

=A0


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


--0016e6d7dff556402c0486f0a109-- From Markus.Isomaki@nokia.com Wed May 19 04:31:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EB363A6C3C for ; Wed, 19 May 2010 04:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.843 X-Spam-Level: X-Spam-Status: No, score=-4.843 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpQlTNvSuqqB for ; Wed, 19 May 2010 04:30:51 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 9F35F3A6C41 for ; Wed, 19 May 2010 04:26:34 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4JBPt9j032494; Wed, 19 May 2010 14:26:20 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 May 2010 14:26:10 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 May 2010 14:26:09 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 May 2010 14:26:02 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 19 May 2010 13:26:02 +0200 From: To: Date: Wed, 19 May 2010 13:26:00 +0200 Thread-Topic: [dispatch] Multi-streams for telepresence description of work Thread-Index: Acr3RS3o9tlOpnC+RK2S5HOU/QI96gAAE14g Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B3F72E5548B10A4A8E6F4795430F8418320D5C4463NOKEUMSG02mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 19 May 2010 11:26:02.0838 (UTC) FILETIME=[10661F60:01CAF746] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 11:31:02 -0000 --_000_B3F72E5548B10A4A8E6F4795430F8418320D5C4463NOKEUMSG02mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That should make things smooth :) It would be good to explain the relationship and worksplit (between IETF an= d IMTC) explicitly in the charter. Markus ________________________________ From: ext stephen botzko [mailto:stephen.botzko@gmail.com] Sent: 19 May, 2010 14:19 To: Isomaki Markus (Nokia-CIC/Espoo) Cc: allyn@cisco.com; dispatch@ietf.org Subject: Re: [dispatch] Multi-streams for telepresence description of work Allyn and I co-chair the IMTC multi-streaming group. The IMTC would be del= ighted if the IETF takes on this work item. Regards Stephen Botzko On Wed, May 19, 2010 at 7:05 AM, > wrote: Hi Allyn, Cisco has recently open sourced under Apache license a protocol called Tele= presence Interoperability Protocol. Also IMTC (International Multimedia Tel= ecommunications Consortium) has setup an activity around TIP and Telepresen= ce [1]. Would this proposed IETF work be overlapping or orthogonal to TIP a= nd what IMTC is doing? It's natural that IETF RAI area is a good fit for this type of standards, e= specially if we can take RTP, SIP, XMPP as the baseline. On the other hand,= if a reasonable solution that is backed up by some major vendors is alread= y being developed elsewhere, that will significantly shrik the succes chanc= es of IETF being able to do something that will get deployed. Regards, Markus [1] http://blog.imtc.org/index.php/2010/03/09/announcing-the-creation-of-im= tc-telepresence-multi-streaming-activity-group/ ________________________________ From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of ex= t Allyn Romanow (allyn) Sent: 18 May, 2010 21:30 To: IETF DISPATCH list Subject: [dispatch] Multi-streams for telepresence description of work Hi Folks, Many of you are aware of telepresence systems (video conferencing on steroi= ds..:), fewer probably are aware of the fact that the current systems are n= ot interoperable with each other. After talking with Mary and Cullen, we ha= ve a rough draft of a charter to work on this problem in DISPATCH, for dis= cussion on the mailing list. We don't yet know whether a working group would need to be spun out or not = - that will be clarified as we go. We think there is enough background info in the work description to start a= discussion, and plan to send out use cases for discussion shortly. Who is the we? Several makers and providers of telepresence systems have go= tten together to define the main problem in interoperability - the handling= of multi-streams. Thanks for your thoughts- Allyn Multi-streams for Telepresence Description of Work Background One branch of video conferencing has evolved that is focused on immersive "= being there" experience. Referred to in various ways such as virtual confe= rencing, telepresence or media spaces, early systems were mainly research p= rojects or business systems with limited deployments. In recent years tele= presence systems have seen considerable market success. Following the mode= l of early systems, the first wave of commercial systems have been typicall= y located in specially designed single-purpose rooms with multiple relative= ly large displays permitting life size image reproduction, multiple cameras= , encoders, decoders and microphones. These systems have several important= characteristics that are different from more traditional video conferencin= g systems. The first difference concerns controlling the visual viewpoint in order to = improve participant nonverbal communication. These systems preserve essenti= al group meeting characteristics such as eye contact, group gestures, seati= ng order and spatial audio by carefully orchestrating the miking and camera= angles at each of the sites . This is distinct from the more traditional a= pproach where the geometric relationship between media streams is not used = to preserve inter-stream communication aspects such as eye contact and grou= p dynamics. A second difference is manipulation of the environment to improve immersion= . With telepresence systems, cinematographic aspects of the local environm= ent reproduction are carefully planned including color, table shape, seatin= g and lighting so that when combined with large high quality displays, a st= rong sense of a "trompe l'oeil" or "being there" immersive experience is cr= eated. Typical video conference systems do not include these consideration= s. As telepresence video systems have become successful in the market, manufac= turers have started exploring delivery of the nonverbal communication and i= mmersive values of telepresence via smaller, less expensive and more flexib= le video conferencing systems for a variety of venues, such as individual o= ffices, homes and kiosks. These are also telepresence systems, since the a= udio and video quality is high enough to allow clear image reproduction for= nonverbal communication, they are able to send and receive multiple media = streams, and large coordinated multi image displays are available for immer= sive installations. As the industry develops, the line between telepresen= ce and video conferencing may become blurred as nonverbal communication and= immersive installations become broadly available. Problem Although telepresence systems are based on open standards such as RTP, SIP,= H.264, H.323 suite, they cannot easily interoperate with each other withou= t operator assistance and expensive additional equipment that translates fr= om one vendor to another. It would be like having to make sure all parties = are on the same equipment (and network) when making a telephone call. A ma= jor factor in the inability of Telepresence systems to work with each other= is that there is no standard description of the multiple streams that comp= rise the media flows. For example, in a multiple screen conference, the video and audio streams s= ent from remote participants must be understood by receivers so that they c= an be presented in a coherent and life-like manner. This includes the abili= ty to present the remote participants at their true size for their apparent= distance, while maintaining correct eye contact, gesticular cues, and simu= ltaneously providing a spatial audio sound stage consistent with the video = presentation. The receiving device that decides how to display the incomin= g information needs to understand a number of variables such as the spatial= position of the speaker, the field of view of the cameras, the camera zoom= , which media stream is related to each of the displays, etc. Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to define= and specify the content of media multi-stream messages and the way these w= ill be transported. This work is aimed at providing a standard for the exchange of media semant= ics information that will foster interoperable end stations and conference = bridges. This work item will specify the variables that describe the semant= ics of the media streams and the recommended behavior to achieve interopera= bility. This requires considering current widely deployed use cases, such as single= and multiple screens, multi-point, Scalable Video Coding (SVC), as well as= cases that are expected to be implemented using the protocol framework pro= duced by this work item. The methodology for describing the variables must= allow extensibility of the variables, since telepresence is still a young = technology and may have use cases that are not currently considered. The work item will identify use cases, define requirements, and define a me= thod for describing and transporting information about multiple media strea= ms, including a specification of variables required to support the use case= s. This work item will consider the reuse of existing IETF protocols and pr= oduce an architecture/protocol framework document describing the protocols = required to be implemented to support this functionality. The document wil= l identify any enhancements required to existing protocols as well as descr= ibing new protocol(s) for interoperable multi-streams negotiation that may = be required. Scope The scope includes both systems that provide a fully immersive experience, = and systems that interwork with them and therefore need to understand the s= ame multiple stream semantics. The focus of this work is on audio and video multiple streams, however othe= r media types may be considered. Definition of new application protocols i= s not within the scope of this work [Is there anything else we need to explicitly say is out of scope?] The group will produce - Requirements and use cases - Architectural Framework describing the protocols required to be implement= ed to support this functionality and identifying existing protocol enhancem= ents and new protocol functionality required - Specification of a new protocol to support telepresence multi-streams [if= required] Goals and Milestones Nov 2010 Use Cases and Requirements to IESG as Informational RFC March 2011 Architecture to IESG as Informational RFC March 2011 Revise Charter [IF new protocol is not required] Nov 2011 Submit protocol draft to IESG as Proposed Standard RFC _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_B3F72E5548B10A4A8E6F4795430F8418320D5C4463NOKEUMSG02mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
That should make things smooth :)<= /DIV>
 
It would be good to explain the relationship and= =20 worksplit (between IETF and IMTC) explicitly in the charter.=20
 
Markus
 
 

From: ext stephen botzko=20 [mailto:stephen.botzko@gmail.com]
Sent: 19 May, 2010=20 14:19
To: Isomaki Markus (Nokia-CIC/Espoo)
Cc:=20 allyn@cisco.com; dispatch@ietf.org
Subject: Re: [dispatch]=20 Multi-streams for telepresence description of work

Allyn and I co-chair the IMTC multi-streaming group.  The= IMTC=20 would be delighted if the IETF takes on this work=20 item.

Regards
Stephen Botzko

On Wed, May 19, 2010 at 7:05 AM, <Markus.Isomaki@nokia.com>= =20 wrote:
Hi=20 Allyn,
 
Cisco=20 has recently open sourced under Apache license a protocol called=20 Telepresence Interoperability Protocol. Also IMTC (International Multim= edia=20 Telecommunications Consortium) has setup an activity around TIP an= d=20 Telepresence [1]. Would this proposed IETF work be overlapping or ortho= gonal=20 to TIP and what IMTC is doing?
 
It's=20 natural that IETF RAI area is a good fit for this type of standards,=20 especially if we can take RTP, SIP, XMPP as the baseline. On the other = hand,=20 if a reasonable solution that is backed up by some major vendors is alr= eady=20 being developed elsewhere, that will significantly shrik the succes cha= nces=20 of IETF being able to do something that will get deployed.=20
 
Regards,
    Markus
 
[1] http://blog.imtc.org/index.php/2010/03/09/announcing-th= e-creation-of-imtc-telepresence-multi-streaming-activity-group/<= /FONT>
 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ex= t Allyn=20 Romanow (allyn)
Sent: 18 May, 2010 21:30
To: IETF= =20 DISPATCH list
Subject: [dispatch] Multi-streams for telepre= sence=20 description of work

Hi Folks,

 

Many of you are aware of telepresence systems (v= ideo=20 conferencing on steroids..:), fewer probably are aware of the fact th= at=20 the current systems are not interoperable with each other. After talk= ing=20 with Mary and Cullen, we have a rough draft of a charter to work on t= his=20 problem in DISPATCH,  for discussion on the mailing list.

 

We don’t yet know whether a working group = would need to=20 be spun out or not – that will be clarified as we go.

 

We think there is enough background info in the = work=20 description to start a discussion, and plan to send out use cases for= =20 discussion shortly.

 

Who is the we? Several makers and providers of=20 telepresence systems have gotten together to define the main problem = in=20 interoperability – the handling of multi-streams.

 

Thanks for your thoughts-

Allyn

 

 

Multi-streams for Telepresence Description of= =20 Work

 

 

 

Background

One branch of video conferencing has evolv= ed that=20 is focused on immersive “being there” experience.  R= eferred to in=20 various ways such as virtual conferencing, telepresence or media spac= es,=20 early systems were mainly research projects or business systems with= =20 limited deployments.  In recent years telepresence systems have = seen=20 considerable market success.  Following the model of early syste= ms,=20 the first wave of commercial systems have been typically located in=20 specially designed single-purpose rooms with multiple relatively larg= e=20 displays permitting life size image reproduction, multiple cameras,=20 encoders, decoders and microphones.  These systems have several= =20 important characteristics that are different from more traditional vi= deo=20 conferencing systems. 

 

The first difference concerns controlling = the=20 visual viewpoint in order to improve participant nonverbal communicat= ion.=20 These systems preserve essential group meeting characteristics such a= s eye=20 contact, group gestures, seating order and spatial audio by carefully= =20 orchestrating the miking and camera angles at each of the sites . Thi= s is=20 distinct from the more traditional approach where the geometric=20 relationship between media streams is not used to preserve inter-stre= am=20 communication aspects such as eye contact and group dynamics. =20

 

A second difference is manipulation of the= =20 environment to improve immersion.  With telepresence systems,=20 cinematographic aspects of the local environment reproduction are=20 carefully planned including color, table shape, seating and lighting = so=20 that when combined with large high quality displays, a strong sense o= f a=20 "trompe l'oeil" or "being there" immersive experience is created.&nbs= p;=20 Typical video conference systems do not include these=20 considerations.

 

As telepresence video systems have become= =20 successful in the market, manufacturers have started exploring delive= ry of=20 the nonverbal communication and immersive values of telepresence via= =20 smaller, less expensive and more flexible video conferencing systems = for a=20 variety of venues, such as individual offices, homes and kiosks. Thes= e are=20 also  telepresence systems, since the audio and video quality is= high=20 enough to allow clear image reproduction for nonverbal communication,= they=20 are able to send and receive multiple media streams, and large coordi= nated=20 multi image displays are available for immersive=20 installations.   As the industry develops, the line between= =20 telepresence and video conferencing may become blurred as nonverbal=20 communication and immersive installations become broadly=20 available.

 

Problem

Although telepresence systems are based on= open=20 standards such as RTP, SIP, H.264, H.323 suite, they cannot easily=20 interoperate with each other without operator assistance and expensiv= e=20 additional equipment that translates from one vendor to another. It w= ould=20 be like having to make sure all parties are on the same equipment (an= d=20 network) when making a telephone call.  A major factor in the=20 inability of Telepresence systems to work with each other is that the= re is=20 no standard description of the multiple streams that comprise the med= ia=20 flows.

 

For example, in a multiple screen conferen= ce, the=20 video and audio streams sent from remote participants must be underst= ood=20 by receivers so that they can be presented in a coherent and life-lik= e=20 manner. This includes the ability to present the remote participants = at=20 their true size for their apparent distance, while maintaining correc= t eye=20 contact, gesticular cues, and simultaneously providing a spatial audi= o=20 sound stage consistent with the video presentation.  The receivi= ng=20 device that decides how to display the incoming information needs to= =20 understand a number of variables such as the spatial position of the= =20 speaker, the field of view of the cameras, the camera zoom, which med= ia=20 stream is related to each of the displays, etc.

 

Charter

The Telepresence Multi-Streams work item i= n=20 DISPATCH is chartered to define and specify the content of media=20 multi-stream messages and the way these will be transported. <= /P>

This work is aimed at providing a standard= for=20 the exchange of media semantics information that will foster interope= rable=20 end stations and conference bridges. This work item will= =20 specify the variables that describe the semantics of the media stream= s and=20 the recommended behavior to achieve interoperability. 

 

This requires considering current widely d= eployed=20 use cases, such as single and multiple screens, multi-point, Scalable= =20 Video Coding (SVC), as well as cases that are expected to be implemen= ted=20 using the protocol framework produced by this work item.  The=20 methodology for describing the variables must allow extensibility of = the=20 variables, since telepresence is still a young technology and may hav= e use=20 cases that are not currently considered.

 

The work item will identify use cases, def= ine=20 requirements, and define a method for describing and transporting=20 information about multiple media streams, including a specification o= f=20 variables required to support the use cases. This work item will cons= ider=20 the reuse of existing IETF protocols and produce an architecture/prot= ocol=20 framework document describing the protocols required to be implemente= d to=20 support this functionality.  The document will identify any=20 enhancements required to existing protocols as well as describing new= =20 protocol(s) for interoperable multi-streams negotiation that may be=20 required.

 

Scope

The scope includes both systems that provi= de a=20 fully immersive experience, and systems that interwork with them and= =20 therefore need to understand the same multiple stream=20 semantics.

 

The focus of this work is on audio and vid= eo=20 multiple streams, however other media types may be considered. = =20 Definition of new application protocols is not within the scope of th= is=20 work

 

[Is there anything else we need to explici= tly say=20 is out of scope?]

&nb= sp;

The group will produce

- Requirements and use cases

 

- Architectural Framework describing the=20 protocols required to be implemented to support this functionality an= d=20 identifying existing protocol enhancements and new protocol functiona= lity=20 required

 

- Specification of a new protocol to suppo= rt=20 telepresence multi-streams [if required]

 

Goals and Milestones

Nov 2010

Use Cases and Requirements to IESG a= s=20 Informational RFC

March 2011

Architecture to IESG as Informationa= l RFC=20

March 2011

Revise Charter [IF new protocol is n= ot=20 required]

Nov 2011

Submit protocol draft to IESG as Pro= posed=20 Standard RFC

 

 

 

 


__= _____________________________________________
dispatch=20 mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
<= BR>

--_000_B3F72E5548B10A4A8E6F4795430F8418320D5C4463NOKEUMSG02mgd_-- From stephen.botzko@gmail.com Wed May 19 04:40:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121253A6C5E for ; Wed, 19 May 2010 04:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsP4qTNWUGOk for ; Wed, 19 May 2010 04:40:47 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E99353A687B for ; Wed, 19 May 2010 04:38:43 -0700 (PDT) Received: by wwb24 with SMTP id 24so548883wwb.31 for ; Wed, 19 May 2010 04:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+GishtikD4JHCnpdG9UAldd9NunJXxWs9RugNGOosp8=; b=bNIofWRAn2dnwiRKG7RVhZNpMd13K+aG2qbUsOUS7q79FxwyLSSvRUA//8EW/NHn4h Nq8CnaVDYIjOhM1jKD7lgaEECR2cK+IPGxLsif3Avpl/PmIO/s9KnuaSkvy5fWPnTQId rlIrcEnZLPooeXE0AzT9LdvcFdqXib9LNeQLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RSZWbfoLp6y9kctjanB7I+070X+6QRthsxEXKWt9fQ5tyicQqtBlplS0YVQopVTxJO 1khECAyRnAIwQIVB4xi2a0RYPKHXreqjDkRAaEVXMGOAsmuPzLklrJ1lfG8KPZvtU9aT r97nZ4iBeGWlM3XBOZq25CorYlz3Ts16yNxKA= MIME-Version: 1.0 Received: by 10.216.85.75 with SMTP id t53mr5013228wee.20.1274269113667; Wed, 19 May 2010 04:38:33 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Wed, 19 May 2010 04:38:33 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0160CE8B@xmb-sjc-221.amer.cisco.com> Date: Wed, 19 May 2010 07:38:33 -0400 Message-ID: From: stephen botzko To: Peter Musgrave Content-Type: multipart/alternative; boundary=0016e6dab037de52620486f0e567 Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 11:40:48 -0000 --0016e6dab037de52620486f0e567 Content-Type: text/plain; charset=ISO-8859-1 Personally I agree that the transport for media should be SIP based, since I think it is problematic One challenge for multi-way streaming is that in multi-way calls the endpoints (and perhaps the intermediate infrastructure) are not receiving all the streams. It is desirable for these devices to be able to "see" the stream semantics, especially if this or future work includes the ability to request streams. Also in a multi-way call you have the late joiner use case. If you signal the stream semantics over SDP, then each source needs to be able to re-send its stream semantics (or there needs to be a lot of state in the infrastructure). This led me to wonder about the use of a presence protocol for signaling the stream semantics. I have not fully analyzed its implications, and it may turn out to be a bad idea. Regards, Stephen Botzko On Wed, May 19, 2010 at 7:17 AM, Peter Musgrave < peter.musgrave@magorcorp.com> wrote: > Hi Stephen, > > I agree that backwards compatibility with existing TP systems should not be > required. It seems we agree that SIP/SDP to talk to legacy > video-conferencing is required, as is RTP for media transport. > > If you are thinking in terms of XMPP - would this be based on Jingle? Or is > XMPP just for 'meta-data'? > > I struggle to see how the answer for the transport stuff could not be SIP > based - since that allows the solution to build on the NAT traversal, TLS, > SRTP stuff etc. which comes with that (unless you're thinking along the > lines of ViPR type NAT-avoidance and p2p SIP). However, I don't see a need > to restrict the charter to that if there are strong beliefs that other > approaches need to be considered. However, the more the scope can be > constrained at the start - the sooner protocol work would get done. > > I agree that there is a bunch of meta-data which may require dedicated > connections. In general I'm finding that adding e.g. TCP in SDP for this > fails since most SBCs do not relay TCP media. So some kind of conveyance for > high rate metadata (speaker changes, view changes etc., collaboration > material) needs to get solved. Maybe XMPP can fit here? (There is a charter > floating around for a WG to address UAs which do both SIP and XMPP - not > sure if this can be used here). > > Peter Musgrave > > > [trimmed previous part of thread] > > > --0016e6dab037de52620486f0e567 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Personally I agree that the transport for media should be SIP based, since = I think it is problematic

One challenge for multi-way streaming is t= hat in multi-way calls the endpoints (and perhaps the intermediate infrastr= ucture) are not receiving all the streams.=A0 It is desirable for these dev= ices to be able to "see" the stream semantics, especially if this= or future work includes the ability to request streams.

Also in a multi-way call you have the late joiner use case.=A0 If you s= ignal the stream semantics over SDP, then each source needs to be able to r= e-send its stream semantics (or there needs to be a lot of state in the inf= rastructure).

This led me to wonder about the use of a presence protocol for signalin= g the stream semantics. I have not fully analyzed its implications, and it = may turn out to be a bad idea.=A0

Regards,
Stephen Botzko
On Wed, May 19, 2010 at 7:17 AM, Peter Musgrave = <peter= .musgrave@magorcorp.com> wrote:
Hi Stephen,=A0

I agree that backwards compati= bility with existing TP systems should not be required. It seems we agree t= hat SIP/SDP to talk to legacy video-conferencing is required, as is RTP for= media transport.=A0

If you are thinking in terms of XMPP - would this be ba= sed on Jingle? Or is XMPP just for 'meta-data'?

I struggle to see how the answer for the transport stuff could not be= SIP based - since that allows the solution to build on the NAT traversal, = TLS, SRTP stuff etc. which comes with that (unless you're thinking alon= g the lines of ViPR type NAT-avoidance and p2p SIP). However, I don't s= ee a need to restrict the charter to that if there are strong beliefs that = other approaches need to be considered. However, the more the scope can be = constrained at the start - the sooner protocol work would get done.=A0

I agree that there is a bunch of meta-data which may re= quire dedicated connections. In general I'm finding that adding e.g. TC= P in SDP for this fails since most SBCs do not relay TCP media. So some kin= d of conveyance for high rate metadata (speaker changes, view changes etc.,= collaboration material) needs to get solved. Maybe XMPP can fit here? (The= re is a charter floating around for a WG to address UAs which do both SIP a= nd XMPP - not sure if this can be used here).=A0

Peter Musgrave


[trim= med previous part of thread]



--0016e6dab037de52620486f0e567-- From stephen.botzko@gmail.com Wed May 19 04:56:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DED53A6C24 for ; Wed, 19 May 2010 04:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voloLqi-yCpQ for ; Wed, 19 May 2010 04:56:15 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 5CA913A6C04 for ; Wed, 19 May 2010 04:55:58 -0700 (PDT) Received: by wwb24 with SMTP id 24so560653wwb.31 for ; Wed, 19 May 2010 04:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=r065gv9hsuc4tsyfKz9wVJOagTHzhTvjEe7Xbet0jKs=; b=AeBmnQMRZx0Owa/b+mz1ieHvfnDyD7/0lY5fXiDvHebWueopBsZCYiR96EfEPbZkBF M1egQEKyGeOlz6fp8IoM7R7no3HydqlCKttBt3M+ee8lE+rAMoNFmg1XTDPT2qDENola sjbo2iyAtPsfac464cLvRTHOtn1+Fi01S5F0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AU5DzdbM+kIhyczwptdaTJG5IUnmkTNMUmFSLZPyMzHaAOhVTW8SkJdtZL0pULvq3r cH/RuW/2B5B53FJuFReLOBJ+IBQ1AhzLPrDhr36M7AKUC5HS3yYmdIj4uqjpAkEYMoMZ B8afOScRxI0TzW2t3ZxXHMKwMshClkW0P8CtQ= MIME-Version: 1.0 Received: by 10.216.187.194 with SMTP id y44mr5040987wem.28.1274270146330; Wed, 19 May 2010 04:55:46 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Wed, 19 May 2010 04:55:46 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0160CE8B@xmb-sjc-221.amer.cisco.com> Date: Wed, 19 May 2010 07:55:46 -0400 Message-ID: From: stephen botzko To: Peter Musgrave Content-Type: multipart/alternative; boundary=00163683351e6b82250486f123ec Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 11:56:16 -0000 --00163683351e6b82250486f123ec Content-Type: text/plain; charset=ISO-8859-1 Sorry about the first sentence, I accidentally hit send before I was done... It should have been: Personally I agree that the solution should be based on SIP. Regards, Stephen Botzko On Wed, May 19, 2010 at 7:38 AM, stephen botzko wrote: > Personally I agree that the transport for media should be SIP based, since > I think it is problematic > > One challenge for multi-way streaming is that in multi-way calls the > endpoints (and perhaps the intermediate infrastructure) are not receiving > all the streams. It is desirable for these devices to be able to "see" the > stream semantics, especially if this or future work includes the ability to > request streams. > > Also in a multi-way call you have the late joiner use case. If you signal > the stream semantics over SDP, then each source needs to be able to re-send > its stream semantics (or there needs to be a lot of state in the > infrastructure). > > This led me to wonder about the use of a presence protocol for signaling > the stream semantics. I have not fully analyzed its implications, and it may > turn out to be a bad idea. > > Regards, > Stephen Botzko > > > On Wed, May 19, 2010 at 7:17 AM, Peter Musgrave < > peter.musgrave@magorcorp.com> wrote: > >> Hi Stephen, >> >> I agree that backwards compatibility with existing TP systems should not >> be required. It seems we agree that SIP/SDP to talk to legacy >> video-conferencing is required, as is RTP for media transport. >> >> If you are thinking in terms of XMPP - would this be based on Jingle? Or >> is XMPP just for 'meta-data'? >> >> I struggle to see how the answer for the transport stuff could not be SIP >> based - since that allows the solution to build on the NAT traversal, TLS, >> SRTP stuff etc. which comes with that (unless you're thinking along the >> lines of ViPR type NAT-avoidance and p2p SIP). However, I don't see a need >> to restrict the charter to that if there are strong beliefs that other >> approaches need to be considered. However, the more the scope can be >> constrained at the start - the sooner protocol work would get done. >> >> I agree that there is a bunch of meta-data which may require dedicated >> connections. In general I'm finding that adding e.g. TCP in SDP for this >> fails since most SBCs do not relay TCP media. So some kind of conveyance for >> high rate metadata (speaker changes, view changes etc., collaboration >> material) needs to get solved. Maybe XMPP can fit here? (There is a charter >> floating around for a WG to address UAs which do both SIP and XMPP - not >> sure if this can be used here). >> >> Peter Musgrave >> >> >> [trimmed previous part of thread] >> >> >> > --00163683351e6b82250486f123ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry about the first sentence, I accidentally hit send before I was done..= .

It should have been: Personally I agree that the solution should b= e based on SIP.

Regards,
Stephen Botzko

On Wed, May 19, 2010 at 7:38 AM, stephen botzko <stephen.botzko@gmail.com> wrote:
Personally I agree that the transport for media should be SIP based, since = I think it is problematic

One challenge for multi-way streaming is t= hat in multi-way calls the endpoints (and perhaps the intermediate infrastr= ucture) are not receiving all the streams.=A0 It is desirable for these dev= ices to be able to "see" the stream semantics, especially if this= or future work includes the ability to request streams.

Also in a multi-way call you have the late joiner use case.=A0 If you s= ignal the stream semantics over SDP, then each source needs to be able to r= e-send its stream semantics (or there needs to be a lot of state in the inf= rastructure).

This led me to wonder about the use of a presence protocol for signalin= g the stream semantics. I have not fully analyzed its implications, and it = may turn out to be a bad idea.=A0

Regards,
Stephen Botzko


On Wed, May 19, 2010 at 7:17 AM, Peter Musgrave = <peter.musgrave@magorcorp.com> wrote:
Hi Stephen,=A0

I agree that backwards compati= bility with existing TP systems should not be required. It seems we agree t= hat SIP/SDP to talk to legacy video-conferencing is required, as is RTP for= media transport.=A0

If you are thinking in terms of XMPP - would this be ba= sed on Jingle? Or is XMPP just for 'meta-data'?

I struggle to see how the answer for the transport stuff could not be= SIP based - since that allows the solution to build on the NAT traversal, = TLS, SRTP stuff etc. which comes with that (unless you're thinking alon= g the lines of ViPR type NAT-avoidance and p2p SIP). However, I don't s= ee a need to restrict the charter to that if there are strong beliefs that = other approaches need to be considered. However, the more the scope can be = constrained at the start - the sooner protocol work would get done.=A0

I agree that there is a bunch of meta-data which may re= quire dedicated connections. In general I'm finding that adding e.g. TC= P in SDP for this fails since most SBCs do not relay TCP media. So some kin= d of conveyance for high rate metadata (speaker changes, view changes etc.,= collaboration material) needs to get solved. Maybe XMPP can fit here? (The= re is a charter floating around for a WG to address UAs which do both SIP a= nd XMPP - not sure if this can be used here).=A0

Peter Musgrave


[trim= med previous part of thread]




--00163683351e6b82250486f123ec-- From john.elwell@siemens-enterprise.com Wed May 19 06:30:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 656AF28C14F for ; Wed, 19 May 2010 06:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbUPK1vX6Zgj for ; Wed, 19 May 2010 06:30:32 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id B4F1E28C18A for ; Wed, 19 May 2010 06:23:29 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-222853; Wed, 19 May 2010 15:23:21 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 8CD7223F028E; Wed, 19 May 2010 15:23:21 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 19 May 2010 15:23:21 +0200 From: "Elwell, John" To: "Allyn Romanow (allyn)" , IETF DISPATCH list Date: Wed, 19 May 2010 15:23:18 +0200 Thread-Topic: Multi-streams for telepresence description of work Thread-Index: Acr2uCFZ+eckhAOrTo2gjbFeNJpM3QAna0Sw Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 13:30:33 -0000 Allyn, I think this work has at least to support the co-existence of legacy video = endpoints and TP endpoints in the same conference. I assume the work will cover point-to-point (two party) calls also, not jus= t conferences. I think it is premature to include a new protocol document in the charter a= t this stage. It could be that work will only require extensions to existin= g protocols, which would better be done in existing groups such as MMUSIC, = AVT, XCON, XMPP. I think we need some progress with the architecture before= making that determination. John =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) > Sent: 18 May 2010 19:30 > To: IETF DISPATCH list > Subject: [dispatch] Multi-streams for telepresence description of work >=20 > Hi Folks, >=20 > =20 >=20 > Many of you are aware of telepresence systems (video=20 > conferencing on steroids..:), fewer probably are aware of the=20 > fact that the current systems are not interoperable with each=20 > other. After talking with Mary and Cullen, we have a rough=20 > draft of a charter to work on this problem in DISPATCH, for=20 > discussion on the mailing list. >=20 > =20 >=20 > We don't yet know whether a working group would need to be=20 > spun out or not - that will be clarified as we go. >=20 > =20 >=20 > We think there is enough background info in the work=20 > description to start a discussion, and plan to send out use=20 > cases for discussion shortly. >=20 > =20 >=20 > Who is the we? Several makers and providers of telepresence=20 > systems have gotten together to define the main problem in=20 > interoperability - the handling of multi-streams. >=20 > =20 >=20 > Thanks for your thoughts- >=20 > Allyn >=20 > =20 >=20 > =20 >=20 > Multi-streams for Telepresence Description of Work >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Background >=20 > One branch of video conferencing has evolved that is focused=20 > on immersive "being there" experience. Referred to in=20 > various ways such as virtual conferencing, telepresence or=20 > media spaces, early systems were mainly research projects or=20 > business systems with limited deployments. In recent years=20 > telepresence systems have seen considerable market success. =20 > Following the model of early systems, the first wave of=20 > commercial systems have been typically located in specially=20 > designed single-purpose rooms with multiple relatively large=20 > displays permitting life size image reproduction, multiple=20 > cameras, encoders, decoders and microphones. These systems=20 > have several important characteristics that are different=20 > from more traditional video conferencing systems. =20 >=20 > =20 >=20 > The first difference concerns controlling the visual=20 > viewpoint in order to improve participant nonverbal=20 > communication. These systems preserve essential group meeting=20 > characteristics such as eye contact, group gestures, seating=20 > order and spatial audio by carefully orchestrating the miking=20 > and camera angles at each of the sites . This is distinct=20 > from the more traditional approach where the geometric=20 > relationship between media streams is not used to preserve=20 > inter-stream communication aspects such as eye contact and=20 > group dynamics. =20 >=20 > =20 >=20 > A second difference is manipulation of the environment to=20 > improve immersion. With telepresence systems,=20 > cinematographic aspects of the local environment reproduction=20 > are carefully planned including color, table shape, seating=20 > and lighting so that when combined with large high quality=20 > displays, a strong sense of a "trompe l'oeil" or "being=20 > there" immersive experience is created. Typical video=20 > conference systems do not include these considerations. >=20 > =20 >=20 > As telepresence video systems have become successful in the=20 > market, manufacturers have started exploring delivery of the=20 > nonverbal communication and immersive values of telepresence=20 > via smaller, less expensive and more flexible video=20 > conferencing systems for a variety of venues, such as=20 > individual offices, homes and kiosks. These are also =20 > telepresence systems, since the audio and video quality is=20 > high enough to allow clear image reproduction for nonverbal=20 > communication, they are able to send and receive multiple=20 > media streams, and large coordinated multi image displays are=20 > available for immersive installations. As the industry=20 > develops, the line between telepresence and video=20 > conferencing may become blurred as nonverbal communication=20 > and immersive installations become broadly available. >=20 > =20 >=20 > Problem >=20 > Although telepresence systems are based on open standards=20 > such as RTP, SIP, H.264, H.323 suite, they cannot easily=20 > interoperate with each other without operator assistance and=20 > expensive additional equipment that translates from one=20 > vendor to another. It would be like having to make sure all=20 > parties are on the same equipment (and network) when making a=20 > telephone call. A major factor in the inability of=20 > Telepresence systems to work with each other is that there is=20 > no standard description of the multiple streams that comprise=20 > the media flows.=20 >=20 > =20 >=20 > For example, in a multiple screen conference, the video and=20 > audio streams sent from remote participants must be=20 > understood by receivers so that they can be presented in a=20 > coherent and life-like manner. This includes the ability to=20 > present the remote participants at their true size for their=20 > apparent distance, while maintaining correct eye contact,=20 > gesticular cues, and simultaneously providing a spatial audio=20 > sound stage consistent with the video presentation. The=20 > receiving device that decides how to display the incoming=20 > information needs to understand a number of variables such as=20 > the spatial position of the speaker, the field of view of the=20 > cameras, the camera zoom, which media stream is related to=20 > each of the displays, etc.=20 >=20 > =20 >=20 > Charter >=20 > The Telepresence Multi-Streams work item in DISPATCH is=20 > chartered to define and specify the content of media=20 > multi-stream messages and the way these will be transported.=20 >=20 > This work is aimed at providing a standard for the exchange=20 > of media semantics information that will foster interoperable=20 > end stations and conference bridges. This work item will=20 > specify the variables that describe the semantics of the=20 > media streams and the recommended behavior to achieve=20 > interoperability. =20 >=20 > =20 >=20 > This requires considering current widely deployed use cases,=20 > such as single and multiple screens, multi-point, Scalable=20 > Video Coding (SVC), as well as cases that are expected to be=20 > implemented using the protocol framework produced by this=20 > work item. The methodology for describing the variables must=20 > allow extensibility of the variables, since telepresence is=20 > still a young technology and may have use cases that are not=20 > currently considered. >=20 > =20 >=20 > The work item will identify use cases, define requirements,=20 > and define a method for describing and transporting=20 > information about multiple media streams, including a=20 > specification of variables required to support the use cases.=20 > This work item will consider the reuse of existing IETF=20 > protocols and produce an architecture/protocol framework=20 > document describing the protocols required to be implemented=20 > to support this functionality. The document will identify=20 > any enhancements required to existing protocols as well as=20 > describing new protocol(s) for interoperable multi-streams=20 > negotiation that may be required. >=20 > =20 >=20 > Scope >=20 > The scope includes both systems that provide a fully=20 > immersive experience, and systems that interwork with them=20 > and therefore need to understand the same multiple stream semantics. >=20 > =20 >=20 > The focus of this work is on audio and video multiple=20 > streams, however other media types may be considered. =20 > Definition of new application protocols is not within the=20 > scope of this work >=20 > =20 >=20 > [Is there anything else we need to explicitly say is out of scope?] >=20 > =20 >=20 > The group will produce >=20 > - Requirements and use cases >=20 > =20 >=20 > - Architectural Framework describing the protocols required=20 > to be implemented to support this functionality and=20 > identifying existing protocol enhancements and new protocol=20 > functionality required >=20 > =20 >=20 > - Specification of a new protocol to support telepresence=20 > multi-streams [if required] >=20 > =20 >=20 > Goals and Milestones >=20 > Nov 2010=20 >=20 > Use Cases and Requirements to IESG as Informational RFC=20 >=20 > =09 > March 2011=20 >=20 > Architecture to IESG as Informational RFC=20 >=20 > =09 > March 2011 >=20 > Revise Charter [IF new protocol is not required] >=20 > =09 > Nov 2011=20 >=20 > Submit protocol draft to IESG as Proposed Standard RFC=20 >=20 > =09 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > = From tme@americafree.tv Wed May 19 06:48:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BB93A6A2C for ; Wed, 19 May 2010 06:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.476 X-Spam-Level: X-Spam-Status: No, score=-100.476 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVwgUo3aDmVz for ; Wed, 19 May 2010 06:48:45 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id EDFBB28C0CF for ; Wed, 19 May 2010 06:45:16 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id CF2F37371317; Wed, 19 May 2010 09:45:09 -0400 (EDT) Message-Id: <5FFEBE77-E5C6-46A1-80CC-B685123E8148@americafree.tv> From: Marshall Eubanks To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 May 2010 09:45:09 -0400 References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> X-Mailer: Apple Mail (2.936) Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 13:48:47 -0000 On May 19, 2010, at 9:23 AM, Elwell, John wrote: > Allyn, > > I think this work has at least to support the co-existence of legacy > video endpoints and TP endpoints in the same conference. Do you mean that it should support interop between purely H.323 units and SIP based units ? Regards Marshall > > I assume the work will cover point-to-point (two party) calls also, > not just conferences. > > I think it is premature to include a new protocol document in the > charter at this stage. It could be that work will only require > extensions to existing protocols, which would better be done in > existing groups such as MMUSIC, AVT, XCON, XMPP. I think we need > some progress with the architecture before making that determination. > > John > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) >> Sent: 18 May 2010 19:30 >> To: IETF DISPATCH list >> Subject: [dispatch] Multi-streams for telepresence description of >> work >> >> Hi Folks, >> >> >> >> Many of you are aware of telepresence systems (video >> conferencing on steroids..:), fewer probably are aware of the >> fact that the current systems are not interoperable with each >> other. After talking with Mary and Cullen, we have a rough >> draft of a charter to work on this problem in DISPATCH, for >> discussion on the mailing list. >> >> >> >> We don't yet know whether a working group would need to be >> spun out or not - that will be clarified as we go. >> >> >> >> We think there is enough background info in the work >> description to start a discussion, and plan to send out use >> cases for discussion shortly. >> >> >> >> Who is the we? Several makers and providers of telepresence >> systems have gotten together to define the main problem in >> interoperability - the handling of multi-streams. >> >> >> >> Thanks for your thoughts- >> >> Allyn >> >> >> >> >> >> Multi-streams for Telepresence Description of Work >> >> >> >> >> >> >> >> Background >> >> One branch of video conferencing has evolved that is focused >> on immersive "being there" experience. Referred to in >> various ways such as virtual conferencing, telepresence or >> media spaces, early systems were mainly research projects or >> business systems with limited deployments. In recent years >> telepresence systems have seen considerable market success. >> Following the model of early systems, the first wave of >> commercial systems have been typically located in specially >> designed single-purpose rooms with multiple relatively large >> displays permitting life size image reproduction, multiple >> cameras, encoders, decoders and microphones. These systems >> have several important characteristics that are different >> from more traditional video conferencing systems. >> >> >> >> The first difference concerns controlling the visual >> viewpoint in order to improve participant nonverbal >> communication. These systems preserve essential group meeting >> characteristics such as eye contact, group gestures, seating >> order and spatial audio by carefully orchestrating the miking >> and camera angles at each of the sites . This is distinct >> from the more traditional approach where the geometric >> relationship between media streams is not used to preserve >> inter-stream communication aspects such as eye contact and >> group dynamics. >> >> >> >> A second difference is manipulation of the environment to >> improve immersion. With telepresence systems, >> cinematographic aspects of the local environment reproduction >> are carefully planned including color, table shape, seating >> and lighting so that when combined with large high quality >> displays, a strong sense of a "trompe l'oeil" or "being >> there" immersive experience is created. Typical video >> conference systems do not include these considerations. >> >> >> >> As telepresence video systems have become successful in the >> market, manufacturers have started exploring delivery of the >> nonverbal communication and immersive values of telepresence >> via smaller, less expensive and more flexible video >> conferencing systems for a variety of venues, such as >> individual offices, homes and kiosks. These are also >> telepresence systems, since the audio and video quality is >> high enough to allow clear image reproduction for nonverbal >> communication, they are able to send and receive multiple >> media streams, and large coordinated multi image displays are >> available for immersive installations. As the industry >> develops, the line between telepresence and video >> conferencing may become blurred as nonverbal communication >> and immersive installations become broadly available. >> >> >> >> Problem >> >> Although telepresence systems are based on open standards >> such as RTP, SIP, H.264, H.323 suite, they cannot easily >> interoperate with each other without operator assistance and >> expensive additional equipment that translates from one >> vendor to another. It would be like having to make sure all >> parties are on the same equipment (and network) when making a >> telephone call. A major factor in the inability of >> Telepresence systems to work with each other is that there is >> no standard description of the multiple streams that comprise >> the media flows. >> >> >> >> For example, in a multiple screen conference, the video and >> audio streams sent from remote participants must be >> understood by receivers so that they can be presented in a >> coherent and life-like manner. This includes the ability to >> present the remote participants at their true size for their >> apparent distance, while maintaining correct eye contact, >> gesticular cues, and simultaneously providing a spatial audio >> sound stage consistent with the video presentation. The >> receiving device that decides how to display the incoming >> information needs to understand a number of variables such as >> the spatial position of the speaker, the field of view of the >> cameras, the camera zoom, which media stream is related to >> each of the displays, etc. >> >> >> >> Charter >> >> The Telepresence Multi-Streams work item in DISPATCH is >> chartered to define and specify the content of media >> multi-stream messages and the way these will be transported. >> >> This work is aimed at providing a standard for the exchange >> of media semantics information that will foster interoperable >> end stations and conference bridges. This work item will >> specify the variables that describe the semantics of the >> media streams and the recommended behavior to achieve >> interoperability. >> >> >> >> This requires considering current widely deployed use cases, >> such as single and multiple screens, multi-point, Scalable >> Video Coding (SVC), as well as cases that are expected to be >> implemented using the protocol framework produced by this >> work item. The methodology for describing the variables must >> allow extensibility of the variables, since telepresence is >> still a young technology and may have use cases that are not >> currently considered. >> >> >> >> The work item will identify use cases, define requirements, >> and define a method for describing and transporting >> information about multiple media streams, including a >> specification of variables required to support the use cases. >> This work item will consider the reuse of existing IETF >> protocols and produce an architecture/protocol framework >> document describing the protocols required to be implemented >> to support this functionality. The document will identify >> any enhancements required to existing protocols as well as >> describing new protocol(s) for interoperable multi-streams >> negotiation that may be required. >> >> >> >> Scope >> >> The scope includes both systems that provide a fully >> immersive experience, and systems that interwork with them >> and therefore need to understand the same multiple stream semantics. >> >> >> >> The focus of this work is on audio and video multiple >> streams, however other media types may be considered. >> Definition of new application protocols is not within the >> scope of this work >> >> >> >> [Is there anything else we need to explicitly say is out of scope?] >> >> >> >> The group will produce >> >> - Requirements and use cases >> >> >> >> - Architectural Framework describing the protocols required >> to be implemented to support this functionality and >> identifying existing protocol enhancements and new protocol >> functionality required >> >> >> >> - Specification of a new protocol to support telepresence >> multi-streams [if required] >> >> >> >> Goals and Milestones >> >> Nov 2010 >> >> Use Cases and Requirements to IESG as Informational RFC >> >> >> March 2011 >> >> Architecture to IESG as Informational RFC >> >> >> March 2011 >> >> Revise Charter [IF new protocol is not required] >> >> >> Nov 2011 >> >> Submit protocol draft to IESG as Proposed Standard RFC >> >> >> >> >> >> >> >> >> >> >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From shida@ntt-at.com Wed May 19 07:04:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA1F3A685E for ; Wed, 19 May 2010 07:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ay4cWu4s7Hwj for ; Wed, 19 May 2010 07:04:01 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.236.22]) by core3.amsl.com (Postfix) with SMTP id 1416F3A6781 for ; Wed, 19 May 2010 07:04:01 -0700 (PDT) Received: (qmail 4218 invoked from network); 19 May 2010 14:07:31 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway07.websitewelcome.com with SMTP; 19 May 2010 14:07:31 -0000 Received: from flh1agc175.tky.mesh.ad.jp ([60.239.252.175]:52149 helo=[192.168.1.6]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1OEjsA-00040w-DB; Wed, 19 May 2010 09:03:46 -0500 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: Shida Schubert In-Reply-To: Date: Wed, 19 May 2010 23:03:50 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> To: Xavier Marjou X-Mailer: Apple Mail (2.1078) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 14:04:02 -0000 +1 On May 17, 2010, at 6:11 PM, Xavier Marjou wrote: > Hi, >=20 > I support the overall proposal of the two drafts. >=20 > Cheers, > Xavier >=20 >=20 >=20 > 2010/5/13 : >> Dear all, >> I have asked for comments on the two drafts mentioned below. >> So far I didn't get any. Does that mean that people are happy now = with the >> content and we could proceed with it? >>=20 >> Thank you and Best Regrads >>=20 >> Roland >>=20 >> _____________________________________________ >> Von: Jesske, Roland >> Gesendet: Donnerstag, 8. April 2010 09:46 >> An: dispatch@ietf.org >> Betreff: Reason In responses >> (draft-jesske-dispatch-reason-in-responses-02) >>=20 >> Dear all, >> During the discussion concerning the Reason header field in Responses = I was >> asked to split the document into an requirements part and an protocol = part. >>=20 >> So please feel free to comment on the drafts. >>=20 >> http://64.170.98.42/html/draft-jesske-dispatch-reason-in-responses-02 >>=20 >> = http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-responses-00 >>=20 >> Best regards >>=20 >> Roland Jesske >>=20 >> Deutsche Telekom Netzproduktion GmbH >> Zentrum Technik Einf=FChrung >> Roland Jesske >> Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt >> +49 6151 628-2766 (Tel.) >> +49 521 9210-3753 (Fax) >> +49 171 8618-445 (Mobil) >> E-Mail: r.jesske@telekom.de >> www.telekom.com >>=20 >> Erleben, was verbindet. >>=20 >> Deutsche Telekom Netzproduktion GmbH >> Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) >> Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, >> Klaus Peren >> Handelsregister: Amtsgericht Bonn HRB 14190 >> Sitz der Gesellschaft: Bonn >> USt-IdNr. DE 814645262 >>=20 >> Gro=DFe Ver=E4nderungen fangen klein an =96 Ressourcen schonen und = nicht jede >> E-Mail drucken. >>=20 >> _______________________________________________ >> 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 john.elwell@siemens-enterprise.com Wed May 19 07:04:40 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34ED3A690A for ; Wed, 19 May 2010 07:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEkzNgCBsSwL for ; Wed, 19 May 2010 07:04:39 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5465E3A6847 for ; Wed, 19 May 2010 07:04:36 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-224943; Wed, 19 May 2010 16:04:29 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 9FCFB23F028E; Wed, 19 May 2010 16:04:29 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 19 May 2010 16:04:29 +0200 From: "Elwell, John" To: Marshall Eubanks Date: Wed, 19 May 2010 16:04:27 +0200 Thread-Topic: [dispatch] Multi-streams for telepresence description of work Thread-Index: Acr3WYDeEjkOwcr/S5CZZ82fH5PnlQAAk9EA Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> <5FFEBE77-E5C6-46A1-80CC-B685123E8148@americafree.tv> In-Reply-To: <5FFEBE77-E5C6-46A1-80CC-B685123E8148@americafree.tv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 14:04:40 -0000 No, I meant co-existence of TP-aware and basic SIP video endpoints in the s= ame conference. If that is supported, then presumably existing SIP-H.323 ga= teways would be able to accommodate legacy H.323 endpoints too, but that wa= s not my primary concern. John=20 > -----Original Message----- > From: Marshall Eubanks [mailto:tme@americafree.tv]=20 > Sent: 19 May 2010 14:45 > To: Elwell, John > Cc: Allyn Romanow (allyn); IETF DISPATCH list > Subject: Re: [dispatch] Multi-streams for telepresence=20 > description of work >=20 >=20 > On May 19, 2010, at 9:23 AM, Elwell, John wrote: >=20 > > Allyn, > > > > I think this work has at least to support the co-existence=20 > of legacy =20 > > video endpoints and TP endpoints in the same conference. >=20 > Do you mean that it should support interop between purely=20 > H.323 units =20 > and SIP based units ? >=20 > Regards > Marshall >=20 > > > > I assume the work will cover point-to-point (two party)=20 > calls also, =20 > > not just conferences. > > > > I think it is premature to include a new protocol document in the =20 > > charter at this stage. It could be that work will only require =20 > > extensions to existing protocols, which would better be done in =20 > > existing groups such as MMUSIC, AVT, XCON, XMPP. I think we need =20 > > some progress with the architecture before making that=20 > determination. > > > > John > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn=20 > Romanow (allyn) > >> Sent: 18 May 2010 19:30 > >> To: IETF DISPATCH list > >> Subject: [dispatch] Multi-streams for telepresence description of =20 > >> work > >> > >> Hi Folks, > >> > >> > >> > >> Many of you are aware of telepresence systems (video > >> conferencing on steroids..:), fewer probably are aware of the > >> fact that the current systems are not interoperable with each > >> other. After talking with Mary and Cullen, we have a rough > >> draft of a charter to work on this problem in DISPATCH, for > >> discussion on the mailing list. > >> > >> > >> > >> We don't yet know whether a working group would need to be > >> spun out or not - that will be clarified as we go. > >> > >> > >> > >> We think there is enough background info in the work > >> description to start a discussion, and plan to send out use > >> cases for discussion shortly. > >> > >> > >> > >> Who is the we? Several makers and providers of telepresence > >> systems have gotten together to define the main problem in > >> interoperability - the handling of multi-streams. > >> > >> > >> > >> Thanks for your thoughts- > >> > >> Allyn > >> > >> > >> > >> > >> > >> Multi-streams for Telepresence Description of Work > >> > >> > >> > >> > >> > >> > >> > >> Background > >> > >> One branch of video conferencing has evolved that is focused > >> on immersive "being there" experience. Referred to in > >> various ways such as virtual conferencing, telepresence or > >> media spaces, early systems were mainly research projects or > >> business systems with limited deployments. In recent years > >> telepresence systems have seen considerable market success. > >> Following the model of early systems, the first wave of > >> commercial systems have been typically located in specially > >> designed single-purpose rooms with multiple relatively large > >> displays permitting life size image reproduction, multiple > >> cameras, encoders, decoders and microphones. These systems > >> have several important characteristics that are different > >> from more traditional video conferencing systems. > >> > >> > >> > >> The first difference concerns controlling the visual > >> viewpoint in order to improve participant nonverbal > >> communication. These systems preserve essential group meeting > >> characteristics such as eye contact, group gestures, seating > >> order and spatial audio by carefully orchestrating the miking > >> and camera angles at each of the sites . This is distinct > >> from the more traditional approach where the geometric > >> relationship between media streams is not used to preserve > >> inter-stream communication aspects such as eye contact and > >> group dynamics. > >> > >> > >> > >> A second difference is manipulation of the environment to > >> improve immersion. With telepresence systems, > >> cinematographic aspects of the local environment reproduction > >> are carefully planned including color, table shape, seating > >> and lighting so that when combined with large high quality > >> displays, a strong sense of a "trompe l'oeil" or "being > >> there" immersive experience is created. Typical video > >> conference systems do not include these considerations. > >> > >> > >> > >> As telepresence video systems have become successful in the > >> market, manufacturers have started exploring delivery of the > >> nonverbal communication and immersive values of telepresence > >> via smaller, less expensive and more flexible video > >> conferencing systems for a variety of venues, such as > >> individual offices, homes and kiosks. These are also > >> telepresence systems, since the audio and video quality is > >> high enough to allow clear image reproduction for nonverbal > >> communication, they are able to send and receive multiple > >> media streams, and large coordinated multi image displays are > >> available for immersive installations. As the industry > >> develops, the line between telepresence and video > >> conferencing may become blurred as nonverbal communication > >> and immersive installations become broadly available. > >> > >> > >> > >> Problem > >> > >> Although telepresence systems are based on open standards > >> such as RTP, SIP, H.264, H.323 suite, they cannot easily > >> interoperate with each other without operator assistance and > >> expensive additional equipment that translates from one > >> vendor to another. It would be like having to make sure all > >> parties are on the same equipment (and network) when making a > >> telephone call. A major factor in the inability of > >> Telepresence systems to work with each other is that there is > >> no standard description of the multiple streams that comprise > >> the media flows. > >> > >> > >> > >> For example, in a multiple screen conference, the video and > >> audio streams sent from remote participants must be > >> understood by receivers so that they can be presented in a > >> coherent and life-like manner. This includes the ability to > >> present the remote participants at their true size for their > >> apparent distance, while maintaining correct eye contact, > >> gesticular cues, and simultaneously providing a spatial audio > >> sound stage consistent with the video presentation. The > >> receiving device that decides how to display the incoming > >> information needs to understand a number of variables such as > >> the spatial position of the speaker, the field of view of the > >> cameras, the camera zoom, which media stream is related to > >> each of the displays, etc. > >> > >> > >> > >> Charter > >> > >> The Telepresence Multi-Streams work item in DISPATCH is > >> chartered to define and specify the content of media > >> multi-stream messages and the way these will be transported. > >> > >> This work is aimed at providing a standard for the exchange > >> of media semantics information that will foster interoperable > >> end stations and conference bridges. This work item will > >> specify the variables that describe the semantics of the > >> media streams and the recommended behavior to achieve > >> interoperability. > >> > >> > >> > >> This requires considering current widely deployed use cases, > >> such as single and multiple screens, multi-point, Scalable > >> Video Coding (SVC), as well as cases that are expected to be > >> implemented using the protocol framework produced by this > >> work item. The methodology for describing the variables must > >> allow extensibility of the variables, since telepresence is > >> still a young technology and may have use cases that are not > >> currently considered. > >> > >> > >> > >> The work item will identify use cases, define requirements, > >> and define a method for describing and transporting > >> information about multiple media streams, including a > >> specification of variables required to support the use cases. > >> This work item will consider the reuse of existing IETF > >> protocols and produce an architecture/protocol framework > >> document describing the protocols required to be implemented > >> to support this functionality. The document will identify > >> any enhancements required to existing protocols as well as > >> describing new protocol(s) for interoperable multi-streams > >> negotiation that may be required. > >> > >> > >> > >> Scope > >> > >> The scope includes both systems that provide a fully > >> immersive experience, and systems that interwork with them > >> and therefore need to understand the same multiple stream=20 > semantics. > >> > >> > >> > >> The focus of this work is on audio and video multiple > >> streams, however other media types may be considered. > >> Definition of new application protocols is not within the > >> scope of this work > >> > >> > >> > >> [Is there anything else we need to explicitly say is out of scope?] > >> > >> > >> > >> The group will produce > >> > >> - Requirements and use cases > >> > >> > >> > >> - Architectural Framework describing the protocols required > >> to be implemented to support this functionality and > >> identifying existing protocol enhancements and new protocol > >> functionality required > >> > >> > >> > >> - Specification of a new protocol to support telepresence > >> multi-streams [if required] > >> > >> > >> > >> Goals and Milestones > >> > >> Nov 2010 > >> > >> Use Cases and Requirements to IESG as Informational RFC > >> > >> =09 > >> March 2011 > >> > >> Architecture to IESG as Informational RFC > >> > >> =09 > >> March 2011 > >> > >> Revise Charter [IF new protocol is not required] > >> > >> =09 > >> Nov 2011 > >> > >> Submit protocol draft to IESG as Proposed Standard RFC > >> > >> =09 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > = From gonzalo.camarillo@ericsson.com Wed May 19 07:16:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3A328C0FD for ; Wed, 19 May 2010 07:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.922 X-Spam-Level: X-Spam-Status: No, score=-101.922 tagged_above=-999 required=5 tests=[AWL=-1.923, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ynhw4WM2UTC2 for ; Wed, 19 May 2010 07:16:44 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 899FE3A6BD2 for ; Wed, 19 May 2010 07:15:39 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-b4-4bf3f2828666 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 87.88.21861.282F3FB4; Wed, 19 May 2010 16:15:30 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 May 2010 16:15:30 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 May 2010 16:15:29 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9E8012986 for ; Wed, 19 May 2010 17:15:29 +0300 (EEST) Message-ID: <4BF3F281.8080102@ericsson.com> Date: Wed, 19 May 2010 17:15:29 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------050105000309070600010609" X-OriginalArrivalTime: 19 May 2010 14:15:29.0837 (UTC) FILETIME=[BC670DD0:01CAF75D] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Alert Info URNs - Revised charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 14:16:46 -0000 This is a multi-part message in MIME format. --------------050105000309070600010609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, thanks for all the good discussions around the Alert-Info URNs charter proposal. They actually helped clarify a few important concepts. I have revised the charter proposal taking into account all the feedback received (see attachment). Please, let me know if you are happy with this proposal so that I can get the IESG to review it. Thanks, Gonzalo --------------050105000309070600010609 Content-Type: text/plain; name="alert-info-charter-proposal.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="alert-info-charter-proposal.txt" The SIP Alert-Info URN (SAIU) working group is chartered to define a new URN-scheme that allows SIP to convey a particular alert indication using a name instead of a referenced URI. The Alert-Info URN addresses issues encountered in current systems that use the Alert-Info header field. RFC 3261 allows a user agent server to provide a specific ringing tone, which can be played to the calling user, as a reference (e.g., an HTTP URI) in the Alert-Info header. In some situations, the calling user may not be able to understand the meaning of the ringing tone being played. For example, a user from a given country may not be familiar with the tone used to indicate call waiting in another country. Similarly, a hearing impaired person may prefer to get a visual call waiting indication instead of a call waiting tone. RFC 3261 also allows a user agent client to provide a reference to a specific alerting tone, which can be played to the called user (e.g., tones for emergency announcements sent over PBX systems or over the local telephone network). As in the previous examples, in some situations, the calling user may not be able to understand the meaning of the alerting tone being played. These issues can be resolved with a mechanism for user agents to exchange this type of alerting information in a semantic way. For example, a user agent client instructed to inform its user about a call waiting service being provided can use the personalized tones that were previously configured by the user. Traditionally, SIP has used status codes to encode session state information (e.g., 180 Ringing). Status codes are used by SIP entities in an automatic fashion. The information this working group is concerned with is related to rendering and may not represent the state of the session. Additionally, the exchange of this information does not affect the way SIP entities process the session. That is why status codes are not an appropriate vehicle to encode this type of information. This working group will work on encoding this information in URNs. In addition to defining URNs that are associated to particular events (e.g., a call waiting service is being applied), this working group will also define URNs that describe the characteristics of the alerting to be applied (e.g., play a short tone followed by a long tone). There are a variety of non-interoperable URI conventions and proprietary Alert-Info header field parameters to provide this type of information today. A standardized set of Alert-Info URNs will increase SIP interoperability for this header field by replacing proprietary conventions. The group will produce a specification that: * describes the problem statement. * describes requirements and use cases. * defines an Alert-Info URN-scheme which allows to resolve the interoperability problems described in the use cases. * defines the specific Alert-Info URNs identifiers for some of the use cases above. The Alert-Info URN scheme must be open, so that additional Alert-Info URN identifiers can be defined later if necessary. Goals and Milestones ==================== Apr 2011 - Alert-Info URN specification to IESG (PS) --------------050105000309070600010609-- From allyn@cisco.com Wed May 19 08:49:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C9B3A6A4A for ; Wed, 19 May 2010 08:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTWOA3uJB5Wh for ; Wed, 19 May 2010 08:48:47 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0C76B3A68C5 for ; Wed, 19 May 2010 08:48:46 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAN2k80urR7Hu/2dsb2JhbACBP5wzcYgpnC+ZfYJPCoI3BIJ5R4w2 X-IronPort-AV: E=Sophos;i="4.53,264,1272844800"; d="scan'208,217";a="199634169" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 19 May 2010 15:48:38 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4JFmcJ2018367; Wed, 19 May 2010 15:48:38 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 May 2010 08:48:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: Bw2+ CHdq FWBP Fssk GQoC GaF3 HrCu Hu7V Iu6j N+LE OXFb OjuA PEwC Q/tv Sa13 Sfzq; 2; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnADsAbQBhAHIAawB1AHMALgBpAHMAbwBtAGEAawBpAEAAbgBvAGsAaQBhAC4AYwBvAG0A; Sosha1_v1; 7; {250553F5-8766-4BDF-8A79-08D74540E564}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 19 May 2010 15:48:33 GMT; UgBFADoAIABNAHUAbAB0AGkALQBzAHQAcgBlAGEAbQBzACAAZgBvAHIAIAB0AGUAbABlAHAAcgBlAHMAZQBuAGMAZQAgAGQAZQBzAGMAcgBpAHAAdABpAG8AbgAgAG8AZgAgAHcAbwByAGsA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAF76A.BF7B7AF1" x-cr-puzzleid: {250553F5-8766-4BDF-8A79-08D74540E564} Content-class: urn:content-classes:message Date: Wed, 19 May 2010 08:48:33 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0160CF89@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multi-streams for telepresence description of work Thread-Index: Acr2uCFZ+eckhAOrTo2gjbFeNJpM3QAh4QeQAAgd0PA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> From: "Allyn Romanow (allyn)" To: , X-OriginalArrivalTime: 19 May 2010 15:48:38.0738 (UTC) FILETIME=[BFA5AB20:01CAF76A] Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 15:49:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF76A.BF7B7AF1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Markus, =20 Thanks for bringing up these telepresence related activities, whose roles need to be clarified. The bottom line is that Cisco's TIP is not related to the proposed multi-stream work, and the IMTC Telepresence Activity Group is related and has had the goal of bringing proposed work definition, use cases and requirements, but NOT solution, to the IETF. =20 Cisco has indeed made its TIP protocol freely available. In fact the copyright is in the process of being given over to the IMTC, who will own it, manage it, and have change control. The IMTC has not yet announced how it will manage TIP. TIP is Cisco's way of doing telepresence signaling and media control. =20 At the same time, Cisco is also engaging in the development of a new open standard which we believe would most appropriately be developed within the IETF as the technology is based IETF protocols, RTP and SIP in particular. The IMTC is a multimedia industry consortium that does a lot of interoperability testing. Many vendors are members and individual non-members can participate in activities. This was a good place to begin to pull together thoughts on how existing standards can help interoperability and what is missing from them. Thus the Telepresence Activity Group was formed. Steve Botzko and myself are the co-chairs. The work of the TP AG has been to define the problem that could be worked on in the IETF. We have been consulting with Cullen and Mary from the beginning, and have been quite clear not to address potential solutions prior to working in the IETF. =20 Again, on the relationship with TIP, since TIP is Cisco's solution for media control, people from Cisco will undoubtedly suggest that what they feel are the most valuable parts of the TIP technology are not discluded from a standard, but no more so than what people from other existing solutions are likely to do. People bring to the table their experience and expertise.=20 =20 I hope this clarifies.. it's potentially quite confusing. Please ask any further questions that come up. =20 Best regards, Allyn =20 From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 Sent: Wednesday, May 19, 2010 4:05 AM To: Allyn Romanow (allyn); dispatch@ietf.org Subject: RE: Multi-streams for telepresence description of work =20 Hi Allyn, =20 Cisco has recently open sourced under Apache license a protocol called Telepresence Interoperability Protocol. Also IMTC (International Multimedia Telecommunications Consortium) has setup an activity around TIP and Telepresence [1]. Would this proposed IETF work be overlapping or orthogonal to TIP and what IMTC is doing? =20 It's natural that IETF RAI area is a good fit for this type of standards, especially if we can take RTP, SIP, XMPP as the baseline. On the other hand, if a reasonable solution that is backed up by some major vendors is already being developed elsewhere, that will significantly shrik the succes chances of IETF being able to do something that will get deployed.=20 =20 Regards, Markus =20 [1] http://blog.imtc.org/index.php/2010/03/09/announcing-the-creation-of-imt c-telepresence-multi-streaming-activity-group/ =20 =20 =09 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Allyn Romanow (allyn) Sent: 18 May, 2010 21:30 To: IETF DISPATCH list Subject: [dispatch] Multi-streams for telepresence description of work Hi Folks, =20 Many of you are aware of telepresence systems (video conferencing on steroids..:), fewer probably are aware of the fact that the current systems are not interoperable with each other. After talking with Mary and Cullen, we have a rough draft of a charter to work on this problem in DISPATCH, for discussion on the mailing list. =20 We don't yet know whether a working group would need to be spun out or not - that will be clarified as we go. =20 We think there is enough background info in the work description to start a discussion, and plan to send out use cases for discussion shortly. =20 Who is the we? Several makers and providers of telepresence systems have gotten together to define the main problem in interoperability - the handling of multi-streams. =20 Thanks for your thoughts- Allyn =20 =20 Multi-streams for Telepresence Description of Work =20 =20 =20 Background One branch of video conferencing has evolved that is focused on immersive "being there" experience. Referred to in various ways such as virtual conferencing, telepresence or media spaces, early systems were mainly research projects or business systems with limited deployments. In recent years telepresence systems have seen considerable market success. Following the model of early systems, the first wave of commercial systems have been typically located in specially designed single-purpose rooms with multiple relatively large displays permitting life size image reproduction, multiple cameras, encoders, decoders and microphones. These systems have several important characteristics that are different from more traditional video conferencing systems. =20 =20 The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential group meeting characteristics such as eye contact, group gestures, seating order and spatial audio by carefully orchestrating the miking and camera angles at each of the sites . This is distinct from the more traditional approach where the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics. =20 =20 A second difference is manipulation of the environment to improve immersion. With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating and lighting so that when combined with large high quality displays, a strong sense of a "trompe l'oeil" or "being there" immersive experience is created. Typical video conference systems do not include these considerations. =20 As telepresence video systems have become successful in the market, manufacturers have started exploring delivery of the nonverbal communication and immersive values of telepresence via smaller, less expensive and more flexible video conferencing systems for a variety of venues, such as individual offices, homes and kiosks. These are also telepresence systems, since the audio and video quality is high enough to allow clear image reproduction for nonverbal communication, they are able to send and receive multiple media streams, and large coordinated multi image displays are available for immersive installations. As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly available. =20 Problem Although telepresence systems are based on open standards such as RTP, SIP, H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one vendor to another. It would be like having to make sure all parties are on the same equipment (and network) when making a telephone call. A major factor in the inability of Telepresence systems to work with each other is that there is no standard description of the multiple streams that comprise the media flows.=20 =20 For example, in a multiple screen conference, the video and audio streams sent from remote participants must be understood by receivers so that they can be presented in a coherent and life-like manner. This includes the ability to present the remote participants at their true size for their apparent distance, while maintaining correct eye contact, gesticular cues, and simultaneously providing a spatial audio sound stage consistent with the video presentation. The receiving device that decides how to display the incoming information needs to understand a number of variables such as the spatial position of the speaker, the field of view of the cameras, the camera zoom, which media stream is related to each of the displays, etc.=20 =20 Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to define and specify the content of media multi-stream messages and the way these will be transported.=20 This work is aimed at providing a standard for the exchange of media semantics information that will foster interoperable end stations and conference bridges. This work item will specify the variables that describe the semantics of the media streams and the recommended behavior to achieve interoperability. =20 =20 This requires considering current widely deployed use cases, such as single and multiple screens, multi-point, Scalable Video Coding (SVC), as well as cases that are expected to be implemented using the protocol framework produced by this work item. The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young technology and may have use cases that are not currently considered. =20 The work item will identify use cases, define requirements, and define a method for describing and transporting information about multiple media streams, including a specification of variables required to support the use cases. This work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols required to be implemented to support this functionality. The document will identify any enhancements required to existing protocols as well as describing new protocol(s) for interoperable multi-streams negotiation that may be required. =20 Scope The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. =20 The focus of this work is on audio and video multiple streams, however other media types may be considered. Definition of new application protocols is not within the scope of this work =20 [Is there anything else we need to explicitly say is out of scope?] =20 The group will produce - Requirements and use cases =20 - Architectural Framework describing the protocols required to be implemented to support this functionality and identifying existing protocol enhancements and new protocol functionality required =20 - Specification of a new protocol to support telepresence multi-streams [if required] =20 Goals and Milestones Nov 2010=20 Use Cases and Requirements to IESG as Informational RFC=20 March 2011=20 Architecture to IESG as Informational RFC=20 March 2011 Revise Charter [IF new protocol is not required] Nov 2011=20 Submit protocol draft to IESG as Proposed Standard RFC=20 =20 =20 =20 =20 ------_=_NextPart_001_01CAF76A.BF7B7AF1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Markus,

 

Thanks for bringing = up these telepresence related activities, whose roles need to be clarified. The = bottom line is that Cisco’s TIP is not related to the proposed = multi-stream work, and the IMTC Telepresence Activity Group is related and has had = the goal of bringing proposed work definition, use cases and requirements, but = NOT solution, to the IETF.

 

Cisco has indeed made = its TIP protocol freely available. In fact  the copyright is in the process = of being given over to the IMTC, who will  own it, manage it, and have = change control. The IMTC has not yet announced how it will manage TIP. TIP is = Cisco’s way of doing telepresence signaling and media = control.

 

At the same time, = Cisco is also engaging in the development of a new open standard which we believe = would most appropriately be developed within the IETF as the technology is based = IETF protocols, RTP and SIP in particular. The IMTC is a multimedia industry consortium that does a lot of interoperability testing. Many vendors are members and individual non-members can participate in activities. This = was a good place to begin to pull together thoughts on how existing standards = can help interoperability and what is missing from them. Thus the = Telepresence Activity Group was formed. Steve Botzko and myself  are the = co-chairs. The work of the TP AG has been to define the problem that could be worked on = in the IETF. We have been consulting with Cullen and Mary from the beginning, = and have been quite clear not to address potential solutions prior to working in = the IETF.

 

Again, on the = relationship with TIP, since TIP is Cisco’s solution for media control, people from = Cisco will undoubtedly suggest that what they feel are the most valuable parts = of the TIP technology are not discluded from a standard, but no more so than = what people from other existing solutions are likely to do. People bring to = the table their experience and expertise.

 

I hope this = clarifies.. it’s potentially quite confusing. Please ask any further questions that come = up.

 

Best = regards,

Allyn

 

From:= = Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
Sent: Wednesday, May 19, 2010 4:05 AM
To: Allyn Romanow (allyn); dispatch@ietf.org
Subject: RE: Multi-streams for telepresence description of = work

 

Hi Allyn,

 

Cisco has recently open sourced under Apache license a = protocol called Telepresence Interoperability Protocol. Also IMTC (International Multimedia Telecommunications Consortium) has setup an activity = around TIP and Telepresence [1]. Would this proposed IETF work be overlapping or orthogonal to TIP and what IMTC is doing?

 

It's natural that IETF RAI area is a good fit for this type = of standards, especially if we can take RTP, SIP, XMPP as the baseline. On = the other hand, if a reasonable solution that is backed up by some major vendors = is already being developed elsewhere, that will significantly shrik the = succes chances of IETF being able to do something that will get deployed. =

 

Regards,

    Markus

 

[1] http://blog.imtc.o= rg/index.php/2010/03/09/announcing-the-creation-of-imtc-telepresence-mult= i-streaming-activity-group/

 

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Allyn Romanow (allyn)
Sent: 18 May, 2010 21:30
To: IETF DISPATCH list
Subject: [dispatch] Multi-streams for telepresence description of = work

Hi Folks,

 

Many of you are aware of telepresence systems = (video conferencing on steroids..:), fewer probably are aware of the fact that = the current systems are not interoperable with each other. After talking = with Mary and Cullen, we have a rough draft of a charter to work on this problem = in DISPATCH,  for discussion on the mailing list.

 

We don’t yet know whether a working group = would need to be spun out or not – that will be clarified as we = go.

 

We think there is enough background info in the = work description to start a discussion, and plan to send out use cases for discussion shortly.

 

Who is the we? Several makers and providers of = telepresence systems have gotten together to define the main problem in = interoperability – the handling of multi-streams.

 

Thanks for your thoughts-

Allyn

 

 

Multi-streams for = Telepresence Description of Work

 

 

 

Background

One branch of video conferencing has evolved that is focused on immersive “being there” experience.  Referred to in various ways such as = virtual conferencing, telepresence or media spaces, early systems were mainly = research projects or business systems with limited deployments.  In recent = years telepresence systems have seen considerable market success.  = Following the model of early systems, the first wave of commercial systems have been typically located in specially designed single-purpose rooms with = multiple relatively large displays permitting life size image reproduction, = multiple cameras, encoders, decoders and microphones.  These systems have = several important characteristics that are different from more traditional video conferencing systems. 

 

The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential = group meeting characteristics such as eye contact, group gestures, seating = order and spatial audio by carefully orchestrating the miking and camera angles at = each of the sites . This is distinct from the more traditional approach where = the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group = dynamics. 

 

A = second difference is manipulation of the environment to improve = immersion.  With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating = and lighting so that when combined with large high quality displays, a = strong sense of a "trompe l'oeil" or "being there" immersive = experience is created.  Typical video conference systems do not include these considerations.

 

As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal communication and = immersive values of telepresence via smaller, less expensive and more flexible = video conferencing systems for a variety of venues, such as individual = offices, homes and kiosks. These are also  telepresence systems, since the audio = and video quality is high enough to allow clear image reproduction for = nonverbal communication, they are able to send and receive multiple media streams, = and large coordinated multi image displays are available for immersive installations.   As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly = available.

 

Problem<= /p>

Although telepresence systems are based on open standards such as RTP, SIP, = H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one = vendor to another. It would be like having to make sure all parties are on the = same equipment (and network) when making a telephone call.  A major = factor in the inability of Telepresence systems to work with each other is that = there is no standard description of the multiple streams that comprise the media = flows.

 

For example, in a multiple screen conference, the video and audio streams sent from = remote participants must be understood by receivers so that they can be = presented in a coherent and life-like manner. This includes the ability to present the = remote participants at their true size for their apparent distance, while = maintaining correct eye contact, gesticular cues, and simultaneously providing a = spatial audio sound stage consistent with the video presentation.  The = receiving device that decides how to display the incoming information needs to = understand a number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is related to = each of the displays, etc.

 

Charter<= /p>

The Telepresence Multi-Streams work item in DISPATCH is chartered to define = and specify the content of media multi-stream messages and the way these = will be transported.

This work is aimed at providing a standard for the exchange of media semantics = information that will foster interoperable end stations and conference bridges. This = work item will specify the variables that describe the semantics of the media streams and the recommended behavior to achieve interoperability.  =

 

This requires considering current widely deployed use cases, such as single and = multiple screens, multi-point, Scalable Video Coding (SVC), as well as cases that = are expected to be implemented using the protocol framework produced by this = work item.  The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young = technology and may have use cases that are not currently = considered.

 

The work item will identify use cases, define requirements, and define a method for = describing and transporting information about multiple media streams, including a specification of variables required to support the use cases. This work = item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols = required to be implemented to support this functionality.  The document will = identify any enhancements required to existing protocols as well as describing = new protocol(s) for interoperable multi-streams negotiation that may be = required.

 

Scope

The scope includes both systems that provide a fully immersive experience, and = systems that interwork with them and therefore need to understand the same = multiple stream semantics.

 

The focus of this work is on audio and video multiple streams, however other media = types may be considered.  Definition of new application protocols is not = within the scope of this work

 

[Is there anything else we need to explicitly say is out of = scope?]

 

The group will produce

- Requirements and use cases

 

- Architectural Framework describing the protocols required to be = implemented to support this functionality and identifying existing protocol = enhancements and new protocol functionality required

 

- = Specification of a new protocol to support telepresence multi-streams [if = required]

 

Goals and Milestones

Nov 2010

Use Cases and Requirements to IESG as Informational RFC

March 2011

Architecture to IESG as Informational RFC

March 2011

Revise Charter [IF new protocol is not required]

Nov 2011

Submit protocol draft to IESG as Proposed Standard RFC

 

 

 

 

------_=_NextPart_001_01CAF76A.BF7B7AF1-- From pkyzivat@cisco.com Wed May 19 12:49:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE433A6924 for ; Wed, 19 May 2010 12:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.939 X-Spam-Level: X-Spam-Status: No, score=-8.939 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT58nCLkd2ym for ; Wed, 19 May 2010 12:49:47 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DA7043A6C7B for ; Wed, 19 May 2010 12:45:43 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABPd80tAZnwM/2dsb2JhbACRGoxhcaRYmV6FEAQ X-IronPort-AV: E=Sophos;i="4.53,265,1272844800"; d="scan'208";a="112773459" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 May 2010 19:45:36 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4JJjahN012704; Wed, 19 May 2010 19:45:36 GMT Message-ID: <4BF43FDC.2030006@cisco.com> Date: Wed, 19 May 2010 15:45:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Laura Liess References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <430FC6BDED356B4C8498F634416644A91C13990F46@mail> <4bec4e62.0c58560a.188d.ffff9205@mx.google.com> <430FC6BDED356B4C8498F634416644A91C1399121F@mail> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , "R.Jesske@telekom.de" , Hadriel Kaplan Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 19:49:48 -0000 Laura Liess wrote: > Alert-Info URNs represent tones. The receiving end device only > resolves it to a tone and plays the tone. Nothing else. The end > device does not look at what the Alert-Info URN means, but only if it > has rules to resolve it to a concrete tone. If it has, it resolves the > URN, otherwise the URN is discarded. It can be call waiting or > Bethoven Fifth or the combination internal+short. The network will not > use the Alert-info URNs for the call control logic. The RFC 3261 > allows Alert-Info in INVITE and 180. People agreed on the ML to exten > this to 18x. I'd like to take issue with the above. Due to precedent we all are biased towards *audio* alerts, but alerts need not be tones, or audio at all. Even for people who can hear, alerts that are, in part or wholly, non-audio are also important. E.g. everybody has reason to put their cellphone into vibrate mode at times. Thanks, Paul From dworley@avaya.com Wed May 19 13:43:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1788E3A68C0 for ; Wed, 19 May 2010 13:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkEtzMPu0Lo2 for ; Wed, 19 May 2010 13:43:20 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id C78F43A67DA for ; Wed, 19 May 2010 13:43:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,265,1272859200"; d="scan'208";a="189515759" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 May 2010 16:43:10 -0400 X-IronPort-AV: E=Sophos;i="4.53,265,1272859200"; d="scan'208";a="476553816" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 May 2010 16:43:10 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 19 May 2010 16:43:09 -0400 From: "WORLEY, Dale R (Dale)" To: Shida Schubert , Xavier Marjou Date: Wed, 19 May 2010 16:42:02 -0400 Thread-Topic: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: Acr3XCMe2RSZKLwkQfSCO3bCUaExewAN5mL7 Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 20:43:21 -0000 ________________________________________ > 2010/5/13 : >> Dear all, >> I have asked for comments on the two drafts mentioned below. >> So far I didn't get any. Does that mean that people are happy now with t= he >> content and we could proceed with it? >> >> Thank you and Best Regrads >> >> Roland >> _______________________________________________ Yes, I think this work should go foward in accordance with these drafts. Dale From eckelcu@cisco.com Wed May 19 15:15:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49053A6ABF for ; Wed, 19 May 2010 15:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.396 X-Spam-Level: X-Spam-Status: No, score=-8.396 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YueO22XiP3h for ; Wed, 19 May 2010 15:14:40 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DA8D93A6AAB for ; Wed, 19 May 2010 15:14:34 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIb/80urR7Ht/2dsb2JhbACdfnGkeplRglmCNwSCeUc X-IronPort-AV: E=Sophos;i="4.53,265,1272844800"; d="scan'208";a="256858880" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 19 May 2010 22:14:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4JMEShd009976; Wed, 19 May 2010 22:14:28 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 May 2010 15:14:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: ALwu D059 FPN4 G0xQ IpTf JWPO KAMX MLq/ MmP3 M9gD OTcW OzcV PPRd PfXp PkKo QrB6; 2; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnADsAcwB0AGUAcABoAGUAbgAuAGIAbwB0AHoAawBvAEAAZwBtAGEAaQBsAC4AYwBvAG0A; Sosha1_v1; 7; {102DBD3C-AEC7-4589-A113-FD59D16B169C}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Wed, 19 May 2010 22:14:28 GMT; UgBFADoAIABbAGQAaQBzAHAAYQB0AGMAaABdACAATQB1AGwAdABpAC0AcwB0AHIAZQBhAG0AcwAgAGYAbwByACAAdABlAGwAZQBwAHIAZQBzAGUAbgBjAGUAIABkAGUAcwBjAHIAaQBwAHQAaQBvAG4AIABvAGYAIAB3AG8AcgBrAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {102DBD3C-AEC7-4589-A113-FD59D16B169C} Content-class: urn:content-classes:message Date: Wed, 19 May 2010 15:14:28 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Multi-streams for telepresence description of work Thread-Index: Acr3Qg22Enm9Y1Z9Q2O+OHP2WrPq0wAWGgcg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0160CE8B@xmb-sjc-221.amer.cisco.com> From: "Charles Eckel (eckelcu)" To: "stephen botzko" , "Allyn Romanow (allyn)" X-OriginalArrivalTime: 19 May 2010 22:14:27.0999 (UTC) FILETIME=[A5AE92F0:01CAF7A0] Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 22:15:05 -0000 Just an FYI, for the more rudimentary level of interoperability along the lines of what is possible with traditional H.323 based video conferencing equipment, folks may want to direct their input and requirements to the SIP Parity group within IMTC (http://www.imtc.org/activity_groups/SIP.asp). This group is not trying to create any new standards or protocols, but rather to describe best practices that promote interoperability among the various vendors. I view this potential DISPATCH working group as taking things to the next level. =20 Cheers, Charles > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of stephen botzko > Sent: Wednesday, May 19, 2010 3:48 AM > To: Allyn Romanow (allyn) > Cc: IETF DISPATCH list > Subject: Re: [dispatch] Multi-streams for telepresence description of work >=20 > Hi Peter >=20 > I am one of the "we" that Allyn refers to. See inline for a comment. >=20 > Regards. > Stephen Botzko >=20 >=20 > On Wed, May 19, 2010 at 12:50 AM, Allyn Romanow (allyn) wrote: >=20 >=20 > Hi Peter, > You've raised excellent points. See inline for a few brief comments, and I'll look to others to > elaborate (or disagree). >=20 > best, > Allyn >=20 >=20 > ________________________________ >=20 > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > Sent: Tuesday, May 18, 2010 9:22 PM > To: Allyn Romanow (allyn) > Cc: IETF DISPATCH list > Subject: Re: [dispatch] Multi-streams for telepresence description of work >=20 >=20 > Hi Allyn, >=20 > I am interested in having this work start. I suspect it will likely warrant a working > group at the appropriate time. >=20 > The charter as written is VERY general. I would suspect that SIP/SDP is going to be the > common ground. Is it worth making this explicit in the charter? If not perhaps the reasons why not > could be stated in the charter. (My understanding is that most of these systems do use SIP but that > they differ in number of sessions per endpoint and how the media is packaged into RTP streams etc.) >=20 > [alr] Certainly RTP is used without question, and there has been discussion about limiting > to RTP streams only, not other types of data. This is still an open issue to be discussed. >=20 > Although I (and some others) initially assumed that we would use SDP for signaling, after > further thought Steve Botsko and others suggested we might want to consider another protocol such as > XMPP in light of the nature of the messages we want to send. I think that it's premature to specify > this in the charter as I consider it part of the the solution, and think it will become clear what > protocol to use as we specify requirements. >=20 > Is there other IETF work which we can see has relevance and should be mentioned as tools > which can be brought to bear? (xcon? mediactrl?) >=20 > [alr] Good point. We definitely want to consider existing work, and look to the experts in > DISPATCH to help with this. As above, I'm not sure if we can go there yet without requirements first- > but centainly we can be begin to look at potential tools. >=20 > Is there interest in ensuring interop of TP with legacy SIP video conferencing systems as > part of this work? Should that be part of the charter? >=20 > [alr] My personal view is not too much, that it's more a matter of going forward with a > common technology that allows us to interoperate. I don't want us to be in the position of needing to > tie together systems that we already have, as that would too much limit our approach. That said, > people will want to incorporate the best of their current technology. What do folks think? >=20 > [scb] Personally I think it is essential that TP devices be able to use SIP/SDP to interoperate with > traditional videoconferencing systems. So I think it is a requirement that this work not preclude > SIP/SDP interoperability, either with videoconferencing or ordinary phones. >=20 > Also, I think that TP calls will need to be be carried on existing [possibly upgraded] infrastructure, > including SIP proxies, SBCs, etc, as it is undesirable to deploy a parallel infrastructure for TP. >=20 > I do not think it is a requirement for this work to fully accommodate existing TP systems. While it > would be a nice outcome if these systems could be easily retrofitted to support this new work, it is > much more important to have a solid basis to go forward. >=20 >=20 >=20 > Regards, >=20 > Peter Musgrave >=20 >=20 >=20 > On Tue, May 18, 2010 at 8:30 PM, Allyn Romanow (allyn) wrote: >=20 >=20 > Hi Folks, >=20 >=20 >=20 > Many of you are aware of telepresence systems (video conferencing on steroids..:), > fewer probably are aware of the fact that the current systems are not interoperable with each other. > After talking with Mary and Cullen, we have a rough draft of a charter to work on this problem in > DISPATCH, for discussion on the mailing list. >=20 >=20 >=20 > We don't yet know whether a working group would need to be spun out or not - that > will be clarified as we go. >=20 >=20 >=20 > We think there is enough background info in the work description to start a > discussion, and plan to send out use cases for discussion shortly. >=20 >=20 >=20 > Who is the we? Several makers and providers of telepresence systems have gotten > together to define the main problem in interoperability - the handling of multi-streams. >=20 >=20 >=20 > Thanks for your thoughts- >=20 > Allyn >=20 >=20 >=20 >=20 >=20 > Multi-streams for Telepresence Description of Work >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Background >=20 > One branch of video conferencing has evolved that is focused on immersive "being > there" experience. Referred to in various ways such as virtual conferencing, telepresence or media > spaces, early systems were mainly research projects or business systems with limited deployments. In > recent years telepresence systems have seen considerable market success. Following the model of early > systems, the first wave of commercial systems have been typically located in specially designed > single-purpose rooms with multiple relatively large displays permitting life size image reproduction, > multiple cameras, encoders, decoders and microphones. These systems have several important > characteristics that are different from more traditional video conferencing systems. >=20 >=20 >=20 > The first difference concerns controlling the visual viewpoint in order to improve > participant nonverbal communication. These systems preserve essential group meeting characteristics > such as eye contact, group gestures, seating order and spatial audio by carefully orchestrating the > miking and camera angles at each of the sites . This is distinct from the more traditional approach > where the geometric relationship between media streams is not used to preserve inter-stream > communication aspects such as eye contact and group dynamics. >=20 >=20 >=20 > A second difference is manipulation of the environment to improve immersion. With > telepresence systems, cinematographic aspects of the local environment reproduction are carefully > planned including color, table shape, seating and lighting so that when combined with large high > quality displays, a strong sense of a "trompe l'oeil" or "being there" immersive experience is > created. Typical video conference systems do not include these considerations. >=20 >=20 >=20 > As telepresence video systems have become successful in the market, manufacturers > have started exploring delivery of the nonverbal communication and immersive values of telepresence > via smaller, less expensive and more flexible video conferencing systems for a variety of venues, such > as individual offices, homes and kiosks. These are also telepresence systems, since the audio and > video quality is high enough to allow clear image reproduction for nonverbal communication, they are > able to send and receive multiple media streams, and large coordinated multi image displays are > available for immersive installations. As the industry develops, the line between telepresence and > video conferencing may become blurred as nonverbal communication and immersive installations become > broadly available. >=20 >=20 >=20 > Problem >=20 > Although telepresence systems are based on open standards such as RTP, SIP, H.264, > H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive > additional equipment that translates from one vendor to another. It would be like having to make sure > all parties are on the same equipment (and network) when making a telephone call. A major factor in > the inability of Telepresence systems to work with each other is that there is no standard description > of the multiple streams that comprise the media flows. >=20 >=20 >=20 > For example, in a multiple screen conference, the video and audio streams sent from > remote participants must be understood by receivers so that they can be presented in a coherent and > life-like manner. This includes the ability to present the remote participants at their true size for > their apparent distance, while maintaining correct eye contact, gesticular cues, and simultaneously > providing a spatial audio sound stage consistent with the video presentation. The receiving device > that decides how to display the incoming information needs to understand a number of variables such as > the spatial position of the speaker, the field of view of the cameras, the camera zoom, which media > stream is related to each of the displays, etc. >=20 >=20 >=20 > Charter >=20 > The Telepresence Multi-Streams work item in DISPATCH is chartered to define and > specify the content of media multi-stream messages and the way these will be transported. >=20 > This work is aimed at providing a standard for the exchange of media semantics > information that will foster interoperable end stations and conference bridges. This work item will > specify the variables that describe the semantics of the media streams and the recommended behavior to > achieve interoperability. >=20 >=20 >=20 > This requires considering current widely deployed use cases, such as single and > multiple screens, multi-point, Scalable Video Coding (SVC), as well as cases that are expected to be > implemented using the protocol framework produced by this work item. The methodology for describing > the variables must allow extensibility of the variables, since telepresence is still a young > technology and may have use cases that are not currently considered. >=20 >=20 >=20 > The work item will identify use cases, define requirements, and define a method for > describing and transporting information about multiple media streams, including a specification of > variables required to support the use cases. This work item will consider the reuse of existing IETF > protocols and produce an architecture/protocol framework document describing the protocols required to > be implemented to support this functionality. The document will identify any enhancements required to > existing protocols as well as describing new protocol(s) for interoperable multi-streams negotiation > that may be required. >=20 >=20 >=20 > Scope >=20 > The scope includes both systems that provide a fully immersive experience, and > systems that interwork with them and therefore need to understand the same multiple stream semantics. >=20 >=20 >=20 > The focus of this work is on audio and video multiple streams, however other media > types may be considered. Definition of new application protocols is not within the scope of this work >=20 >=20 >=20 > [Is there anything else we need to explicitly say is out of scope?] >=20 >=20 >=20 > The group will produce >=20 > - Requirements and use cases >=20 >=20 >=20 > - Architectural Framework describing the protocols required to be implemented to > support this functionality and identifying existing protocol enhancements and new protocol > functionality required >=20 >=20 >=20 > - Specification of a new protocol to support telepresence multi-streams [if > required] >=20 >=20 >=20 > Goals and Milestones >=20 > Nov 2010 >=20 > Use Cases and Requirements to IESG as Informational RFC >=20 > March 2011 >=20 > Architecture to IESG as Informational RFC >=20 > March 2011 >=20 > Revise Charter [IF new protocol is not required] >=20 > Nov 2011 >=20 > Submit protocol draft to IESG as Proposed Standard RFC >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 >=20 From ranjit@motorola.com Wed May 19 21:33:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0693A6900 for ; Wed, 19 May 2010 21:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.455 X-Spam-Level: X-Spam-Status: No, score=-4.455 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeJPcMozz72l for ; Wed, 19 May 2010 21:33:32 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 01ABF3A67C2 for ; Wed, 19 May 2010 21:33:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1274330003!50171027!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21915 invoked from network); 20 May 2010 04:33:24 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 May 2010 04:33:24 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o4K4XI4x025324 for ; Wed, 19 May 2010 21:33:23 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o4K4XHJT018190 for ; Wed, 19 May 2010 23:33:17 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o4K4XFwF018178 for ; Wed, 19 May 2010 23:33:16 -0500 (CDT) 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, 20 May 2010 12:32:52 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 thread-index: AcryhWzbLdlIO5CLQ9SHlQmzpNqWjwAAB6jQAAFkdMAAKFcIIAEqOt0g References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> From: "Avasarala Ranjit-A20990" To: "Elwell, John" , X-CFilter-Loop: Reflected Cc: R.Jesske@telekom.de Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 04:33:34 -0000 Hi All Any further comments on this I-D and suggestions for next steps? Thanks Regards Ranjit -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990 Sent: Friday, May 14, 2010 11:49 AM To: Elwell, John; dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 Hi John This I-D on communication barring notification talks about an event package for reporting the notification information of communication barrings (call blocking) that happen in the network on behalf of the users. For e.g if Alice sets a call blocking rule that all calls from Bob need to be blocked, then the network blocks all calls from Bob towards Alice. So here The notification information will include the details of the call block - i.e (1) the identity of caller (Bob) (2) time of block (2) reason for block, etc Yes I agree with you that there is synergy between this I-D and the one on CDIV, since both of them deal with reporting of events that occur in the network. While CDIV deals with communication diversion, this one deals with ICB service. Though both the event packages are similar in terms of subscriptions and format, their execution and user preference may vary. So they need to be looked at differently and standardized seperately. Regards Ranjit -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Thursday, May 13, 2010 6:25 PM To: Avasarala Ranjit-A20990; dispatch@ietf.org Cc: T Satyanarayana-A12694 Subject: RE: [dispatch] FW: New Version Notification fordraft-avasarala-dispatch-comm-barring-notification-00 Ranjit, It is not entirely clear to me what the notifications report. For example, in 6.7, it says "Typically, it will send one when a communication barring is enacted on behalf of the user." What is meant by "enacted" here? Is it when some entity, on behalf of the user, perhaps through some web page, establishes a communication barring rule? Or is it when an inbound communication arrives and is processed in accordance with some pre-existing communication barring rule? I thought at first it was the former, but I am tending towards thinking it is the latter. Some clarification would be useful. Assuming it is the latter, there is obviously some synergy with draft-avasarala-dispatch-comm-div-notification. Both deal with reporting inbound communications that have been subject to some rule, the rule being conditional on certain criteria such as caller ID. Where the conditions are met for a given call to be subject to a given rule, a notification in accordance with one or the other event package will be triggered. I fail to see the reason for having two separate event packages, since this means two separate specifications, two different subscriptions, two different formats, etc.. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 > Ranjit-A20990 > Sent: 13 May 2010 11:28 > To: dispatch@ietf.org > Cc: T Satyanarayana-A12694 > Subject: [dispatch] FW: New Version Notification for=20 > draft-avasarala-dispatch-comm-barring-notification-00 >=20 > Hi all >=20 > I have submitted a new I-D on communication barring notification=20 > information based on the following >=20 > Section 8.2.10 Communication Barring - ICB enhancement of dynamic=20 > blocking of incoming communications of 3GPP TS 22.173 >=20 > Section 4.5.2.6.1 Actions for ICB at the terminating AS of 3GPP TS > 24.611 >=20 > The draft can be accessed from: > http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n > otificatio > n-00.txt >=20 > Please review and comment. >=20 > Thanks >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Thursday, May 13, 2010 3:47 PM > To: Avasarala Ranjit-A20990 > Cc: r.jesske@telekom.de > Subject: New Version Notification for > draft-avasarala-dispatch-comm-barring-notification-00 >=20 >=20 > A new version of I-D, > draft-avasarala-dispatch-comm-barring-notification-00.txt has been=20 > successfully submitted by Ranjit Avasarala and posted to the IETF=20 > repository. >=20 > Filename: draft-avasarala-dispatch-comm-barring-notification > Revision: 00 > Title: A Session Initiation Protocol (SIP)=20 > Event Package for > Communication Barring Notification Information in support of the=20 > Dynamic Incoming Communication Barring (ICB) Notification service > Creation_date: 2010-05-13 > WG ID: Independent Submission > Number_of_pages: 22 >=20 > Abstract: > 3GPP is defining the protocol specification for the Communication=20 > Barring (CB) service using IP Multimedia (IM) Core Network (CN)=20 > subsystem supplementary service and more particularly the dynamic=20 > incoming communication barring service. As part of dynamic incoming=20 > communication barring (ICB) service, a SIP based Event package=20 > framework is used for notifying users about communication barrings=20 > (dynamic and rule based) of their incoming communication sessions. > This document proposes a new SIP event package for allowing users to=20 > subscribe to and receive such notifications. Users can further define > filters to control the rate and content of such notifications. > The proposed event package is applicable to the ICB supplementary=20 > service in IMS and may not be applicable to the general internet. > =20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From christer.holmberg@ericsson.com Wed May 19 23:01:40 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F49F3A6CA8 for ; Wed, 19 May 2010 23:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-1.558, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5M+Jn7G2tws for ; Wed, 19 May 2010 23:01:39 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 402D13A6CC3 for ; Wed, 19 May 2010 23:01:39 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-eb-4bf4d03ad6b4 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C0.2D.21861.A30D4FB4; Thu, 20 May 2010 08:01:30 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 20 May 2010 08:01:30 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 20 May 2010 08:01:29 +0200 From: Christer Holmberg To: Paul Kyzivat , Laura Liess Date: Thu, 20 May 2010 08:01:28 +0200 Thread-Topic: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: Acr3jG6O20SM6QXpSoGznF0/u/rdTgAVStjw Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <430FC6BDED356B4C8498F634416644A91C13990F46@mail> <4bec4e62.0c58560a.188d.ffff9205@mx.google.com> <430FC6BDED356B4C8498F634416644A91C1399121F@mail> <4BF43FDC.2030006@cisco.com> In-Reply-To: <4BF43FDC.2030006@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" , Hadriel Kaplan , "R.Jesske@telekom.de" Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 06:01:40 -0000 Hi,=20 >>Alert-Info URNs represent tones. The receiving end device only=20 >>resolves it to a tone and plays the tone. Nothing else. The end=20 >>device does not look at what the Alert-Info URN means, but only if it=20 >>has rules to resolve it to a concrete tone. If it has, it resolves the=20 >>URN, otherwise the URN is discarded. It can be call waiting or=20 >>Bethoven Fifth or the combination internal+short. The=20 >>network will not use the Alert-info URNs for the call control logic. The = RFC 3261=20 >>allows Alert-Info in INVITE and 180. People agreed on the ML to exten=20 >>this to 18x. >=20 >I'd like to take issue with the above. >Due to precedent we all are biased towards *audio* alerts,=20 >but alerts need not be tones, or audio at all. Even for=20 >people who can hear, alerts that are, in part or wholly,=20 >non-audio are also important. E.g.=20 >everybody has reason to put their cellphone into vibrate mode=20 >at times. Of course. In that case you won't get an audio alert - no matter if you use= Alert-Info or your "default" audio ring tone. Regards, Christer From john.elwell@siemens-enterprise.com Wed May 19 23:44:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40473A6CC7 for ; Wed, 19 May 2010 23:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eQAJPcd2ZYj for ; Wed, 19 May 2010 23:44:42 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 731703A6CB1 for ; Wed, 19 May 2010 23:44:41 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-231468; Thu, 20 May 2010 08:44:33 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 384DB23F028E; Thu, 20 May 2010 08:44:33 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 20 May 2010 08:44:33 +0200 From: "Elwell, John" To: Avasarala Ranjit-A20990 , "dispatch@ietf.org" Date: Thu, 20 May 2010 08:44:31 +0200 Thread-Topic: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 Thread-Index: AcryhWzbLdlIO5CLQ9SHlQmzpNqWjwAAB6jQAAFkdMAAKFcIIAEqOt0gAARuN/A= Message-ID: References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.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: "R.Jesske@telekom.de" Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 06:44:43 -0000 Sorry, I thought I had already responded, but clearly not. I am still of the opinion that there is sufficient synergy between the two = event packages that they can be combined into a single event package. This = would have the benefit of being able to have a single subscription to get a= ll information relating to automatic handling of incoming calls, rather tha= n being forced to subscribe twice. If you only want information about diver= ted calls, or only information about barred calls, you could filter accordi= ngly. If you want different filtering criteria, or different subscription t= imes for the two, there is nothing to stop you having two separate subscrip= tions. But we should not penalise the simple case by forcing two subscripti= ons where one would do. John > -----Original Message----- > From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20 > Sent: 20 May 2010 05:33 > To: Elwell, John; dispatch@ietf.org > Cc: R.Jesske@telekom.de > Subject: RE: [dispatch] FW: New Version=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >=20 > Hi All >=20 > Any further comments on this I-D and suggestions for next steps? >=20 > Thanks >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Avasarala Ranjit-A20990 > Sent: Friday, May 14, 2010 11:49 AM > To: Elwell, John; dispatch@ietf.org > Subject: Re: [dispatch] FW: New Version > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >=20 > Hi John >=20 > This I-D on communication barring notification talks about an event > package for reporting the notification information of communication > barrings (call blocking) that happen in the network on behalf of the > users. >=20 > For e.g if Alice sets a call blocking rule that all calls=20 > from Bob need > to be blocked, then the network blocks all calls from Bob=20 > towards Alice. > So here > The notification information will include the details of the=20 > call block > - i.e (1) the identity of caller (Bob) (2) time of block (2)=20 > reason for > block, etc >=20 > Yes I agree with you that there is synergy between this I-D=20 > and the one > on CDIV, since both of them deal with reporting of events=20 > that occur in > the network. While CDIV deals with communication diversion, this one > deals with ICB service. Though both the event packages are similar in > terms of subscriptions and format, their execution and user preference > may vary. So they need to be looked at differently and standardized > seperately. >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, May 13, 2010 6:25 PM > To: Avasarala Ranjit-A20990; dispatch@ietf.org > Cc: T Satyanarayana-A12694 > Subject: RE: [dispatch] FW: New Version Notification > fordraft-avasarala-dispatch-comm-barring-notification-00 >=20 > Ranjit, >=20 > It is not entirely clear to me what the notifications report. For > example, in 6.7, it says "Typically, it will send > one when a communication barring is enacted on behalf of the user." >=20 > What is meant by "enacted" here? Is it when some entity, on behalf of > the user, perhaps through some web page, establishes a communication > barring rule? Or is it when an inbound communication arrives and is > processed in accordance with some pre-existing communication barring > rule? I thought at first it was the former, but I am tending towards > thinking it is the latter. Some clarification would be useful. >=20 > Assuming it is the latter, there is obviously some synergy with > draft-avasarala-dispatch-comm-div-notification. Both deal=20 > with reporting > inbound communications that have been subject to some rule, the rule > being conditional on certain criteria such as caller ID. Where the > conditions are met for a given call to be subject to a given rule, a > notification in accordance with one or the other event package will be > triggered. I fail to see the reason for having two separate event > packages, since this means two separate specifications, two different > subscriptions, two different formats, etc.. >=20 > John=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 > > Ranjit-A20990 > > Sent: 13 May 2010 11:28 > > To: dispatch@ietf.org > > Cc: T Satyanarayana-A12694 > > Subject: [dispatch] FW: New Version Notification for=20 > > draft-avasarala-dispatch-comm-barring-notification-00 > >=20 > > Hi all > >=20 > > I have submitted a new I-D on communication barring notification=20 > > information based on the following > >=20 > > Section 8.2.10 Communication Barring - ICB enhancement of dynamic=20 > > blocking of incoming communications of 3GPP TS 22.173 > >=20 > > Section 4.5.2.6.1 Actions for ICB at the terminating AS of 3GPP TS > > 24.611 > >=20 > > The draft can be accessed from: > > http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n > > otificatio > > n-00.txt > >=20 > > Please review and comment. > >=20 > > Thanks > >=20 > >=20 > > Regards > > Ranjit > >=20 > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Thursday, May 13, 2010 3:47 PM > > To: Avasarala Ranjit-A20990 > > Cc: r.jesske@telekom.de > > Subject: New Version Notification for > > draft-avasarala-dispatch-comm-barring-notification-00 > >=20 > >=20 > > A new version of I-D, > > draft-avasarala-dispatch-comm-barring-notification-00.txt has been=20 > > successfully submitted by Ranjit Avasarala and posted to the IETF=20 > > repository. > >=20 > > Filename: draft-avasarala-dispatch-comm-barring-notification > > Revision: 00 > > Title: A Session Initiation Protocol (SIP)=20 > > Event Package for > > Communication Barring Notification Information in support of the=20 > > Dynamic Incoming Communication Barring (ICB) Notification service > > Creation_date: 2010-05-13 > > WG ID: Independent Submission > > Number_of_pages: 22 > >=20 > > Abstract: > > 3GPP is defining the protocol specification for the Communication=20 > > Barring (CB) service using IP Multimedia (IM) Core Network (CN)=20 > > subsystem supplementary service and more particularly the dynamic=20 > > incoming communication barring service. As part of dynamic=20 > incoming=20 > > communication barring (ICB) service, a SIP based Event package=20 > > framework is used for notifying users about communication barrings=20 > > (dynamic and rule based) of their incoming communication sessions. > > This document proposes a new SIP event package for allowing=20 > users to=20 > > subscribe to and receive such notifications. Users can=20 > further define >=20 > > filters to control the rate and content of such notifications. > > The proposed event package is applicable to the ICB supplementary=20 > > service in IMS and may not be applicable to the general internet. > > =20 > >=20 > >=20 > >=20 > > The IETF Secretariat. > >=20 > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From gonzalo.camarillo@ericsson.com Thu May 20 00:39:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC1A3A6B0C for ; Thu, 20 May 2010 00:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.996 X-Spam-Level: X-Spam-Status: No, score=-101.996 tagged_above=-999 required=5 tests=[AWL=-1.811, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGv1mJui6UIW for ; Thu, 20 May 2010 00:39:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D41EA3A6928 for ; Thu, 20 May 2010 00:39:32 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-b2-4bf4e72c58d1 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 81.2A.21861.C27E4FB4; Thu, 20 May 2010 09:39:24 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 09:39:24 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 09:39:24 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 34727245A for ; Thu, 20 May 2010 10:39:24 +0300 (EEST) Message-ID: <4BF4E72B.7060600@ericsson.com> Date: Thu, 20 May 2010 10:39:23 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: DISPATCH References: <4BF3F281.8080102@ericsson.com> In-Reply-To: <4BF3F281.8080102@ericsson.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 May 2010 07:39:24.0396 (UTC) FILETIME=[91824AC0:01CAF7EF] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Alert Info URNs - Acronym X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 07:39:35 -0000 Hi, note that we also need an acronym for this WG proposal. We have so many WGs and drafts about drinking in RAI that we are going to need a few URINALS (URNs for INforming about ALerting in SIP) pretty soon! :o) We are of course open to better proposals! Thanks, Gonzalo On 19/05/2010 5:15 PM, Gonzalo Camarillo wrote: > Hi, > > thanks for all the good discussions around the Alert-Info URNs charter > proposal. They actually helped clarify a few important concepts. I have > revised the charter proposal taking into account all the feedback > received (see attachment). > > Please, let me know if you are happy with this proposal so that I can > get the IESG to review it. > > Thanks, > > Gonzalo > From john.elwell@siemens-enterprise.com Thu May 20 00:52:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7653A6CB4 for ; Thu, 20 May 2010 00:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o3MvbjYS-Mq for ; Thu, 20 May 2010 00:52:11 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id CBA313A6D21 for ; Thu, 20 May 2010 00:51:46 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-233479; Thu, 20 May 2010 09:51:39 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 23D3123F0278; Thu, 20 May 2010 09:51:39 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 20 May 2010 09:51:39 +0200 From: "Elwell, John" To: Gonzalo Camarillo , DISPATCH Date: Thu, 20 May 2010 09:51:36 +0200 Thread-Topic: [dispatch] Alert Info URNs - Acronym Thread-Index: Acr375ae0ipvH+5IQjCtYWmUfl4L6gAAWLrQ Message-ID: References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com> In-Reply-To: <4BF4E72B.7060600@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Alert Info URNs - Acronym X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 07:52:12 -0000 Well, simply ALES (ALErting in Sip). John =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 20 May 2010 08:39 > To: DISPATCH > Subject: [dispatch] Alert Info URNs - Acronym >=20 > Hi, >=20 > note that we also need an acronym for this WG proposal. We=20 > have so many > WGs and drafts about drinking in RAI that we are going to need a few > URINALS (URNs for INforming about ALerting in SIP) pretty soon! :o) >=20 > We are of course open to better proposals! >=20 > Thanks, >=20 > Gonzalo >=20 > On 19/05/2010 5:15 PM, Gonzalo Camarillo wrote: > > Hi, > >=20 > > thanks for all the good discussions around the Alert-Info=20 > URNs charter > > proposal. They actually helped clarify a few important=20 > concepts. I have > > revised the charter proposal taking into account all the feedback > > received (see attachment). > >=20 > > Please, let me know if you are happy with this proposal so=20 > that I can > > get the IESG to review it. > >=20 > > Thanks, > >=20 > > Gonzalo > >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From ranjit@motorola.com Thu May 20 01:35:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C713A6D12 for ; Thu, 20 May 2010 01:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.641 X-Spam-Level: X-Spam-Status: No, score=-5.641 tagged_above=-999 required=5 tests=[AWL=0.958, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBIsZb6Vye4K for ; Thu, 20 May 2010 01:35:21 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id A92383A6D5F for ; Thu, 20 May 2010 01:25:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1274343942!26440186!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27007 invoked from network); 20 May 2010 08:25:43 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 May 2010 08:25:43 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o4K8PgFV006157 for ; Thu, 20 May 2010 01:25:42 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o4K8Pgua017395 for ; Thu, 20 May 2010 03:25:42 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o4K8Pehe017385 for ; Thu, 20 May 2010 03:25:41 -0500 (CDT) 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, 20 May 2010 16:25:18 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 thread-index: AcryhWzbLdlIO5CLQ9SHlQmzpNqWjwAAB6jQAAFkdMAAKFcIIAEqOt0gAARuN/AAA7TOgA== References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> From: "Avasarala Ranjit-A20990" To: "Elwell, John" , X-CFilter-Loop: Reflected Cc: R.Jesske@telekom.de Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 08:35:27 -0000 Hi So is the consensus to proceed forward?=20 Regards Ranjit -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Thursday, May 20, 2010 12:15 PM To: Avasarala Ranjit-A20990; dispatch@ietf.org Cc: R.Jesske@telekom.de Subject: RE: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 Sorry, I thought I had already responded, but clearly not. I am still of the opinion that there is sufficient synergy between the two event packages that they can be combined into a single event package. This would have the benefit of being able to have a single subscription to get all information relating to automatic handling of incoming calls, rather than being forced to subscribe twice. If you only want information about diverted calls, or only information about barred calls, you could filter accordingly. If you want different filtering criteria, or different subscription times for the two, there is nothing to stop you having two separate subscriptions. But we should not penalise the simple case by forcing two subscriptions where one would do. John > -----Original Message----- > From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] > Sent: 20 May 2010 05:33 > To: Elwell, John; dispatch@ietf.org > Cc: R.Jesske@telekom.de > Subject: RE: [dispatch] FW: New Version=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >=20 > Hi All >=20 > Any further comments on this I-D and suggestions for next steps? >=20 > Thanks >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Avasarala Ranjit-A20990 > Sent: Friday, May 14, 2010 11:49 AM > To: Elwell, John; dispatch@ietf.org > Subject: Re: [dispatch] FW: New Version=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >=20 > Hi John >=20 > This I-D on communication barring notification talks about an event=20 > package for reporting the notification information of communication=20 > barrings (call blocking) that happen in the network on behalf of the=20 > users. >=20 > For e.g if Alice sets a call blocking rule that all calls from Bob=20 > need to be blocked, then the network blocks all calls from Bob towards > Alice. > So here > The notification information will include the details of the call=20 > block > - i.e (1) the identity of caller (Bob) (2) time of block (2) reason=20 > for block, etc >=20 > Yes I agree with you that there is synergy between this I-D and the=20 > one on CDIV, since both of them deal with reporting of events that=20 > occur in the network. While CDIV deals with communication diversion,=20 > this one deals with ICB service. Though both the event packages are=20 > similar in terms of subscriptions and format, their execution and user > preference may vary. So they need to be looked at differently and=20 > standardized seperately. >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, May 13, 2010 6:25 PM > To: Avasarala Ranjit-A20990; dispatch@ietf.org > Cc: T Satyanarayana-A12694 > Subject: RE: [dispatch] FW: New Version Notification=20 > fordraft-avasarala-dispatch-comm-barring-notification-00 >=20 > Ranjit, >=20 > It is not entirely clear to me what the notifications report. For=20 > example, in 6.7, it says "Typically, it will send > one when a communication barring is enacted on behalf of the user." >=20 > What is meant by "enacted" here? Is it when some entity, on behalf of=20 > the user, perhaps through some web page, establishes a communication=20 > barring rule? Or is it when an inbound communication arrives and is=20 > processed in accordance with some pre-existing communication barring=20 > rule? I thought at first it was the former, but I am tending towards=20 > thinking it is the latter. Some clarification would be useful. >=20 > Assuming it is the latter, there is obviously some synergy with=20 > draft-avasarala-dispatch-comm-div-notification. Both deal with=20 > reporting inbound communications that have been subject to some rule,=20 > the rule being conditional on certain criteria such as caller ID.=20 > Where the conditions are met for a given call to be subject to a given > rule, a notification in accordance with one or the other event package > will be triggered. I fail to see the reason for having two separate=20 > event packages, since this means two separate specifications, two=20 > different subscriptions, two different formats, etc.. >=20 > John >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 > > Ranjit-A20990 > > Sent: 13 May 2010 11:28 > > To: dispatch@ietf.org > > Cc: T Satyanarayana-A12694 > > Subject: [dispatch] FW: New Version Notification for=20 > > draft-avasarala-dispatch-comm-barring-notification-00 > >=20 > > Hi all > >=20 > > I have submitted a new I-D on communication barring notification=20 > > information based on the following > >=20 > > Section 8.2.10 Communication Barring - ICB enhancement of dynamic=20 > > blocking of incoming communications of 3GPP TS 22.173 > >=20 > > Section 4.5.2.6.1 Actions for ICB at the terminating AS of 3GPP TS > > 24.611 > >=20 > > The draft can be accessed from: > > http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n > > otificatio > > n-00.txt > >=20 > > Please review and comment. > >=20 > > Thanks > >=20 > >=20 > > Regards > > Ranjit > >=20 > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Thursday, May 13, 2010 3:47 PM > > To: Avasarala Ranjit-A20990 > > Cc: r.jesske@telekom.de > > Subject: New Version Notification for=20 > > draft-avasarala-dispatch-comm-barring-notification-00 > >=20 > >=20 > > A new version of I-D, > > draft-avasarala-dispatch-comm-barring-notification-00.txt has been=20 > > successfully submitted by Ranjit Avasarala and posted to the IETF=20 > > repository. > >=20 > > Filename: draft-avasarala-dispatch-comm-barring-notification > > Revision: 00 > > Title: A Session Initiation Protocol (SIP)=20 > > Event Package for > > Communication Barring Notification Information in support of the=20 > > Dynamic Incoming Communication Barring (ICB) Notification service > > Creation_date: 2010-05-13 > > WG ID: Independent Submission > > Number_of_pages: 22 > >=20 > > Abstract: > > 3GPP is defining the protocol specification for the Communication=20 > > Barring (CB) service using IP Multimedia (IM) Core Network (CN)=20 > > subsystem supplementary service and more particularly the dynamic=20 > > incoming communication barring service. As part of dynamic > incoming > > communication barring (ICB) service, a SIP based Event package=20 > > framework is used for notifying users about communication barrings=20 > > (dynamic and rule based) of their incoming communication sessions. > > This document proposes a new SIP event package for allowing > users to > > subscribe to and receive such notifications. Users can > further define >=20 > > filters to control the rate and content of such notifications. > > The proposed event package is applicable to the ICB supplementary=20 > > service in IMS and may not be applicable to the general internet. > > =20 > >=20 > >=20 > >=20 > > The IETF Secretariat. > >=20 > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From peter.leis@nsn.com Thu May 20 02:06:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1883A6B67 for ; Thu, 20 May 2010 02:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PABUWDyQGdI2 for ; Thu, 20 May 2010 02:06:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id B6A573A6B2E for ; Thu, 20 May 2010 02:05:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o4K94rmV027843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 May 2010 11:04:53 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o4K94pNp012779; Thu, 20 May 2010 11:04:53 +0200 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 May 2010 11:04:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 May 2010 11:04:40 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sADKuJwAAoMDiCA= References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail><430FC6BDED356B4C8498F634416644A91A8A5F1711@mail><430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> From: "Leis, Peter (NSN - DE/Munich)" To: "ext Elwell, John" , "ext Hadriel Kaplan" , "Dawes, Peter, VF-Group" , X-OriginalArrivalTime: 20 May 2010 09:04:42.0967 (UTC) FILETIME=[7C6A3E70:01CAF7FB] Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 09:06:27 -0000 hello, sorry for the late reply. The requirments for media-plane security in 3GPP IMS have been defined in TS 33.328 http://www.3gpp.org/ftp/Specs/html-info/33328.htm .=20 For SDES SRTP there are two modes defined, one is end2end and one is end2accessedge. We need to provide a solution for both modes. And for end2accessedge we do have a requirement that the UE knows whether or not the network (P-CSCF) will support SDES-SRTP before the session takes place as described below. Peter > -----Original Message----- > From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Friday, May 07, 2010 4:17 PM > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes,=20 > Peter, VF-Group; dispatch@ietf.org > Subject: RE: [dispatch] New I-D:=20 > draft-dawes-dispatch-mediasec-parameter-01 >=20 > =20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Leis, Peter=20 > > (NSN - DE/Munich) > > Sent: 03 May 2010 14:32 > > To: ext Hadriel Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org > > Subject: Re: [dispatch] New I-D:=20 > > draft-dawes-dispatch-mediasec-parameter-01 > >=20 > >=20 > > comments inline=20 > >=20 > > > -----Original Message----- > > > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > > > Sent: Friday, April 30, 2010 5:47 PM > > > To: Leis, Peter (NSN - DE/Munich); Dawes, Peter, VF-Group;=20 > > > dispatch@ietf.org > > > Subject: RE: [dispatch] New I-D:=20 > > > draft-dawes-dispatch-mediasec-parameter-01 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > > > > Sent: Friday, April 30, 2010 4:17 AM > > > > To: Hadriel Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org > > > >=20 > > > > > -----Original Message----- > > > > > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > > Sent: Thursday, April 29, 2010 6:59 PM > > > > > > > > > > Right, but I'm trying to figure out why that is. I mean > > > > > what's the reason the UA needs to know at Registration time > > > > > that it's next-hop b2bua can do srtp, instead of letting SDP > > > > > handle it? > > > > > > > > > > I *think* the answer is so that it can later send an INVITE > > > > > with an SDP offer without failing the request - is that=20 > > > the reason? > > > >=20 > > > > Right > > > =20 > > > OK, and I also agree that's a real problem. That issue was=20 > > > raised in the IETF in 2006/2007. There was a very simple=20 > > > proposal to avoid that, in=20 > > > draft-kaplan-mmusic-best-effort-srtp, but the decision of the=20 > > > MMUSIC WG was to instead use=20 > > > draft-ietf-mmusic-sdp-capability-negotiation to accomplish=20 > > > it. That draft is now in the RFC editor's queue. I know=20 > > > it's a lot of processing overhead, but that was the decision.=20 > > > And I think 3gpp has put support for that into some=20 > > release or other. > > >=20 > >=20 > > The requirement in 3GPP is, that the UE has to know whether=20 > or not the > > network (P-CSCF) will support SDES-SRTP before the session=20 > > takes place, > > if it wants to employ End2AccessEdge media plane security. This will > > ensure that the IMS UE shares the media keys only with the=20 > P-CSCF and > > not with some other entity.=20 > [JRE] Why would the UE "want to employ End2AccessEdge" media=20 > plane security, as opposed to E2E media plane security? I=20 > would have thought the UE would always prefer the latter.=20 > Furthermore, the UE should not use keys that have value=20 > outside this particular communication session, so if they get=20 > passed on beyond the P-CSCF, no harm is done. In fact, if=20 > they reach the remote UA, you can end up with E2E security,=20 > which would be great from the UE's perspective. >=20 > > In addition, in 3GPP there is a=20 > > requirement > > that the UE knows whether media plane security is=20 > established between > > itself and the network (i.e. End2AccessEdge), or whether media plane > > security is established between itself and the far end.=20 > [JRE] That would be interesting to know, but it is a more=20 > general problem - any B2BUA can terminate SRTP, and SIP does=20 > not provide any mechanism to indicate whether SRTP is truly=20 > end-to-end or just end-to-some-B2BUA. Also a gateway to TDM=20 > will terminate SRTP, and SIP does not provide any means of=20 > indicating whether SRTP is truly end-to-end or=20 > end-to-first-TDM-gateway. >=20 > John >=20 > >=20 > > As you said, CapNeg has a lot of processing overhead, and=20 > in addition, > > it does not solve the requirements I have listed. > >=20 > >=20 > > >=20 > > > > > > RFC 3840 does only cover UA indicating support, but not SBC > > > > > indicating > > > > > > support. > > > > > > > > > > Actually, in a way it does. An SBC is a B2BUA. As a UA, it > > > > > can indicate feature tags. What it *can't* do is indicate it > > > > > in the REGISTER response it sends to the UA. But the UA > > > > > could send an OPTIONS to the B2BUA and get it in a feature > > > > > tag of the response to the OPTIONS. I know it sucks to send > > > > > more SIP messages, but I don't see how to avoid that and be > > > > > consistent with the SIP architecture. It's really weird for > > > > > a REGISTER response to indicate media capabilities of the=20 > > > Registrar. > > > >=20 > > > > use of OPTIONS was discussed, but due to the additional=20 > > > signalling, it > > > > was discarded. > > >=20 > > > Considering all of the other signaling already required=20 > > > (subscription to reg-event, subscription to presence, xcap,=20 > > > possibly subscription to Config server) isn't an OPTIONS just=20 > > > a nit at this point? And that way this could be a general=20 > > > solution, instead of a 3gpp-specific one. > > >=20 > > >=20 > > > > The indication of network support for SDES-SRTP in response=20 > > > to REGISTER > > > > is not included by the registrar, but by the network=20 > > > element placed at > > > > the edge (the SBC/B2BUA) > > >=20 > > > I know, but from the UA's perspective the REGISTER response=20 > > > is coming from the Registrar, possibly through proxies. =20 > > > There's no logical/conceptual model in the IETF for a=20 > > > REGISTER response to indicate media capabilities of some=20 > > > middle hop of the REGISTER. > > >=20 > > > -hadriel > > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 From victor.pascual.avila@gmail.com Thu May 20 03:05:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E403A67F6 for ; Thu, 20 May 2010 03:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbIfOhiHElFY for ; Thu, 20 May 2010 03:05:54 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id AE29A3A67E6 for ; Thu, 20 May 2010 03:05:53 -0700 (PDT) Received: by fxm12 with SMTP id 12so538474fxm.31 for ; Thu, 20 May 2010 03:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3xXB8Ci3m/muiNNXowQFdnNpna95WwPAEY6uHlX7//w=; b=OydmU5bDZyJVKlKuIMVw8Vm6nj3zFznuonVNxaNgG6PsGvjcWUQsH6eTJ4y2SQIIwf MCSDRbYgMhmzT8kFvsAuFdMgp7odvuInGfSqGWZ00wuK+bMq3OzRRsggt3ImINcCWnTq 29BN+9NL4bDmizaEMkmcsOzR+82cLO5dE+/7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KUxjOCSkHtvrRyUhfs6eOiO3KKB07oXpuH95JjqD9s6jPDJ7PIjzt1YeK1LWatxuKA P+XRqxCoiovPsJFIODcODt4UQO6AUSlrPngcf1HjTJq+HKP9U5+XvV020wygLUwsAEOg m6wd/joGsX6zCTF2T8nhfildU627IowzYy590= MIME-Version: 1.0 Received: by 10.103.127.8 with SMTP id e8mr210697mun.39.1274349943581; Thu, 20 May 2010 03:05:43 -0700 (PDT) Received: by 10.204.70.141 with HTTP; Thu, 20 May 2010 03:05:43 -0700 (PDT) In-Reply-To: <4BF4E72B.7060600@ericsson.com> References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com> Date: Thu, 20 May 2010 12:05:43 +0200 Message-ID: From: Victor Pascual Avila To: Gonzalo Camarillo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] Alert Info URNs - Acronym X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 10:05:55 -0000 On Thu, May 20, 2010 at 9:39 AM, Gonzalo Camarillo wrote: > note that we also need an acronym for this WG proposal. We have so many > WGs and drafts about drinking in RAI that we are going to need a few > URINALS (URNs for INforming about ALerting in SIP) pretty soon! :o) +1 Given drinks, martini, gin and vermouth... we will really need urinals := -) --=20 Victor Pascual =C3=81vila From pkyzivat@cisco.com Thu May 20 05:59:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3749F3A6BB1 for ; Thu, 20 May 2010 05:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.232 X-Spam-Level: X-Spam-Status: No, score=-10.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDWRuPfSS7og for ; Thu, 20 May 2010 05:59:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 27C2A3A6990 for ; Thu, 20 May 2010 05:59:18 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC7P9EtAZnwM/2dsb2JhbACeCHGjKplRglEJgjgEj3c X-IronPort-AV: E=Sophos;i="4.53,271,1272844800"; d="scan'208";a="112887589" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 20 May 2010 12:59:10 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4KCxADA010485; Thu, 20 May 2010 12:59:10 GMT Message-ID: <4BF5321E.1070806@cisco.com> Date: Thu, 20 May 2010 08:59:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 12:59:21 -0000 Ranjit, I just now got the time to look at this draft for the first time. There is indeed a great deal of similarity between this and the CDIV draft in terms of mechanisms, formats, and concepts. I'm neutral on whether these should be one event package or two. (Certainly it *could* be one - perhaps reporting on each incoming call together with its outcome, with filters to select the sorts of calls or outcomes of interest.) But because of the similarity, I see most of the same issues with this draft as with the CDIV draft. Thanks, Paul Avasarala Ranjit-A20990 wrote: > Hi All > > Any further comments on this I-D and suggestions for next steps? > > Thanks > > > Regards > Ranjit > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Avasarala Ranjit-A20990 > Sent: Friday, May 14, 2010 11:49 AM > To: Elwell, John; dispatch@ietf.org > Subject: Re: [dispatch] FW: New Version > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > > Hi John > > This I-D on communication barring notification talks about an event > package for reporting the notification information of communication > barrings (call blocking) that happen in the network on behalf of the > users. > > For e.g if Alice sets a call blocking rule that all calls from Bob need > to be blocked, then the network blocks all calls from Bob towards Alice. > So here > The notification information will include the details of the call block > - i.e (1) the identity of caller (Bob) (2) time of block (2) reason for > block, etc > > Yes I agree with you that there is synergy between this I-D and the one > on CDIV, since both of them deal with reporting of events that occur in > the network. While CDIV deals with communication diversion, this one > deals with ICB service. Though both the event packages are similar in > terms of subscriptions and format, their execution and user preference > may vary. So they need to be looked at differently and standardized > seperately. > > > Regards > Ranjit > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, May 13, 2010 6:25 PM > To: Avasarala Ranjit-A20990; dispatch@ietf.org > Cc: T Satyanarayana-A12694 > Subject: RE: [dispatch] FW: New Version Notification > fordraft-avasarala-dispatch-comm-barring-notification-00 > > Ranjit, > > It is not entirely clear to me what the notifications report. For > example, in 6.7, it says "Typically, it will send > one when a communication barring is enacted on behalf of the user." > > What is meant by "enacted" here? Is it when some entity, on behalf of > the user, perhaps through some web page, establishes a communication > barring rule? Or is it when an inbound communication arrives and is > processed in accordance with some pre-existing communication barring > rule? I thought at first it was the former, but I am tending towards > thinking it is the latter. Some clarification would be useful. > > Assuming it is the latter, there is obviously some synergy with > draft-avasarala-dispatch-comm-div-notification. Both deal with reporting > inbound communications that have been subject to some rule, the rule > being conditional on certain criteria such as caller ID. Where the > conditions are met for a given call to be subject to a given rule, a > notification in accordance with one or the other event package will be > triggered. I fail to see the reason for having two separate event > packages, since this means two separate specifications, two different > subscriptions, two different formats, etc.. > > John > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala >> Ranjit-A20990 >> Sent: 13 May 2010 11:28 >> To: dispatch@ietf.org >> Cc: T Satyanarayana-A12694 >> Subject: [dispatch] FW: New Version Notification for >> draft-avasarala-dispatch-comm-barring-notification-00 >> >> Hi all >> >> I have submitted a new I-D on communication barring notification >> information based on the following >> >> Section 8.2.10 Communication Barring - ICB enhancement of dynamic >> blocking of incoming communications of 3GPP TS 22.173 >> >> Section 4.5.2.6.1 Actions for ICB at the terminating AS of 3GPP TS >> 24.611 >> >> The draft can be accessed from: >> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n >> otificatio >> n-00.txt >> >> Please review and comment. >> >> Thanks >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> Sent: Thursday, May 13, 2010 3:47 PM >> To: Avasarala Ranjit-A20990 >> Cc: r.jesske@telekom.de >> Subject: New Version Notification for >> draft-avasarala-dispatch-comm-barring-notification-00 >> >> >> A new version of I-D, >> draft-avasarala-dispatch-comm-barring-notification-00.txt has been >> successfully submitted by Ranjit Avasarala and posted to the IETF >> repository. >> >> Filename: draft-avasarala-dispatch-comm-barring-notification >> Revision: 00 >> Title: A Session Initiation Protocol (SIP) >> Event Package for >> Communication Barring Notification Information in support of the >> Dynamic Incoming Communication Barring (ICB) Notification service >> Creation_date: 2010-05-13 >> WG ID: Independent Submission >> Number_of_pages: 22 >> >> Abstract: >> 3GPP is defining the protocol specification for the Communication >> Barring (CB) service using IP Multimedia (IM) Core Network (CN) >> subsystem supplementary service and more particularly the dynamic >> incoming communication barring service. As part of dynamic incoming >> communication barring (ICB) service, a SIP based Event package >> framework is used for notifying users about communication barrings >> (dynamic and rule based) of their incoming communication sessions. >> This document proposes a new SIP event package for allowing users to >> subscribe to and receive such notifications. Users can further define > >> filters to control the rate and content of such notifications. >> The proposed event package is applicable to the ICB supplementary >> service in IMS and may not be applicable to the general internet. >> >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Thu May 20 06:05:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333C43A6C50 for ; Thu, 20 May 2010 06:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.027 X-Spam-Level: X-Spam-Status: No, score=-9.027 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DMc4KZk-zGG for ; Thu, 20 May 2010 06:05:31 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F41733A6C30 for ; Thu, 20 May 2010 06:05:09 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFANLQ9EtAZnwM/2dsb2JhbACRKIxgcaMtmVKFEgQ X-IronPort-AV: E=Sophos;i="4.53,271,1272844800"; d="scan'208";a="113023380" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 May 2010 13:05:02 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4KD52jQ013848; Thu, 20 May 2010 13:05:02 GMT Message-ID: <4BF5337E.4040906@cisco.com> Date: Thu, 20 May 2010 09:05:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <430FC6BDED356B4C8498F634416644A91C13990F46@mail> <4bec4e62.0c58560a.188d.ffff9205@mx.google.com> <430FC6BDED356B4C8498F634416644A91C1399121F@mail> <4BF43FDC.2030006@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , "R.Jesske@telekom.de" , Hadriel Kaplan Subject: [dispatch] Alert-Info URNs - alternative renderings X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 13:05:33 -0000 I changed the subject to be consistent with the content Christer Holmberg wrote: > Hi, > >>> Alert-Info URNs represent tones. The receiving end device only >>> resolves it to a tone and plays the tone. Nothing else. The end >>> device does not look at what the Alert-Info URN means, but only if it >>> has rules to resolve it to a concrete tone. If it has, it resolves the >>> URN, otherwise the URN is discarded. It can be call waiting or >>> Bethoven Fifth or the combination internal+short. The >>> network will not use the Alert-info URNs for the call control logic. The RFC 3261 >>> allows Alert-Info in INVITE and 180. People agreed on the ML to exten >>> this to 18x. >> I'd like to take issue with the above. >> Due to precedent we all are biased towards *audio* alerts, >> but alerts need not be tones, or audio at all. Even for >> people who can hear, alerts that are, in part or wholly, >> non-audio are also important. E.g. >> everybody has reason to put their cellphone into vibrate mode >> at times. > > Of course. In that case you won't get an audio alert - no matter if you use Alert-Info or your "default" audio ring tone. This is one of the values of Alert-Info URNs. The different alerting modes of your phone (normal, vibrate, ...) can simply select alternative sets of renderings of all the supported Alert-Info URNs. Thanks, Paul From pkyzivat@cisco.com Thu May 20 06:17:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6843A6995 for ; Thu, 20 May 2010 06:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF8Ar5hNYyuw for ; Thu, 20 May 2010 06:17:49 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 160DF3A6CE1 for ; Thu, 20 May 2010 06:16:57 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHfS9EtAZnwM/2dsb2JhbACeCHGjSJlTglEJgjgEj3c X-IronPort-AV: E=Sophos;i="4.53,271,1272844800"; d="scan'208";a="112894514" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 20 May 2010 13:16:49 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4KDGnS7019072; Thu, 20 May 2010 13:16:49 GMT Message-ID: <4BF53641.3070105@cisco.com> Date: Thu, 20 May 2010 09:16:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 13:17:51 -0000 Avasarala Ranjit-A20990 wrote: > Hi > > So is the consensus to proceed forward? Proceed forward in what way? Are you asking for a new WG? Thanks, Paul > Regards > Ranjit > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, May 20, 2010 12:15 PM > To: Avasarala Ranjit-A20990; dispatch@ietf.org > Cc: R.Jesske@telekom.de > Subject: RE: [dispatch] FW: New Version > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > > Sorry, I thought I had already responded, but clearly not. > > I am still of the opinion that there is sufficient synergy between the > two event packages that they can be combined into a single event > package. This would have the benefit of being able to have a single > subscription to get all information relating to automatic handling of > incoming calls, rather than being forced to subscribe twice. If you only > want information about diverted calls, or only information about barred > calls, you could filter accordingly. If you want different filtering > criteria, or different subscription times for the two, there is nothing > to stop you having two separate subscriptions. But we should not > penalise the simple case by forcing two subscriptions where one would > do. > > John > >> -----Original Message----- >> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] >> Sent: 20 May 2010 05:33 >> To: Elwell, John; dispatch@ietf.org >> Cc: R.Jesske@telekom.de >> Subject: RE: [dispatch] FW: New Version >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> Hi All >> >> Any further comments on this I-D and suggestions for next steps? >> >> Thanks >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Avasarala Ranjit-A20990 >> Sent: Friday, May 14, 2010 11:49 AM >> To: Elwell, John; dispatch@ietf.org >> Subject: Re: [dispatch] FW: New Version >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> Hi John >> >> This I-D on communication barring notification talks about an event >> package for reporting the notification information of communication >> barrings (call blocking) that happen in the network on behalf of the >> users. >> >> For e.g if Alice sets a call blocking rule that all calls from Bob >> need to be blocked, then the network blocks all calls from Bob towards > >> Alice. >> So here >> The notification information will include the details of the call >> block >> - i.e (1) the identity of caller (Bob) (2) time of block (2) reason >> for block, etc >> >> Yes I agree with you that there is synergy between this I-D and the >> one on CDIV, since both of them deal with reporting of events that >> occur in the network. While CDIV deals with communication diversion, >> this one deals with ICB service. Though both the event packages are >> similar in terms of subscriptions and format, their execution and user > >> preference may vary. So they need to be looked at differently and >> standardized seperately. >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Thursday, May 13, 2010 6:25 PM >> To: Avasarala Ranjit-A20990; dispatch@ietf.org >> Cc: T Satyanarayana-A12694 >> Subject: RE: [dispatch] FW: New Version Notification >> fordraft-avasarala-dispatch-comm-barring-notification-00 >> >> Ranjit, >> >> It is not entirely clear to me what the notifications report. For >> example, in 6.7, it says "Typically, it will send >> one when a communication barring is enacted on behalf of the user." >> >> What is meant by "enacted" here? Is it when some entity, on behalf of >> the user, perhaps through some web page, establishes a communication >> barring rule? Or is it when an inbound communication arrives and is >> processed in accordance with some pre-existing communication barring >> rule? I thought at first it was the former, but I am tending towards >> thinking it is the latter. Some clarification would be useful. >> >> Assuming it is the latter, there is obviously some synergy with >> draft-avasarala-dispatch-comm-div-notification. Both deal with >> reporting inbound communications that have been subject to some rule, >> the rule being conditional on certain criteria such as caller ID. >> Where the conditions are met for a given call to be subject to a given > >> rule, a notification in accordance with one or the other event package > >> will be triggered. I fail to see the reason for having two separate >> event packages, since this means two separate specifications, two >> different subscriptions, two different formats, etc.. >> >> John >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala >>> Ranjit-A20990 >>> Sent: 13 May 2010 11:28 >>> To: dispatch@ietf.org >>> Cc: T Satyanarayana-A12694 >>> Subject: [dispatch] FW: New Version Notification for >>> draft-avasarala-dispatch-comm-barring-notification-00 >>> >>> Hi all >>> >>> I have submitted a new I-D on communication barring notification >>> information based on the following >>> >>> Section 8.2.10 Communication Barring - ICB enhancement of dynamic >>> blocking of incoming communications of 3GPP TS 22.173 >>> >>> Section 4.5.2.6.1 Actions for ICB at the terminating AS of 3GPP TS >>> 24.611 >>> >>> The draft can be accessed from: >>> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n >>> otificatio >>> n-00.txt >>> >>> Please review and comment. >>> >>> Thanks >>> >>> >>> Regards >>> Ranjit >>> >>> -----Original Message----- >>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>> Sent: Thursday, May 13, 2010 3:47 PM >>> To: Avasarala Ranjit-A20990 >>> Cc: r.jesske@telekom.de >>> Subject: New Version Notification for >>> draft-avasarala-dispatch-comm-barring-notification-00 >>> >>> >>> A new version of I-D, >>> draft-avasarala-dispatch-comm-barring-notification-00.txt has been >>> successfully submitted by Ranjit Avasarala and posted to the IETF >>> repository. >>> >>> Filename: draft-avasarala-dispatch-comm-barring-notification >>> Revision: 00 >>> Title: A Session Initiation Protocol (SIP) >>> Event Package for >>> Communication Barring Notification Information in support of the >>> Dynamic Incoming Communication Barring (ICB) Notification service >>> Creation_date: 2010-05-13 >>> WG ID: Independent Submission >>> Number_of_pages: 22 >>> >>> Abstract: >>> 3GPP is defining the protocol specification for the Communication >>> Barring (CB) service using IP Multimedia (IM) Core Network (CN) >>> subsystem supplementary service and more particularly the dynamic >>> incoming communication barring service. As part of dynamic >> incoming >>> communication barring (ICB) service, a SIP based Event package >>> framework is used for notifying users about communication barrings >>> (dynamic and rule based) of their incoming communication sessions. >>> This document proposes a new SIP event package for allowing >> users to >>> subscribe to and receive such notifications. Users can >> further define >> >>> filters to control the rate and content of such notifications. >>> The proposed event package is applicable to the ICB supplementary >>> service in IMS and may not be applicable to the general internet. >>> >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> _______________________________________________ >>> 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 john.elwell@siemens-enterprise.com Thu May 20 06:43:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C4FF3A69CC for ; Thu, 20 May 2010 06:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22RRJhduADiu for ; Thu, 20 May 2010 06:43:26 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 206833A69EB for ; Thu, 20 May 2010 06:43:17 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-238199; Thu, 20 May 2010 15:43:10 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id D57671EB82AB; Thu, 20 May 2010 15:43:10 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 20 May 2010 15:43:10 +0200 From: "Elwell, John" To: "Leis, Peter (NSN - DE/Munich)" , ext Hadriel Kaplan , "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Date: Thu, 20 May 2010 15:43:09 +0200 Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sADKuJwAAoMDiCAACXnDkA== Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail><430FC6BDED356B4C8498F634416644A91A8A5F1711@mail><430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 13:43:28 -0000 Peter, I could not locate the particular requirements in the referenced document, = which does not seem to have a Requirements section as such. Please cite the= particular requirements that answer my questions and point to the section/= paragraph where rationale for those requirements is given. The Internet Draft will need to be enhanced to give more rationale for requ= irements, rather than rely on reference to a relatively large external docu= ment that allegedly has requirements hidden somewhere within it. Thanks, John=20 > -----Original Message----- > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com]=20 > Sent: 20 May 2010 10:05 > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group;=20 > dispatch@ietf.org > Subject: RE: [dispatch] New I-D:=20 > draft-dawes-dispatch-mediasec-parameter-01 >=20 > hello, >=20 > sorry for the late reply. >=20 > The requirments for media-plane security in 3GPP IMS have been defined > in TS 33.328 http://www.3gpp.org/ftp/Specs/html-info/33328.htm .=20 >=20 > For SDES SRTP there are two modes defined, one is end2end and one is > end2accessedge. We need to provide a solution for both modes. >=20 > And for end2accessedge we do have a requirement that the UE knows > whether or not the network (P-CSCF) will support SDES-SRTP before the > session takes place as described below. >=20 > Peter >=20 > > -----Original Message----- > > From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > > Sent: Friday, May 07, 2010 4:17 PM > > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes,=20 > > Peter, VF-Group; dispatch@ietf.org > > Subject: RE: [dispatch] New I-D:=20 > > draft-dawes-dispatch-mediasec-parameter-01 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org=20 > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Leis, Peter=20 > > > (NSN - DE/Munich) > > > Sent: 03 May 2010 14:32 > > > To: ext Hadriel Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org > > > Subject: Re: [dispatch] New I-D:=20 > > > draft-dawes-dispatch-mediasec-parameter-01 > > >=20 > > >=20 > > > comments inline=20 > > >=20 > > > > -----Original Message----- > > > > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > > > > Sent: Friday, April 30, 2010 5:47 PM > > > > To: Leis, Peter (NSN - DE/Munich); Dawes, Peter, VF-Group;=20 > > > > dispatch@ietf.org > > > > Subject: RE: [dispatch] New I-D:=20 > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Leis, Peter (NSN - DE/Munich)=20 > [mailto:peter.leis@nsn.com] > > > > > Sent: Friday, April 30, 2010 4:17 AM > > > > > To: Hadriel Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > > > Sent: Thursday, April 29, 2010 6:59 PM > > > > > > > > > > > > Right, but I'm trying to figure out why that is. I mean > > > > > > what's the reason the UA needs to know at Registration time > > > > > > that it's next-hop b2bua can do srtp, instead of letting SDP > > > > > > handle it? > > > > > > > > > > > > I *think* the answer is so that it can later send an INVITE > > > > > > with an SDP offer without failing the request - is that=20 > > > > the reason? > > > > >=20 > > > > > Right > > > > =20 > > > > OK, and I also agree that's a real problem. That issue was=20 > > > > raised in the IETF in 2006/2007. There was a very simple=20 > > > > proposal to avoid that, in=20 > > > > draft-kaplan-mmusic-best-effort-srtp, but the decision of the=20 > > > > MMUSIC WG was to instead use=20 > > > > draft-ietf-mmusic-sdp-capability-negotiation to accomplish=20 > > > > it. That draft is now in the RFC editor's queue. I know=20 > > > > it's a lot of processing overhead, but that was the decision.=20 > > > > And I think 3gpp has put support for that into some=20 > > > release or other. > > > >=20 > > >=20 > > > The requirement in 3GPP is, that the UE has to know whether=20 > > or not the > > > network (P-CSCF) will support SDES-SRTP before the session=20 > > > takes place, > > > if it wants to employ End2AccessEdge media plane=20 > security. This will > > > ensure that the IMS UE shares the media keys only with the=20 > > P-CSCF and > > > not with some other entity.=20 > > [JRE] Why would the UE "want to employ End2AccessEdge" media=20 > > plane security, as opposed to E2E media plane security? I=20 > > would have thought the UE would always prefer the latter.=20 > > Furthermore, the UE should not use keys that have value=20 > > outside this particular communication session, so if they get=20 > > passed on beyond the P-CSCF, no harm is done. In fact, if=20 > > they reach the remote UA, you can end up with E2E security,=20 > > which would be great from the UE's perspective. > >=20 > > > In addition, in 3GPP there is a=20 > > > requirement > > > that the UE knows whether media plane security is=20 > > established between > > > itself and the network (i.e. End2AccessEdge), or whether=20 > media plane > > > security is established between itself and the far end.=20 > > [JRE] That would be interesting to know, but it is a more=20 > > general problem - any B2BUA can terminate SRTP, and SIP does=20 > > not provide any mechanism to indicate whether SRTP is truly=20 > > end-to-end or just end-to-some-B2BUA. Also a gateway to TDM=20 > > will terminate SRTP, and SIP does not provide any means of=20 > > indicating whether SRTP is truly end-to-end or=20 > > end-to-first-TDM-gateway. > >=20 > > John > >=20 > > >=20 > > > As you said, CapNeg has a lot of processing overhead, and=20 > > in addition, > > > it does not solve the requirements I have listed. > > >=20 > > >=20 > > > >=20 > > > > > > > RFC 3840 does only cover UA indicating support,=20 > but not SBC > > > > > > indicating > > > > > > > support. > > > > > > > > > > > > Actually, in a way it does. An SBC is a B2BUA. As a UA, it > > > > > > can indicate feature tags. What it *can't* do is=20 > indicate it > > > > > > in the REGISTER response it sends to the UA. But the UA > > > > > > could send an OPTIONS to the B2BUA and get it in a feature > > > > > > tag of the response to the OPTIONS. I know it sucks to send > > > > > > more SIP messages, but I don't see how to avoid that and be > > > > > > consistent with the SIP architecture. It's really weird for > > > > > > a REGISTER response to indicate media capabilities of the=20 > > > > Registrar. > > > > >=20 > > > > > use of OPTIONS was discussed, but due to the additional=20 > > > > signalling, it > > > > > was discarded. > > > >=20 > > > > Considering all of the other signaling already required=20 > > > > (subscription to reg-event, subscription to presence, xcap,=20 > > > > possibly subscription to Config server) isn't an OPTIONS just=20 > > > > a nit at this point? And that way this could be a general=20 > > > > solution, instead of a 3gpp-specific one. > > > >=20 > > > >=20 > > > > > The indication of network support for SDES-SRTP in response=20 > > > > to REGISTER > > > > > is not included by the registrar, but by the network=20 > > > > element placed at > > > > > the edge (the SBC/B2BUA) > > > >=20 > > > > I know, but from the UA's perspective the REGISTER response=20 > > > > is coming from the Registrar, possibly through proxies. =20 > > > > There's no logical/conceptual model in the IETF for a=20 > > > > REGISTER response to indicate media capabilities of some=20 > > > > middle hop of the REGISTER. > > > >=20 > > > > -hadriel > > > >=20 > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > >=20 > = From laura.liess.dt@googlemail.com Thu May 20 06:43:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1443A69CC for ; Thu, 20 May 2010 06:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FonWcJy5e00n for ; Thu, 20 May 2010 06:43:28 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 2738E3A6AC9 for ; Thu, 20 May 2010 06:43:18 -0700 (PDT) Received: by wwb24 with SMTP id 24so1532419wwb.31 for ; Thu, 20 May 2010 06:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OA+MbFBmyctIuJ+phyum9m7AI/FwM17KCKpgQfwcxDg=; b=OZSDR52ShQeGncwyYjB9XlbTB0gumlexHA8ovubRBbxEFg5mSuAgsH4YWAKwyl+4zW y9aeKD63tMqC3QgrM0HSdWIj3orTUC9HeBfbofd7u3PqmprrMmso7+bJjGXaUHj69CX4 K2ICFWqIgnVNDLZQQQCn3rtinmL6wGsWi6UOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y20lSI1X8jJLU6ytMUYVn8YrhqgiPd0kOdA8WOJ9Mu1/6BVPBsdeE9xP2IKMRDMMY8 2JF4URDeufrWnXS0pXUqBHn6SP5je+rvFHD7LtfSHTPIXs71egmMJlWZlfAA9cZKtjg1 GdGTj0KaqYNSj6o3iD9tMFsZPYTlIguQbOh14= MIME-Version: 1.0 Received: by 10.216.87.204 with SMTP id y54mr329293wee.142.1274362988436; Thu, 20 May 2010 06:43:08 -0700 (PDT) Received: by 10.216.178.133 with HTTP; Thu, 20 May 2010 06:43:02 -0700 (PDT) In-Reply-To: <4BF3F281.8080102@ericsson.com> References: <4BF3F281.8080102@ericsson.com> Date: Thu, 20 May 2010 15:43:02 +0200 Message-ID: From: Laura Liess To: Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH Subject: Re: [dispatch] Alert Info URNs - Revised charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 13:43:29 -0000 I have two issues here: 1) On the ML we discussed allowing the usege of Alert-Info in 18x instead of only 180 (as currently allowed in 3261). Do we need to mention this in the charter in some way? 2) I think Apr 2011 - Alert-Info URN specification to IESG (PS) is no longer realistic. I would propose Aug 2011. Thanks Laura 2010/5/19 Gonzalo Camarillo : > Hi, > > thanks for all the good discussions around the Alert-Info URNs charter > proposal. They actually helped clarify a few important concepts. I have > revised the charter proposal taking into account all the feedback > received (see attachment). > > Please, let me know if you are happy with this proposal so that I can > get the IESG to review it. > > Thanks, > > Gonzalo > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From laura.liess.dt@googlemail.com Thu May 20 06:47:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07AD23A67F7 for ; Thu, 20 May 2010 06:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPqziyS6O-l2 for ; Thu, 20 May 2010 06:47:33 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B88A13A6AC4 for ; Thu, 20 May 2010 06:47:32 -0700 (PDT) Received: by wyb32 with SMTP id 32so1583277wyb.31 for ; Thu, 20 May 2010 06:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=x/mdJ1+vJulcemVm5i05gbs84C9gdO/4FQmAgXKQLtA=; b=RmC6PFPDkhAbV5sNjSHZntU21hj868SfdVIxRot5tc0ww5nufJauaXxZyEh1Ac7YTw iUgncMrBoGlU+31ROEnoECfkVLoJDaak2qpcisS+doq9edjatbhGsRcMjt51yjRe2tl9 bg3uLvW6cLvOCvWUwLlBg1wNdIo64VVJRoBi4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v4LKRVfqSOKhDbD29C9XKBASR6+fYjE6yvPVvOAIesp7Z0xY+i2DidiLsnlyYaQ0RL DA+Px8xBAqdBxbRd/WEDjy6r0uU+HoiweSo4RJcCBK77p9gxzVPhnA5GhTCy89NVX9fT 7RR8fIkKnOkKwTJsgO9ixY8JtaqH1Xc/8EvCY= MIME-Version: 1.0 Received: by 10.216.88.196 with SMTP id a46mr680325wef.36.1274363241920; Thu, 20 May 2010 06:47:21 -0700 (PDT) Received: by 10.216.178.133 with HTTP; Thu, 20 May 2010 06:47:20 -0700 (PDT) In-Reply-To: <4BF4E72B.7060600@ericsson.com> References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com> Date: Thu, 20 May 2010 15:47:20 +0200 Message-ID: From: Laura Liess To: Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH Subject: Re: [dispatch] Alert Info URNs - Acronym X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 13:47:34 -0000 I would really prefer some other acronym, e.g. the one proposed in the charter: SAIU (SIP Alert-Info URN). Thanks Laura 2010/5/20 Gonzalo Camarillo : > Hi, > > note that we also need an acronym for this WG proposal. We have so many > WGs and drafts about drinking in RAI that we are going to need a few > URINALS (URNs for INforming about ALerting in SIP) pretty soon! :o) > > We are of course open to better proposals! > > Thanks, > > Gonzalo > > On 19/05/2010 5:15 PM, Gonzalo Camarillo wrote: >> Hi, >> >> thanks for all the good discussions around the Alert-Info URNs charter >> proposal. They actually helped clarify a few important concepts. I have >> revised the charter proposal taking into account all the feedback >> received (see attachment). >> >> Please, let me know if you are happy with this proposal so that I can >> get the IESG to review it. >> >> Thanks, >> >> Gonzalo >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From ranjit@motorola.com Thu May 20 07:29:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3623A6CEC for ; Thu, 20 May 2010 07:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TAGrMkUBEs2 for ; Thu, 20 May 2010 07:29:05 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 29FAF3A6A2C for ; Thu, 20 May 2010 07:27:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-8.tower-55.messagelabs.com!1274365644!103663612!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2961 invoked from network); 20 May 2010 14:27:24 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 May 2010 14:27:24 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o4KERItg009679 for ; Thu, 20 May 2010 07:27:23 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o4KERIaf000933 for ; Thu, 20 May 2010 09:27:18 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o4KERHx7000926 for ; Thu, 20 May 2010 09:27:17 -0500 (CDT) 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, 20 May 2010 22:26:53 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> In-Reply-To: <4BF53641.3070105@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 thread-index: Acr4HrsB6YVUeSS7Ra+OGP80vQn7uwACZXwg References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> From: "Avasarala Ranjit-A20990" To: "Paul Kyzivat" X-CFilter-Loop: Reflected Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 14:29:06 -0000 Hi Paul No I am not asking for a new WG. I wanted directions to take this I-D forward. Like should we merge it with CDIV one as John Elwell was suggesting or keep this separate - which I think is better.=20 Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Thursday, May 20, 2010 6:47 PM To: Avasarala Ranjit-A20990 Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 Avasarala Ranjit-A20990 wrote: > Hi >=20 > So is the consensus to proceed forward?=20 Proceed forward in what way? Are you asking for a new WG? Thanks, Paul > Regards > Ranjit >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, May 20, 2010 12:15 PM > To: Avasarala Ranjit-A20990; dispatch@ietf.org > Cc: R.Jesske@telekom.de > Subject: RE: [dispatch] FW: New Version=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >=20 > Sorry, I thought I had already responded, but clearly not. >=20 > I am still of the opinion that there is sufficient synergy between the > two event packages that they can be combined into a single event=20 > package. This would have the benefit of being able to have a single=20 > subscription to get all information relating to automatic handling of=20 > incoming calls, rather than being forced to subscribe twice. If you=20 > only want information about diverted calls, or only information about=20 > barred calls, you could filter accordingly. If you want different=20 > filtering criteria, or different subscription times for the two, there > is nothing to stop you having two separate subscriptions. But we=20 > should not penalise the simple case by forcing two subscriptions where > one would do. >=20 > John >=20 >> -----Original Message----- >> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] >> Sent: 20 May 2010 05:33 >> To: Elwell, John; dispatch@ietf.org >> Cc: R.Jesske@telekom.de >> Subject: RE: [dispatch] FW: New Version=20 >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> Hi All >> >> Any further comments on this I-D and suggestions for next steps? >> >> Thanks >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Avasarala Ranjit-A20990 >> Sent: Friday, May 14, 2010 11:49 AM >> To: Elwell, John; dispatch@ietf.org >> Subject: Re: [dispatch] FW: New Version=20 >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> Hi John >> >> This I-D on communication barring notification talks about an event=20 >> package for reporting the notification information of communication=20 >> barrings (call blocking) that happen in the network on behalf of the=20 >> users. >> >> For e.g if Alice sets a call blocking rule that all calls from Bob=20 >> need to be blocked, then the network blocks all calls from Bob=20 >> towards >=20 >> Alice. >> So here >> The notification information will include the details of the call=20 >> block >> - i.e (1) the identity of caller (Bob) (2) time of block (2) reason=20 >> for block, etc >> >> Yes I agree with you that there is synergy between this I-D and the=20 >> one on CDIV, since both of them deal with reporting of events that=20 >> occur in the network. While CDIV deals with communication diversion,=20 >> this one deals with ICB service. Though both the event packages are=20 >> similar in terms of subscriptions and format, their execution and=20 >> user >=20 >> preference may vary. So they need to be looked at differently and=20 >> standardized seperately. >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Thursday, May 13, 2010 6:25 PM >> To: Avasarala Ranjit-A20990; dispatch@ietf.org >> Cc: T Satyanarayana-A12694 >> Subject: RE: [dispatch] FW: New Version Notification=20 >> fordraft-avasarala-dispatch-comm-barring-notification-00 >> >> Ranjit, >> >> It is not entirely clear to me what the notifications report. For=20 >> example, in 6.7, it says "Typically, it will send >> one when a communication barring is enacted on behalf of the user." >> >> What is meant by "enacted" here? Is it when some entity, on behalf of >> the user, perhaps through some web page, establishes a communication=20 >> barring rule? Or is it when an inbound communication arrives and is=20 >> processed in accordance with some pre-existing communication barring=20 >> rule? I thought at first it was the former, but I am tending towards=20 >> thinking it is the latter. Some clarification would be useful. >> >> Assuming it is the latter, there is obviously some synergy with=20 >> draft-avasarala-dispatch-comm-div-notification. Both deal with=20 >> reporting inbound communications that have been subject to some rule, >> the rule being conditional on certain criteria such as caller ID. >> Where the conditions are met for a given call to be subject to a=20 >> given >=20 >> rule, a notification in accordance with one or the other event=20 >> package >=20 >> will be triggered. I fail to see the reason for having two separate=20 >> event packages, since this means two separate specifications, two=20 >> different subscriptions, two different formats, etc.. >> >> John >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 >>> Ranjit-A20990 >>> Sent: 13 May 2010 11:28 >>> To: dispatch@ietf.org >>> Cc: T Satyanarayana-A12694 >>> Subject: [dispatch] FW: New Version Notification for=20 >>> draft-avasarala-dispatch-comm-barring-notification-00 >>> >>> Hi all >>> >>> I have submitted a new I-D on communication barring notification=20 >>> information based on the following >>> >>> Section 8.2.10 Communication Barring - ICB enhancement of dynamic=20 >>> blocking of incoming communications of 3GPP TS 22.173 >>> >>> Section 4.5.2.6.1 Actions for ICB at the terminating AS of 3GPP TS >>> 24.611 >>> >>> The draft can be accessed from: >>> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n >>> otificatio >>> n-00.txt >>> >>> Please review and comment. >>> >>> Thanks >>> >>> >>> Regards >>> Ranjit >>> >>> -----Original Message----- >>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>> Sent: Thursday, May 13, 2010 3:47 PM >>> To: Avasarala Ranjit-A20990 >>> Cc: r.jesske@telekom.de >>> Subject: New Version Notification for=20 >>> draft-avasarala-dispatch-comm-barring-notification-00 >>> >>> >>> A new version of I-D, >>> draft-avasarala-dispatch-comm-barring-notification-00.txt has been=20 >>> successfully submitted by Ranjit Avasarala and posted to the IETF=20 >>> repository. >>> >>> Filename: draft-avasarala-dispatch-comm-barring-notification >>> Revision: 00 >>> Title: A Session Initiation Protocol (SIP)=20 >>> Event Package for >>> Communication Barring Notification Information in support of the=20 >>> Dynamic Incoming Communication Barring (ICB) Notification service >>> Creation_date: 2010-05-13 >>> WG ID: Independent Submission >>> Number_of_pages: 22 >>> >>> Abstract: >>> 3GPP is defining the protocol specification for the Communication=20 >>> Barring (CB) service using IP Multimedia (IM) Core Network (CN)=20 >>> subsystem supplementary service and more particularly the dynamic=20 >>> incoming communication barring service. As part of dynamic >> incoming >>> communication barring (ICB) service, a SIP based Event package=20 >>> framework is used for notifying users about communication barrings=20 >>> (dynamic and rule based) of their incoming communication sessions. >>> This document proposes a new SIP event package for allowing >> users to >>> subscribe to and receive such notifications. Users can >> further define >> >>> filters to control the rate and content of such notifications. >>> The proposed event package is applicable to the ICB supplementary=20 >>> service in IMS and may not be applicable to the general internet. >>> =20 >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> _______________________________________________ >>> 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 mary.ietf.barnes@gmail.com Thu May 20 08:17:40 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F1D3A6B19 for ; Thu, 20 May 2010 08:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NClw-GnpSClU for ; Thu, 20 May 2010 08:17:39 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 69BCB3A6933 for ; Thu, 20 May 2010 08:17:39 -0700 (PDT) Received: by iwn42 with SMTP id 42so4485302iwn.31 for ; Thu, 20 May 2010 08:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ZoSHUgNPrBga9LAytHnQrH66xIarsM4ItUCNyPBJIlA=; b=RWJ5Ze+Tu/PPKQblVkYjofyVtbQQgb3mNh5OnfvI7KR45kPV/ph98uXdSgIfID6wjT Ij2rMVvKOTgsdYI7RUEdYF8byv7Dsp5dJ0eh+8TQIClNzzwcJ9Yac2Zn56SqyDIbKHS9 Ogg+iHbyyzjoOTnsZ//P0eYje5Rj8Mpt3ZWb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lMOnjyEKFQQp/mYcqh9HDvlMyXD2+BWN0fQ/dpRizSJRgO1MoJECrlImeedv2LS708 sVTQLBSnbK36pHkiVdpd0N91c76WeD6tP72szVyj8NIMHTtA/y1llVkkH+HdYqCfMfSN rPhhw5N4yqxb7kNXRjNZJVg55/mr75T2D0wx0= MIME-Version: 1.0 Received: by 10.231.157.4 with SMTP id z4mr167353ibw.32.1274368649443; Thu, 20 May 2010 08:17:29 -0700 (PDT) Received: by 10.231.79.147 with HTTP; Thu, 20 May 2010 08:17:29 -0700 (PDT) In-Reply-To: <4BF4E72B.7060600@ericsson.com> References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com> Date: Thu, 20 May 2010 10:17:29 -0500 Message-ID: From: Mary Barnes To: Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH Subject: Re: [dispatch] Alert Info URNs - Acronym X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 15:17:40 -0000 What about SIPALE (SIP ALErting)? On Thu, May 20, 2010 at 2:39 AM, Gonzalo Camarillo wrote: > Hi, > > note that we also need an acronym for this WG proposal. We have so many > WGs and drafts about drinking in RAI that we are going to need a few > URINALS (URNs for INforming about ALerting in SIP) pretty soon! :o) > > We are of course open to better proposals! > > Thanks, > > Gonzalo > > On 19/05/2010 5:15 PM, Gonzalo Camarillo wrote: >> Hi, >> >> thanks for all the good discussions around the Alert-Info URNs charter >> proposal. They actually helped clarify a few important concepts. I have >> revised the charter proposal taking into account all the feedback >> received (see attachment). >> >> Please, let me know if you are happy with this proposal so that I can >> get the IESG to review it. >> >> Thanks, >> >> Gonzalo >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dworley@avaya.com Thu May 20 08:21:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B63783A68B3 for ; Thu, 20 May 2010 08:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9dLiYtBn6LE for ; Thu, 20 May 2010 08:21:38 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 0B5603A6A21 for ; Thu, 20 May 2010 08:21:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,272,1272859200"; d="scan'208";a="219061388" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 May 2010 11:21:09 -0400 X-IronPort-AV: E=Sophos;i="4.53,272,1272859200"; d="scan'208";a="476814650" 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; 20 May 2010 11:21:09 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX2.global.avaya.com ([2002:870b:3415::870b:3415]) with mapi; Thu, 20 May 2010 11:21:09 -0400 From: "WORLEY, Dale R (Dale)" To: "Elwell, John" , Gonzalo Camarillo , DISPATCH Date: Thu, 20 May 2010 11:18:51 -0400 Thread-Topic: [dispatch] Alert Info URNs - Acronym Thread-Index: Acr375ae0ipvH+5IQjCtYWmUfl4L6gAAWLrQAA+x2ls= Message-ID: References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Alert Info URNs - Acronym X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 15:21:39 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of El= well, John [john.elwell@siemens-enterprise.com] Well, simply ALES (ALErting in Sip). ________________________________________ +1 ________________________________________ From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > > note that we also need an acronym for this WG proposal. We > have so many > WGs and drafts about drinking in RAI that we are going to need a few > URINALS (URNs for INforming about ALerting in SIP) pretty soon! :o) _______________________________________________ -1 This joke is quite funny now, but it won't be funny the 20th time we hear i= t. Dale From pkyzivat@cisco.com Thu May 20 08:33:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6EB3A6870 for ; Thu, 20 May 2010 08:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.232 X-Spam-Level: X-Spam-Status: No, score=-10.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6hzMjLrCoMq for ; Thu, 20 May 2010 08:33:35 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B22913A6C4F for ; Thu, 20 May 2010 08:33:26 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANjy9EtAZnwN/2dsb2JhbACeBHGiQJlUglEJgjgEj3c X-IronPort-AV: E=Sophos;i="4.53,272,1272844800"; d="scan'208";a="113088540" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 May 2010 15:33:19 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4KFXJZO008595; Thu, 20 May 2010 15:33:19 GMT Message-ID: <4BF5563F.8090508@cisco.com> Date: Thu, 20 May 2010 11:33:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 15:33:37 -0000 Avasarala Ranjit-A20990 wrote: > Hi Paul > > No I am not asking for a new WG. I wanted directions to take this I-D > forward. Like should we merge it with CDIV one as John Elwell was > suggesting or keep this separate - which I think is better. Well, with the new operating rules for RAI and DISPATCH, if you want this to be worked on by some WG, then we either have to find one to recharter to do the work, or else we have to spin up another. I don't see any obvious existing one to take on the work. I *do* think this work is potentially interesting beyond IMS. A new WG is a *possibility* if the work can be framed in a way that people want to work on. IMO that will mean first defining the requirements, without presuming the mechanism. And combining the requirements for CDIV and barring would probably make it more attractive. Thanks, Paul > Regards > Ranjit > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, May 20, 2010 6:47 PM > To: Avasarala Ranjit-A20990 > Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de > Subject: Re: [dispatch] FW: New Version > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > > > > Avasarala Ranjit-A20990 wrote: >> Hi >> >> So is the consensus to proceed forward? > > Proceed forward in what way? Are you asking for a new WG? > > Thanks, > Paul > >> Regards >> Ranjit >> >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Thursday, May 20, 2010 12:15 PM >> To: Avasarala Ranjit-A20990; dispatch@ietf.org >> Cc: R.Jesske@telekom.de >> Subject: RE: [dispatch] FW: New Version >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> Sorry, I thought I had already responded, but clearly not. >> >> I am still of the opinion that there is sufficient synergy between the > >> two event packages that they can be combined into a single event >> package. This would have the benefit of being able to have a single >> subscription to get all information relating to automatic handling of >> incoming calls, rather than being forced to subscribe twice. If you >> only want information about diverted calls, or only information about >> barred calls, you could filter accordingly. If you want different >> filtering criteria, or different subscription times for the two, there > >> is nothing to stop you having two separate subscriptions. But we >> should not penalise the simple case by forcing two subscriptions where > >> one would do. >> >> John >> >>> -----Original Message----- >>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] >>> Sent: 20 May 2010 05:33 >>> To: Elwell, John; dispatch@ietf.org >>> Cc: R.Jesske@telekom.de >>> Subject: RE: [dispatch] FW: New Version >>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>> >>> Hi All >>> >>> Any further comments on this I-D and suggestions for next steps? >>> >>> Thanks >>> >>> >>> Regards >>> Ranjit >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >>> Behalf Of Avasarala Ranjit-A20990 >>> Sent: Friday, May 14, 2010 11:49 AM >>> To: Elwell, John; dispatch@ietf.org >>> Subject: Re: [dispatch] FW: New Version >>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>> >>> Hi John >>> >>> This I-D on communication barring notification talks about an event >>> package for reporting the notification information of communication >>> barrings (call blocking) that happen in the network on behalf of the >>> users. >>> >>> For e.g if Alice sets a call blocking rule that all calls from Bob >>> need to be blocked, then the network blocks all calls from Bob >>> towards >>> Alice. >>> So here >>> The notification information will include the details of the call >>> block >>> - i.e (1) the identity of caller (Bob) (2) time of block (2) reason >>> for block, etc >>> >>> Yes I agree with you that there is synergy between this I-D and the >>> one on CDIV, since both of them deal with reporting of events that >>> occur in the network. While CDIV deals with communication diversion, >>> this one deals with ICB service. Though both the event packages are >>> similar in terms of subscriptions and format, their execution and >>> user >>> preference may vary. So they need to be looked at differently and >>> standardized seperately. >>> >>> >>> Regards >>> Ranjit >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Thursday, May 13, 2010 6:25 PM >>> To: Avasarala Ranjit-A20990; dispatch@ietf.org >>> Cc: T Satyanarayana-A12694 >>> Subject: RE: [dispatch] FW: New Version Notification >>> fordraft-avasarala-dispatch-comm-barring-notification-00 >>> >>> Ranjit, >>> >>> It is not entirely clear to me what the notifications report. For >>> example, in 6.7, it says "Typically, it will send >>> one when a communication barring is enacted on behalf of the > user." >>> What is meant by "enacted" here? Is it when some entity, on behalf of > >>> the user, perhaps through some web page, establishes a communication >>> barring rule? Or is it when an inbound communication arrives and is >>> processed in accordance with some pre-existing communication barring >>> rule? I thought at first it was the former, but I am tending towards >>> thinking it is the latter. Some clarification would be useful. >>> >>> Assuming it is the latter, there is obviously some synergy with >>> draft-avasarala-dispatch-comm-div-notification. Both deal with >>> reporting inbound communications that have been subject to some rule, > >>> the rule being conditional on certain criteria such as caller ID. >>> Where the conditions are met for a given call to be subject to a >>> given >>> rule, a notification in accordance with one or the other event >>> package >>> will be triggered. I fail to see the reason for having two separate >>> event packages, since this means two separate specifications, two >>> different subscriptions, two different formats, etc.. >>> >>> John >>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org >>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala >>>> Ranjit-A20990 >>>> Sent: 13 May 2010 11:28 >>>> To: dispatch@ietf.org >>>> Cc: T Satyanarayana-A12694 >>>> Subject: [dispatch] FW: New Version Notification for >>>> draft-avasarala-dispatch-comm-barring-notification-00 >>>> >>>> Hi all >>>> >>>> I have submitted a new I-D on communication barring notification >>>> information based on the following >>>> >>>> Section 8.2.10 Communication Barring - ICB enhancement of dynamic >>>> blocking of incoming communications of 3GPP TS 22.173 >>>> >>>> Section 4.5.2.6.1 Actions for ICB at the terminating AS of 3GPP TS >>>> 24.611 >>>> >>>> The draft can be accessed from: >>>> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n >>>> otificatio >>>> n-00.txt >>>> >>>> Please review and comment. >>>> >>>> Thanks >>>> >>>> >>>> Regards >>>> Ranjit >>>> >>>> -----Original Message----- >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>>> Sent: Thursday, May 13, 2010 3:47 PM >>>> To: Avasarala Ranjit-A20990 >>>> Cc: r.jesske@telekom.de >>>> Subject: New Version Notification for >>>> draft-avasarala-dispatch-comm-barring-notification-00 >>>> >>>> >>>> A new version of I-D, >>>> draft-avasarala-dispatch-comm-barring-notification-00.txt has been >>>> successfully submitted by Ranjit Avasarala and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-avasarala-dispatch-comm-barring-notification >>>> Revision: 00 >>>> Title: A Session Initiation Protocol (SIP) >>>> Event Package for >>>> Communication Barring Notification Information in support of the >>>> Dynamic Incoming Communication Barring (ICB) Notification service >>>> Creation_date: 2010-05-13 >>>> WG ID: Independent Submission >>>> Number_of_pages: 22 >>>> >>>> Abstract: >>>> 3GPP is defining the protocol specification for the Communication >>>> Barring (CB) service using IP Multimedia (IM) Core Network (CN) >>>> subsystem supplementary service and more particularly the dynamic >>>> incoming communication barring service. As part of dynamic >>> incoming >>>> communication barring (ICB) service, a SIP based Event package >>>> framework is used for notifying users about communication barrings >>>> (dynamic and rule based) of their incoming communication sessions. >>>> This document proposes a new SIP event package for allowing >>> users to >>>> subscribe to and receive such notifications. Users can >>> further define >>> >>>> filters to control the rate and content of such notifications. >>>> The proposed event package is applicable to the ICB supplementary >>>> service in IMS and may not be applicable to the general internet. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> _______________________________________________ >>>> 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 Milan.Patel@InterDigital.com Thu May 20 08:35:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2523A6C91 for ; Thu, 20 May 2010 08:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONQBPoyc1rG6 for ; Thu, 20 May 2010 08:35:04 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 209C43A6C78 for ; Thu, 20 May 2010 08:34:57 -0700 (PDT) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 11:34:50 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 20 May 2010 11:34:49 -0400 Message-ID: <61CAF342FE1EE34EAC8FB19B765914000E6FB122@SABRE.InterDigital.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Reason Inresponses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: Acr3XCMe2RSZKLwkQfSCO3bCUaExewAN5mL7ACdnteA= From: "Patel, Milan" To: "WORLEY, Dale R (Dale)" , "Shida Schubert" , "Xavier Marjou" X-OriginalArrivalTime: 20 May 2010 15:34:50.0215 (UTC) FILETIME=[FC38D770:01CAF831] Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] Reason Inresponses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 15:35:05 -0000 Hi, I've read these drafts, and apart from a few editorials, I believe these drafts accurately convey the use cases and solution for Reason in responses. I agree with Dale, this work should go forwards based on these drafts. Regards, Milan -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of WORLEY, Dale R (Dale) Sent: Wednesday, May 19, 2010 9:42 PM To: Shida Schubert; Xavier Marjou Cc: dispatch@ietf.org; R.Jesske@telekom.de Subject: Re: [dispatch] Reason Inresponses (draft-jesske-dispatch-reason-in-responses-02) ________________________________________ > 2010/5/13 : >> Dear all, >> I have asked for comments on the two drafts mentioned below. >> So far I didn't get any. Does that mean that people are happy now with the >> content and we could proceed with it? >> >> Thank you and Best Regrads >> >> Roland >> _______________________________________________ Yes, I think this work should go foward in accordance with these drafts. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Thu May 20 08:41:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA853A6A89 for ; Thu, 20 May 2010 08:41:06 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEiF-hT8w7Ue for ; Thu, 20 May 2010 08:41:05 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D8E133A6A3F for ; Thu, 20 May 2010 08:41:03 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACf19EtAZnwN/2dsb2JhbACeBHGiWJlUhRIE X-IronPort-AV: E=Sophos;i="4.53,272,1272844800"; d="scan'208";a="113091040" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 May 2010 15:40:56 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4KFeusm011907; Thu, 20 May 2010 15:40:56 GMT Message-ID: <4BF55808.5080801@cisco.com> Date: Thu, 20 May 2010 11:40:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "WORLEY, Dale R (Dale)" References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com>, In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] Alert Info URNs - Acronym X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 15:41:06 -0000 How about just ALERTS? (ALERT urns for Sip) WORLEY, Dale R (Dale) wrote: > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] > > Well, simply ALES (ALErting in Sip). > ________________________________________ > > +1 > > ________________________________________ > From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> >> note that we also need an acronym for this WG proposal. We >> have so many >> WGs and drafts about drinking in RAI that we are going to need a few >> URINALS (URNs for INforming about ALerting in SIP) pretty soon! :o) > _______________________________________________ > > -1 > > This joke is quite funny now, but it won't be funny the 20th time we hear it. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From spromano@unina.it Thu May 20 08:57:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321933A6AB1 for ; Thu, 20 May 2010 08:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.926 X-Spam-Level: * X-Spam-Status: No, score=1.926 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYd3j5wHOjwT for ; Thu, 20 May 2010 08:57:19 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by core3.amsl.com (Postfix) with ESMTP id 204123A6AA2 for ; Thu, 20 May 2010 08:57:18 -0700 (PDT) Received: from [1.16.106.219] ([94.167.61.47]) (authenticated bits=0) by smtp2.unina.it (8.14.0/8.14.0) with ESMTP id o4KFutFk005849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 May 2010 17:57:03 +0200 From: Simon Pietro Romano To: Paul Kyzivat In-Reply-To: <4BF55808.5080801@cisco.com> X-Mailer: iPhone Mail (7C144) References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com>, <4BF55808.5080801@cisco.com> Message-Id: <36550936-3A99-4793-8C24-512C3C01B6C8@unina.it> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7C144) Date: Thu, 20 May 2010 17:56:07 +0200 Cc: DISPATCH Subject: Re: [dispatch] Alert Info URNs - Acronym X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 15:57:20 -0000 Here is my proposal: ALICE -- ALert Info between Communicating Entities. Simon Il giorno 20/mag/2010, alle ore 17.40, Paul Kyzivat ha scritto: > How about just ALERTS? (ALERT urns for Sip) > > WORLEY, Dale R (Dale) wrote: >> ________________________________________ >> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On >> Behalf Of Elwell, John [john.elwell@siemens-enterprise.com] >> Well, simply ALES (ALErting in Sip). >> ________________________________________ >> +1 >> ________________________________________ >> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>> >>> note that we also need an acronym for this WG proposal. We >>> have so many >>> WGs and drafts about drinking in RAI that we are going to need a few >>> URINALS (URNs for INforming about ALerting in SIP) pretty soon! :o) >> _______________________________________________ >> -1 >> This joke is quite funny now, but it won't be funny the 20th time >> we hear it. >> Dale >> _______________________________________________ >> 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 john.elwell@siemens-enterprise.com Thu May 20 09:09:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004EA3A6943 for ; Thu, 20 May 2010 09:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTCQvmj7PvSY for ; Thu, 20 May 2010 09:09:22 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id CA6F53A67AC for ; Thu, 20 May 2010 09:09:21 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-241182; Thu, 20 May 2010 18:09:14 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 8CEB123F0278; Thu, 20 May 2010 18:09:14 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 20 May 2010 18:09:14 +0200 From: "Elwell, John" To: Paul Kyzivat , Avasarala Ranjit-A20990 Date: Thu, 20 May 2010 18:09:12 +0200 Thread-Topic: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 Thread-Index: Acr4Mci0fKx3uMtoTEa77nhh9IGRwwAA30Hw Message-ID: References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> In-Reply-To: <4BF5563F.8090508@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 16:09:24 -0000 I too think this work is potentially interesting beyond IMS, and would find= it more attractive to combine requirements and have a single event package= . Of course, there are other ways of achieving this. There could be an HTTP r= esource that allows me to inspect recent calls that have been subject to au= tomatic call handling, e.g., by being diverted or barred. Then I could use = https://datatracker.ietf.org/doc/draft-roach-sip-http-subscribe/ to be noti= fied of changes to that resource. No SIP standardisation required. It would= be interesting to know whether this would solve requirements. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 20 May 2010 16:33 > To: Avasarala Ranjit-A20990 > Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de > Subject: Re: [dispatch] FW: New Version=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >=20 >=20 >=20 > Avasarala Ranjit-A20990 wrote: > > Hi Paul > >=20 > > No I am not asking for a new WG. I wanted directions to=20 > take this I-D > > forward. Like should we merge it with CDIV one as John Elwell was > > suggesting or keep this separate - which I think is better.=20 >=20 > Well, with the new operating rules for RAI and DISPATCH, if you want=20 > this to be worked on by some WG, then we either have to find one to=20 > recharter to do the work, or else we have to spin up another. I don't=20 > see any obvious existing one to take on the work. >=20 > I *do* think this work is potentially interesting beyond IMS.=20 > A new WG=20 > is a *possibility* if the work can be framed in a way that=20 > people want=20 > to work on. IMO that will mean first defining the=20 > requirements, without=20 > presuming the mechanism. And combining the requirements for CDIV and=20 > barring would probably make it more attractive. >=20 > Thanks, > Paul >=20 > > Regards > > Ranjit > >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > > Sent: Thursday, May 20, 2010 6:47 PM > > To: Avasarala Ranjit-A20990 > > Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de > > Subject: Re: [dispatch] FW: New Version > > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > >=20 > >=20 > >=20 > > Avasarala Ranjit-A20990 wrote: > >> Hi > >> > >> So is the consensus to proceed forward?=20 > >=20 > > Proceed forward in what way? Are you asking for a new WG? > >=20 > > Thanks, > > Paul > >=20 > >> Regards > >> Ranjit > >> > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >> Sent: Thursday, May 20, 2010 12:15 PM > >> To: Avasarala Ranjit-A20990; dispatch@ietf.org > >> Cc: R.Jesske@telekom.de > >> Subject: RE: [dispatch] FW: New Version=20 > >>=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > >> > >> Sorry, I thought I had already responded, but clearly not. > >> > >> I am still of the opinion that there is sufficient synergy=20 > between the > >=20 > >> two event packages that they can be combined into a single event=20 > >> package. This would have the benefit of being able to have=20 > a single=20 > >> subscription to get all information relating to automatic=20 > handling of=20 > >> incoming calls, rather than being forced to subscribe=20 > twice. If you=20 > >> only want information about diverted calls, or only=20 > information about=20 > >> barred calls, you could filter accordingly. If you want different=20 > >> filtering criteria, or different subscription times for=20 > the two, there > >=20 > >> is nothing to stop you having two separate subscriptions. But we=20 > >> should not penalise the simple case by forcing two=20 > subscriptions where > >=20 > >> one would do. > >> > >> John > >> > >>> -----Original Message----- > >>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] > >>> Sent: 20 May 2010 05:33 > >>> To: Elwell, John; dispatch@ietf.org > >>> Cc: R.Jesske@telekom.de > >>> Subject: RE: [dispatch] FW: New Version=20 > >>>=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > >>> > >>> Hi All > >>> > >>> Any further comments on this I-D and suggestions for next steps? > >>> > >>> Thanks > >>> > >>> > >>> Regards > >>> Ranjit > >>> > >>> -----Original Message----- > >>> From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > >=20 > >>> Behalf Of Avasarala Ranjit-A20990 > >>> Sent: Friday, May 14, 2010 11:49 AM > >>> To: Elwell, John; dispatch@ietf.org > >>> Subject: Re: [dispatch] FW: New Version=20 > >>>=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > >>> > >>> Hi John > >>> > >>> This I-D on communication barring notification talks=20 > about an event=20 > >>> package for reporting the notification information of=20 > communication=20 > >>> barrings (call blocking) that happen in the network on=20 > behalf of the=20 > >>> users. > >>> > >>> For e.g if Alice sets a call blocking rule that all calls=20 > from Bob=20 > >>> need to be blocked, then the network blocks all calls from Bob=20 > >>> towards > >>> Alice. > >>> So here > >>> The notification information will include the details of the call=20 > >>> block > >>> - i.e (1) the identity of caller (Bob) (2) time of block=20 > (2) reason=20 > >>> for block, etc > >>> > >>> Yes I agree with you that there is synergy between this=20 > I-D and the=20 > >>> one on CDIV, since both of them deal with reporting of=20 > events that=20 > >>> occur in the network. While CDIV deals with communication=20 > diversion,=20 > >>> this one deals with ICB service. Though both the event=20 > packages are=20 > >>> similar in terms of subscriptions and format, their execution and=20 > >>> user > >>> preference may vary. So they need to be looked at differently and=20 > >>> standardized seperately. > >>> > >>> > >>> Regards > >>> Ranjit > >>> > >>> -----Original Message----- > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>> Sent: Thursday, May 13, 2010 6:25 PM > >>> To: Avasarala Ranjit-A20990; dispatch@ietf.org > >>> Cc: T Satyanarayana-A12694 > >>> Subject: RE: [dispatch] FW: New Version Notification=20 > >>> fordraft-avasarala-dispatch-comm-barring-notification-00 > >>> > >>> Ranjit, > >>> > >>> It is not entirely clear to me what the notifications report. For=20 > >>> example, in 6.7, it says "Typically, it will send > >>> one when a communication barring is enacted on behalf of the > > user." > >>> What is meant by "enacted" here? Is it when some entity,=20 > on behalf of > >=20 > >>> the user, perhaps through some web page, establishes a=20 > communication=20 > >>> barring rule? Or is it when an inbound communication=20 > arrives and is=20 > >>> processed in accordance with some pre-existing=20 > communication barring=20 > >>> rule? I thought at first it was the former, but I am=20 > tending towards=20 > >>> thinking it is the latter. Some clarification would be useful. > >>> > >>> Assuming it is the latter, there is obviously some synergy with=20 > >>> draft-avasarala-dispatch-comm-div-notification. Both deal with=20 > >>> reporting inbound communications that have been subject=20 > to some rule, > >=20 > >>> the rule being conditional on certain criteria such as caller ID. > >>> Where the conditions are met for a given call to be subject to a=20 > >>> given > >>> rule, a notification in accordance with one or the other event=20 > >>> package > >>> will be triggered. I fail to see the reason for having=20 > two separate=20 > >>> event packages, since this means two separate specifications, two=20 > >>> different subscriptions, two different formats, etc.. > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: dispatch-bounces@ietf.org > >>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 > >>>> Ranjit-A20990 > >>>> Sent: 13 May 2010 11:28 > >>>> To: dispatch@ietf.org > >>>> Cc: T Satyanarayana-A12694 > >>>> Subject: [dispatch] FW: New Version Notification for=20 > >>>> draft-avasarala-dispatch-comm-barring-notification-00 > >>>> > >>>> Hi all > >>>> > >>>> I have submitted a new I-D on communication barring notification=20 > >>>> information based on the following > >>>> > >>>> Section 8.2.10 Communication Barring - ICB enhancement=20 > of dynamic=20 > >>>> blocking of incoming communications of 3GPP TS 22.173 > >>>> > >>>> Section 4.5.2.6.1 Actions for ICB at the terminating AS=20 > of 3GPP TS > >>>> 24.611 > >>>> > >>>> The draft can be accessed from: > >>>> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n > >>>> otificatio > >>>> n-00.txt > >>>> > >>>> Please review and comment. > >>>> > >>>> Thanks > >>>> > >>>> > >>>> Regards > >>>> Ranjit > >>>> > >>>> -----Original Message----- > >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > >>>> Sent: Thursday, May 13, 2010 3:47 PM > >>>> To: Avasarala Ranjit-A20990 > >>>> Cc: r.jesske@telekom.de > >>>> Subject: New Version Notification for=20 > >>>> draft-avasarala-dispatch-comm-barring-notification-00 > >>>> > >>>> > >>>> A new version of I-D, > >>>>=20 > draft-avasarala-dispatch-comm-barring-notification-00.txt has been=20 > >>>> successfully submitted by Ranjit Avasarala and posted to=20 > the IETF=20 > >>>> repository. > >>>> > >>>> Filename: =20 > draft-avasarala-dispatch-comm-barring-notification > >>>> Revision: 00 > >>>> Title: A Session Initiation Protocol (SIP)=20 > >>>> Event Package for > >>>> Communication Barring Notification Information in support of the=20 > >>>> Dynamic Incoming Communication Barring (ICB) Notification service > >>>> Creation_date: 2010-05-13 > >>>> WG ID: Independent Submission > >>>> Number_of_pages: 22 > >>>> > >>>> Abstract: > >>>> 3GPP is defining the protocol specification for the=20 > Communication=20 > >>>> Barring (CB) service using IP Multimedia (IM) Core Network (CN)=20 > >>>> subsystem supplementary service and more particularly=20 > the dynamic=20 > >>>> incoming communication barring service. As part of dynamic > >>> incoming > >>>> communication barring (ICB) service, a SIP based Event package=20 > >>>> framework is used for notifying users about=20 > communication barrings=20 > >>>> (dynamic and rule based) of their incoming communication=20 > sessions. > >>>> This document proposes a new SIP event package for allowing > >>> users to > >>>> subscribe to and receive such notifications. Users can > >>> further define > >>> > >>>> filters to control the rate and content of such notifications. > >>>> The proposed event package is applicable to the ICB=20 > supplementary=20 > >>>> service in IMS and may not be applicable to the general internet. > >>>> =20 > >>>> > >>>> > >>>> > >>>> The IETF Secretariat. > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 pkyzivat@cisco.com Thu May 20 09:19:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B403A67E5 for ; Thu, 20 May 2010 09:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.236 X-Spam-Level: X-Spam-Status: No, score=-10.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSTELOvpkRA9 for ; Thu, 20 May 2010 09:19:32 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A9FC93A6907 for ; Thu, 20 May 2010 09:19:30 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFr99EtAaMHG/2dsb2JhbACeEXGjF5lXglEJgjgEj3c X-IronPort-AV: E=Sophos;i="4.53,272,1272844800"; d="scan'208";a="132547886" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 20 May 2010 16:19:22 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4KGJJkC018661; Thu, 20 May 2010 16:19:20 GMT Message-ID: <4BF56106.4010806@cisco.com> Date: Thu, 20 May 2010 12:19:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Elwell, John" References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 16:19:35 -0000 Elwell, John wrote: > I too think this work is potentially interesting beyond IMS, and would find it more attractive to combine requirements and have a single event package. > > Of course, there are other ways of achieving this. There could be an HTTP resource that allows me to inspect recent calls that have been subject to automatic call handling, e.g., by being diverted or barred. Then I could use https://datatracker.ietf.org/doc/draft-roach-sip-http-subscribe/ to be notified of changes to that resource. No SIP standardisation required. It would be interesting to know whether this would solve requirements. I guess this is fundamentally about automatic call handling. Seems like it might be in the scope of BLISS, except I gather BLISS is winding down. Thanks, Paul > John > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 20 May 2010 16:33 >> To: Avasarala Ranjit-A20990 >> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de >> Subject: Re: [dispatch] FW: New Version >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> >> >> Avasarala Ranjit-A20990 wrote: >>> Hi Paul >>> >>> No I am not asking for a new WG. I wanted directions to >> take this I-D >>> forward. Like should we merge it with CDIV one as John Elwell was >>> suggesting or keep this separate - which I think is better. >> Well, with the new operating rules for RAI and DISPATCH, if you want >> this to be worked on by some WG, then we either have to find one to >> recharter to do the work, or else we have to spin up another. I don't >> see any obvious existing one to take on the work. >> >> I *do* think this work is potentially interesting beyond IMS. >> A new WG >> is a *possibility* if the work can be framed in a way that >> people want >> to work on. IMO that will mean first defining the >> requirements, without >> presuming the mechanism. And combining the requirements for CDIV and >> barring would probably make it more attractive. >> >> Thanks, >> Paul >> >>> Regards >>> Ranjit >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Thursday, May 20, 2010 6:47 PM >>> To: Avasarala Ranjit-A20990 >>> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de >>> Subject: Re: [dispatch] FW: New Version >>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>> >>> >>> >>> Avasarala Ranjit-A20990 wrote: >>>> Hi >>>> >>>> So is the consensus to proceed forward? >>> Proceed forward in what way? Are you asking for a new WG? >>> >>> Thanks, >>> Paul >>> >>>> Regards >>>> Ranjit >>>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>> Sent: Thursday, May 20, 2010 12:15 PM >>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org >>>> Cc: R.Jesske@telekom.de >>>> Subject: RE: [dispatch] FW: New Version >>>> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>>> Sorry, I thought I had already responded, but clearly not. >>>> >>>> I am still of the opinion that there is sufficient synergy >> between the >>>> two event packages that they can be combined into a single event >>>> package. This would have the benefit of being able to have >> a single >>>> subscription to get all information relating to automatic >> handling of >>>> incoming calls, rather than being forced to subscribe >> twice. If you >>>> only want information about diverted calls, or only >> information about >>>> barred calls, you could filter accordingly. If you want different >>>> filtering criteria, or different subscription times for >> the two, there >>>> is nothing to stop you having two separate subscriptions. But we >>>> should not penalise the simple case by forcing two >> subscriptions where >>>> one would do. >>>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] >>>>> Sent: 20 May 2010 05:33 >>>>> To: Elwell, John; dispatch@ietf.org >>>>> Cc: R.Jesske@telekom.de >>>>> Subject: RE: [dispatch] FW: New Version >>>>> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>>>> Hi All >>>>> >>>>> Any further comments on this I-D and suggestions for next steps? >>>>> >>>>> Thanks >>>>> >>>>> >>>>> Regards >>>>> Ranjit >>>>> >>>>> -----Original Message----- >>>>> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On >>>>> Behalf Of Avasarala Ranjit-A20990 >>>>> Sent: Friday, May 14, 2010 11:49 AM >>>>> To: Elwell, John; dispatch@ietf.org >>>>> Subject: Re: [dispatch] FW: New Version >>>>> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>>>> Hi John >>>>> >>>>> This I-D on communication barring notification talks >> about an event >>>>> package for reporting the notification information of >> communication >>>>> barrings (call blocking) that happen in the network on >> behalf of the >>>>> users. >>>>> >>>>> For e.g if Alice sets a call blocking rule that all calls >> from Bob >>>>> need to be blocked, then the network blocks all calls from Bob >>>>> towards >>>>> Alice. >>>>> So here >>>>> The notification information will include the details of the call >>>>> block >>>>> - i.e (1) the identity of caller (Bob) (2) time of block >> (2) reason >>>>> for block, etc >>>>> >>>>> Yes I agree with you that there is synergy between this >> I-D and the >>>>> one on CDIV, since both of them deal with reporting of >> events that >>>>> occur in the network. While CDIV deals with communication >> diversion, >>>>> this one deals with ICB service. Though both the event >> packages are >>>>> similar in terms of subscriptions and format, their execution and >>>>> user >>>>> preference may vary. So they need to be looked at differently and >>>>> standardized seperately. >>>>> >>>>> >>>>> Regards >>>>> Ranjit >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Thursday, May 13, 2010 6:25 PM >>>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org >>>>> Cc: T Satyanarayana-A12694 >>>>> Subject: RE: [dispatch] FW: New Version Notification >>>>> fordraft-avasarala-dispatch-comm-barring-notification-00 >>>>> >>>>> Ranjit, >>>>> >>>>> It is not entirely clear to me what the notifications report. For >>>>> example, in 6.7, it says "Typically, it will send >>>>> one when a communication barring is enacted on behalf of the >>> user." >>>>> What is meant by "enacted" here? Is it when some entity, >> on behalf of >>>>> the user, perhaps through some web page, establishes a >> communication >>>>> barring rule? Or is it when an inbound communication >> arrives and is >>>>> processed in accordance with some pre-existing >> communication barring >>>>> rule? I thought at first it was the former, but I am >> tending towards >>>>> thinking it is the latter. Some clarification would be useful. >>>>> >>>>> Assuming it is the latter, there is obviously some synergy with >>>>> draft-avasarala-dispatch-comm-div-notification. Both deal with >>>>> reporting inbound communications that have been subject >> to some rule, >>>>> the rule being conditional on certain criteria such as caller ID. >>>>> Where the conditions are met for a given call to be subject to a >>>>> given >>>>> rule, a notification in accordance with one or the other event >>>>> package >>>>> will be triggered. I fail to see the reason for having >> two separate >>>>> event packages, since this means two separate specifications, two >>>>> different subscriptions, two different formats, etc.. >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala >>>>>> Ranjit-A20990 >>>>>> Sent: 13 May 2010 11:28 >>>>>> To: dispatch@ietf.org >>>>>> Cc: T Satyanarayana-A12694 >>>>>> Subject: [dispatch] FW: New Version Notification for >>>>>> draft-avasarala-dispatch-comm-barring-notification-00 >>>>>> >>>>>> Hi all >>>>>> >>>>>> I have submitted a new I-D on communication barring notification >>>>>> information based on the following >>>>>> >>>>>> Section 8.2.10 Communication Barring - ICB enhancement >> of dynamic >>>>>> blocking of incoming communications of 3GPP TS 22.173 >>>>>> >>>>>> Section 4.5.2.6.1 Actions for ICB at the terminating AS >> of 3GPP TS >>>>>> 24.611 >>>>>> >>>>>> The draft can be accessed from: >>>>>> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n >>>>>> otificatio >>>>>> n-00.txt >>>>>> >>>>>> Please review and comment. >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> Regards >>>>>> Ranjit >>>>>> >>>>>> -----Original Message----- >>>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>>>>> Sent: Thursday, May 13, 2010 3:47 PM >>>>>> To: Avasarala Ranjit-A20990 >>>>>> Cc: r.jesske@telekom.de >>>>>> Subject: New Version Notification for >>>>>> draft-avasarala-dispatch-comm-barring-notification-00 >>>>>> >>>>>> >>>>>> A new version of I-D, >>>>>> >> draft-avasarala-dispatch-comm-barring-notification-00.txt has been >>>>>> successfully submitted by Ranjit Avasarala and posted to >> the IETF >>>>>> repository. >>>>>> >>>>>> Filename: >> draft-avasarala-dispatch-comm-barring-notification >>>>>> Revision: 00 >>>>>> Title: A Session Initiation Protocol (SIP) >>>>>> Event Package for >>>>>> Communication Barring Notification Information in support of the >>>>>> Dynamic Incoming Communication Barring (ICB) Notification service >>>>>> Creation_date: 2010-05-13 >>>>>> WG ID: Independent Submission >>>>>> Number_of_pages: 22 >>>>>> >>>>>> Abstract: >>>>>> 3GPP is defining the protocol specification for the >> Communication >>>>>> Barring (CB) service using IP Multimedia (IM) Core Network (CN) >>>>>> subsystem supplementary service and more particularly >> the dynamic >>>>>> incoming communication barring service. As part of dynamic >>>>> incoming >>>>>> communication barring (ICB) service, a SIP based Event package >>>>>> framework is used for notifying users about >> communication barrings >>>>>> (dynamic and rule based) of their incoming communication >> sessions. >>>>>> This document proposes a new SIP event package for allowing >>>>> users to >>>>>> subscribe to and receive such notifications. Users can >>>>> further define >>>>> >>>>>> filters to control the rate and content of such notifications. >>>>>> The proposed event package is applicable to the ICB >> supplementary >>>>>> service in IMS and may not be applicable to the general internet. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 gonzalo.camarillo@ericsson.com Thu May 20 09:27:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EAA13A699D for ; Thu, 20 May 2010 09:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.167 X-Spam-Level: X-Spam-Status: No, score=-103.167 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LebWP4oaHtY0 for ; Thu, 20 May 2010 09:27:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A74E13A6861 for ; Thu, 20 May 2010 09:26:58 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-0f-4bf562cac287 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A8.80.21861.AC265FB4; Thu, 20 May 2010 18:26:50 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 18:26:50 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 18:26:49 +0200 Received: from [131.160.126.133] (rvi2-126-133.lmf.ericsson.se [131.160.126.133]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D25B3231C; Thu, 20 May 2010 19:26:49 +0300 (EEST) Message-ID: <4BF562C9.6060503@ericsson.com> Date: Thu, 20 May 2010 19:26:49 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Laura Liess References: <4BF3F281.8080102@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 May 2010 16:26:49.0647 (UTC) FILETIME=[3F8C63F0:01CAF839] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Alert Info URNs - Revised charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 16:27:02 -0000 Hi Laura, > 1) On the ML we discussed allowing the usege of Alert-Info in 18x > instead of only 180 (as currently allowed in 3261). Do we need to > mention this in the charter in some way? no, there is no need to mention it in the charter. > 2) I think Apr 2011 - Alert-Info URN specification to IESG (PS) is > no longer realistic. I would propose Aug 2011. sure, I will use Aug 2011 instead. Thanks, Gonzalo From john.elwell@siemens-enterprise.com Thu May 20 09:32:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E993A3A68AE for ; Thu, 20 May 2010 09:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of37vQR9iJO5 for ; Thu, 20 May 2010 09:32:25 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C7E4D3A6935 for ; Thu, 20 May 2010 09:32:22 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-242390; Thu, 20 May 2010 18:32:15 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id A14361EB82AB; Thu, 20 May 2010 18:32:15 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 20 May 2010 18:32:15 +0200 From: "Elwell, John" To: Mary Barnes , Gonzalo Camarillo Date: Thu, 20 May 2010 18:32:14 +0200 Thread-Topic: [dispatch] Alert Info URNs - Acronym Thread-Index: Acr4L5Si1WxTwxW0TNKo8ik/gUTSagACk/Vg Message-ID: References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] Alert Info URNs - Acronym X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 16:32:26 -0000 Yes, but one normally talks about swigging ale, not sipping ale. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 20 May 2010 16:17 > To: Gonzalo Camarillo > Cc: DISPATCH > Subject: Re: [dispatch] Alert Info URNs - Acronym >=20 > What about SIPALE (SIP ALErting)? >=20 > On Thu, May 20, 2010 at 2:39 AM, Gonzalo Camarillo > wrote: > > Hi, > > > > note that we also need an acronym for this WG proposal. We=20 > have so many > > WGs and drafts about drinking in RAI that we are going to need a few > > URINALS (URNs for INforming about ALerting in SIP) pretty soon! :o) > > > > We are of course open to better proposals! > > > > Thanks, > > > > Gonzalo > > > > On 19/05/2010 5:15 PM, Gonzalo Camarillo wrote: > >> Hi, > >> > >> thanks for all the good discussions around the Alert-Info=20 > URNs charter > >> proposal. They actually helped clarify a few important=20 > concepts. I have > >> revised the charter proposal taking into account all the feedback > >> received (see attachment). > >> > >> Please, let me know if you are happy with this proposal so=20 > that I can > >> get the IESG to review it. > >> > >> Thanks, > >> > >> 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 laura.liess.dt@googlemail.com Thu May 20 12:08:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26DF3A690F for ; Thu, 20 May 2010 12:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.222 X-Spam-Level: X-Spam-Status: No, score=-0.222 tagged_above=-999 required=5 tests=[AWL=-1.727, BAYES_40=-0.185, DATE_IN_PAST_96_XX=1.69] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3GdyysHf09U for ; Thu, 20 May 2010 12:08:49 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 98BC03A68DC for ; Thu, 20 May 2010 12:08:46 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so72667fge.13 for ; Thu, 20 May 2010 12:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=+nq9s9pYIrgPkxd/hbKlEf5lkM65tt2iAGchmUcH8dQ=; b=sKZrB/bVYOJOP+gwaOMLKQDiwqAC1e7zqKqszq6ciP6P4KnUY6aa7armYVmWEJPcVO kXgD5txMoORAqdccWJpmdEpCtVQAhLxl2TpXs5wMXQZcQ3CKdV7IYYvOJbDUq162CME2 YoOl+b+fYmvJs8zmhgHR7RXzWQ6pdohY49uIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=nZxWEQTe5eS6tyZZL6ei/oXB/GWCWk3gKz4joHRCfZocWR+S1f3Nq1EYTPE8qJLF4x ru4DM+xwnfE0X9jy5tuXgaywJMuYz73EDr4iMclv84lRxBFeF4Vz42caO3ZsZmBrSq2J CwjzUVg810M0v3MHG1QLDPvujCXh10Szl6CBQ= Received: by 10.223.92.152 with SMTP id r24mr429085fam.74.1274382513316; Thu, 20 May 2010 12:08:33 -0700 (PDT) Received: from LauraLiess (p54A7F9A5.dip.t-dialin.net [84.167.249.165]) by mx.google.com with ESMTPS id 2sm753204faf.15.2010.05.20.12.08.17 (version=SSLv3 cipher=RC4-MD5); Thu, 20 May 2010 12:08:22 -0700 (PDT) From: Laura Liess To: "'Paul Kyzivat'" , "'Christer Holmberg'" References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <430FC6BDED356B4C8498F634416644A91C13990F46@mail> <4bec4e62.0c58560a.188d.ffff9205@mx.google.com> <430FC6BDED356B4C8498F634416644A91C1399121F@mail> <4BF43FDC.2030006@cisco.com> <4BF5337E.4040906@cisco.com> In-Reply-To: <4BF5337E.4040906@cisco.com> Message-ID: <4bf588a6.8201df0a.68ef.0cd3@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr4HRCdr7JMYj/PSR2K3RgQMdqyPEpn19Vw Content-Language: de Cc: dispatch@ietf.org, R.Jesske@telekom.de, 'Hadriel Kaplan' Subject: Re: [dispatch] Alert-Info URNs - alternative renderings X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 20 May 2010 19:08:51 -0000 X-Original-Date: Wed, 6 May 2009 21:08:13 +0200 X-List-Received-Date: Thu, 20 May 2010 19:08:51 -0000 Paul, Sorry, the wording was inaccurate in my e-mail. What I meant was = renderings, not just tones. In the draft we talk about renderings. We ever have some text about the advantage of Alert-Info URN for hearing impaired.=20 Thanks Laura > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Donnerstag, 20. Mai 2010 15:05 > An: Christer Holmberg > Cc: Laura Liess; dispatch@ietf.org; R.Jesske@telekom.de; Hadriel = Kaplan > Betreff: Alert-Info URNs - alternative renderings >=20 > I changed the subject to be consistent with the content >=20 > Christer Holmberg wrote: > > Hi, > > > >>> Alert-Info URNs represent tones. The receiving end device only > >>> resolves it to a tone and plays the tone. Nothing else. The end > >>> device does not look at what the Alert-Info URN means, but only = if > it > >>> has rules to resolve it to a concrete tone. If it has, it resolves > the > >>> URN, otherwise the URN is discarded. It can be call waiting or > >>> Bethoven Fifth or the combination internal+short. The > >>> network will not use the Alert-info URNs for the call control = logic. > The RFC 3261 > >>> allows Alert-Info in INVITE and 180. People agreed on the ML to = exten > >>> this to 18x. > >> I'd like to take issue with the above. > >> Due to precedent we all are biased towards *audio* alerts, > >> but alerts need not be tones, or audio at all. Even for > >> people who can hear, alerts that are, in part or wholly, > >> non-audio are also important. E.g. > >> everybody has reason to put their cellphone into vibrate mode > >> at times. > > > > Of course. In that case you won't get an audio alert - no matter if = you > use Alert-Info or your "default" audio ring tone. >=20 > This is one of the values of Alert-Info URNs. The different alerting > modes of your phone (normal, vibrate, ...) can simply select = alternative > sets of renderings of all the supported Alert-Info URNs. >=20 > Thanks, > Paul From deepanshu@huawei.com Thu May 20 17:58:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFCA3A6B74 for ; Thu, 20 May 2010 17:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.508 X-Spam-Level: * X-Spam-Status: No, score=1.508 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIgAd9FJj8U5 for ; Thu, 20 May 2010 17:58:46 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 5B0F03A6B86 for ; Thu, 20 May 2010 17:57:55 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2Q00IDGW027R@szxga02-in.huawei.com> for dispatch@ietf.org; Fri, 21 May 2010 08:57:38 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2Q003BNW02KY@szxga02-in.huawei.com> for dispatch@ietf.org; Fri, 21 May 2010 08:57:38 +0800 (CST) Received: from D57531 ([10.168.86.63]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2Q002XLW02M4@szxml04-in.huawei.com> for dispatch@ietf.org; Fri, 21 May 2010 08:57:38 +0800 (CST) Date: Fri, 21 May 2010 08:57:43 +0800 From: Deepanshu Gautam To: dispatch@ietf.org Message-id: <002401caf880$9f0f68d0$3f56a80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_v5xYuoE6XuzaDR5yYdQoqw)" Thread-index: Acr4gJ7A8Bpw3xLXQqiCVQfTRm4Azw== Subject: [dispatch] Quick Answer usecase and requirement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 00:58:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_v5xYuoE6XuzaDR5yYdQoqw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all, I have just submitted an I-D containing usecases and requirement for what I call Quick Answer. http://tools.ietf.org/id/draft-gautam-dispatch-quick-answer-00.txt This concept was discussed in SIMPLE list/meeting some time ago and requested for clear usecase and requirements. It was suggested to take this to DISPATCH WG for more comments/reviews. http://www.ietf.org/mail-archive/web/simple/current/msg08553.html For summary: I defined Quick Answer as some readely avaliable IM to the user, from which he can choose as and when required. These are created by the user himself. The term "Canned responses" are used for the same purpose elsewhere http://en.wikipedia.org/wiki/Canned_response http://gmailblog.blogspot.com/2008/10/new-in-labs-canned-responses.html I would appreciate any comments and opinions form the group. Regards Deepanshu --Boundary_(ID_v5xYuoE6XuzaDR5yYdQoqw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Dear all,
 
I have just submitted an I-D containing usecases and requirement for what I call Quick Answer.
 
This concept was discussed in SIMPLE list/meeting some time ago and requested for clear usecase and requirements. It was suggested to take this to DISPATCH WG for more comments/reviews.
 
 
For summary: I defined Quick Answer as some readely avaliable IM to the user, from which he can choose as and when required. These are created by the user himself. The term "Canned responses" are used for the same purpose elsewhere
 
I would appreciate any comments and opinions form the group.
 
 
Regards
Deepanshu
 
--Boundary_(ID_v5xYuoE6XuzaDR5yYdQoqw)-- From ranjit@motorola.com Fri May 21 03:27:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93ED73A7877 for ; Fri, 21 May 2010 03:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqKUISGRKstr for ; Fri, 21 May 2010 03:27:42 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id E3B673A9340 for ; Fri, 21 May 2010 00:00:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1274425248!12642596!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 904 invoked from network); 21 May 2010 07:00:48 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-11.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 May 2010 07:00:48 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id o4L70hMd027115 for ; Fri, 21 May 2010 00:00:48 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o4L70hMg011278 for ; Fri, 21 May 2010 02:00:43 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o4L70fKB011245 for ; Fri, 21 May 2010 02:00:41 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 May 2010 15:00:18 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.com> In-Reply-To: <4BF56106.4010806@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 thread-index: Acr4ODn25CvYAsA6SVmIw3HKpX+S2wAeugaw References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> <4BF56106.4010806@cisco.com> From: "Avasarala Ranjit-A20990" To: "Paul Kyzivat" , "Elwell, John" X-CFilter-Loop: Reflected Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 10:27:43 -0000 Hi Paul So what is the consensus? Come up with a requirements I-D and then continue on the event package? Thanks=20 Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Thursday, May 20, 2010 9:49 PM To: Elwell, John Cc: Avasarala Ranjit-A20990; dispatch@ietf.org; R.Jesske@telekom.de Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 Elwell, John wrote: > I too think this work is potentially interesting beyond IMS, and would find it more attractive to combine requirements and have a single event package. >=20 > Of course, there are other ways of achieving this. There could be an HTTP resource that allows me to inspect recent calls that have been subject to automatic call handling, e.g., by being diverted or barred. Then I could use https://datatracker.ietf.org/doc/draft-roach-sip-http-subscribe/ to be notified of changes to that resource. No SIP standardisation required. It would be interesting to know whether this would solve requirements. I guess this is fundamentally about automatic call handling. Seems like it might be in the scope of BLISS, except I gather BLISS is winding down. Thanks, Paul > John >=20 >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 20 May 2010 16:33 >> To: Avasarala Ranjit-A20990 >> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de >> Subject: Re: [dispatch] FW: New Version=20 >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> >> >> Avasarala Ranjit-A20990 wrote: >>> Hi Paul >>> >>> No I am not asking for a new WG. I wanted directions to >> take this I-D >>> forward. Like should we merge it with CDIV one as John Elwell was=20 >>> suggesting or keep this separate - which I think is better. >> Well, with the new operating rules for RAI and DISPATCH, if you want=20 >> this to be worked on by some WG, then we either have to find one to=20 >> recharter to do the work, or else we have to spin up another. I don't >> see any obvious existing one to take on the work. >> >> I *do* think this work is potentially interesting beyond IMS.=20 >> A new WG >> is a *possibility* if the work can be framed in a way that people=20 >> want to work on. IMO that will mean first defining the requirements,=20 >> without presuming the mechanism. And combining the requirements for=20 >> CDIV and barring would probably make it more attractive. >> >> Thanks, >> Paul >> >>> Regards >>> Ranjit >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Thursday, May 20, 2010 6:47 PM >>> To: Avasarala Ranjit-A20990 >>> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de >>> Subject: Re: [dispatch] FW: New Version=20 >>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>> >>> >>> >>> Avasarala Ranjit-A20990 wrote: >>>> Hi >>>> >>>> So is the consensus to proceed forward?=20 >>> Proceed forward in what way? Are you asking for a new WG? >>> >>> Thanks, >>> Paul >>> >>>> Regards >>>> Ranjit >>>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>> Sent: Thursday, May 20, 2010 12:15 PM >>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org >>>> Cc: R.Jesske@telekom.de >>>> Subject: RE: [dispatch] FW: New Version >>>> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>>> Sorry, I thought I had already responded, but clearly not. >>>> >>>> I am still of the opinion that there is sufficient synergy >> between the >>>> two event packages that they can be combined into a single event=20 >>>> package. This would have the benefit of being able to have >> a single >>>> subscription to get all information relating to automatic >> handling of >>>> incoming calls, rather than being forced to subscribe >> twice. If you >>>> only want information about diverted calls, or only >> information about >>>> barred calls, you could filter accordingly. If you want different=20 >>>> filtering criteria, or different subscription times for >> the two, there >>>> is nothing to stop you having two separate subscriptions. But we=20 >>>> should not penalise the simple case by forcing two >> subscriptions where >>>> one would do. >>>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] >>>>> Sent: 20 May 2010 05:33 >>>>> To: Elwell, John; dispatch@ietf.org >>>>> Cc: R.Jesske@telekom.de >>>>> Subject: RE: [dispatch] FW: New Version >>>>> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>>>> Hi All >>>>> >>>>> Any further comments on this I-D and suggestions for next steps? >>>>> >>>>> Thanks >>>>> >>>>> >>>>> Regards >>>>> Ranjit >>>>> >>>>> -----Original Message----- >>>>> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On >>>>> Behalf Of Avasarala Ranjit-A20990 >>>>> Sent: Friday, May 14, 2010 11:49 AM >>>>> To: Elwell, John; dispatch@ietf.org >>>>> Subject: Re: [dispatch] FW: New Version >>>>> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>>>> Hi John >>>>> >>>>> This I-D on communication barring notification talks >> about an event >>>>> package for reporting the notification information of >> communication >>>>> barrings (call blocking) that happen in the network on >> behalf of the >>>>> users. >>>>> >>>>> For e.g if Alice sets a call blocking rule that all calls >> from Bob >>>>> need to be blocked, then the network blocks all calls from Bob=20 >>>>> towards Alice. >>>>> So here >>>>> The notification information will include the details of the call=20 >>>>> block >>>>> - i.e (1) the identity of caller (Bob) (2) time of block >> (2) reason >>>>> for block, etc >>>>> >>>>> Yes I agree with you that there is synergy between this >> I-D and the >>>>> one on CDIV, since both of them deal with reporting of >> events that >>>>> occur in the network. While CDIV deals with communication >> diversion, >>>>> this one deals with ICB service. Though both the event >> packages are >>>>> similar in terms of subscriptions and format, their execution and=20 >>>>> user preference may vary. So they need to be looked at differently >>>>> and standardized seperately. >>>>> >>>>> >>>>> Regards >>>>> Ranjit >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Thursday, May 13, 2010 6:25 PM >>>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org >>>>> Cc: T Satyanarayana-A12694 >>>>> Subject: RE: [dispatch] FW: New Version Notification=20 >>>>> fordraft-avasarala-dispatch-comm-barring-notification-00 >>>>> >>>>> Ranjit, >>>>> >>>>> It is not entirely clear to me what the notifications report. For=20 >>>>> example, in 6.7, it says "Typically, it will send >>>>> one when a communication barring is enacted on behalf of the >>> user." >>>>> What is meant by "enacted" here? Is it when some entity,=20 >> on behalf of >>>>> the user, perhaps through some web page, establishes a=20 >> communication=20 >>>>> barring rule? Or is it when an inbound communication=20 >> arrives and is=20 >>>>> processed in accordance with some pre-existing=20 >> communication barring=20 >>>>> rule? I thought at first it was the former, but I am=20 >> tending towards=20 >>>>> thinking it is the latter. Some clarification would be useful. >>>>> >>>>> Assuming it is the latter, there is obviously some synergy with=20 >>>>> draft-avasarala-dispatch-comm-div-notification. Both deal with=20 >>>>> reporting inbound communications that have been subject=20 >> to some rule, >>>>> the rule being conditional on certain criteria such as caller ID. >>>>> Where the conditions are met for a given call to be subject to a=20 >>>>> given >>>>> rule, a notification in accordance with one or the other event=20 >>>>> package >>>>> will be triggered. I fail to see the reason for having=20 >> two separate=20 >>>>> event packages, since this means two separate specifications, two=20 >>>>> different subscriptions, two different formats, etc.. >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 >>>>>> Ranjit-A20990 >>>>>> Sent: 13 May 2010 11:28 >>>>>> To: dispatch@ietf.org >>>>>> Cc: T Satyanarayana-A12694 >>>>>> Subject: [dispatch] FW: New Version Notification for=20 >>>>>> draft-avasarala-dispatch-comm-barring-notification-00 >>>>>> >>>>>> Hi all >>>>>> >>>>>> I have submitted a new I-D on communication barring notification=20 >>>>>> information based on the following >>>>>> >>>>>> Section 8.2.10 Communication Barring - ICB enhancement=20 >> of dynamic=20 >>>>>> blocking of incoming communications of 3GPP TS 22.173 >>>>>> >>>>>> Section 4.5.2.6.1 Actions for ICB at the terminating AS=20 >> of 3GPP TS >>>>>> 24.611 >>>>>> >>>>>> The draft can be accessed from: >>>>>> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n >>>>>> otificatio >>>>>> n-00.txt >>>>>> >>>>>> Please review and comment. >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> Regards >>>>>> Ranjit >>>>>> >>>>>> -----Original Message----- >>>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>>>>> Sent: Thursday, May 13, 2010 3:47 PM >>>>>> To: Avasarala Ranjit-A20990 >>>>>> Cc: r.jesske@telekom.de >>>>>> Subject: New Version Notification for=20 >>>>>> draft-avasarala-dispatch-comm-barring-notification-00 >>>>>> >>>>>> >>>>>> A new version of I-D, >>>>>> >> draft-avasarala-dispatch-comm-barring-notification-00.txt has been=20 >>>>>> successfully submitted by Ranjit Avasarala and posted to=20 >> the IETF=20 >>>>>> repository. >>>>>> >>>>>> Filename: =20 >> draft-avasarala-dispatch-comm-barring-notification >>>>>> Revision: 00 >>>>>> Title: A Session Initiation Protocol (SIP)=20 >>>>>> Event Package for >>>>>> Communication Barring Notification Information in support of the=20 >>>>>> Dynamic Incoming Communication Barring (ICB) Notification service >>>>>> Creation_date: 2010-05-13 >>>>>> WG ID: Independent Submission >>>>>> Number_of_pages: 22 >>>>>> >>>>>> Abstract: >>>>>> 3GPP is defining the protocol specification for the=20 >> Communication=20 >>>>>> Barring (CB) service using IP Multimedia (IM) Core Network (CN)=20 >>>>>> subsystem supplementary service and more particularly=20 >> the dynamic=20 >>>>>> incoming communication barring service. As part of dynamic >>>>> incoming >>>>>> communication barring (ICB) service, a SIP based Event package=20 >>>>>> framework is used for notifying users about=20 >> communication barrings=20 >>>>>> (dynamic and rule based) of their incoming communication=20 >> sessions. >>>>>> This document proposes a new SIP event package for allowing >>>>> users to >>>>>> subscribe to and receive such notifications. Users can >>>>> further define >>>>> >>>>>> filters to control the rate and content of such notifications. >>>>>> The proposed event package is applicable to the ICB=20 >> supplementary=20 >>>>>> service in IMS and may not be applicable to the general internet. >>>>>> =20 >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 deepanshu@huawei.com Fri May 21 04:47:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284473A924A for ; Fri, 21 May 2010 04:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.491 X-Spam-Level: X-Spam-Status: No, score=0.491 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjtEQR8o+n4X for ; Fri, 21 May 2010 04:47:42 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 968A83A98DA for ; Fri, 21 May 2010 00:46:51 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2R004ESEV76O@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 21 May 2010 15:45:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2R003F0EV7O3@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 21 May 2010 15:45:07 +0800 (CST) Received: from D57531 ([10.168.86.63]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2R0076WEV7P8@szxml06-in.huawei.com> for dispatch@ietf.org; Fri, 21 May 2010 15:45:07 +0800 (CST) Date: Fri, 21 May 2010 15:45:07 +0800 From: Deepanshu Gautam In-reply-to: To: dispatch@ietf.org Message-id: <002f01caf8b9$88523e90$3f56a80a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_sAWth5mV/XSfO8nthGWHgw)" Thread-index: Acr4gJ7A8Bpw3xLXQqiCVQfTRm4AzwAOMStA Subject: [dispatch] Quick Answer usecase and requirement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 11:47:47 -0000 This is a multi-part message in MIME format. --Boundary_(ID_sAWth5mV/XSfO8nthGWHgw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all, I have just submitted an I-D containing usecases and requirement for what I call Quick Answer. http://tools.ietf.org/id/draft-gautam-dispatch-quick-answer-00.txt This concept was discussed in SIMPLE list/meeting some time ago and requested for clear usecase and requirements. It was suggested to take this to DISPATCH WG for more comments/reviews. http://www.ietf.org/mail-archive/web/simple/current/msg08553.html For summary: I defined Quick Answer as some readely avaliable IM to the user, from which he can choose as and when required. These are created by the user himself. The term "Canned responses" are used for the same purpose elsewhere http://en.wikipedia.org/wiki/Canned_response http://gmailblog.blogspot.com/2008/10/new-in-labs-canned-responses.html I would appreciate any comments and opinions form the group. Regards Deepanshu --Boundary_(ID_sAWth5mV/XSfO8nthGWHgw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
 
Dear all,
 
I have just submitted an I-D containing usecases and requirement for what I call Quick Answer.
 
This concept was discussed in SIMPLE list/meeting some time ago and requested for clear usecase and requirements. It was suggested to take this to DISPATCH WG for more comments/reviews.
 
 
For summary: I defined Quick Answer as some readely avaliable IM to the user, from which he can choose as and when required. These are created by the user himself. The term "Canned responses" are used for the same purpose elsewhere
 
I would appreciate any comments and opinions form the group.
 
 
Regards
Deepanshu
 
--Boundary_(ID_sAWth5mV/XSfO8nthGWHgw)-- From john.elwell@siemens-enterprise.com Fri May 21 05:28:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258D13A6D0E for ; Fri, 21 May 2010 05:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3i2OHJ7Jck2 for ; Fri, 21 May 2010 05:28:02 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 2F3153A7012 for ; Fri, 21 May 2010 01:04:18 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-248752; Fri, 21 May 2010 10:04:12 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id EC6581EB82AE; Fri, 21 May 2010 10:04:11 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 21 May 2010 10:04:12 +0200 From: "Elwell, John" To: Avasarala Ranjit-A20990 , Paul Kyzivat Date: Fri, 21 May 2010 10:04:10 +0200 Thread-Topic: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 Thread-Index: Acr4ODn25CvYAsA6SVmIw3HKpX+S2wAeugawAAIbTdA= Message-ID: References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> <4BF56106.4010806@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.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" , "R.Jesske@telekom.de" Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 12:28:04 -0000 Ranjit, What I would like to see are: - statement of requirements (for both barring and diversion); - survey of solution space, with pros and cons (e.g., event package(s) as s= o far described versus other approaches); - in case of event package, pros and cons of combining diversion and barrin= g into a single event package. Getting these fundamental principles established is more important than wor= king on details of an event package. John=20 > -----Original Message----- > From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20 > Sent: 21 May 2010 08:00 > To: Paul Kyzivat; Elwell, John > Cc: dispatch@ietf.org; R.Jesske@telekom.de > Subject: RE: [dispatch] FW: New Version=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >=20 > Hi Paul >=20 > So what is the consensus? Come up with a requirements I-D and then > continue on the event package? >=20 > Thanks=20 >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Thursday, May 20, 2010 9:49 PM > To: Elwell, John > Cc: Avasarala Ranjit-A20990; dispatch@ietf.org; R.Jesske@telekom.de > Subject: Re: [dispatch] FW: New Version > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >=20 >=20 >=20 > Elwell, John wrote: > > I too think this work is potentially interesting beyond=20 > IMS, and would > find it more attractive to combine requirements and have a=20 > single event > package. > >=20 > > Of course, there are other ways of achieving this. There could be an > HTTP resource that allows me to inspect recent calls that have been > subject to automatic call handling, e.g., by being diverted or barred. > Then I could use > https://datatracker.ietf.org/doc/draft-roach-sip-http-subscribe/ to be > notified of changes to that resource. No SIP standardisation required. > It would be interesting to know whether this would solve requirements. >=20 > I guess this is fundamentally about automatic call handling. > Seems like it might be in the scope of BLISS, except I gather BLISS is > winding down. >=20 > Thanks, > Paul >=20 > > John > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 20 May 2010 16:33 > >> To: Avasarala Ranjit-A20990 > >> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de > >> Subject: Re: [dispatch] FW: New Version=20 > >>=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > >> > >> > >> > >> Avasarala Ranjit-A20990 wrote: > >>> Hi Paul > >>> > >>> No I am not asking for a new WG. I wanted directions to > >> take this I-D > >>> forward. Like should we merge it with CDIV one as John Elwell was=20 > >>> suggesting or keep this separate - which I think is better. > >> Well, with the new operating rules for RAI and DISPATCH,=20 > if you want=20 > >> this to be worked on by some WG, then we either have to=20 > find one to=20 > >> recharter to do the work, or else we have to spin up=20 > another. I don't >=20 > >> see any obvious existing one to take on the work. > >> > >> I *do* think this work is potentially interesting beyond IMS.=20 > >> A new WG > >> is a *possibility* if the work can be framed in a way that people=20 > >> want to work on. IMO that will mean first defining the=20 > requirements,=20 > >> without presuming the mechanism. And combining the=20 > requirements for=20 > >> CDIV and barring would probably make it more attractive. > >> > >> Thanks, > >> Paul > >> > >>> Regards > >>> Ranjit > >>> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: Thursday, May 20, 2010 6:47 PM > >>> To: Avasarala Ranjit-A20990 > >>> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de > >>> Subject: Re: [dispatch] FW: New Version=20 > >>>=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > >>> > >>> > >>> > >>> Avasarala Ranjit-A20990 wrote: > >>>> Hi > >>>> > >>>> So is the consensus to proceed forward?=20 > >>> Proceed forward in what way? Are you asking for a new WG? > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Regards > >>>> Ranjit > >>>> > >>>> -----Original Message----- > >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>> Sent: Thursday, May 20, 2010 12:15 PM > >>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org > >>>> Cc: R.Jesske@telekom.de > >>>> Subject: RE: [dispatch] FW: New Version > >>>> > >>=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > >>>> Sorry, I thought I had already responded, but clearly not. > >>>> > >>>> I am still of the opinion that there is sufficient synergy > >> between the > >>>> two event packages that they can be combined into a single event=20 > >>>> package. This would have the benefit of being able to have > >> a single > >>>> subscription to get all information relating to automatic > >> handling of > >>>> incoming calls, rather than being forced to subscribe > >> twice. If you > >>>> only want information about diverted calls, or only > >> information about > >>>> barred calls, you could filter accordingly. If you want=20 > different=20 > >>>> filtering criteria, or different subscription times for > >> the two, there > >>>> is nothing to stop you having two separate subscriptions. But we=20 > >>>> should not penalise the simple case by forcing two > >> subscriptions where > >>>> one would do. > >>>> > >>>> John > >>>> > >>>>> -----Original Message----- > >>>>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] > >>>>> Sent: 20 May 2010 05:33 > >>>>> To: Elwell, John; dispatch@ietf.org > >>>>> Cc: R.Jesske@telekom.de > >>>>> Subject: RE: [dispatch] FW: New Version > >>>>> > >>=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > >>>>> Hi All > >>>>> > >>>>> Any further comments on this I-D and suggestions for next steps? > >>>>> > >>>>> Thanks > >>>>> > >>>>> > >>>>> Regards > >>>>> Ranjit > >>>>> > >>>>> -----Original Message----- > >>>>> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On > >>>>> Behalf Of Avasarala Ranjit-A20990 > >>>>> Sent: Friday, May 14, 2010 11:49 AM > >>>>> To: Elwell, John; dispatch@ietf.org > >>>>> Subject: Re: [dispatch] FW: New Version > >>>>> > >>=20 > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > >>>>> Hi John > >>>>> > >>>>> This I-D on communication barring notification talks > >> about an event > >>>>> package for reporting the notification information of > >> communication > >>>>> barrings (call blocking) that happen in the network on > >> behalf of the > >>>>> users. > >>>>> > >>>>> For e.g if Alice sets a call blocking rule that all calls > >> from Bob > >>>>> need to be blocked, then the network blocks all calls from Bob=20 > >>>>> towards Alice. > >>>>> So here > >>>>> The notification information will include the details=20 > of the call=20 > >>>>> block > >>>>> - i.e (1) the identity of caller (Bob) (2) time of block > >> (2) reason > >>>>> for block, etc > >>>>> > >>>>> Yes I agree with you that there is synergy between this > >> I-D and the > >>>>> one on CDIV, since both of them deal with reporting of > >> events that > >>>>> occur in the network. While CDIV deals with communication > >> diversion, > >>>>> this one deals with ICB service. Though both the event > >> packages are > >>>>> similar in terms of subscriptions and format, their=20 > execution and=20 > >>>>> user preference may vary. So they need to be looked at=20 > differently >=20 > >>>>> and standardized seperately. > >>>>> > >>>>> > >>>>> Regards > >>>>> Ranjit > >>>>> > >>>>> -----Original Message----- > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>> Sent: Thursday, May 13, 2010 6:25 PM > >>>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org > >>>>> Cc: T Satyanarayana-A12694 > >>>>> Subject: RE: [dispatch] FW: New Version Notification=20 > >>>>> fordraft-avasarala-dispatch-comm-barring-notification-00 > >>>>> > >>>>> Ranjit, > >>>>> > >>>>> It is not entirely clear to me what the notifications=20 > report. For=20 > >>>>> example, in 6.7, it says "Typically, it will send > >>>>> one when a communication barring is enacted on behalf of the > >>> user." > >>>>> What is meant by "enacted" here? Is it when some entity,=20 > >> on behalf of > >>>>> the user, perhaps through some web page, establishes a=20 > >> communication=20 > >>>>> barring rule? Or is it when an inbound communication=20 > >> arrives and is=20 > >>>>> processed in accordance with some pre-existing=20 > >> communication barring=20 > >>>>> rule? I thought at first it was the former, but I am=20 > >> tending towards=20 > >>>>> thinking it is the latter. Some clarification would be useful. > >>>>> > >>>>> Assuming it is the latter, there is obviously some synergy with=20 > >>>>> draft-avasarala-dispatch-comm-div-notification. Both deal with=20 > >>>>> reporting inbound communications that have been subject=20 > >> to some rule, > >>>>> the rule being conditional on certain criteria such as=20 > caller ID. > >>>>> Where the conditions are met for a given call to be=20 > subject to a=20 > >>>>> given > >>>>> rule, a notification in accordance with one or the other event=20 > >>>>> package > >>>>> will be triggered. I fail to see the reason for having=20 > >> two separate=20 > >>>>> event packages, since this means two separate=20 > specifications, two=20 > >>>>> different subscriptions, two different formats, etc.. > >>>>> > >>>>> John > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: dispatch-bounces@ietf.org > >>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 > >>>>>> Ranjit-A20990 > >>>>>> Sent: 13 May 2010 11:28 > >>>>>> To: dispatch@ietf.org > >>>>>> Cc: T Satyanarayana-A12694 > >>>>>> Subject: [dispatch] FW: New Version Notification for=20 > >>>>>> draft-avasarala-dispatch-comm-barring-notification-00 > >>>>>> > >>>>>> Hi all > >>>>>> > >>>>>> I have submitted a new I-D on communication barring=20 > notification=20 > >>>>>> information based on the following > >>>>>> > >>>>>> Section 8.2.10 Communication Barring - ICB enhancement=20 > >> of dynamic=20 > >>>>>> blocking of incoming communications of 3GPP TS 22.173 > >>>>>> > >>>>>> Section 4.5.2.6.1 Actions for ICB at the terminating AS=20 > >> of 3GPP TS > >>>>>> 24.611 > >>>>>> > >>>>>> The draft can be accessed from: > >>>>>> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n > >>>>>> otificatio > >>>>>> n-00.txt > >>>>>> > >>>>>> Please review and comment. > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> > >>>>>> Regards > >>>>>> Ranjit > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > >>>>>> Sent: Thursday, May 13, 2010 3:47 PM > >>>>>> To: Avasarala Ranjit-A20990 > >>>>>> Cc: r.jesske@telekom.de > >>>>>> Subject: New Version Notification for=20 > >>>>>> draft-avasarala-dispatch-comm-barring-notification-00 > >>>>>> > >>>>>> > >>>>>> A new version of I-D, > >>>>>> > >> draft-avasarala-dispatch-comm-barring-notification-00.txt has been=20 > >>>>>> successfully submitted by Ranjit Avasarala and posted to=20 > >> the IETF=20 > >>>>>> repository. > >>>>>> > >>>>>> Filename: =20 > >> draft-avasarala-dispatch-comm-barring-notification > >>>>>> Revision: 00 > >>>>>> Title: A Session Initiation Protocol (SIP)=20 > >>>>>> Event Package for > >>>>>> Communication Barring Notification Information in=20 > support of the=20 > >>>>>> Dynamic Incoming Communication Barring (ICB)=20 > Notification service > >>>>>> Creation_date: 2010-05-13 > >>>>>> WG ID: Independent Submission > >>>>>> Number_of_pages: 22 > >>>>>> > >>>>>> Abstract: > >>>>>> 3GPP is defining the protocol specification for the=20 > >> Communication=20 > >>>>>> Barring (CB) service using IP Multimedia (IM) Core=20 > Network (CN)=20 > >>>>>> subsystem supplementary service and more particularly=20 > >> the dynamic=20 > >>>>>> incoming communication barring service. As part of dynamic > >>>>> incoming > >>>>>> communication barring (ICB) service, a SIP based Event package=20 > >>>>>> framework is used for notifying users about=20 > >> communication barrings=20 > >>>>>> (dynamic and rule based) of their incoming communication=20 > >> sessions. > >>>>>> This document proposes a new SIP event package for allowing > >>>>> users to > >>>>>> subscribe to and receive such notifications. Users can > >>>>> further define > >>>>> > >>>>>> filters to control the rate and content of such notifications. > >>>>>> The proposed event package is applicable to the ICB=20 > >> supplementary=20 > >>>>>> service in IMS and may not be applicable to the=20 > general internet. > >>>>>> =20 > >>>>>> > >>>>>> > >>>>>> > >>>>>> The IETF Secretariat. > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> dispatch mailing list > >>>>>> dispatch@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/dispatch > >>>>>> > >>>>> _______________________________________________ > >>>>> dispatch mailing list > >>>>> dispatch@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/dispatch > >>>>> > >>>> _______________________________________________ > >>>> dispatch mailing list > >>>> dispatch@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dispatch > >>>> > = From pkyzivat@cisco.com Fri May 21 09:39:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E64728C1CD for ; Fri, 21 May 2010 09:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.483 X-Spam-Level: X-Spam-Status: No, score=-9.483 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNmbkHiyHaNd for ; Fri, 21 May 2010 09:39:49 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1D7033A7E5F for ; Fri, 21 May 2010 05:43:47 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACsd9ktAZnwN/2dsb2JhbACeIXGif5lahRIE X-IronPort-AV: E=Sophos;i="4.53,278,1272844800"; d="scan'208";a="113276698" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 May 2010 12:43:40 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4LChenk016756; Fri, 21 May 2010 12:43:40 GMT Message-ID: <4BF67FFC.2080103@cisco.com> Date: Fri, 21 May 2010 08:43:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Deepanshu Gautam References: <002401caf880$9f0f68d0$3f56a80a@china.huawei.com> In-Reply-To: <002401caf880$9f0f68d0$3f56a80a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Quick Answer usecase and requirement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 16:39:51 -0000 I took a quick look at this. It seems the essence of this is: - a per-user database with text keys and text values - a way for a client to query by key and get a value - a way for client to query for all the keys - a way for a client to revise the db There are potentially many uses for such a thing besides quick answer. There are also lots of potential solutions to this that don't involve SIP in any way. So I don't see any reason to work on this in DISPATCH or RAI. Thanks, Paul Deepanshu Gautam wrote: > Dear all, > > I have just submitted an I-D containing usecases and requirement for > what I call Quick Answer. > http://tools.ietf.org/id/draft-gautam-dispatch-quick-answer-00.txt > > This concept was discussed in SIMPLE list/meeting some time ago and > requested for clear usecase and requirements. It was suggested to take > this to DISPATCH WG for more comments/reviews. > http://www.ietf.org/mail-archive/web/simple/current/msg08553.html > > > For summary: I defined Quick Answer as some readely avaliable IM to the > user, from which he can choose as and when required. These are created > by the user himself. The term "Canned responses" are used for the same > purpose elsewhere > http://en.wikipedia.org/wiki/Canned_response > http://gmailblog.blogspot.com/2008/10/new-in-labs-canned-responses.html > > I would appreciate any comments and opinions form the group. > > > Regards > Deepanshu > > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Fri May 21 10:24:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D051B28C60B for ; Fri, 21 May 2010 10:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifof31uaW1kn for ; Fri, 21 May 2010 10:24:13 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 472873A7EA8 for ; Fri, 21 May 2010 05:52:02 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFYe9ktAZnwM/2dsb2JhbACeIXGjEJleglEJgjgEj34 X-IronPort-AV: E=Sophos;i="4.53,278,1272844800"; d="scan'208";a="113279104" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 May 2010 12:51:55 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4LCptjk008698; Fri, 21 May 2010 12:51:55 GMT Message-ID: <4BF681EB.40205@cisco.com> Date: Fri, 21 May 2010 08:51:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4EBF6A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A55483A@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> <4BF56106.4010806@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 17:24:14 -0000 Ranjit, I can't declare consensus for dispatch - I'm just a participant like everybody else. The chairs can declare consensus when they think it has been achieved. IMO there is as yet no consensus. I agree with what John stated in his reply to you. Thanks, Paul Avasarala Ranjit-A20990 wrote: > Hi Paul > > So what is the consensus? Come up with a requirements I-D and then > continue on the event package? > > Thanks > > > Regards > Ranjit > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, May 20, 2010 9:49 PM > To: Elwell, John > Cc: Avasarala Ranjit-A20990; dispatch@ietf.org; R.Jesske@telekom.de > Subject: Re: [dispatch] FW: New Version > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > > > > Elwell, John wrote: >> I too think this work is potentially interesting beyond IMS, and would > find it more attractive to combine requirements and have a single event > package. >> Of course, there are other ways of achieving this. There could be an > HTTP resource that allows me to inspect recent calls that have been > subject to automatic call handling, e.g., by being diverted or barred. > Then I could use > https://datatracker.ietf.org/doc/draft-roach-sip-http-subscribe/ to be > notified of changes to that resource. No SIP standardisation required. > It would be interesting to know whether this would solve requirements. > > I guess this is fundamentally about automatic call handling. > Seems like it might be in the scope of BLISS, except I gather BLISS is > winding down. > > Thanks, > Paul > >> John >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: 20 May 2010 16:33 >>> To: Avasarala Ranjit-A20990 >>> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de >>> Subject: Re: [dispatch] FW: New Version >>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>> >>> >>> >>> Avasarala Ranjit-A20990 wrote: >>>> Hi Paul >>>> >>>> No I am not asking for a new WG. I wanted directions to >>> take this I-D >>>> forward. Like should we merge it with CDIV one as John Elwell was >>>> suggesting or keep this separate - which I think is better. >>> Well, with the new operating rules for RAI and DISPATCH, if you want >>> this to be worked on by some WG, then we either have to find one to >>> recharter to do the work, or else we have to spin up another. I don't > >>> see any obvious existing one to take on the work. >>> >>> I *do* think this work is potentially interesting beyond IMS. >>> A new WG >>> is a *possibility* if the work can be framed in a way that people >>> want to work on. IMO that will mean first defining the requirements, >>> without presuming the mechanism. And combining the requirements for >>> CDIV and barring would probably make it more attractive. >>> >>> Thanks, >>> Paul >>> >>>> Regards >>>> Ranjit >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Thursday, May 20, 2010 6:47 PM >>>> To: Avasarala Ranjit-A20990 >>>> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de >>>> Subject: Re: [dispatch] FW: New Version >>>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>>> >>>> >>>> >>>> Avasarala Ranjit-A20990 wrote: >>>>> Hi >>>>> >>>>> So is the consensus to proceed forward? >>>> Proceed forward in what way? Are you asking for a new WG? >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards >>>>> Ranjit >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Thursday, May 20, 2010 12:15 PM >>>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org >>>>> Cc: R.Jesske@telekom.de >>>>> Subject: RE: [dispatch] FW: New Version >>>>> >>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>>>> Sorry, I thought I had already responded, but clearly not. >>>>> >>>>> I am still of the opinion that there is sufficient synergy >>> between the >>>>> two event packages that they can be combined into a single event >>>>> package. This would have the benefit of being able to have >>> a single >>>>> subscription to get all information relating to automatic >>> handling of >>>>> incoming calls, rather than being forced to subscribe >>> twice. If you >>>>> only want information about diverted calls, or only >>> information about >>>>> barred calls, you could filter accordingly. If you want different >>>>> filtering criteria, or different subscription times for >>> the two, there >>>>> is nothing to stop you having two separate subscriptions. But we >>>>> should not penalise the simple case by forcing two >>> subscriptions where >>>>> one would do. >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] >>>>>> Sent: 20 May 2010 05:33 >>>>>> To: Elwell, John; dispatch@ietf.org >>>>>> Cc: R.Jesske@telekom.de >>>>>> Subject: RE: [dispatch] FW: New Version >>>>>> >>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>>>>> Hi All >>>>>> >>>>>> Any further comments on this I-D and suggestions for next steps? >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> Regards >>>>>> Ranjit >>>>>> >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On >>>>>> Behalf Of Avasarala Ranjit-A20990 >>>>>> Sent: Friday, May 14, 2010 11:49 AM >>>>>> To: Elwell, John; dispatch@ietf.org >>>>>> Subject: Re: [dispatch] FW: New Version >>>>>> >>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >>>>>> Hi John >>>>>> >>>>>> This I-D on communication barring notification talks >>> about an event >>>>>> package for reporting the notification information of >>> communication >>>>>> barrings (call blocking) that happen in the network on >>> behalf of the >>>>>> users. >>>>>> >>>>>> For e.g if Alice sets a call blocking rule that all calls >>> from Bob >>>>>> need to be blocked, then the network blocks all calls from Bob >>>>>> towards Alice. >>>>>> So here >>>>>> The notification information will include the details of the call >>>>>> block >>>>>> - i.e (1) the identity of caller (Bob) (2) time of block >>> (2) reason >>>>>> for block, etc >>>>>> >>>>>> Yes I agree with you that there is synergy between this >>> I-D and the >>>>>> one on CDIV, since both of them deal with reporting of >>> events that >>>>>> occur in the network. While CDIV deals with communication >>> diversion, >>>>>> this one deals with ICB service. Though both the event >>> packages are >>>>>> similar in terms of subscriptions and format, their execution and >>>>>> user preference may vary. So they need to be looked at differently > >>>>>> and standardized seperately. >>>>>> >>>>>> >>>>>> Regards >>>>>> Ranjit >>>>>> >>>>>> -----Original Message----- >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>> Sent: Thursday, May 13, 2010 6:25 PM >>>>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org >>>>>> Cc: T Satyanarayana-A12694 >>>>>> Subject: RE: [dispatch] FW: New Version Notification >>>>>> fordraft-avasarala-dispatch-comm-barring-notification-00 >>>>>> >>>>>> Ranjit, >>>>>> >>>>>> It is not entirely clear to me what the notifications report. For >>>>>> example, in 6.7, it says "Typically, it will send >>>>>> one when a communication barring is enacted on behalf of the >>>> user." >>>>>> What is meant by "enacted" here? Is it when some entity, >>> on behalf of >>>>>> the user, perhaps through some web page, establishes a >>> communication >>>>>> barring rule? Or is it when an inbound communication >>> arrives and is >>>>>> processed in accordance with some pre-existing >>> communication barring >>>>>> rule? I thought at first it was the former, but I am >>> tending towards >>>>>> thinking it is the latter. Some clarification would be useful. >>>>>> >>>>>> Assuming it is the latter, there is obviously some synergy with >>>>>> draft-avasarala-dispatch-comm-div-notification. Both deal with >>>>>> reporting inbound communications that have been subject >>> to some rule, >>>>>> the rule being conditional on certain criteria such as caller ID. >>>>>> Where the conditions are met for a given call to be subject to a >>>>>> given >>>>>> rule, a notification in accordance with one or the other event >>>>>> package >>>>>> will be triggered. I fail to see the reason for having >>> two separate >>>>>> event packages, since this means two separate specifications, two >>>>>> different subscriptions, two different formats, etc.. >>>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: dispatch-bounces@ietf.org >>>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala >>>>>>> Ranjit-A20990 >>>>>>> Sent: 13 May 2010 11:28 >>>>>>> To: dispatch@ietf.org >>>>>>> Cc: T Satyanarayana-A12694 >>>>>>> Subject: [dispatch] FW: New Version Notification for >>>>>>> draft-avasarala-dispatch-comm-barring-notification-00 >>>>>>> >>>>>>> Hi all >>>>>>> >>>>>>> I have submitted a new I-D on communication barring notification >>>>>>> information based on the following >>>>>>> >>>>>>> Section 8.2.10 Communication Barring - ICB enhancement >>> of dynamic >>>>>>> blocking of incoming communications of 3GPP TS 22.173 >>>>>>> >>>>>>> Section 4.5.2.6.1 Actions for ICB at the terminating AS >>> of 3GPP TS >>>>>>> 24.611 >>>>>>> >>>>>>> The draft can be accessed from: >>>>>>> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n >>>>>>> otificatio >>>>>>> n-00.txt >>>>>>> >>>>>>> Please review and comment. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Ranjit >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>>>>>> Sent: Thursday, May 13, 2010 3:47 PM >>>>>>> To: Avasarala Ranjit-A20990 >>>>>>> Cc: r.jesske@telekom.de >>>>>>> Subject: New Version Notification for >>>>>>> draft-avasarala-dispatch-comm-barring-notification-00 >>>>>>> >>>>>>> >>>>>>> A new version of I-D, >>>>>>> >>> draft-avasarala-dispatch-comm-barring-notification-00.txt has been >>>>>>> successfully submitted by Ranjit Avasarala and posted to >>> the IETF >>>>>>> repository. >>>>>>> >>>>>>> Filename: >>> draft-avasarala-dispatch-comm-barring-notification >>>>>>> Revision: 00 >>>>>>> Title: A Session Initiation Protocol (SIP) >>>>>>> Event Package for >>>>>>> Communication Barring Notification Information in support of the >>>>>>> Dynamic Incoming Communication Barring (ICB) Notification service >>>>>>> Creation_date: 2010-05-13 >>>>>>> WG ID: Independent Submission >>>>>>> Number_of_pages: 22 >>>>>>> >>>>>>> Abstract: >>>>>>> 3GPP is defining the protocol specification for the >>> Communication >>>>>>> Barring (CB) service using IP Multimedia (IM) Core Network (CN) >>>>>>> subsystem supplementary service and more particularly >>> the dynamic >>>>>>> incoming communication barring service. As part of dynamic >>>>>> incoming >>>>>>> communication barring (ICB) service, a SIP based Event package >>>>>>> framework is used for notifying users about >>> communication barrings >>>>>>> (dynamic and rule based) of their incoming communication >>> sessions. >>>>>>> This document proposes a new SIP event package for allowing >>>>>> users to >>>>>>> subscribe to and receive such notifications. Users can >>>>>> further define >>>>>> >>>>>>> filters to control the rate and content of such notifications. >>>>>>> The proposed event package is applicable to the ICB >>> supplementary >>>>>>> service in IMS and may not be applicable to the general internet. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF Secretariat. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 Fri May 21 11:03:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596E63A73E9 for ; Fri, 21 May 2010 11:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.908, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hnx4qq3XGnM for ; Fri, 21 May 2010 11:03:16 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 66F773A687B for ; Fri, 21 May 2010 07:05:20 -0700 (PDT) Received: by iwn42 with SMTP id 42so1199561iwn.31 for ; Fri, 21 May 2010 07:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fu8czmy2OkCzRFOuc3HjLwhyZCEYcmPEFZj15+9N7uU=; b=FKOHLBeKOJKal8ktT/xZmLHxhLGDMMWU2dAHoT9pTC+phgH7qeCCTECY3pBcBUP86Z Sh+qfSeY49zH1OI4O+4vXVNjUvyvcZ5cxEHMGB8quUkDB1rk+x6IlEYQEK1nVsYNFe3f DQmTeolldow+uOnxgaf+pr054o70RF9MkLVDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QruCXZSXS2oQl9IRuh0mOqdx9LUkH+y7WZNL/RhfbseoxNxZgw5LIa9c8w1IjhwU+3 /t9K+RFxS2LCQLshgwAQOiLhPZHSsak4FwHqKf4C5edpNdCMXFbMP2DKfrji/Uzm4CrT R4/dEOOOB8v46F8/MkzCvsAMHIb81Ia13HVu4= MIME-Version: 1.0 Received: by 10.231.147.18 with SMTP id j18mr1231822ibv.12.1274450711394; Fri, 21 May 2010 07:05:11 -0700 (PDT) Received: by 10.231.79.147 with HTTP; Fri, 21 May 2010 07:05:11 -0700 (PDT) In-Reply-To: References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> <4BF56106.4010806@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.com> Date: Fri, 21 May 2010 09:05:11 -0500 Message-ID: From: Mary Barnes To: ranjit@motorola.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 18:03:18 -0000 Ranjit, John's suggestion is the right approach - that's really the only way this work is going to get traction within DISPATCH. Regards, Mary DISPATCH WG co-chair On Fri, May 21, 2010 at 3:04 AM, Elwell, John wrote: > Ranjit, > > What I would like to see are: > - statement of requirements (for both barring and diversion); > - survey of solution space, with pros and cons (e.g., event package(s) as= so far described versus other approaches); > - in case of event package, pros and cons of combining diversion and barr= ing into a single event package. > > Getting these fundamental principles established is more important than w= orking on details of an event package. > > John > >> -----Original Message----- >> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] >> Sent: 21 May 2010 08:00 >> To: Paul Kyzivat; Elwell, John >> Cc: dispatch@ietf.org; R.Jesske@telekom.de >> Subject: RE: [dispatch] FW: New Version >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> Hi Paul >> >> So what is the consensus? Come up with a requirements I-D and then >> continue on the event package? >> >> Thanks >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, May 20, 2010 9:49 PM >> To: Elwell, John >> Cc: Avasarala Ranjit-A20990; dispatch@ietf.org; R.Jesske@telekom.de >> Subject: Re: [dispatch] FW: New Version >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> >> >> Elwell, John wrote: >> > I too think this work is potentially interesting beyond >> IMS, and would >> find it more attractive to combine requirements and have a >> single event >> package. >> > >> > Of course, there are other ways of achieving this. There could be an >> HTTP resource that allows me to inspect recent calls that have been >> subject to automatic call handling, e.g., by being diverted or barred. >> Then I could use >> https://datatracker.ietf.org/doc/draft-roach-sip-http-subscribe/ to be >> notified of changes to that resource. No SIP standardisation required. >> It would be interesting to know whether this would solve requirements. >> >> I guess this is fundamentally about automatic call handling. >> Seems like it might be in the scope of BLISS, except I gather BLISS is >> winding down. >> >> =A0 =A0 =A0 Thanks, >> =A0 =A0 =A0 Paul >> >> > John >> > >> >> -----Original Message----- >> >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >> Sent: 20 May 2010 16:33 >> >> To: Avasarala Ranjit-A20990 >> >> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de >> >> Subject: Re: [dispatch] FW: New Version >> >> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> >> >> >> >> >> >> Avasarala Ranjit-A20990 wrote: >> >>> Hi Paul >> >>> >> >>> No I am not asking for a new WG. I wanted directions to >> >> take this I-D >> >>> forward. Like should we merge it with CDIV one as John Elwell was >> >>> suggesting or keep this separate - which I think is better. >> >> Well, with the new operating rules for RAI and DISPATCH, >> if you want >> >> this to be worked on by some WG, then we either have to >> find one to >> >> recharter to do the work, or else we have to spin up >> another. I don't >> >> >> see any obvious existing one to take on the work. >> >> >> >> I *do* think this work is potentially interesting beyond IMS. >> >> A new WG >> >> is a *possibility* if the work can be framed in a way that people >> >> want to work on. IMO that will mean first defining the >> requirements, >> >> without presuming the mechanism. And combining the >> requirements for >> >> CDIV and barring would probably make it more attractive. >> >> >> >> =A0 =A0Thanks, >> >> =A0 =A0Paul >> >> >> >>> Regards >> >>> Ranjit >> >>> >> >>> -----Original Message----- >> >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >>> Sent: Thursday, May 20, 2010 6:47 PM >> >>> To: Avasarala Ranjit-A20990 >> >>> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de >> >>> Subject: Re: [dispatch] FW: New Version >> >>> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >>> >> >>> >> >>> >> >>> Avasarala Ranjit-A20990 wrote: >> >>>> Hi >> >>>> >> >>>> So is the consensus to proceed forward? >> >>> Proceed forward in what way? Are you asking for a new WG? >> >>> >> >>> =A0 Thanks, >> >>> =A0 Paul >> >>> >> >>>> Regards >> >>>> Ranjit >> >>>> >> >>>> -----Original Message----- >> >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> >>>> Sent: Thursday, May 20, 2010 12:15 PM >> >>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org >> >>>> Cc: R.Jesske@telekom.de >> >>>> Subject: RE: [dispatch] FW: New Version >> >>>> >> >> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >>>> Sorry, I thought I had already responded, but clearly not. >> >>>> >> >>>> I am still of the opinion that there is sufficient synergy >> >> between the >> >>>> two event packages that they can be combined into a single event >> >>>> package. This would have the benefit of being able to have >> >> a single >> >>>> subscription to get all information relating to automatic >> >> handling of >> >>>> incoming calls, rather than being forced to subscribe >> >> twice. If you >> >>>> only want information about diverted calls, or only >> >> information about >> >>>> barred calls, you could filter accordingly. If you want >> different >> >>>> filtering criteria, or different subscription times for >> >> the two, there >> >>>> is nothing to stop you having two separate subscriptions. But we >> >>>> should not penalise the simple case by forcing two >> >> subscriptions where >> >>>> one would do. >> >>>> >> >>>> John >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] >> >>>>> Sent: 20 May 2010 05:33 >> >>>>> To: Elwell, John; dispatch@ietf.org >> >>>>> Cc: R.Jesske@telekom.de >> >>>>> Subject: RE: [dispatch] FW: New Version >> >>>>> >> >> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >>>>> Hi All >> >>>>> >> >>>>> Any further comments on this I-D and suggestions for next steps? >> >>>>> >> >>>>> Thanks >> >>>>> >> >>>>> >> >>>>> Regards >> >>>>> Ranjit >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: dispatch-bounces@ietf.org >> >> [mailto:dispatch-bounces@ietf.org] On >> >>>>> Behalf Of Avasarala Ranjit-A20990 >> >>>>> Sent: Friday, May 14, 2010 11:49 AM >> >>>>> To: Elwell, John; dispatch@ietf.org >> >>>>> Subject: Re: [dispatch] FW: New Version >> >>>>> >> >> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >>>>> Hi John >> >>>>> >> >>>>> This I-D on communication barring notification talks >> >> about an event >> >>>>> package for reporting the notification information of >> >> communication >> >>>>> barrings (call blocking) that happen in the network on >> >> behalf of the >> >>>>> users. >> >>>>> >> >>>>> For e.g if Alice sets a call blocking rule that all calls >> >> from Bob >> >>>>> need to be blocked, then the network blocks all calls from Bob >> >>>>> towards Alice. >> >>>>> So here >> >>>>> The notification information will include the details >> of the call >> >>>>> block >> >>>>> - i.e (1) the identity of caller (Bob) (2) time of block >> >> (2) reason >> >>>>> for block, etc >> >>>>> >> >>>>> Yes I agree with you that there is synergy between this >> >> I-D and the >> >>>>> one on CDIV, since both of them deal with reporting of >> >> events that >> >>>>> occur in the network. While CDIV deals with communication >> >> diversion, >> >>>>> this one deals with ICB service. Though both the event >> >> packages are >> >>>>> similar in terms of subscriptions and format, their >> execution and >> >>>>> user preference may vary. So they need to be looked at >> differently >> >> >>>>> and standardized seperately. >> >>>>> >> >>>>> >> >>>>> Regards >> >>>>> Ranjit >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> >>>>> Sent: Thursday, May 13, 2010 6:25 PM >> >>>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org >> >>>>> Cc: T Satyanarayana-A12694 >> >>>>> Subject: RE: [dispatch] FW: New Version Notification >> >>>>> fordraft-avasarala-dispatch-comm-barring-notification-00 >> >>>>> >> >>>>> Ranjit, >> >>>>> >> >>>>> It is not entirely clear to me what the notifications >> report. For >> >>>>> example, in 6.7, it says "Typically, it will send >> >>>>> =A0 =A0one when a communication barring is enacted on behalf of th= e >> >>> user." >> >>>>> What is meant by "enacted" here? Is it when some entity, >> >> on behalf of >> >>>>> the user, perhaps through some web page, establishes a >> >> communication >> >>>>> barring rule? Or is it when an inbound communication >> >> arrives and is >> >>>>> processed in accordance with some pre-existing >> >> communication barring >> >>>>> rule? I thought at first it was the former, but I am >> >> tending towards >> >>>>> thinking it is the latter. Some clarification would be useful. >> >>>>> >> >>>>> Assuming it is the latter, there is obviously some synergy with >> >>>>> draft-avasarala-dispatch-comm-div-notification. Both deal with >> >>>>> reporting inbound communications that have been subject >> >> to some rule, >> >>>>> the rule being conditional on certain criteria such as >> caller ID. >> >>>>> Where the conditions are met for a given call to be >> subject to a >> >>>>> given >> >>>>> rule, a notification in accordance with one or the other event >> >>>>> package >> >>>>> will be triggered. I fail to see the reason for having >> >> two separate >> >>>>> event packages, since this means two separate >> specifications, two >> >>>>> different subscriptions, two different formats, etc.. >> >>>>> >> >>>>> John >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: dispatch-bounces@ietf.org >> >>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala >> >>>>>> Ranjit-A20990 >> >>>>>> Sent: 13 May 2010 11:28 >> >>>>>> To: dispatch@ietf.org >> >>>>>> Cc: T Satyanarayana-A12694 >> >>>>>> Subject: [dispatch] FW: New Version Notification for >> >>>>>> draft-avasarala-dispatch-comm-barring-notification-00 >> >>>>>> >> >>>>>> Hi all >> >>>>>> >> >>>>>> I have submitted a new I-D on communication barring >> notification >> >>>>>> information based on the following >> >>>>>> >> >>>>>> Section 8.2.10 Communication Barring - ICB enhancement >> >> of dynamic >> >>>>>> blocking of incoming communications of 3GPP TS 22.173 >> >>>>>> >> >>>>>> Section 4.5.2.6.1 Actions for ICB at the terminating AS >> >> of 3GPP TS >> >>>>>> 24.611 >> >>>>>> >> >>>>>> The draft can be accessed from: >> >>>>>> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n >> >>>>>> otificatio >> >>>>>> n-00.txt >> >>>>>> >> >>>>>> Please review and comment. >> >>>>>> >> >>>>>> Thanks >> >>>>>> >> >>>>>> >> >>>>>> Regards >> >>>>>> Ranjit >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> >>>>>> Sent: Thursday, May 13, 2010 3:47 PM >> >>>>>> To: Avasarala Ranjit-A20990 >> >>>>>> Cc: r.jesske@telekom.de >> >>>>>> Subject: New Version Notification for >> >>>>>> draft-avasarala-dispatch-comm-barring-notification-00 >> >>>>>> >> >>>>>> >> >>>>>> A new version of I-D, >> >>>>>> >> >> draft-avasarala-dispatch-comm-barring-notification-00.txt has been >> >>>>>> successfully submitted by Ranjit Avasarala and posted to >> >> the IETF >> >>>>>> repository. >> >>>>>> >> >>>>>> Filename: >> >> draft-avasarala-dispatch-comm-barring-notification >> >>>>>> Revision: =A0 =A0 =A0 00 >> >>>>>> Title: =A0 =A0 =A0 =A0 =A0A Session Initiation Protocol (SIP) >> >>>>>> Event Package for >> >>>>>> Communication Barring Notification Information in >> support of the >> >>>>>> Dynamic Incoming Communication Barring (ICB) >> Notification service >> >>>>>> Creation_date: =A02010-05-13 >> >>>>>> WG ID: =A0 =A0 =A0 =A0 =A0Independent Submission >> >>>>>> Number_of_pages: 22 >> >>>>>> >> >>>>>> Abstract: >> >>>>>> 3GPP is defining the protocol specification for the >> >> Communication >> >>>>>> Barring (CB) service using IP Multimedia (IM) Core >> Network (CN) >> >>>>>> subsystem supplementary service and more particularly >> >> the dynamic >> >>>>>> incoming communication barring service. =A0As part of dynamic >> >>>>> incoming >> >>>>>> communication barring (ICB) service, a SIP based Event package >> >>>>>> framework is used for notifying users about >> >> communication barrings >> >>>>>> (dynamic and rule based) of their incoming communication >> >> sessions. >> >>>>>> This document proposes a new SIP event package for allowing >> >>>>> users to >> >>>>>> subscribe to and receive such notifications. =A0Users can >> >>>>> further define >> >>>>> >> >>>>>> filters to control the rate and content of such notifications. >> >>>>>> The proposed event package is applicable to the ICB >> >> supplementary >> >>>>>> service in IMS and may not be applicable to the >> general internet. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> The IETF Secretariat. >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> 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 dean.willis@softarmor.com Sun May 23 18:08:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3573A6937 for ; Sun, 23 May 2010 18:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.614 X-Spam-Level: X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Noyqa50ecrRB for ; Sun, 23 May 2010 18:08:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3BC213A6929 for ; Sun, 23 May 2010 18:08:03 -0700 (PDT) Received: from [192.168.2.109] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4O17okd004752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 23 May 2010 20:07:51 -0500 From: Dean Willis To: Mary Barnes In-Reply-To: References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com> Content-Type: text/plain; charset="UTF-8" Date: Sun, 23 May 2010 20:07:44 -0500 Message-ID: <1274663264.1419.6.camel@damnableubu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: DISPATCH Subject: Re: [dispatch] Alert Info URNs - Acronym X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 01:08:04 -0000 On Thu, 2010-05-20 at 10:17 -0500, Mary Barnes wrote: > What about SIPALE (SIP ALErting)? > This suggests a variant, also drink related: SALUD (Sip ALerting for User Devices) "¡salud!" is a proper phrase for a very short toast, meaning "To your health!". Gonzalo should recognize it.... Besides, we're supposed to be multilingual these days, right? -- Dean From christer.holmberg@ericsson.com Mon May 24 04:35:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB73E3A6B97 for ; Mon, 24 May 2010 04:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=-1.905, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol0NKup0Wi4d for ; Mon, 24 May 2010 04:35:27 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2D7D43A6B7E for ; Mon, 24 May 2010 04:35:26 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-a2-4bfa64756522 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 02.45.21861.5746AFB4; Mon, 24 May 2010 13:35:17 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 24 May 2010 13:35:17 +0200 From: Christer Holmberg To: "'Patel, Milan'" , "WORLEY, Dale R (Dale)" , Shida Schubert , Xavier Marjou Date: Mon, 24 May 2010 13:35:16 +0200 Thread-Topic: [dispatch] Reason Inresponses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: Acr3XCMe2RSZKLwkQfSCO3bCUaExewAN5mL7ACdnteAAwPN0sA== Message-ID: References: <61CAF342FE1EE34EAC8FB19B765914000E6FB122@SABRE.InterDigital.com> In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000E6FB122@SABRE.InterDigital.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [dispatch] Reason Inresponses (draft-jesske-dispatch-reason-in-responses-02) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 11:35:28 -0000 +1 Regards, Christer=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Patel, Milan Sent: 20. toukokuuta 2010 18:35 To: WORLEY, Dale R (Dale); Shida Schubert; Xavier Marjou Cc: dispatch@ietf.org; R.Jesske@telekom.de Subject: Re: [dispatch] Reason Inresponses (draft-jesske-dispatch-reason-in= -responses-02) Hi, I've read these drafts, and apart from a few editorials, I believe these dr= afts accurately convey the use cases and solution for Reason in responses. = I agree with Dale, this work should go forwards based on these drafts. Regards, Milan -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of WORLEY, Dale R (Dale) Sent: Wednesday, May 19, 2010 9:42 PM To: Shida Schubert; Xavier Marjou Cc: dispatch@ietf.org; R.Jesske@telekom.de Subject: Re: [dispatch] Reason Inresponses (draft-jesske-dispatch-reason-in-responses-02) ________________________________________ > 2010/5/13 : >> Dear all, >> I have asked for comments on the two drafts mentioned below. >> So far I didn't get any. Does that mean that people are happy now with the >> content and we could proceed with it? >> >> Thank you and Best Regrads >> >> Roland >> _______________________________________________ Yes, I think this work should go foward in accordance with these drafts. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From peter.leis@nsn.com Tue May 25 22:54:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3AA13A6872 for ; Tue, 25 May 2010 22:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGTd3ZECmWem for ; Tue, 25 May 2010 22:54:00 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 0B2D83A6862 for ; Tue, 25 May 2010 22:53:59 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o4Q5riMP002107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 May 2010 07:53:44 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o4Q5ri0M011487; Wed, 26 May 2010 07:53:44 +0200 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 May 2010 07:53:44 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 May 2010 07:53:43 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sADKuJwAAoMDiCAACXnDkAEcfAkg References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail><430FC6BDED356B4C8498F634416644A91A8A5F1711@mail><430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> From: "Leis, Peter (NSN - DE/Munich)" To: "ext Elwell, John" , "ext Hadriel Kaplan" , "Dawes, Peter, VF-Group" , X-OriginalArrivalTime: 26 May 2010 05:53:44.0675 (UTC) FILETIME=[CD382330:01CAFC97] Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 05:54:03 -0000 hello John, 33.328 does not have a particular requirements section. It is the stage-2 specification for the feature "media plane security" and as such provides architecture and functional flows for the feature. I have refered to this as "requirements". Clause 4 of the docuement gives an overview and describes that two solutions based on SDES are required, namely end2end and end2accessedge media protection. The need for two modes based on SDES SRTP is reflected throughout the specification where in every clause you find a sub-clause for end2end and a sub-clasue end2accessedge. Clause 7 provides the registration and session setup procedures, again different for end2end and end2access edge. So end2end and end2accessedge are described as two different and distinct use cases. One goal for end2accessedege security as specified in TS33.328 is to allow to achieve media plane security (on the access leg) fully independant of of any capabilities of clients on the far end side. 33.328 was developped based on requirements documented in 33.828 http://www.3gpp.org/ftp/Specs/html-info/33828.htm Clause 4 describes the use cases whith 4.1.2 describing end2accessedge (access media protection). regards Peter > -----Original Message----- > From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Thursday, May 20, 2010 3:43 PM > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes,=20 > Peter, VF-Group; dispatch@ietf.org > Subject: RE: [dispatch] New I-D:=20 > draft-dawes-dispatch-mediasec-parameter-01 >=20 > Peter, >=20 > I could not locate the particular requirements in the=20 > referenced document, which does not seem to have a=20 > Requirements section as such. Please cite the particular=20 > requirements that answer my questions and point to the=20 > section/paragraph where rationale for those requirements is given. >=20 > The Internet Draft will need to be enhanced to give more=20 > rationale for requirements, rather than rely on reference to=20 > a relatively large external document that allegedly has=20 > requirements hidden somewhere within it. >=20 > Thanks, >=20 > John=20 >=20 > > -----Original Message----- > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com]=20 > > Sent: 20 May 2010 10:05 > > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group;=20 > > dispatch@ietf.org > > Subject: RE: [dispatch] New I-D:=20 > > draft-dawes-dispatch-mediasec-parameter-01 > >=20 > > hello, > >=20 > > sorry for the late reply. > >=20 > > The requirments for media-plane security in 3GPP IMS have=20 > been defined > > in TS 33.328 http://www.3gpp.org/ftp/Specs/html-info/33328.htm .=20 > >=20 > > For SDES SRTP there are two modes defined, one is end2end and one is > > end2accessedge. We need to provide a solution for both modes. > >=20 > > And for end2accessedge we do have a requirement that the UE knows > > whether or not the network (P-CSCF) will support SDES-SRTP=20 > before the > > session takes place as described below. > >=20 > > Peter > >=20 > > > -----Original Message----- > > > From: ext Elwell, John=20 > [mailto:john.elwell@siemens-enterprise.com]=20 > > > Sent: Friday, May 07, 2010 4:17 PM > > > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes,=20 > > > Peter, VF-Group; dispatch@ietf.org > > > Subject: RE: [dispatch] New I-D:=20 > > > draft-dawes-dispatch-mediasec-parameter-01 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: dispatch-bounces@ietf.org=20 > > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Leis, Peter=20 > > > > (NSN - DE/Munich) > > > > Sent: 03 May 2010 14:32 > > > > To: ext Hadriel Kaplan; Dawes, Peter, VF-Group;=20 > dispatch@ietf.org > > > > Subject: Re: [dispatch] New I-D:=20 > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > >=20 > > > >=20 > > > > comments inline=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > > > > > Sent: Friday, April 30, 2010 5:47 PM > > > > > To: Leis, Peter (NSN - DE/Munich); Dawes, Peter, VF-Group;=20 > > > > > dispatch@ietf.org > > > > > Subject: RE: [dispatch] New I-D:=20 > > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Leis, Peter (NSN - DE/Munich)=20 > > [mailto:peter.leis@nsn.com] > > > > > > Sent: Friday, April 30, 2010 4:17 AM > > > > > > To: Hadriel Kaplan; Dawes, Peter, VF-Group;=20 > dispatch@ietf.org > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > > > > Sent: Thursday, April 29, 2010 6:59 PM > > > > > > > > > > > > > > Right, but I'm trying to figure out why that is. I mean > > > > > > > what's the reason the UA needs to know at=20 > Registration time > > > > > > > that it's next-hop b2bua can do srtp, instead of=20 > letting SDP > > > > > > > handle it? > > > > > > > > > > > > > > I *think* the answer is so that it can later send=20 > an INVITE > > > > > > > with an SDP offer without failing the request - is that=20 > > > > > the reason? > > > > > >=20 > > > > > > Right > > > > > =20 > > > > > OK, and I also agree that's a real problem. That issue was=20 > > > > > raised in the IETF in 2006/2007. There was a very simple=20 > > > > > proposal to avoid that, in=20 > > > > > draft-kaplan-mmusic-best-effort-srtp, but the decision of the=20 > > > > > MMUSIC WG was to instead use=20 > > > > > draft-ietf-mmusic-sdp-capability-negotiation to accomplish=20 > > > > > it. That draft is now in the RFC editor's queue. I know=20 > > > > > it's a lot of processing overhead, but that was the decision.=20 > > > > > And I think 3gpp has put support for that into some=20 > > > > release or other. > > > > >=20 > > > >=20 > > > > The requirement in 3GPP is, that the UE has to know whether=20 > > > or not the > > > > network (P-CSCF) will support SDES-SRTP before the session=20 > > > > takes place, > > > > if it wants to employ End2AccessEdge media plane=20 > > security. This will > > > > ensure that the IMS UE shares the media keys only with the=20 > > > P-CSCF and > > > > not with some other entity.=20 > > > [JRE] Why would the UE "want to employ End2AccessEdge" media=20 > > > plane security, as opposed to E2E media plane security? I=20 > > > would have thought the UE would always prefer the latter.=20 > > > Furthermore, the UE should not use keys that have value=20 > > > outside this particular communication session, so if they get=20 > > > passed on beyond the P-CSCF, no harm is done. In fact, if=20 > > > they reach the remote UA, you can end up with E2E security,=20 > > > which would be great from the UE's perspective. > > >=20 > > > > In addition, in 3GPP there is a=20 > > > > requirement > > > > that the UE knows whether media plane security is=20 > > > established between > > > > itself and the network (i.e. End2AccessEdge), or whether=20 > > media plane > > > > security is established between itself and the far end.=20 > > > [JRE] That would be interesting to know, but it is a more=20 > > > general problem - any B2BUA can terminate SRTP, and SIP does=20 > > > not provide any mechanism to indicate whether SRTP is truly=20 > > > end-to-end or just end-to-some-B2BUA. Also a gateway to TDM=20 > > > will terminate SRTP, and SIP does not provide any means of=20 > > > indicating whether SRTP is truly end-to-end or=20 > > > end-to-first-TDM-gateway. > > >=20 > > > John > > >=20 > > > >=20 > > > > As you said, CapNeg has a lot of processing overhead, and=20 > > > in addition, > > > > it does not solve the requirements I have listed. > > > >=20 > > > >=20 > > > > >=20 > > > > > > > > RFC 3840 does only cover UA indicating support,=20 > > but not SBC > > > > > > > indicating > > > > > > > > support. > > > > > > > > > > > > > > Actually, in a way it does. An SBC is a B2BUA. =20 > As a UA, it > > > > > > > can indicate feature tags. What it *can't* do is=20 > > indicate it > > > > > > > in the REGISTER response it sends to the UA. But the UA > > > > > > > could send an OPTIONS to the B2BUA and get it in a feature > > > > > > > tag of the response to the OPTIONS. I know it=20 > sucks to send > > > > > > > more SIP messages, but I don't see how to avoid=20 > that and be > > > > > > > consistent with the SIP architecture. It's=20 > really weird for > > > > > > > a REGISTER response to indicate media capabilities of the=20 > > > > > Registrar. > > > > > >=20 > > > > > > use of OPTIONS was discussed, but due to the additional=20 > > > > > signalling, it > > > > > > was discarded. > > > > >=20 > > > > > Considering all of the other signaling already required=20 > > > > > (subscription to reg-event, subscription to presence, xcap,=20 > > > > > possibly subscription to Config server) isn't an OPTIONS just=20 > > > > > a nit at this point? And that way this could be a general=20 > > > > > solution, instead of a 3gpp-specific one. > > > > >=20 > > > > >=20 > > > > > > The indication of network support for SDES-SRTP in response=20 > > > > > to REGISTER > > > > > > is not included by the registrar, but by the network=20 > > > > > element placed at > > > > > > the edge (the SBC/B2BUA) > > > > >=20 > > > > > I know, but from the UA's perspective the REGISTER response=20 > > > > > is coming from the Registrar, possibly through proxies. =20 > > > > > There's no logical/conceptual model in the IETF for a=20 > > > > > REGISTER response to indicate media capabilities of some=20 > > > > > middle hop of the REGISTER. > > > > >=20 > > > > > -hadriel > > > > >=20 > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > >=20 > > >=20 > >=20 >=20 From john.elwell@siemens-enterprise.com Wed May 26 00:15:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7674C3A6858 for ; Wed, 26 May 2010 00:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEH71YYgTpOU for ; Wed, 26 May 2010 00:15:12 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id B2B263A67AC for ; Wed, 26 May 2010 00:15:11 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-290902; Wed, 26 May 2010 09:15:02 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id EE0E723F0278; Wed, 26 May 2010 09:15:01 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 26 May 2010 09:15:02 +0200 From: "Elwell, John" To: "Leis, Peter (NSN - DE/Munich)" , ext Hadriel Kaplan , "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Date: Wed, 26 May 2010 09:15:01 +0200 Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sADKuJwAAoMDiCAACXnDkAEcfAkgAAMniEA= Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail><430FC6BDED356B4C8498F634416644A91A8A5F1711@mail><430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 07:15:14 -0000 Peter, Rather than having to trawl through several 3GPP specifications to find req= uirements, it would be better to state them clearly, with motivation, in th= e Internet Draft, so that DISPATCH has something concrete on which to base = its discussions. I don't think I received satisfactory answers to the following questions th= at I posted on 2010-05-07 (apologies if I missed the answers): First I asked: "Why would the UE "want to employ End2AccessEdge" media plane security, as = opposed to E2E media plane security? I would have thought the UE would alwa= ys prefer the latter. Furthermore, the UE should not use keys that have val= ue outside this particular communication session, so if they get passed on = beyond the P-CSCF, no harm is done. In fact, if they reach the remote UA, y= ou can end up with E2E security, which would be great from the UE's perspec= tive." Second, in response to your statement "The requirement in 3GPP is, that the= UE has to know whether or not the network (P-CSCF) will support SDES-SRTP = before the session takes place, if it wants to employ End2AccessEdge media = plane security. This will ensure that the IMS UE shares the media keys only= with the P-CSCF and not with some other entity." I asked the question: "That would be interesting to know, but it is a more general problem - any = B2BUA can terminate SRTP, and SIP does not provide any mechanism to indicat= e whether SRTP is truly end-to-end or just end-to-some-B2BUA. Also a gatewa= y to TDM will terminate SRTP, and SIP does not provide any means of indicat= ing whether SRTP is truly end-to-end or end-to-first-TDM-gateway." In addition, I am curious to know whether the proposed mechanism will work = when there is a proxy between the UA and the P-CSCF, e.g., a proxy/B2BUA in= an enterprise or residential network. Is there a danger that the proxy/B2B= UA will apply end2AccessEdge security (between the UA and itself), leaving = the hop between proxy/B2BUA and the P-CSCF unprotected? The so-called requi= rement of the UA to provide security on the first hop is fulfilled, but the= critical hop to the P-CSCF is not secured. There have been extensive discussions on the DISPATCH and the former SIP li= sts over the last couple of years or more about authenticated identity and = how that can be used to give some guarantee to the user as to where secure = media terminates, without any resolution. A solution that just guarantees s= ecurity on a first hop does not really take us further forward. As Hadriel = pointed out, there is the SDP capability negotiation solution, as well as o= ther solutions proposed in the past. John > -----Original Message----- > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com]=20 > Sent: 26 May 2010 06:54 > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group;=20 > dispatch@ietf.org > Subject: RE: [dispatch] New I-D:=20 > draft-dawes-dispatch-mediasec-parameter-01 >=20 > hello John, >=20 > 33.328 does not have a particular requirements section. It is the > stage-2 specification for the feature "media plane security"=20 > and as such > provides architecture and functional flows for the feature. I have > refered to this as "requirements". >=20 > Clause 4 of the docuement gives an overview and describes that two > solutions based on SDES are required, namely end2end and=20 > end2accessedge > media protection. The need for two modes based on SDES SRTP=20 > is reflected > throughout the specification where in every clause you find a=20 > sub-clause > for end2end and a sub-clasue end2accessedge. Clause 7 provides the > registration and session setup procedures, again different for end2end > and end2access edge. >=20 > So end2end and end2accessedge are described as two different and > distinct use cases. >=20 > One goal for end2accessedege security as specified in TS33.328 is to > allow to achieve media plane security (on the access leg) fully > independant of of any capabilities of clients on the far end side. >=20 > 33.328 was developped based on requirements documented in 33.828 > http://www.3gpp.org/ftp/Specs/html-info/33828.htm >=20 > Clause 4 describes the use cases whith 4.1.2 describing end2accessedge > (access media protection). >=20 > regards > Peter >=20 From peter.leis@nsn.com Wed May 26 02:08:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16E63A68C0 for ; Wed, 26 May 2010 02:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLTNJ5293bww for ; Wed, 26 May 2010 02:08:01 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 0AD773A689E for ; Wed, 26 May 2010 02:08:00 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o4Q97kX1021394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 May 2010 11:07:46 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o4Q97jdg009989; Wed, 26 May 2010 11:07:45 +0200 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 May 2010 11:07:45 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 May 2010 11:07:44 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sADKuJwAAoMDiCAACXnDkAEcfAkgAAMniEAAA+ypYA== References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail><430FC6BDED356B4C8498F634416644A91A8A5F1711@mail><430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> From: "Leis, Peter (NSN - DE/Munich)" To: "ext Elwell, John" , "ext Hadriel Kaplan" , "Dawes, Peter, VF-Group" , X-OriginalArrivalTime: 26 May 2010 09:07:45.0548 (UTC) FILETIME=[E7B864C0:01CAFCB2] Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 09:08:03 -0000 John, pls see inline=20 > -----Original Message----- > From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Wednesday, May 26, 2010 9:15 AM > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes,=20 > Peter, VF-Group; dispatch@ietf.org > Subject: RE: [dispatch] New I-D:=20 > draft-dawes-dispatch-mediasec-parameter-01 >=20 > Peter, >=20 > Rather than having to trawl through several 3GPP=20 > specifications to find requirements, it would be better to=20 > state them clearly, with motivation, in the Internet Draft,=20 > so that DISPATCH has something concrete on which to base its=20 > discussions. >=20 > I don't think I received satisfactory answers to the=20 > following questions that I posted on 2010-05-07 (apologies if=20 > I missed the answers): >=20 > First I asked: > "Why would the UE "want to employ End2AccessEdge" media plane=20 > security, as opposed to E2E media plane security? I would=20 > have thought the UE would always prefer the latter.=20 > Furthermore, the UE should not use keys that have value=20 > outside this particular communication session, so if they get=20 > passed on beyond the P-CSCF, no harm is done. In fact, if=20 > they reach the remote UA, you can end up with E2E security,=20 > which would be great from the UE's perspective." [PETER] if the UE knows that the network support media plane security, then the UE can employ this mechanism in order to secure the access link. This mechanisms is independant of support for SDES-SRTP in the UE on the far end. From a network provider point of view this is a desirable feature as it provides a level of security similar to what is known from exsting cellular networks.=20 >=20 > Second, in response to your statement "The requirement in=20 > 3GPP is, that the UE has to know whether or not the network=20 > (P-CSCF) will support SDES-SRTP before the session takes=20 > place, if it wants to employ End2AccessEdge media plane=20 > security. This will ensure that the IMS UE shares the media=20 > keys only with the P-CSCF and not with some other entity." I=20 > asked the question: >=20 > "That would be interesting to know, but it is a more general=20 > problem - any B2BUA can terminate SRTP, and SIP does not=20 > provide any mechanism to indicate whether SRTP is truly=20 > end-to-end or just end-to-some-B2BUA. Also a gateway to TDM=20 > will terminate SRTP, and SIP does not provide any means of=20 > indicating whether SRTP is truly end-to-end or=20 > end-to-first-TDM-gateway." [PETER] IF the UE knows that the network supports SDES-SRTP (i.e. P-CSCF in collaboration with Access-Gateway), then this can be taken into account when deciding whether or not to ask for SRTP. In the end this has an effect on how fast the session setup will be, as the UE can avoid unsuccessfuall session setups. As there are two distinct use cases, namely end2end and end2accessedge, there is a requirement in a 3GPP environment to let the UE (user) know what level of security has been applied to the media. >=20 > In addition, I am curious to know whether the proposed=20 > mechanism will work when there is a proxy between the UA and=20 > the P-CSCF, e.g., a proxy/B2BUA in an enterprise or=20 > residential network. Is there a danger that the proxy/B2BUA=20 > will apply end2AccessEdge security (between the UA and=20 > itself), leaving the hop between proxy/B2BUA and the P-CSCF=20 > unprotected? The so-called requirement of the UA to provide=20 > security on the first hop is fulfilled, but the critical hop=20 > to the P-CSCF is not secured. [PETER] at least in the IMS architecture (which is the driver for the requirements in the draft) there is no proxy between the UA and the P-CSCF. I guess that for enterprise/residential cases this would work as well, as the "UA" in that case is the PBX/residential gateway (attachment point to the SSP network) and therefore media is secured between the PBX/residential gateway and the P-CSCF. In that case it is NOT the linke between the real endpoints (i.e. the PBX phones or residential phones) but the link between the attachement point and the network that is secured. >=20 > There have been extensive discussions on the DISPATCH and the=20 > former SIP lists over the last couple of years or more about=20 > authenticated identity and how that can be used to give some=20 > guarantee to the user as to where secure media terminates,=20 > without any resolution. A solution that just guarantees=20 > security on a first hop does not really take us further=20 > forward. As Hadriel pointed out, there is the SDP capability=20 > negotiation solution, as well as other solutions proposed in the past. [PETER] cellular networks do have access link security, i.e. media encryption. So I believe there is justification for such a solution >=20 > John >=20 >=20 > > -----Original Message----- > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com]=20 > > Sent: 26 May 2010 06:54 > > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group;=20 > > dispatch@ietf.org > > Subject: RE: [dispatch] New I-D:=20 > > draft-dawes-dispatch-mediasec-parameter-01 > >=20 > > hello John, > >=20 > > 33.328 does not have a particular requirements section. It is the > > stage-2 specification for the feature "media plane security"=20 > > and as such > > provides architecture and functional flows for the feature. I have > > refered to this as "requirements". > >=20 > > Clause 4 of the docuement gives an overview and describes that two > > solutions based on SDES are required, namely end2end and=20 > > end2accessedge > > media protection. The need for two modes based on SDES SRTP=20 > > is reflected > > throughout the specification where in every clause you find a=20 > > sub-clause > > for end2end and a sub-clasue end2accessedge. Clause 7 provides the > > registration and session setup procedures, again different=20 > for end2end > > and end2access edge. > >=20 > > So end2end and end2accessedge are described as two different and > > distinct use cases. > >=20 > > One goal for end2accessedege security as specified in TS33.328 is to > > allow to achieve media plane security (on the access leg) fully > > independant of of any capabilities of clients on the far end side. > >=20 > > 33.328 was developped based on requirements documented in 33.828 > > http://www.3gpp.org/ftp/Specs/html-info/33828.htm > >=20 > > Clause 4 describes the use cases whith 4.1.2 describing=20 > end2accessedge > > (access media protection). > >=20 > > regards > > Peter > >=20 >=20 From john.elwell@siemens-enterprise.com Wed May 26 03:23:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7AE33A68C7 for ; Wed, 26 May 2010 03:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkosuHffGi1U for ; Wed, 26 May 2010 03:23:10 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 2AFF23A68BD for ; Wed, 26 May 2010 03:23:08 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-292326; Wed, 26 May 2010 12:22:59 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 3CEA31EB82AE; Wed, 26 May 2010 12:22:59 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 26 May 2010 12:22:59 +0200 From: "Elwell, John" To: "Leis, Peter (NSN - DE/Munich)" , ext Hadriel Kaplan , "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Date: Wed, 26 May 2010 12:22:57 +0200 Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sADKuJwAAoMDiCAACXnDkAEcfAkgAAMniEAAA+ypYAACxFjw Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail><430FC6BDED356B4C8498F634416644A91A8A5F1711@mail><430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 10:23:24 -0000 =20 > -----Original Message----- > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com]=20 > Sent: 26 May 2010 10:08 > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group;=20 > dispatch@ietf.org > Subject: RE: [dispatch] New I-D:=20 > draft-dawes-dispatch-mediasec-parameter-01 >=20 > John, >=20 > pls see inline=20 >=20 > > -----Original Message----- > > From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > > Sent: Wednesday, May 26, 2010 9:15 AM > > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes,=20 > > Peter, VF-Group; dispatch@ietf.org > > Subject: RE: [dispatch] New I-D:=20 > > draft-dawes-dispatch-mediasec-parameter-01 > >=20 > > Peter, > >=20 > > Rather than having to trawl through several 3GPP=20 > > specifications to find requirements, it would be better to=20 > > state them clearly, with motivation, in the Internet Draft,=20 > > so that DISPATCH has something concrete on which to base its=20 > > discussions. > >=20 > > I don't think I received satisfactory answers to the=20 > > following questions that I posted on 2010-05-07 (apologies if=20 > > I missed the answers): > >=20 > > First I asked: > > "Why would the UE "want to employ End2AccessEdge" media plane=20 > > security, as opposed to E2E media plane security? I would=20 > > have thought the UE would always prefer the latter.=20 > > Furthermore, the UE should not use keys that have value=20 > > outside this particular communication session, so if they get=20 > > passed on beyond the P-CSCF, no harm is done. In fact, if=20 > > they reach the remote UA, you can end up with E2E security,=20 > > which would be great from the UE's perspective." >=20 > [PETER] if the UE knows that the network support media plane security, > then the UE can employ this mechanism in order to secure the access > link. This mechanisms is independant of support for SDES-SRTP=20 > in the UE > on the far end. From a network provider point of view this is a > desirable feature as it provides a level of security similar=20 > to what is > known from exsting cellular networks.=20 [JRE] My question was not about network provider benefit, it was about user= benefit, or UE benefit.=20 You appear to be asking for a solution whereby the UE can ask for single ho= p SRTP (just to the P-CSCF) and have it refused if the P-CSCF is unable to = provide it, rather than allowing an entity beyond the P-CSCF to terminate S= RTP. This I do not understand. Why would the UE __want__ to have security o= nly on that hop and not be prepared to have security beyond that hop? As fa= r as I can see, the UE would just want to ask for SRTP and would prefer to = have SRTP end-to-end but might accept something less than end-to-end. >=20 > >=20 > > Second, in response to your statement "The requirement in=20 > > 3GPP is, that the UE has to know whether or not the network=20 > > (P-CSCF) will support SDES-SRTP before the session takes=20 > > place, if it wants to employ End2AccessEdge media plane=20 > > security. This will ensure that the IMS UE shares the media=20 > > keys only with the P-CSCF and not with some other entity." I=20 > > asked the question: > >=20 > > "That would be interesting to know, but it is a more general=20 > > problem - any B2BUA can terminate SRTP, and SIP does not=20 > > provide any mechanism to indicate whether SRTP is truly=20 > > end-to-end or just end-to-some-B2BUA. Also a gateway to TDM=20 > > will terminate SRTP, and SIP does not provide any means of=20 > > indicating whether SRTP is truly end-to-end or=20 > > end-to-first-TDM-gateway." >=20 > [PETER] IF the UE knows that the network supports SDES-SRTP=20 > (i.e. P-CSCF > in collaboration with Access-Gateway), then this can be taken into > account when deciding whether or not to ask for SRTP. In the end this > has an effect on how fast the session setup will be, as the=20 > UE can avoid > unsuccessfuall session setups. As there are two distinct use cases, > namely end2end and end2accessedge, there is a requirement in a 3GPP > environment to let the UE (user) know what level of security has been > applied to the media. [JRE]The UE could just ask for best effort SRTP - if it is supported by the= "far end" (whether this be the P-CSCF or something beyond), SRTP will be u= sed, if not RTP will be used. We have a solution for that already. >=20 > >=20 > > In addition, I am curious to know whether the proposed=20 > > mechanism will work when there is a proxy between the UA and=20 > > the P-CSCF, e.g., a proxy/B2BUA in an enterprise or=20 > > residential network. Is there a danger that the proxy/B2BUA=20 > > will apply end2AccessEdge security (between the UA and=20 > > itself), leaving the hop between proxy/B2BUA and the P-CSCF=20 > > unprotected? The so-called requirement of the UA to provide=20 > > security on the first hop is fulfilled, but the critical hop=20 > > to the P-CSCF is not secured. >=20 > [PETER] at least in the IMS architecture (which is the driver for the > requirements in the draft) there is no proxy between the UA and the > P-CSCF. I guess that for enterprise/residential cases this=20 > would work as > well, as the "UA" in that case is the PBX/residential gateway > (attachment point to the SSP network) and therefore media is secured > between the PBX/residential gateway and the P-CSCF. In that case it is > NOT the linke between the real endpoints (i.e. the PBX phones or > residential phones) but the link between the attachement point and the > network that is secured. [JRE] The proxy/B2BUA acting as PBX might not handle media. Media (and henc= e media security) will come from the UA behind the PBX, whereas signalling = security will come from the PBX. The PBX in this case is not in a position = to negotiate media security - that is just passed on from the UA behind the= PBX. It seems to me that trying to add media security to RFC 3329 violates= this architectural distinction between the hop-by-hop nature of signalling= and the end-to-end nature of media. I agree that if you put in a device su= ch as a Session Border Controller (SBC) between the PBX and the IMS network= the proposed solution might work, but we should not force the presence of = an SBC here. > >=20 > > There have been extensive discussions on the DISPATCH and the=20 > > former SIP lists over the last couple of years or more about=20 > > authenticated identity and how that can be used to give some=20 > > guarantee to the user as to where secure media terminates,=20 > > without any resolution. A solution that just guarantees=20 > > security on a first hop does not really take us further=20 > > forward. As Hadriel pointed out, there is the SDP capability=20 > > negotiation solution, as well as other solutions proposed=20 > in the past. >=20 > [PETER] cellular networks do have access link security, i.e. media > encryption. So I believe there is justification for such a solution [JRE] This does not answer my concern. I am not disputing that security is = required. However, we already have a solution for best effort SRTP. The exi= sting solution is not ideal, since it doesn't tell me how far media is secu= red, only that it is secured at least part of the way to the remote endpoin= t. What the draft seems to be asking for is a solution that specifically li= mits SRTP to a single hop, and I dispute the need and the architectural via= bility of that. John >=20 > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com]=20 > > > Sent: 26 May 2010 06:54 > > > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group;=20 > > > dispatch@ietf.org > > > Subject: RE: [dispatch] New I-D:=20 > > > draft-dawes-dispatch-mediasec-parameter-01 > > >=20 > > > hello John, > > >=20 > > > 33.328 does not have a particular requirements section. It is the > > > stage-2 specification for the feature "media plane security"=20 > > > and as such > > > provides architecture and functional flows for the feature. I have > > > refered to this as "requirements". > > >=20 > > > Clause 4 of the docuement gives an overview and describes that two > > > solutions based on SDES are required, namely end2end and=20 > > > end2accessedge > > > media protection. The need for two modes based on SDES SRTP=20 > > > is reflected > > > throughout the specification where in every clause you find a=20 > > > sub-clause > > > for end2end and a sub-clasue end2accessedge. Clause 7 provides the > > > registration and session setup procedures, again different=20 > > for end2end > > > and end2access edge. > > >=20 > > > So end2end and end2accessedge are described as two different and > > > distinct use cases. > > >=20 > > > One goal for end2accessedege security as specified in=20 > TS33.328 is to > > > allow to achieve media plane security (on the access leg) fully > > > independant of of any capabilities of clients on the far end side. > > >=20 > > > 33.328 was developped based on requirements documented in 33.828 > > > http://www.3gpp.org/ftp/Specs/html-info/33828.htm > > >=20 > > > Clause 4 describes the use cases whith 4.1.2 describing=20 > > end2accessedge > > > (access media protection). > > >=20 > > > regards > > > Peter > > >=20 > >=20 > = From thomas.belling@nsn.com Wed May 26 04:50:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5ABE3A6898 for ; Wed, 26 May 2010 04:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMTWfuBMgwhY for ; Wed, 26 May 2010 04:50:30 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 4CC053A67E6 for ; Wed, 26 May 2010 04:50:29 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o4QBoAcw015074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 May 2010 13:50:10 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o4QBo5sk007330; Wed, 26 May 2010 13:50:10 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 May 2010 13:50:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 May 2010 13:50:05 +0200 Message-ID: <744A66DF31B5B34EA8B08BBD8187A72201BEFD85@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 thread-index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sADKuJwAAoMDiCAACXnDkAEcfAkgAAMniEAAA+ypYAACxFjwAAKOYuA= References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail><430FC6BDED356B4C8498F634416644A91A8A5F1711@mail><430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Elwell, John" , "Leis, Peter (NSN - DE/Munich)" , "ext Hadriel Kaplan" , "Dawes, Peter, VF-Group" , X-OriginalArrivalTime: 26 May 2010 11:50:09.0376 (UTC) FILETIME=[977E8E00:01CAFCC9] Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 11:50:31 -0000 Dear John, see inline=20 Thomas -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext Elwell, John Sent: Wednesday, May 26, 2010 12:23 PM To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes, Peter, = VF-Group; dispatch@ietf.org Subject: Re: [dispatch] New I-D: = draft-dawes-dispatch-mediasec-parameter-01 =20 > -----Original Message----- > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > Sent: 26 May 2010 10:08 > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group;=20 > dispatch@ietf.org > Subject: RE: [dispatch] New I-D:=20 > draft-dawes-dispatch-mediasec-parameter-01 >=20 > John, >=20 > pls see inline >=20 > > -----Original Message----- > > From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, May 26, 2010 9:15 AM > > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes, Peter, = > > VF-Group; dispatch@ietf.org > > Subject: RE: [dispatch] New I-D:=20 > > draft-dawes-dispatch-mediasec-parameter-01 > >=20 > > Peter, > >=20 > > Rather than having to trawl through several 3GPP specifications to=20 > > find requirements, it would be better to state them clearly, with=20 > > motivation, in the Internet Draft, so that DISPATCH has something=20 > > concrete on which to base its discussions. > >=20 > > I don't think I received satisfactory answers to the following=20 > > questions that I posted on 2010-05-07 (apologies if I missed the=20 > > answers): > >=20 > > First I asked: > > "Why would the UE "want to employ End2AccessEdge" media plane=20 > > security, as opposed to E2E media plane security? I would have=20 > > thought the UE would always prefer the latter. > > Furthermore, the UE should not use keys that have value outside this = > > particular communication session, so if they get passed on beyond=20 > > the P-CSCF, no harm is done. In fact, if they reach the remote UA,=20 > > you can end up with E2E security, which would be great from the UE's = > > perspective." >=20 > [PETER] if the UE knows that the network support media plane security, = > then the UE can employ this mechanism in order to secure the access=20 > link. This mechanisms is independant of support for SDES-SRTP in the=20 > UE on the far end. From a network provider point of view this is a=20 > desirable feature as it provides a level of security similar to what=20 > is known from exsting cellular networks. [JRE] My question was not about network provider benefit, it was about = user benefit, or UE benefit.=20 You appear to be asking for a solution whereby the UE can ask for single = hop SRTP (just to the P-CSCF) and have it refused if the P-CSCF is = unable to provide it, rather than allowing an entity beyond the P-CSCF = to terminate SRTP. This I do not understand. Why would the UE __want__ = to have security only on that hop and not be prepared to have security = beyond that hop? As far as I can see, the UE would just want to ask for = SRTP and would prefer to have SRTP end-to-end but might accept something = less than end-to-end. [Thomas] In my understnading there is a considerable user benefit in = having some encryption for every call, irrespective of the capabilities = of the peer (All 3GPP UEs prior to Rel-9 will not support SRTP media = plane security, and in Rel-9 this is an optional feature). Consider an = unsecured WLAN air interface as an important use case (3GPP air = interfaces would offer encryption at a lower layer). 3GPP focused on the = IMS scenario, where the operator is likely to use a walled garden and = protect media streams in that manner. A call is likely to either go to a = PSTN or some other IMS peer, where a certain amount of protection can = also be assumed. So the real vulnerable point is the air interface. In another use case, the user might not be satisfied with the above = level of protection but desire true end-to-end security. While you are = correct that in the internet intermediates might spoil this, the IMS is = a controlled environment and specificatotions define that intermediates = shall pass the media transparentley. For instance, such a call would not = be interworked with the PSTN. So true end-to-end security can be = guaranteed to a requesting user within the IMS. The drawback is that = call setup for end-to-end media security will frequentleq fail, as many = peers will not support this. >=20 > >=20 > > Second, in response to your statement "The requirement in 3GPP is,=20 > > that the UE has to know whether or not the network > > (P-CSCF) will support SDES-SRTP before the session takes place, if=20 > > it wants to employ End2AccessEdge media plane security. This will=20 > > ensure that the IMS UE shares the media keys only with the P-CSCF=20 > > and not with some other entity." I asked the question: > >=20 > > "That would be interesting to know, but it is a more general problem = > > - any B2BUA can terminate SRTP, and SIP does not provide any=20 > > mechanism to indicate whether SRTP is truly end-to-end or just=20 > > end-to-some-B2BUA. Also a gateway to TDM will terminate SRTP, and=20 > > SIP does not provide any means of indicating whether SRTP is truly=20 > > end-to-end or end-to-first-TDM-gateway." >=20 > [PETER] IF the UE knows that the network supports SDES-SRTP (i.e.=20 > P-CSCF in collaboration with Access-Gateway), then this can be taken=20 > into account when deciding whether or not to ask for SRTP. In the end=20 > this has an effect on how fast the session setup will be, as the UE=20 > can avoid unsuccessfuall session setups. As there are two distinct use = > cases, namely end2end and end2accessedge, there is a requirement in a=20 > 3GPP environment to let the UE (user) know what level of security has=20 > been applied to the media. [JRE]The UE could just ask for best effort SRTP - if it is supported by = the "far end" (whether this be the P-CSCF or something beyond), SRTP = will be used, if not RTP will be used. We have a solution for that = already. [Thomas] This is debatable from the requirements perspective. 3GPP was = of the opinion that a call for which end-to-end security was requested = should only succeed with true end-to-end security, or otherwise fail to = indicate to the user that this security is not availbale. It is then the = users=B4s choice to set up an unprotected call or not to communicate. >=20 > >=20 > > In addition, I am curious to know whether the proposed mechanism=20 > > will work when there is a proxy between the UA and the P-CSCF, e.g., = > > a proxy/B2BUA in an enterprise or residential network. Is there a=20 > > danger that the proxy/B2BUA will apply end2AccessEdge security=20 > > (between the UA and itself), leaving the hop between proxy/B2BUA and = > > the P-CSCF unprotected? The so-called requirement of the UA to=20 > > provide security on the first hop is fulfilled, but the critical hop = > > to the P-CSCF is not secured. >=20 > [PETER] at least in the IMS architecture (which is the driver for the=20 > requirements in the draft) there is no proxy between the UA and the=20 > P-CSCF. I guess that for enterprise/residential cases this would work=20 > as well, as the "UA" in that case is the PBX/residential gateway=20 > (attachment point to the SSP network) and therefore media is secured=20 > between the PBX/residential gateway and the P-CSCF. In that case it is = > NOT the linke between the real endpoints (i.e. the PBX phones or=20 > residential phones) but the link between the attachement point and the = > network that is secured. [JRE] The proxy/B2BUA acting as PBX might not handle media. Media (and = hence media security) will come from the UA behind the PBX, whereas = signalling security will come from the PBX. The PBX in this case is not = in a position to negotiate media security - that is just passed on from = the UA behind the PBX. It seems to me that trying to add media security = to RFC 3329 violates this architectural distinction between the = hop-by-hop nature of signalling and the end-to-end nature of media. I = agree that if you put in a device such as a Session Border Controller = (SBC) between the PBX and the IMS network the proposed solution might = work, but we should not force the presence of an SBC here. > >=20 > > There have been extensive discussions on the DISPATCH and the former = > > SIP lists over the last couple of years or more about authenticated=20 > > identity and how that can be used to give some guarantee to the user = > > as to where secure media terminates, without any resolution. A=20 > > solution that just guarantees security on a first hop does not=20 > > really take us further forward. As Hadriel pointed out, there is the = > > SDP capability negotiation solution, as well as other solutions=20 > > proposed > in the past. >=20 > [PETER] cellular networks do have access link security, i.e. media=20 > encryption. So I believe there is justification for such a solution [JRE] This does not answer my concern. I am not disputing that security = is required. However, we already have a solution for best effort SRTP. = The existing solution is not ideal, since it doesn't tell me how far = media is secured, only that it is secured at least part of the way to = the remote endpoint. What the draft seems to be asking for is a solution = that specifically limits SRTP to a single hop, and I dispute the need = and the architectural viability of that. [Thomas] As explained above, the IMS security aims to do better than = that for end-to-end security and provide protection for the most = vulnerable point with end-to-access-edge encryption. For end-to-access edge protection, architectural considerations also = played a role: only the P-CSCF and controlled BGW need to be updated, = not all the entities handling the user plane. This is shurly an argument = primarily from an operator=B4s perspective, but are such arguments = forbidden in IETF? >=20 > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > > > Sent: 26 May 2010 06:54 > > > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group;=20 > > > dispatch@ietf.org > > > Subject: RE: [dispatch] New I-D:=20 > > > draft-dawes-dispatch-mediasec-parameter-01 > > >=20 > > > hello John, > > >=20 > > > 33.328 does not have a particular requirements section. It is the > > > stage-2 specification for the feature "media plane security"=20 > > > and as such > > > provides architecture and functional flows for the feature. I have = > > > refered to this as "requirements". > > >=20 > > > Clause 4 of the docuement gives an overview and describes that two = > > > solutions based on SDES are required, namely end2end and=20 > > > end2accessedge media protection. The need for two modes based on=20 > > > SDES SRTP is reflected throughout the specification where in every = > > > clause you find a sub-clause for end2end and a sub-clasue=20 > > > end2accessedge. Clause 7 provides the registration and session=20 > > > setup procedures, again different > > for end2end > > > and end2access edge. > > >=20 > > > So end2end and end2accessedge are described as two different and=20 > > > distinct use cases. > > >=20 > > > One goal for end2accessedege security as specified in > TS33.328 is to > > > allow to achieve media plane security (on the access leg) fully=20 > > > independant of of any capabilities of clients on the far end side. > > >=20 > > > 33.328 was developped based on requirements documented in 33.828=20 > > > http://www.3gpp.org/ftp/Specs/html-info/33828.htm > > >=20 > > > Clause 4 describes the use cases whith 4.1.2 describing > > end2accessedge > > > (access media protection). > > >=20 > > > regards > > > Peter > > >=20 > >=20 >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Wed May 26 05:37:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C0703A68E4 for ; Wed, 26 May 2010 05:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m81L51gjXknE for ; Wed, 26 May 2010 05:37:18 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 808213A687C for ; Wed, 26 May 2010 05:37:17 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-295942; Wed, 26 May 2010 14:37:07 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id AED591EB82AB; Wed, 26 May 2010 14:37:07 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 26 May 2010 14:37:07 +0200 From: "Elwell, John" To: "Belling, Thomas (NSN - DE/Munich)" , "Leis, Peter (NSN - DE/Munich)" , ext Hadriel Kaplan , "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Date: Wed, 26 May 2010 14:37:05 +0200 Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sADKuJwAAoMDiCAACXnDkAEcfAkgAAMniEAAA+ypYAACxFjwAAKOYuAAAdVVgA== Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail><430FC6BDED356B4C8498F634416644A91A8A5F1711@mail><430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> <744A66DF31B5B34EA8B08BBD8187A72201BEFD85@DEMUEXC014.nsn-intra.net> In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A72201BEFD85@DEMUEXC014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 12:37:20 -0000 Thomas, > -----Original Message----- > From: Belling, Thomas (NSN - DE/Munich) > [mailto:thomas.belling@nsn.com] > Sent: 26 May 2010 12:50 > To: Elwell, John; Leis, Peter (NSN - DE/Munich); ext Hadriel > Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org > Subject: RE: [dispatch] New I-D: > draft-dawes-dispatch-mediasec-parameter-01 > > Dear John, see inline > > Thomas > > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Elwell, John > Sent: Wednesday, May 26, 2010 12:23 PM > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes, > Peter, VF-Group; dispatch@ietf.org > Subject: Re: [dispatch] New I-D: > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > -----Original Message----- > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > > Sent: 26 May 2010 10:08 > > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group; > > dispatch@ietf.org > > Subject: RE: [dispatch] New I-D: > > draft-dawes-dispatch-mediasec-parameter-01 > > > > John, > > > > pls see inline > > > > > -----Original Message----- > > > From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Wednesday, May 26, 2010 9:15 AM > > > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; > Dawes, Peter, > > > VF-Group; dispatch@ietf.org > > > Subject: RE: [dispatch] New I-D: > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > Peter, > > > > > > Rather than having to trawl through several 3GPP > specifications to > > > find requirements, it would be better to state them clearly, with > > > motivation, in the Internet Draft, so that DISPATCH has something > > > concrete on which to base its discussions. > > > > > > I don't think I received satisfactory answers to the following > > > questions that I posted on 2010-05-07 (apologies if I missed the > > > answers): > > > > > > First I asked: > > > "Why would the UE "want to employ End2AccessEdge" media plane > > > security, as opposed to E2E media plane security? I would have > > > thought the UE would always prefer the latter. > > > Furthermore, the UE should not use keys that have value > outside this > > > particular communication session, so if they get passed on beyond > > > the P-CSCF, no harm is done. In fact, if they reach the > remote UA, > > > you can end up with E2E security, which would be great > from the UE's > > > perspective." > > > > [PETER] if the UE knows that the network support media > plane security, > > then the UE can employ this mechanism in order to secure the access > > link. This mechanisms is independant of support for > SDES-SRTP in the > > UE on the far end. From a network provider point of view this is a > > desirable feature as it provides a level of security > similar to what > > is known from exsting cellular networks. > [JRE] My question was not about network provider benefit, it > was about user benefit, or UE benefit. > You appear to be asking for a solution whereby the UE can ask > for single hop SRTP (just to the P-CSCF) and have it refused > if the P-CSCF is unable to provide it, rather than allowing > an entity beyond the P-CSCF to terminate SRTP. This I do not > understand. Why would the UE __want__ to have security only > on that hop and not be prepared to have security beyond that > hop? As far as I can see, the UE would just want to ask for > SRTP and would prefer to have SRTP end-to-end but might > accept something less than end-to-end. > > [Thomas] In my understnading there is a considerable user > benefit in having some encryption for every call, > irrespective of the capabilities of the peer (All 3GPP UEs > prior to Rel-9 will not support SRTP media plane security, > and in Rel-9 this is an optional feature). Consider an > unsecured WLAN air interface as an important use case (3GPP > air interfaces would offer encryption at a lower layer). 3GPP > focused on the IMS scenario, where the operator is likely to > use a walled garden and protect media streams in that manner. > A call is likely to either go to a PSTN or some other IMS > peer, where a certain amount of protection can also be > assumed. So the real vulnerable point is the air interface. [JRE] I am not disputing that, but the vulnerable air interface can exist a= t both ends, and securing one end without knowing whether the other end is = secured does not give much assurance to the user. > > In another use case, the user might not be satisfied with the > above level of protection but desire true end-to-end > security. While you are correct that in the internet > intermediates might spoil this, the IMS is a controlled > environment and specificatotions define that intermediates > shall pass the media transparentley. For instance, such a > call would not be interworked with the PSTN. So true > end-to-end security can be guaranteed to a requesting user > within the IMS. The drawback is that call setup for > end-to-end media security will frequentleq fail, as many > peers will not support this. > > > > > > > > > Second, in response to your statement "The requirement in > 3GPP is, > > > that the UE has to know whether or not the network > > > (P-CSCF) will support SDES-SRTP before the session takes > place, if > > > it wants to employ End2AccessEdge media plane security. This will > > > ensure that the IMS UE shares the media keys only with the P-CSCF > > > and not with some other entity." I asked the question: > > > > > > "That would be interesting to know, but it is a more > general problem > > > - any B2BUA can terminate SRTP, and SIP does not provide any > > > mechanism to indicate whether SRTP is truly end-to-end or just > > > end-to-some-B2BUA. Also a gateway to TDM will terminate SRTP, and > > > SIP does not provide any means of indicating whether SRTP > is truly > > > end-to-end or end-to-first-TDM-gateway." > > > > [PETER] IF the UE knows that the network supports SDES-SRTP (i.e. > > P-CSCF in collaboration with Access-Gateway), then this can > be taken > > into account when deciding whether or not to ask for SRTP. > In the end > > this has an effect on how fast the session setup will be, as the UE > > can avoid unsuccessfuall session setups. As there are two > distinct use > > cases, namely end2end and end2accessedge, there is a > requirement in a > > 3GPP environment to let the UE (user) know what level of > security has > > been applied to the media. > [JRE]The UE could just ask for best effort SRTP - if it is > supported by the "far end" (whether this be the P-CSCF or > something beyond), SRTP will be used, if not RTP will be > used. We have a solution for that already. > > [Thomas] This is debatable from the requirements perspective. > 3GPP was of the opinion that a call for which end-to-end > security was requested should only succeed with true > end-to-end security, or otherwise fail to indicate to the > user that this security is not availbale. It is then the > users=B4s choice to set up an unprotected call or not to communicate. [JRE] If the UA just wants SRTP or nothing (rejected call), it can ask for = that at present. The P-CSCF could forward the offer and hope that the far e= nd can accept SRTP, and if the far end rejects SRTP the P-CSCF could interv= ene and accept SRTP. The only thing missing then is some indication to the = calling UA as to how far media is encrypted. But as I said earlier, this is= a more general problem. It would be good in general to have secure identif= ication of the entity that terminates SRTP, so that the user can assess how= secure the call really is. > > > > > > > > > In addition, I am curious to know whether the proposed mechanism > > > will work when there is a proxy between the UA and the > P-CSCF, e.g., > > > a proxy/B2BUA in an enterprise or residential network. Is there a > > > danger that the proxy/B2BUA will apply end2AccessEdge security > > > (between the UA and itself), leaving the hop between > proxy/B2BUA and > > > the P-CSCF unprotected? The so-called requirement of the UA to > > > provide security on the first hop is fulfilled, but the > critical hop > > > to the P-CSCF is not secured. > > > > [PETER] at least in the IMS architecture (which is the > driver for the > > requirements in the draft) there is no proxy between the UA and the > > P-CSCF. I guess that for enterprise/residential cases this > would work > > as well, as the "UA" in that case is the PBX/residential gateway > > (attachment point to the SSP network) and therefore media > is secured > > between the PBX/residential gateway and the P-CSCF. In that > case it is > > NOT the linke between the real endpoints (i.e. the PBX phones or > > residential phones) but the link between the attachement > point and the > > network that is secured. > [JRE] The proxy/B2BUA acting as PBX might not handle media. > Media (and hence media security) will come from the UA behind > the PBX, whereas signalling security will come from the PBX. > The PBX in this case is not in a position to negotiate media > security - that is just passed on from the UA behind the PBX. > It seems to me that trying to add media security to RFC 3329 > violates this architectural distinction between the > hop-by-hop nature of signalling and the end-to-end nature of > media. I agree that if you put in a device such as a Session > Border Controller (SBC) between the PBX and the IMS network > the proposed solution might work, but we should not force the > presence of an SBC here. > > > > > > > There have been extensive discussions on the DISPATCH and > the former > > > SIP lists over the last couple of years or more about > authenticated > > > identity and how that can be used to give some guarantee > to the user > > > as to where secure media terminates, without any resolution. A > > > solution that just guarantees security on a first hop does not > > > really take us further forward. As Hadriel pointed out, > there is the > > > SDP capability negotiation solution, as well as other solutions > > > proposed > > in the past. > > > > [PETER] cellular networks do have access link security, i.e. media > > encryption. So I believe there is justification for such a solution > [JRE] This does not answer my concern. I am not disputing > that security is required. However, we already have a > solution for best effort SRTP. The existing solution is not > ideal, since it doesn't tell me how far media is secured, > only that it is secured at least part of the way to the > remote endpoint. What the draft seems to be asking for is a > solution that specifically limits SRTP to a single hop, and I > dispute the need and the architectural viability of that. > > [Thomas] As explained above, the IMS security aims to do > better than that for end-to-end security and provide > protection for the most vulnerable point with > end-to-access-edge encryption. > > For end-to-access edge protection, architectural > considerations also played a role: only the P-CSCF and > controlled BGW need to be updated, not all the entities > handling the user plane. This is shurly an argument primarily > from an operator=B4s perspective, but are such arguments > forbidden in IETF? [JRE] I don't dispute that. I was commenting on an earlier statement (from = Peter I think) that suggested it would be the UE's wish to have media secur= ity only as far as the edge, and I did not buy that argument. You did not comment on my architectural concern about the single-hop nature= of RFC 3329 versus the end-to-end nature of media, and how that would work= in certain PBX environments when attaching to IMS. So notwithstanding our = slight differences of opinion concerning the requirements, I still have thi= s architectural concern. Any shortcomings relating to the negotiation of me= dia security should, in my opinion, be handled in SDP. John > > > > > > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > > > > Sent: 26 May 2010 06:54 > > > > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group; > > > > dispatch@ietf.org > > > > Subject: RE: [dispatch] New I-D: > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > hello John, > > > > > > > > 33.328 does not have a particular requirements section. > It is the > > > > stage-2 specification for the feature "media plane security" > > > > and as such > > > > provides architecture and functional flows for the > feature. I have > > > > refered to this as "requirements". > > > > > > > > Clause 4 of the docuement gives an overview and > describes that two > > > > solutions based on SDES are required, namely end2end and > > > > end2accessedge media protection. The need for two modes > based on > > > > SDES SRTP is reflected throughout the specification > where in every > > > > clause you find a sub-clause for end2end and a sub-clasue > > > > end2accessedge. Clause 7 provides the registration and session > > > > setup procedures, again different > > > for end2end > > > > and end2access edge. > > > > > > > > So end2end and end2accessedge are described as two > different and > > > > distinct use cases. > > > > > > > > One goal for end2accessedege security as specified in > > TS33.328 is to > > > > allow to achieve media plane security (on the access leg) fully > > > > independant of of any capabilities of clients on the > far end side. > > > > > > > > 33.328 was developped based on requirements documented > in 33.828 > > > > http://www.3gpp.org/ftp/Specs/html-info/33828.htm > > > > > > > > Clause 4 describes the use cases whith 4.1.2 describing > > > end2accessedge > > > > (access media protection). > > > > > > > > regards > > > > Peter > > > > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From keith.drage@alcatel-lucent.com Wed May 26 09:23:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6A03A693F for ; Wed, 26 May 2010 09:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toUghU1PG-6P for ; Wed, 26 May 2010 09:23:28 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 3010F3A68FE for ; Wed, 26 May 2010 09:23:21 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4QGNA7G029523 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 May 2010 18:23:10 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 26 May 2010 18:23:10 +0200 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Date: Wed, 26 May 2010 18:23:08 +0200 Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sADKuJwAAoMDiCAACXnDkAEcfAkgAAMniEAAA+ypYAACxFjwAAKOYuAAAdVVgAAIYbBw Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail><430FC6BDED356B4C8498F634416644A91A8A5F1711@mail><430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> <744A66DF31B5B34EA8B08BBD8187A72201BEFD85@DEMUEXC014.nsn-intra.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 16:23:35 -0000 Firstly lets remove some of the discussion about end-to-end. If the user wants end-to-end security, then a mechanism (in fact two curren= tly) is provided for that, and end-to-access-edge will not be invoked for a= ny media where the user requests that. I do not really see a use case for p= roviding fallback to end-to-end security where end-to-access-edge is not pr= ovided. To me the use cases are different and distinct. I am also not sure = what keys would end up being used if this occurred. Thus, it is intended that user user knows at the time of registration as to= whether end-to-access-edge security is available, and therefore at the poi= nt of sending an INVITE, the user's UA (or the user themselves) can determi= ne which one they want to use. My understanding of the use case for the end-to-access-edge security is tha= t it is to protect to hop on which absolutely no security might exist at al= l. So on 3G, all data is protected to a certain extent, and then the IMS si= gnalling is protected a stage beyond that. Hoever on other access technolog= ies, there would not be this underlying level of protection for the data, a= nd therefore it becomes a matter for the user to use end-to-access-edge sec= urity to replace that deficiency for all the media paths passing over that = access technology. So in the question you raise about the attached proxy/gateway, e.g. an atta= ched PBX, and how that would work, for this use case the importance is only= on the local hop, and therefore if the proxy/gateway wanted to use the cap= ability, then it would do the same as the P-CSCF in the reverse direction. = I must admit we haven't worked through the implications of doing that on th= e call request itself. And none of this would prevent the PBX end user usin= g end-to-end security with the remote users. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Wednesday, May 26, 2010 1:37 PM > To: Belling, Thomas (NSN - DE/Munich); Leis, Peter (NSN - > DE/Munich); ext Hadriel Kaplan; Dawes, Peter, VF-Group; > dispatch@ietf.org > Subject: Re: [dispatch] New I-D: > draft-dawes-dispatch-mediasec-parameter-01 > > Thomas, > > > -----Original Message----- > > From: Belling, Thomas (NSN - DE/Munich) > > [mailto:thomas.belling@nsn.com] > > Sent: 26 May 2010 12:50 > > To: Elwell, John; Leis, Peter (NSN - DE/Munich); ext > Hadriel Kaplan; > > Dawes, Peter, VF-Group; dispatch@ietf.org > > Subject: RE: [dispatch] New I-D: > > draft-dawes-dispatch-mediasec-parameter-01 > > > > Dear John, see inline > > > > Thomas > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Elwell, John > > Sent: Wednesday, May 26, 2010 12:23 PM > > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; > Dawes, Peter, > > VF-Group; dispatch@ietf.org > > Subject: Re: [dispatch] New I-D: > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > > > > -----Original Message----- > > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > > > Sent: 26 May 2010 10:08 > > > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group; > > > dispatch@ietf.org > > > Subject: RE: [dispatch] New I-D: > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > John, > > > > > > pls see inline > > > > > > > -----Original Message----- > > > > From: ext Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Wednesday, May 26, 2010 9:15 AM > > > > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; > > Dawes, Peter, > > > > VF-Group; dispatch@ietf.org > > > > Subject: RE: [dispatch] New I-D: > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > Peter, > > > > > > > > Rather than having to trawl through several 3GPP > > specifications to > > > > find requirements, it would be better to state them > clearly, with > > > > motivation, in the Internet Draft, so that DISPATCH has > something > > > > concrete on which to base its discussions. > > > > > > > > I don't think I received satisfactory answers to the following > > > > questions that I posted on 2010-05-07 (apologies if I missed the > > > > answers): > > > > > > > > First I asked: > > > > "Why would the UE "want to employ End2AccessEdge" media plane > > > > security, as opposed to E2E media plane security? I would have > > > > thought the UE would always prefer the latter. > > > > Furthermore, the UE should not use keys that have value > > outside this > > > > particular communication session, so if they get passed > on beyond > > > > the P-CSCF, no harm is done. In fact, if they reach the > > remote UA, > > > > you can end up with E2E security, which would be great > > from the UE's > > > > perspective." > > > > > > [PETER] if the UE knows that the network support media > > plane security, > > > then the UE can employ this mechanism in order to secure > the access > > > link. This mechanisms is independant of support for > > SDES-SRTP in the > > > UE on the far end. From a network provider point of view > this is a > > > desirable feature as it provides a level of security > > similar to what > > > is known from exsting cellular networks. > > [JRE] My question was not about network provider benefit, > it was about > > user benefit, or UE benefit. > > You appear to be asking for a solution whereby the UE can ask for > > single hop SRTP (just to the P-CSCF) and have it refused if > the P-CSCF > > is unable to provide it, rather than allowing an entity beyond the > > P-CSCF to terminate SRTP. This I do not understand. Why > would the UE > > __want__ to have security only on that hop and not be > prepared to have > > security beyond that hop? As far as I can see, the UE would > just want > > to ask for SRTP and would prefer to have SRTP end-to-end but might > > accept something less than end-to-end. > > > > [Thomas] In my understnading there is a considerable user > benefit in > > having some encryption for every call, irrespective of the > > capabilities of the peer (All 3GPP UEs prior to Rel-9 will > not support > > SRTP media plane security, and in Rel-9 this is an optional > feature). > > Consider an unsecured WLAN air interface as an important use case > > (3GPP air interfaces would offer encryption at a lower layer). 3GPP > > focused on the IMS scenario, where the operator is likely to use a > > walled garden and protect media streams in that manner. > > A call is likely to either go to a PSTN or some other IMS > peer, where > > a certain amount of protection can also be assumed. So the real > > vulnerable point is the air interface. > [JRE] I am not disputing that, but the vulnerable air > interface can exist at both ends, and securing one end > without knowing whether the other end is secured does not > give much assurance to the user. > > > > > In another use case, the user might not be satisfied with the above > > level of protection but desire true end-to-end security. > While you are > > correct that in the internet intermediates might spoil > this, the IMS > > is a controlled environment and specificatotions define that > > intermediates shall pass the media transparentley. For > instance, such > > a call would not be interworked with the PSTN. So true end-to-end > > security can be guaranteed to a requesting user within the IMS. The > > drawback is that call setup for end-to-end media security will > > frequentleq fail, as many peers will not support this. > > > > > > > > > > > > > Second, in response to your statement "The requirement in > > 3GPP is, > > > > that the UE has to know whether or not the network > > > > (P-CSCF) will support SDES-SRTP before the session takes > > place, if > > > > it wants to employ End2AccessEdge media plane security. > This will > > > > ensure that the IMS UE shares the media keys only with > the P-CSCF > > > > and not with some other entity." I asked the question: > > > > > > > > "That would be interesting to know, but it is a more > > general problem > > > > - any B2BUA can terminate SRTP, and SIP does not provide any > > > > mechanism to indicate whether SRTP is truly end-to-end or just > > > > end-to-some-B2BUA. Also a gateway to TDM will terminate > SRTP, and > > > > SIP does not provide any means of indicating whether SRTP > > is truly > > > > end-to-end or end-to-first-TDM-gateway." > > > > > > [PETER] IF the UE knows that the network supports SDES-SRTP (i.e. > > > P-CSCF in collaboration with Access-Gateway), then this can > > be taken > > > into account when deciding whether or not to ask for SRTP. > > In the end > > > this has an effect on how fast the session setup will be, > as the UE > > > can avoid unsuccessfuall session setups. As there are two > > distinct use > > > cases, namely end2end and end2accessedge, there is a > > requirement in a > > > 3GPP environment to let the UE (user) know what level of > > security has > > > been applied to the media. > > [JRE]The UE could just ask for best effort SRTP - if it is > supported > > by the "far end" (whether this be the P-CSCF or something beyond), > > SRTP will be used, if not RTP will be used. We have a solution for > > that already. > > > > [Thomas] This is debatable from the requirements perspective. > > 3GPP was of the opinion that a call for which end-to-end > security was > > requested should only succeed with true end-to-end security, or > > otherwise fail to indicate to the user that this security is not > > availbale. It is then the users=B4s choice to set up an > unprotected call > > or not to communicate. > [JRE] If the UA just wants SRTP or nothing (rejected call), > it can ask for that at present. The P-CSCF could forward the > offer and hope that the far end can accept SRTP, and if the > far end rejects SRTP the P-CSCF could intervene and accept > SRTP. The only thing missing then is some indication to the > calling UA as to how far media is encrypted. But as I said > earlier, this is a more general problem. It would be good in > general to have secure identification of the entity that > terminates SRTP, so that the user can assess how secure the > call really is. > > > > > > > > > > > > > > In addition, I am curious to know whether the proposed > mechanism > > > > will work when there is a proxy between the UA and the > > P-CSCF, e.g., > > > > a proxy/B2BUA in an enterprise or residential network. > Is there a > > > > danger that the proxy/B2BUA will apply end2AccessEdge security > > > > (between the UA and itself), leaving the hop between > > proxy/B2BUA and > > > > the P-CSCF unprotected? The so-called requirement of the UA to > > > > provide security on the first hop is fulfilled, but the > > critical hop > > > > to the P-CSCF is not secured. > > > > > > [PETER] at least in the IMS architecture (which is the > > driver for the > > > requirements in the draft) there is no proxy between the > UA and the > > > P-CSCF. I guess that for enterprise/residential cases this > > would work > > > as well, as the "UA" in that case is the PBX/residential gateway > > > (attachment point to the SSP network) and therefore media > > is secured > > > between the PBX/residential gateway and the P-CSCF. In that > > case it is > > > NOT the linke between the real endpoints (i.e. the PBX phones or > > > residential phones) but the link between the attachement > > point and the > > > network that is secured. > > [JRE] The proxy/B2BUA acting as PBX might not handle media. > > Media (and hence media security) will come from the UA > behind the PBX, > > whereas signalling security will come from the PBX. > > The PBX in this case is not in a position to negotiate > media security > > - that is just passed on from the UA behind the PBX. > > It seems to me that trying to add media security to RFC > 3329 violates > > this architectural distinction between the hop-by-hop nature of > > signalling and the end-to-end nature of media. I agree that > if you put > > in a device such as a Session Border Controller (SBC) > between the PBX > > and the IMS network the proposed solution might work, but we should > > not force the presence of an SBC here. > > > > > > > > > > There have been extensive discussions on the DISPATCH and > > the former > > > > SIP lists over the last couple of years or more about > > authenticated > > > > identity and how that can be used to give some guarantee > > to the user > > > > as to where secure media terminates, without any resolution. A > > > > solution that just guarantees security on a first hop does not > > > > really take us further forward. As Hadriel pointed out, > > there is the > > > > SDP capability negotiation solution, as well as other solutions > > > > proposed > > > in the past. > > > > > > [PETER] cellular networks do have access link security, > i.e. media > > > encryption. So I believe there is justification for such > a solution > > [JRE] This does not answer my concern. I am not disputing that > > security is required. However, we already have a solution for best > > effort SRTP. The existing solution is not ideal, since it > doesn't tell > > me how far media is secured, only that it is secured at > least part of > > the way to the remote endpoint. What the draft seems to be > asking for > > is a solution that specifically limits SRTP to a single hop, and I > > dispute the need and the architectural viability of that. > > > > [Thomas] As explained above, the IMS security aims to do > better than > > that for end-to-end security and provide protection for the most > > vulnerable point with end-to-access-edge encryption. > > > > For end-to-access edge protection, architectural > considerations also > > played a role: only the P-CSCF and controlled BGW need to > be updated, > > not all the entities handling the user plane. This is shurly an > > argument primarily from an operator=B4s perspective, but are such > > arguments forbidden in IETF? > [JRE] I don't dispute that. I was commenting on an earlier > statement (from Peter I think) that suggested it would be the > UE's wish to have media security only as far as the edge, and > I did not buy that argument. > > You did not comment on my architectural concern about the > single-hop nature of RFC 3329 versus the end-to-end nature of > media, and how that would work in certain PBX environments > when attaching to IMS. So notwithstanding our slight > differences of opinion concerning the requirements, I still > have this architectural concern. Any shortcomings relating to > the negotiation of media security should, in my opinion, be > handled in SDP. > > John > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: Leis, Peter (NSN - DE/Munich) > [mailto:peter.leis@nsn.com] > > > > > Sent: 26 May 2010 06:54 > > > > > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group; > > > > > dispatch@ietf.org > > > > > Subject: RE: [dispatch] New I-D: > > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > > > hello John, > > > > > > > > > > 33.328 does not have a particular requirements section. > > It is the > > > > > stage-2 specification for the feature "media plane security" > > > > > and as such > > > > > provides architecture and functional flows for the > > feature. I have > > > > > refered to this as "requirements". > > > > > > > > > > Clause 4 of the docuement gives an overview and > > describes that two > > > > > solutions based on SDES are required, namely end2end and > > > > > end2accessedge media protection. The need for two modes > > based on > > > > > SDES SRTP is reflected throughout the specification > > where in every > > > > > clause you find a sub-clause for end2end and a sub-clasue > > > > > end2accessedge. Clause 7 provides the registration > and session > > > > > setup procedures, again different > > > > for end2end > > > > > and end2access edge. > > > > > > > > > > So end2end and end2accessedge are described as two > > different and > > > > > distinct use cases. > > > > > > > > > > One goal for end2accessedege security as specified in > > > TS33.328 is to > > > > > allow to achieve media plane security (on the access > leg) fully > > > > > independant of of any capabilities of clients on the > > far end side. > > > > > > > > > > 33.328 was developped based on requirements documented > > in 33.828 > > > > > http://www.3gpp.org/ftp/Specs/html-info/33828.htm > > > > > > > > > > Clause 4 describes the use cases whith 4.1.2 describing > > > > end2accessedge > > > > > (access media protection). > > > > > > > > > > regards > > > > > Peter > > > > > > > > > > > > > > _______________________________________________ > > 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 john.elwell@siemens-enterprise.com Wed May 26 09:55:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762E23A68DA for ; Wed, 26 May 2010 09:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD3cP1+r7Rqc for ; Wed, 26 May 2010 09:54:59 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A55BB3A6873 for ; Wed, 26 May 2010 09:54:58 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-299386; Wed, 26 May 2010 18:54:49 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 299141EB82AB; Wed, 26 May 2010 18:54:49 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 26 May 2010 18:54:49 +0200 From: "Elwell, John" To: "DRAGE, Keith (Keith)" , "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Date: Wed, 26 May 2010 18:54:47 +0200 Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sADKuJwAAoMDiCAACXnDkAEcfAkgAAMniEAAA+ypYAACxFjwAAKOYuAAAdVVgAAIYbBwAAGBdJA= Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail><430FC6BDED356B4C8498F634416644A91A8A5F1711@mail><430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> <744A66DF31B5B34EA8B08BBD8187A72201BEFD85@DEMUEXC014.nsn-intra.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 16:55:01 -0000 Keith, The point is, the PBX would know from the security agreement that e2ae secu= rity is available at the P-CSCF. However, a UA behind the PBX, when it init= iates a call, a) does not know whether it will be routed to an IMS network,= and b) does not know details of the security agreement between the PBX and= the P-CSCF. So it may or may not request e2e security, and if it does requ= est e2e security and that fails, I don't see how it can request e2ea securi= ty (between the PBX and the P-CSCF). If somebody could explain this, it wou= ld help. John > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: 26 May 2010 17:23 > To: Elwell, John; Dawes, Peter, VF-Group; dispatch@ietf.org > Subject: RE: [dispatch] New I-D: > draft-dawes-dispatch-mediasec-parameter-01 > > Firstly lets remove some of the discussion about end-to-end. > > If the user wants end-to-end security, then a mechanism (in > fact two currently) is provided for that, and > end-to-access-edge will not be invoked for any media where > the user requests that. I do not really see a use case for > providing fallback to end-to-end security where > end-to-access-edge is not provided. To me the use cases are > different and distinct. I am also not sure what keys would > end up being used if this occurred. > > Thus, it is intended that user user knows at the time of > registration as to whether end-to-access-edge security is > available, and therefore at the point of sending an INVITE, > the user's UA (or the user themselves) can determine which > one they want to use. > > My understanding of the use case for the end-to-access-edge > security is that it is to protect to hop on which absolutely > no security might exist at all. So on 3G, all data is > protected to a certain extent, and then the IMS signalling is > protected a stage beyond that. Hoever on other access > technologies, there would not be this underlying level of > protection for the data, and therefore it becomes a matter > for the user to use end-to-access-edge security to replace > that deficiency for all the media paths passing over that > access technology. > > So in the question you raise about the attached > proxy/gateway, e.g. an attached PBX, and how that would work, > for this use case the importance is only on the local hop, > and therefore if the proxy/gateway wanted to use the > capability, then it would do the same as the P-CSCF in the > reverse direction. I must admit we haven't worked through the > implications of doing that on the call request itself. And > none of this would prevent the PBX end user using end-to-end > security with the remote users. > > regards > > Keith > > > > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Wednesday, May 26, 2010 1:37 PM > > To: Belling, Thomas (NSN - DE/Munich); Leis, Peter (NSN - > > DE/Munich); ext Hadriel Kaplan; Dawes, Peter, VF-Group; > > dispatch@ietf.org > > Subject: Re: [dispatch] New I-D: > > draft-dawes-dispatch-mediasec-parameter-01 > > > > Thomas, > > > > > -----Original Message----- > > > From: Belling, Thomas (NSN - DE/Munich) > > > [mailto:thomas.belling@nsn.com] > > > Sent: 26 May 2010 12:50 > > > To: Elwell, John; Leis, Peter (NSN - DE/Munich); ext > > Hadriel Kaplan; > > > Dawes, Peter, VF-Group; dispatch@ietf.org > > > Subject: RE: [dispatch] New I-D: > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > Dear John, see inline > > > > > > Thomas > > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Elwell, John > > > Sent: Wednesday, May 26, 2010 12:23 PM > > > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; > > Dawes, Peter, > > > VF-Group; dispatch@ietf.org > > > Subject: Re: [dispatch] New I-D: > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > > > > Sent: 26 May 2010 10:08 > > > > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group; > > > > dispatch@ietf.org > > > > Subject: RE: [dispatch] New I-D: > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > John, > > > > > > > > pls see inline > > > > > > > > > -----Original Message----- > > > > > From: ext Elwell, John > > [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Wednesday, May 26, 2010 9:15 AM > > > > > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; > > > Dawes, Peter, > > > > > VF-Group; dispatch@ietf.org > > > > > Subject: RE: [dispatch] New I-D: > > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > > > Peter, > > > > > > > > > > Rather than having to trawl through several 3GPP > > > specifications to > > > > > find requirements, it would be better to state them > > clearly, with > > > > > motivation, in the Internet Draft, so that DISPATCH has > > something > > > > > concrete on which to base its discussions. > > > > > > > > > > I don't think I received satisfactory answers to the following > > > > > questions that I posted on 2010-05-07 (apologies if I > missed the > > > > > answers): > > > > > > > > > > First I asked: > > > > > "Why would the UE "want to employ End2AccessEdge" media plane > > > > > security, as opposed to E2E media plane security? I would have > > > > > thought the UE would always prefer the latter. > > > > > Furthermore, the UE should not use keys that have value > > > outside this > > > > > particular communication session, so if they get passed > > on beyond > > > > > the P-CSCF, no harm is done. In fact, if they reach the > > > remote UA, > > > > > you can end up with E2E security, which would be great > > > from the UE's > > > > > perspective." > > > > > > > > [PETER] if the UE knows that the network support media > > > plane security, > > > > then the UE can employ this mechanism in order to secure > > the access > > > > link. This mechanisms is independant of support for > > > SDES-SRTP in the > > > > UE on the far end. From a network provider point of view > > this is a > > > > desirable feature as it provides a level of security > > > similar to what > > > > is known from exsting cellular networks. > > > [JRE] My question was not about network provider benefit, > > it was about > > > user benefit, or UE benefit. > > > You appear to be asking for a solution whereby the UE can ask for > > > single hop SRTP (just to the P-CSCF) and have it refused if > > the P-CSCF > > > is unable to provide it, rather than allowing an entity beyond the > > > P-CSCF to terminate SRTP. This I do not understand. Why > > would the UE > > > __want__ to have security only on that hop and not be > > prepared to have > > > security beyond that hop? As far as I can see, the UE would > > just want > > > to ask for SRTP and would prefer to have SRTP end-to-end but might > > > accept something less than end-to-end. > > > > > > [Thomas] In my understnading there is a considerable user > > benefit in > > > having some encryption for every call, irrespective of the > > > capabilities of the peer (All 3GPP UEs prior to Rel-9 will > > not support > > > SRTP media plane security, and in Rel-9 this is an optional > > feature). > > > Consider an unsecured WLAN air interface as an important use case > > > (3GPP air interfaces would offer encryption at a lower > layer). 3GPP > > > focused on the IMS scenario, where the operator is likely to use a > > > walled garden and protect media streams in that manner. > > > A call is likely to either go to a PSTN or some other IMS > > peer, where > > > a certain amount of protection can also be assumed. So the real > > > vulnerable point is the air interface. > > [JRE] I am not disputing that, but the vulnerable air > > interface can exist at both ends, and securing one end > > without knowing whether the other end is secured does not > > give much assurance to the user. > > > > > > > > In another use case, the user might not be satisfied with > the above > > > level of protection but desire true end-to-end security. > > While you are > > > correct that in the internet intermediates might spoil > > this, the IMS > > > is a controlled environment and specificatotions define that > > > intermediates shall pass the media transparentley. For > > instance, such > > > a call would not be interworked with the PSTN. So true end-to-end > > > security can be guaranteed to a requesting user within > the IMS. The > > > drawback is that call setup for end-to-end media security will > > > frequentleq fail, as many peers will not support this. > > > > > > > > > > > > > > > > > Second, in response to your statement "The requirement in > > > 3GPP is, > > > > > that the UE has to know whether or not the network > > > > > (P-CSCF) will support SDES-SRTP before the session takes > > > place, if > > > > > it wants to employ End2AccessEdge media plane security. > > This will > > > > > ensure that the IMS UE shares the media keys only with > > the P-CSCF > > > > > and not with some other entity." I asked the question: > > > > > > > > > > "That would be interesting to know, but it is a more > > > general problem > > > > > - any B2BUA can terminate SRTP, and SIP does not provide any > > > > > mechanism to indicate whether SRTP is truly end-to-end or just > > > > > end-to-some-B2BUA. Also a gateway to TDM will terminate > > SRTP, and > > > > > SIP does not provide any means of indicating whether SRTP > > > is truly > > > > > end-to-end or end-to-first-TDM-gateway." > > > > > > > > [PETER] IF the UE knows that the network supports > SDES-SRTP (i.e. > > > > P-CSCF in collaboration with Access-Gateway), then this can > > > be taken > > > > into account when deciding whether or not to ask for SRTP. > > > In the end > > > > this has an effect on how fast the session setup will be, > > as the UE > > > > can avoid unsuccessfuall session setups. As there are two > > > distinct use > > > > cases, namely end2end and end2accessedge, there is a > > > requirement in a > > > > 3GPP environment to let the UE (user) know what level of > > > security has > > > > been applied to the media. > > > [JRE]The UE could just ask for best effort SRTP - if it is > > supported > > > by the "far end" (whether this be the P-CSCF or something beyond), > > > SRTP will be used, if not RTP will be used. We have a solution for > > > that already. > > > > > > [Thomas] This is debatable from the requirements perspective. > > > 3GPP was of the opinion that a call for which end-to-end > > security was > > > requested should only succeed with true end-to-end security, or > > > otherwise fail to indicate to the user that this security is not > > > availbale. It is then the users=B4s choice to set up an > > unprotected call > > > or not to communicate. > > [JRE] If the UA just wants SRTP or nothing (rejected call), > > it can ask for that at present. The P-CSCF could forward the > > offer and hope that the far end can accept SRTP, and if the > > far end rejects SRTP the P-CSCF could intervene and accept > > SRTP. The only thing missing then is some indication to the > > calling UA as to how far media is encrypted. But as I said > > earlier, this is a more general problem. It would be good in > > general to have secure identification of the entity that > > terminates SRTP, so that the user can assess how secure the > > call really is. > > > > > > > > > > > > > > > > > > > In addition, I am curious to know whether the proposed > > mechanism > > > > > will work when there is a proxy between the UA and the > > > P-CSCF, e.g., > > > > > a proxy/B2BUA in an enterprise or residential network. > > Is there a > > > > > danger that the proxy/B2BUA will apply end2AccessEdge security > > > > > (between the UA and itself), leaving the hop between > > > proxy/B2BUA and > > > > > the P-CSCF unprotected? The so-called requirement of the UA to > > > > > provide security on the first hop is fulfilled, but the > > > critical hop > > > > > to the P-CSCF is not secured. > > > > > > > > [PETER] at least in the IMS architecture (which is the > > > driver for the > > > > requirements in the draft) there is no proxy between the > > UA and the > > > > P-CSCF. I guess that for enterprise/residential cases this > > > would work > > > > as well, as the "UA" in that case is the PBX/residential gateway > > > > (attachment point to the SSP network) and therefore media > > > is secured > > > > between the PBX/residential gateway and the P-CSCF. In that > > > case it is > > > > NOT the linke between the real endpoints (i.e. the PBX phones or > > > > residential phones) but the link between the attachement > > > point and the > > > > network that is secured. > > > [JRE] The proxy/B2BUA acting as PBX might not handle media. > > > Media (and hence media security) will come from the UA > > behind the PBX, > > > whereas signalling security will come from the PBX. > > > The PBX in this case is not in a position to negotiate > > media security > > > - that is just passed on from the UA behind the PBX. > > > It seems to me that trying to add media security to RFC > > 3329 violates > > > this architectural distinction between the hop-by-hop nature of > > > signalling and the end-to-end nature of media. I agree that > > if you put > > > in a device such as a Session Border Controller (SBC) > > between the PBX > > > and the IMS network the proposed solution might work, but > we should > > > not force the presence of an SBC here. > > > > > > > > > > > > > There have been extensive discussions on the DISPATCH and > > > the former > > > > > SIP lists over the last couple of years or more about > > > authenticated > > > > > identity and how that can be used to give some guarantee > > > to the user > > > > > as to where secure media terminates, without any resolution. A > > > > > solution that just guarantees security on a first hop does not > > > > > really take us further forward. As Hadriel pointed out, > > > there is the > > > > > SDP capability negotiation solution, as well as other > solutions > > > > > proposed > > > > in the past. > > > > > > > > [PETER] cellular networks do have access link security, > > i.e. media > > > > encryption. So I believe there is justification for such > > a solution > > > [JRE] This does not answer my concern. I am not disputing that > > > security is required. However, we already have a solution for best > > > effort SRTP. The existing solution is not ideal, since it > > doesn't tell > > > me how far media is secured, only that it is secured at > > least part of > > > the way to the remote endpoint. What the draft seems to be > > asking for > > > is a solution that specifically limits SRTP to a single hop, and I > > > dispute the need and the architectural viability of that. > > > > > > [Thomas] As explained above, the IMS security aims to do > > better than > > > that for end-to-end security and provide protection for the most > > > vulnerable point with end-to-access-edge encryption. > > > > > > For end-to-access edge protection, architectural > > considerations also > > > played a role: only the P-CSCF and controlled BGW need to > > be updated, > > > not all the entities handling the user plane. This is shurly an > > > argument primarily from an operator=B4s perspective, but are such > > > arguments forbidden in IETF? > > [JRE] I don't dispute that. I was commenting on an earlier > > statement (from Peter I think) that suggested it would be the > > UE's wish to have media security only as far as the edge, and > > I did not buy that argument. > > > > You did not comment on my architectural concern about the > > single-hop nature of RFC 3329 versus the end-to-end nature of > > media, and how that would work in certain PBX environments > > when attaching to IMS. So notwithstanding our slight > > differences of opinion concerning the requirements, I still > > have this architectural concern. Any shortcomings relating to > > the negotiation of media security should, in my opinion, be > > handled in SDP. > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Leis, Peter (NSN - DE/Munich) > > [mailto:peter.leis@nsn.com] > > > > > > Sent: 26 May 2010 06:54 > > > > > > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, > VF-Group; > > > > > > dispatch@ietf.org > > > > > > Subject: RE: [dispatch] New I-D: > > > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > > > > > hello John, > > > > > > > > > > > > 33.328 does not have a particular requirements section. > > > It is the > > > > > > stage-2 specification for the feature "media plane security" > > > > > > and as such > > > > > > provides architecture and functional flows for the > > > feature. I have > > > > > > refered to this as "requirements". > > > > > > > > > > > > Clause 4 of the docuement gives an overview and > > > describes that two > > > > > > solutions based on SDES are required, namely end2end and > > > > > > end2accessedge media protection. The need for two modes > > > based on > > > > > > SDES SRTP is reflected throughout the specification > > > where in every > > > > > > clause you find a sub-clause for end2end and a sub-clasue > > > > > > end2accessedge. Clause 7 provides the registration > > and session > > > > > > setup procedures, again different > > > > > for end2end > > > > > > and end2access edge. > > > > > > > > > > > > So end2end and end2accessedge are described as two > > > different and > > > > > > distinct use cases. > > > > > > > > > > > > One goal for end2accessedege security as specified in > > > > TS33.328 is to > > > > > > allow to achieve media plane security (on the access > > leg) fully > > > > > > independant of of any capabilities of clients on the > > > far end side. > > > > > > > > > > > > 33.328 was developped based on requirements documented > > > in 33.828 > > > > > > http://www.3gpp.org/ftp/Specs/html-info/33828.htm > > > > > > > > > > > > Clause 4 describes the use cases whith 4.1.2 describing > > > > > end2accessedge > > > > > > (access media protection). > > > > > > > > > > > > regards > > > > > > Peter > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 keith.drage@alcatel-lucent.com Wed May 26 10:36:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91FE73A69A3 for ; Wed, 26 May 2010 10:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.716 X-Spam-Level: X-Spam-Status: No, score=-4.716 tagged_above=-999 required=5 tests=[AWL=1.533, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqKP1yxqKPDN for ; Wed, 26 May 2010 10:36:26 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 5DAF43A696D for ; Wed, 26 May 2010 10:36:18 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4QHa86m016324 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 May 2010 19:36:08 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 26 May 2010 19:36:08 +0200 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Date: Wed, 26 May 2010 19:35:59 +0200 Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7AAoA94sADKuJwAAoMDiCAACXnDkAEcfAkgAAMniEAAA+ypYAACxFjwAAKOYuAAAdVVgAAIYbBwAAGBdJAAAYBSEA== Message-ID: References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail><430FC6BDED356B4C8498F634416644A91A8A5F1711@mail><430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> <744A66DF31B5B34EA8B08BBD8187A72201BEFD85@DEMUEXC014.nsn-intra.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 17:36:55 -0000 If it wants end-to-end security and that fails, then end-to-access-edge sec= urity will not form an acceptable substitute. In the case of an attached PBX, it would be the policy of the PBX that woul= d determine the need to use end-to-access-edge security for all its individ= ual users, or not. I do not see the end user forming part of this decision = process, or indeed needing to. The only case where that would get overridde= n is where the end user requests end-to-end security and gets it, on a per = SDP offer / answer basis. Keith > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, May 26, 2010 5:55 PM > To: DRAGE, Keith (Keith); Dawes, Peter, VF-Group; dispatch@ietf.org > Subject: RE: [dispatch] New I-D: > draft-dawes-dispatch-mediasec-parameter-01 > > Keith, > > The point is, the PBX would know from the security agreement > that e2ae security is available at the P-CSCF. However, a UA > behind the PBX, when it initiates a call, a) does not know > whether it will be routed to an IMS network, and b) does not > know details of the security agreement between the PBX and > the P-CSCF. So it may or may not request e2e security, and if > it does request e2e security and that fails, I don't see how > it can request e2ea security (between the PBX and the > P-CSCF). If somebody could explain this, it would help. > > John > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > > Sent: 26 May 2010 17:23 > > To: Elwell, John; Dawes, Peter, VF-Group; dispatch@ietf.org > > Subject: RE: [dispatch] New I-D: > > draft-dawes-dispatch-mediasec-parameter-01 > > > > Firstly lets remove some of the discussion about end-to-end. > > > > If the user wants end-to-end security, then a mechanism (in > fact two > > currently) is provided for that, and end-to-access-edge will not be > > invoked for any media where the user requests that. I do not really > > see a use case for providing fallback to end-to-end security where > > end-to-access-edge is not provided. To me the use cases are > different > > and distinct. I am also not sure what keys would end up > being used if > > this occurred. > > > > Thus, it is intended that user user knows at the time of > registration > > as to whether end-to-access-edge security is available, and > therefore > > at the point of sending an INVITE, the user's UA (or the user > > themselves) can determine which one they want to use. > > > > My understanding of the use case for the end-to-access-edge > security > > is that it is to protect to hop on which absolutely no > security might > > exist at all. So on 3G, all data is protected to a certain > extent, and > > then the IMS signalling is protected a stage beyond that. Hoever on > > other access technologies, there would not be this > underlying level of > > protection for the data, and therefore it becomes a matter for the > > user to use end-to-access-edge security to replace that > deficiency for > > all the media paths passing over that access technology. > > > > So in the question you raise about the attached > proxy/gateway, e.g. an > > attached PBX, and how that would work, for this use case the > > importance is only on the local hop, and therefore if the > > proxy/gateway wanted to use the capability, then it would > do the same > > as the P-CSCF in the reverse direction. I must admit we > haven't worked > > through the implications of doing that on the call request > itself. And > > none of this would prevent the PBX end user using > end-to-end security > > with the remote users. > > > > regards > > > > Keith > > > > > > > > > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Elwell, John > > > Sent: Wednesday, May 26, 2010 1:37 PM > > > To: Belling, Thomas (NSN - DE/Munich); Leis, Peter (NSN - > > > DE/Munich); ext Hadriel Kaplan; Dawes, Peter, VF-Group; > > > dispatch@ietf.org > > > Subject: Re: [dispatch] New I-D: > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > Thomas, > > > > > > > -----Original Message----- > > > > From: Belling, Thomas (NSN - DE/Munich) > > > > [mailto:thomas.belling@nsn.com] > > > > Sent: 26 May 2010 12:50 > > > > To: Elwell, John; Leis, Peter (NSN - DE/Munich); ext > > > Hadriel Kaplan; > > > > Dawes, Peter, VF-Group; dispatch@ietf.org > > > > Subject: RE: [dispatch] New I-D: > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > Dear John, see inline > > > > > > > > Thomas > > > > > > > > -----Original Message----- > > > > From: dispatch-bounces@ietf.org > > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Elwell, John > > > > Sent: Wednesday, May 26, 2010 12:23 PM > > > > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; > > > Dawes, Peter, > > > > VF-Group; dispatch@ietf.org > > > > Subject: Re: [dispatch] New I-D: > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Leis, Peter (NSN - DE/Munich) > [mailto:peter.leis@nsn.com] > > > > > Sent: 26 May 2010 10:08 > > > > > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group; > > > > > dispatch@ietf.org > > > > > Subject: RE: [dispatch] New I-D: > > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > > > John, > > > > > > > > > > pls see inline > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Elwell, John > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > Sent: Wednesday, May 26, 2010 9:15 AM > > > > > > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; > > > > Dawes, Peter, > > > > > > VF-Group; dispatch@ietf.org > > > > > > Subject: RE: [dispatch] New I-D: > > > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > > > > > Peter, > > > > > > > > > > > > Rather than having to trawl through several 3GPP > > > > specifications to > > > > > > find requirements, it would be better to state them > > > clearly, with > > > > > > motivation, in the Internet Draft, so that DISPATCH has > > > something > > > > > > concrete on which to base its discussions. > > > > > > > > > > > > I don't think I received satisfactory answers to > the following > > > > > > questions that I posted on 2010-05-07 (apologies if I > > missed the > > > > > > answers): > > > > > > > > > > > > First I asked: > > > > > > "Why would the UE "want to employ End2AccessEdge" > media plane > > > > > > security, as opposed to E2E media plane security? I > would have > > > > > > thought the UE would always prefer the latter. > > > > > > Furthermore, the UE should not use keys that have value > > > > outside this > > > > > > particular communication session, so if they get passed > > > on beyond > > > > > > the P-CSCF, no harm is done. In fact, if they reach the > > > > remote UA, > > > > > > you can end up with E2E security, which would be great > > > > from the UE's > > > > > > perspective." > > > > > > > > > > [PETER] if the UE knows that the network support media > > > > plane security, > > > > > then the UE can employ this mechanism in order to secure > > > the access > > > > > link. This mechanisms is independant of support for > > > > SDES-SRTP in the > > > > > UE on the far end. From a network provider point of view > > > this is a > > > > > desirable feature as it provides a level of security > > > > similar to what > > > > > is known from exsting cellular networks. > > > > [JRE] My question was not about network provider benefit, > > > it was about > > > > user benefit, or UE benefit. > > > > You appear to be asking for a solution whereby the UE > can ask for > > > > single hop SRTP (just to the P-CSCF) and have it refused if > > > the P-CSCF > > > > is unable to provide it, rather than allowing an entity > beyond the > > > > P-CSCF to terminate SRTP. This I do not understand. Why > > > would the UE > > > > __want__ to have security only on that hop and not be > > > prepared to have > > > > security beyond that hop? As far as I can see, the UE would > > > just want > > > > to ask for SRTP and would prefer to have SRTP > end-to-end but might > > > > accept something less than end-to-end. > > > > > > > > [Thomas] In my understnading there is a considerable user > > > benefit in > > > > having some encryption for every call, irrespective of the > > > > capabilities of the peer (All 3GPP UEs prior to Rel-9 will > > > not support > > > > SRTP media plane security, and in Rel-9 this is an optional > > > feature). > > > > Consider an unsecured WLAN air interface as an > important use case > > > > (3GPP air interfaces would offer encryption at a lower > > layer). 3GPP > > > > focused on the IMS scenario, where the operator is > likely to use a > > > > walled garden and protect media streams in that manner. > > > > A call is likely to either go to a PSTN or some other IMS > > > peer, where > > > > a certain amount of protection can also be assumed. So the real > > > > vulnerable point is the air interface. > > > [JRE] I am not disputing that, but the vulnerable air > interface can > > > exist at both ends, and securing one end without knowing > whether the > > > other end is secured does not give much assurance to the user. > > > > > > > > > > > In another use case, the user might not be satisfied with > > the above > > > > level of protection but desire true end-to-end security. > > > While you are > > > > correct that in the internet intermediates might spoil > > > this, the IMS > > > > is a controlled environment and specificatotions define that > > > > intermediates shall pass the media transparentley. For > > > instance, such > > > > a call would not be interworked with the PSTN. So true > end-to-end > > > > security can be guaranteed to a requesting user within > > the IMS. The > > > > drawback is that call setup for end-to-end media security will > > > > frequentleq fail, as many peers will not support this. > > > > > > > > > > > > > > > > > > > > > Second, in response to your statement "The requirement in > > > > 3GPP is, > > > > > > that the UE has to know whether or not the network > > > > > > (P-CSCF) will support SDES-SRTP before the session takes > > > > place, if > > > > > > it wants to employ End2AccessEdge media plane security. > > > This will > > > > > > ensure that the IMS UE shares the media keys only with > > > the P-CSCF > > > > > > and not with some other entity." I asked the question: > > > > > > > > > > > > "That would be interesting to know, but it is a more > > > > general problem > > > > > > - any B2BUA can terminate SRTP, and SIP does not > provide any > > > > > > mechanism to indicate whether SRTP is truly > end-to-end or just > > > > > > end-to-some-B2BUA. Also a gateway to TDM will terminate > > > SRTP, and > > > > > > SIP does not provide any means of indicating whether SRTP > > > > is truly > > > > > > end-to-end or end-to-first-TDM-gateway." > > > > > > > > > > [PETER] IF the UE knows that the network supports > > SDES-SRTP (i.e. > > > > > P-CSCF in collaboration with Access-Gateway), then this can > > > > be taken > > > > > into account when deciding whether or not to ask for SRTP. > > > > In the end > > > > > this has an effect on how fast the session setup will be, > > > as the UE > > > > > can avoid unsuccessfuall session setups. As there are two > > > > distinct use > > > > > cases, namely end2end and end2accessedge, there is a > > > > requirement in a > > > > > 3GPP environment to let the UE (user) know what level of > > > > security has > > > > > been applied to the media. > > > > [JRE]The UE could just ask for best effort SRTP - if it is > > > supported > > > > by the "far end" (whether this be the P-CSCF or > something beyond), > > > > SRTP will be used, if not RTP will be used. We have a > solution for > > > > that already. > > > > > > > > [Thomas] This is debatable from the requirements perspective. > > > > 3GPP was of the opinion that a call for which end-to-end > > > security was > > > > requested should only succeed with true end-to-end security, or > > > > otherwise fail to indicate to the user that this > security is not > > > > availbale. It is then the users=B4s choice to set up an > > > unprotected call > > > > or not to communicate. > > > [JRE] If the UA just wants SRTP or nothing (rejected > call), it can > > > ask for that at present. The P-CSCF could forward the > offer and hope > > > that the far end can accept SRTP, and if the far end rejects SRTP > > > the P-CSCF could intervene and accept SRTP. The only > thing missing > > > then is some indication to the calling UA as to how far media is > > > encrypted. But as I said earlier, this is a more general > problem. It > > > would be good in general to have secure identification of > the entity > > > that terminates SRTP, so that the user can assess how secure the > > > call really is. > > > > > > > > > > > > > > > > > > > > > > > > In addition, I am curious to know whether the proposed > > > mechanism > > > > > > will work when there is a proxy between the UA and the > > > > P-CSCF, e.g., > > > > > > a proxy/B2BUA in an enterprise or residential network. > > > Is there a > > > > > > danger that the proxy/B2BUA will apply > end2AccessEdge security > > > > > > (between the UA and itself), leaving the hop between > > > > proxy/B2BUA and > > > > > > the P-CSCF unprotected? The so-called requirement > of the UA to > > > > > > provide security on the first hop is fulfilled, but the > > > > critical hop > > > > > > to the P-CSCF is not secured. > > > > > > > > > > [PETER] at least in the IMS architecture (which is the > > > > driver for the > > > > > requirements in the draft) there is no proxy between the > > > UA and the > > > > > P-CSCF. I guess that for enterprise/residential cases this > > > > would work > > > > > as well, as the "UA" in that case is the > PBX/residential gateway > > > > > (attachment point to the SSP network) and therefore media > > > > is secured > > > > > between the PBX/residential gateway and the P-CSCF. In that > > > > case it is > > > > > NOT the linke between the real endpoints (i.e. the > PBX phones or > > > > > residential phones) but the link between the attachement > > > > point and the > > > > > network that is secured. > > > > [JRE] The proxy/B2BUA acting as PBX might not handle media. > > > > Media (and hence media security) will come from the UA > > > behind the PBX, > > > > whereas signalling security will come from the PBX. > > > > The PBX in this case is not in a position to negotiate > > > media security > > > > - that is just passed on from the UA behind the PBX. > > > > It seems to me that trying to add media security to RFC > > > 3329 violates > > > > this architectural distinction between the hop-by-hop nature of > > > > signalling and the end-to-end nature of media. I agree that > > > if you put > > > > in a device such as a Session Border Controller (SBC) > > > between the PBX > > > > and the IMS network the proposed solution might work, but > > we should > > > > not force the presence of an SBC here. > > > > > > > > > > > > > > > > There have been extensive discussions on the DISPATCH and > > > > the former > > > > > > SIP lists over the last couple of years or more about > > > > authenticated > > > > > > identity and how that can be used to give some guarantee > > > > to the user > > > > > > as to where secure media terminates, without any > resolution. A > > > > > > solution that just guarantees security on a first > hop does not > > > > > > really take us further forward. As Hadriel pointed out, > > > > there is the > > > > > > SDP capability negotiation solution, as well as other > > solutions > > > > > > proposed > > > > > in the past. > > > > > > > > > > [PETER] cellular networks do have access link security, > > > i.e. media > > > > > encryption. So I believe there is justification for such > > > a solution > > > > [JRE] This does not answer my concern. I am not disputing that > > > > security is required. However, we already have a > solution for best > > > > effort SRTP. The existing solution is not ideal, since it > > > doesn't tell > > > > me how far media is secured, only that it is secured at > > > least part of > > > > the way to the remote endpoint. What the draft seems to be > > > asking for > > > > is a solution that specifically limits SRTP to a single > hop, and I > > > > dispute the need and the architectural viability of that. > > > > > > > > [Thomas] As explained above, the IMS security aims to do > > > better than > > > > that for end-to-end security and provide protection for > the most > > > > vulnerable point with end-to-access-edge encryption. > > > > > > > > For end-to-access edge protection, architectural > > > considerations also > > > > played a role: only the P-CSCF and controlled BGW need to > > > be updated, > > > > not all the entities handling the user plane. This is shurly an > > > > argument primarily from an operator=B4s perspective, but are such > > > > arguments forbidden in IETF? > > > [JRE] I don't dispute that. I was commenting on an > earlier statement > > > (from Peter I think) that suggested it would be the UE's wish to > > > have media security only as far as the edge, and I did > not buy that > > > argument. > > > > > > You did not comment on my architectural concern about the > single-hop > > > nature of RFC 3329 versus the end-to-end nature of media, and how > > > that would work in certain PBX environments when > attaching to IMS. > > > So notwithstanding our slight differences of opinion > concerning the > > > requirements, I still have this architectural concern. Any > > > shortcomings relating to the negotiation of media > security should, > > > in my opinion, be handled in SDP. > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Leis, Peter (NSN - DE/Munich) > > > [mailto:peter.leis@nsn.com] > > > > > > > Sent: 26 May 2010 06:54 > > > > > > > To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, > > VF-Group; > > > > > > > dispatch@ietf.org > > > > > > > Subject: RE: [dispatch] New I-D: > > > > > > > draft-dawes-dispatch-mediasec-parameter-01 > > > > > > > > > > > > > > hello John, > > > > > > > > > > > > > > 33.328 does not have a particular requirements section. > > > > It is the > > > > > > > stage-2 specification for the feature "media > plane security" > > > > > > > and as such > > > > > > > provides architecture and functional flows for the > > > > feature. I have > > > > > > > refered to this as "requirements". > > > > > > > > > > > > > > Clause 4 of the docuement gives an overview and > > > > describes that two > > > > > > > solutions based on SDES are required, namely end2end and > > > > > > > end2accessedge media protection. The need for two modes > > > > based on > > > > > > > SDES SRTP is reflected throughout the specification > > > > where in every > > > > > > > clause you find a sub-clause for end2end and a sub-clasue > > > > > > > end2accessedge. Clause 7 provides the registration > > > and session > > > > > > > setup procedures, again different > > > > > > for end2end > > > > > > > and end2access edge. > > > > > > > > > > > > > > So end2end and end2accessedge are described as two > > > > different and > > > > > > > distinct use cases. > > > > > > > > > > > > > > One goal for end2accessedege security as specified in > > > > > TS33.328 is to > > > > > > > allow to achieve media plane security (on the access > > > leg) fully > > > > > > > independant of of any capabilities of clients on the > > > > far end side. > > > > > > > > > > > > > > 33.328 was developped based on requirements documented > > > > in 33.828 > > > > > > > http://www.3gpp.org/ftp/Specs/html-info/33828.htm > > > > > > > > > > > > > > Clause 4 describes the use cases whith 4.1.2 describing > > > > > > end2accessedge > > > > > > > (access media protection). > > > > > > > > > > > > > > regards > > > > > > > Peter > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > From Peter.Dawes@vodafone.com Thu May 27 06:45:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9385D3A6ADA for ; Thu, 27 May 2010 06:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n2DSBSEbHZf for ; Thu, 27 May 2010 06:45:49 -0700 (PDT) Received: from mailout01.vodafone.com (mailout01.vodafone.com [195.232.224.70]) by core3.amsl.com (Postfix) with ESMTP id 7913D3A691D for ; Thu, 27 May 2010 06:45:48 -0700 (PDT) Received: from mailint01 (localhost [127.0.0.1]) by mailout01 (Postfix) with ESMTP id 5C3B14585 for ; Thu, 27 May 2010 15:45:37 +0200 (CEST) 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 mailint01 (Postfix) with ESMTPS id 4F4DF44CB; Thu, 27 May 2010 15:45:37 +0200 (CEST) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 15:45:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 May 2010 15:45:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: Acr9ouRmIZcIwxKPSByC+f2WI2K6ag== From: "Dawes, Peter, VF-Group" To: X-OriginalArrivalTime: 27 May 2010 13:45:38.0339 (UTC) FILETIME=[E3E42730:01CAFDA2] Cc: dispatch@ietf.org Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 13:45:51 -0000 Hello James, I think the scenario you have in mind is=20 UA1 <-----------> SBC/B2BUA1 <-------------> Core Network <----------->SBC/B2BUA2 <-------> UA2 I guess that your suggestion is that media plane security runs between UA1 and UA2 and that SBC/B2BUA1 and SBC/B2BUA2 should have the security keys in order to perform lawful intercept. This end-to-end scenario is possible, and lawful intercept can work as you described in such a scenario. However, the scenario for draft-dawes-dispatch-mediasec-parameter-01 is that media plane security runs between UA1 <-----------> SBC/B2BUA1 and is decrypted by SBC/B2BUA1 before continuing in the direction of UA2.=20 Lawful intercept is not the only reason that 3GPP did not adopt DTLS-SRTP. Middleboxes that block the media path until the caller receives 200 OK also make security setup in the media path unuseable because they cause a period of silence while media plane security is being set up, which is why the draft describes exchange of media plane security capabilities at registration.=20 Regards, Peter Message: 1 Date: Wed, 28 Apr 2010 16:24:55 -0500 From: "James M. Polk" Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 To: Paul Kyzivat , "DRAGE, Keith (Keith)" Cc: "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Message-ID: <201004282124.o3SLOu2M023994@sj-core-4.cisco.com> Content-Type: text/plain; charset=3D"us-ascii"; format=3Dflowed At 12:26 PM 4/28/2010, Paul Kyzivat wrote: >DRAGE, Keith (Keith) wrote: >>The underlying way this works is described in: >>http://www.3gpp.org/ftp/Specs/html-info/33328.htm >>Search for "a2ae" for the relevant bits of text. >>The first hop device is in fact a B2BUA with media, where it needs to=20 >>implement these procedures. > >This is the key thing I was suspecting. >If it needs to be a B2BUA for this to work, then talking about it as a=20 >proxy is inappropriate. > > Thanks, > Paul > >>The general use case for these procedures would seem to be where you=20 >>have an access technology that is not secure in itself, but needs some >>level of security therefore provided. So WLAN uses accessing 3G would=20 >>use it, but 3G users would not, this makes it appear in an SBC role (which does always receive the media) more than a B2BUA role (which doesn't always (i.e., perhaps rarely) receive the media). If this is agreed to, then this can be more of an e2e scenario in which DTLS-SRTP can be used, in which the P-CSCF has the decryption keys for the media - thus able to meet the requirements for LI that the IETF cannot address, per RFC 2804, as Adam stated already. I'm also not completely clear now SRTP can be used at all in this scenario, given the scenario assumes that SRTP breaks the requirements for LI capture. Thus, isn't this doc advocating a mandate that (effectively) "there shall be no SRTP between the UE and the first hop proxy (that really isn't a proxy) because it breaks the LI requirements that 3GPP wants to address (that the IETF can't)".... this appears curious at best James >>because the underlying bearers are already security protected to an extent. >>I'll leave Peter to discuss how much more introductory material should >>be in the document, but this at least will hopefully help you=20 >>understand what is happening. >>regards >>Keith >>>-----Original Message----- >>>From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >>>On Behalf Of Paul Kyzivat >>>Sent: Wednesday, April 28, 2010 2:30 PM >>>To: Dawes, Peter, VF-Group >>>Cc: dispatch@ietf.org >>>Subject: Re: [dispatch] New I-D:=20 >>>draft-dawes-dispatch-mediasec-parameter-01 >>> >>>Peter - a question: >>> >>>Dawes, Peter, VF-Group wrote: >>>>Hello All, >>>>An updated draft is available on the topic of providing >>>security for >>>>the media plane between a SIP client and its first-hop proxy >>>(http://www.ietf.org/id/draft-dawes-dispatch-mediasec-paramete >>> >> r-01.txt). >>>>This draft defines a "mediasec" header field parameter and >>>a "mediasec" >>>>option tag to extend RFC 3329 "Security Mechanism Agreement for the=20 >>>>Session Initiation Protocol (SIP)" to apply to the media plane. >>>I am confused about the concept of "security for the media plane=20 >>>between a SIP client and its first-hop proxy". >>> >>>A proxy has no involvement with media. I read through the draft to=20 >>>understand better, but didn't gain enlightenment there. In fact I=20 >>>found no mention of proxies at all. However I did find that the=20 >>>mechanism only applies in cases where there is a single Via header,=20 >>>which means the server must be one hop removed from the client. >>> >>>So I haven't been able to discern if this is just a matter of the=20 >>>first hop from the client enforcing a requirement that media security >>>be used between the UAC and UAS, or if there is some expectation that >>>the proxy will in fact control the receipt and encryption/decryption=20 >>>of the media. >>> >>>That might have been clearer if the examples showed the SDP. >>> >>> Thanks, >>> Paul >>>_______________________________________________ >>>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 ------------------------------ Peter Dawes Group R&D =20 Tel: +44 (0)7717 275009 Fax: +44 (0)1635 234873 =20 E-mail: peter.dawes@vodafone.com =20 www.betavine.net - Web betavine.mobi - Mobile Web =20 Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001 Regards, Peter=20 From Milan.Patel@InterDigital.com Fri May 28 06:13:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0953A6861 for ; Fri, 28 May 2010 06:13:22 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sktlw+V1EfbP for ; Fri, 28 May 2010 06:13:16 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 314F53A67EF for ; Fri, 28 May 2010 06:13:16 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 May 2010 09:13:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CAFE67.827ABD3E" Date: Fri, 28 May 2010 09:13:05 -0400 Message-ID: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Charter proposal for drafts related to the tel URI Thread-Index: Acr781AwwOgR9/sgQ9igLdsV8J81CQCczVyw From: "Patel, Milan" To: , , "Cullen Jennings" X-OriginalArrivalTime: 28 May 2010 13:13:05.0974 (UTC) FILETIME=[829AA560:01CAFE67] Subject: [dispatch] Charter proposal for drafts related to the tel URI X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 13:13:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAFE67.827ABD3E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAFE67.827ABD3E" ------_=_NextPart_002_01CAFE67.827ABD3E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 Attached is a charter proposal for a WG to be formed for work pertaining to extensions to the tel URI - specifically, parameters for carrying the DAI, CPC, OLI and RN required for primarily interworking scenarios to ISUP/PSTN.=20 Feedback is appreciated.=20 Regards, Milan =20 =20 ________________________________ From: Patel, Milan=20 Sent: Tuesday, May 25, 2010 11:16 AM To: Cullen Jennings; 'mary.ietf.barnes@gmail.com'; Robert Sparks; 'Gonzalo Camarillo' Cc: R.Jesske@telekom.de; 'Sumanth Channabasappa' Subject: Charter proposal =20 Hi all, =20 Attached is a charter proposal for a WG to be formed to handle Internet Drafts pertaining to the Tel URI. Specifically these are the DAI draft and the CPC/OLI draft and some further work on the RN parameter.=20 Feedback is welcome.=20 =20 Kind regards, Milan ------_=_NextPart_002_01CAFE67.827ABD3E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Attached is a charter proposal for = a WG to be formed for work pertaining to extensions to the tel URI – specifically, parameters for carrying the DAI, CPC, OLI and RN required = for primarily interworking scenarios to ISUP/PSTN. =

Feedback is appreciated. =

Regards,

Milan

 

 

From: = Patel, Milan
Sent: Tuesday, May 25, = 2010 11:16 AM
To: Cullen Jennings; = 'mary.ietf.barnes@gmail.com'; Robert Sparks; = 'Gonzalo Camarillo'
Cc: R.Jesske@telekom.de; = 'Sumanth Channabasappa'
Subject: Charter = proposal

 

Hi all,

 

Attached is a charter proposal for a WG to be = formed to handle Internet Drafts pertaining to the Tel URI. Specifically these = are the DAI draft and the CPC/OLI draft and some further work on the RN = parameter.

Feedback is welcome. =

 

Kind regards,

Milan

------_=_NextPart_002_01CAFE67.827ABD3E-- ------_=_NextPart_001_01CAFE67.827ABD3E Content-Type: text/plain; name="XXXX WG charter proposal.txt" Content-Transfer-Encoding: base64 Content-Description: XXXX WG charter proposal.txt Content-Disposition: attachment; filename="XXXX WG charter proposal.txt" VGhlIFhYWFggV0cgaGFzIGJlZW4gY2hhcnRlcmVkIHRvIGNvbnRpbnVlIHNwZWNpZmljYXRpb24g b2YgdGVsIFVSSSBhZGRyZXNzIHNjaGVtZSBwYXJhbWV0ZXJzIHJlcXVpcmVkIGZvciBpbnRlcndv cmtpbmcgd2l0aCBleGlzdGluZyBjaXJjdWl0IHN3aXRjaGVkIGFuZCBJU1VQIG5ldHdvcmtzLiBS RkMgMzk2NiAiVGhlIHRlbCBVUkkgZm9yIFRlbGVwaG9uZSBOdW1iZXJzIiBzcGVjaWZpZXMgZXh0 ZW5zaWJsZSBzeW50YXggZm9yIHBhcmFtZXRlcnMgcGVydGFpbmluZyB0byB0aGUgdGVsIFVSSSBh ZGRyZXNzIHNjaGVtZS4gQWRkaXRpb25hbCByZXF1aXJlbWVudHMsIGFzIGEgcmVzdWx0IG9mIHRo ZSBuZWVkIHRvIGludGVyd29yayBJUCBUZWxlcGhvbnkgbmV0d29ya3Mgd2l0aCBJU1VQIG5ldHdv cmtzIHN1Y2ggYXMgdGhlIFBTVE4gb3IgY2VsbHVsYXIgbmV0d29ya3MgcmVxdWlyZSBmdXJ0aGVy IHBhcmFtZXRlcnMgdG8gYmUgc3BlY2lmaWVkLg0KQmVmb3JlIGVxdWFsIGFjY2VzcyB3YXMgc3Vw cG9ydGVkIGluIHRoZSBVbml0ZWQgU3RhdGVzLCBvbmx5IEFUJlQncyBzdWJzY3JpYmVycyBjb3Vs ZCBkaWFsICIxIiB0byByZWFjaCBBVCZUIHdoZW4gdGhleSBtYWRlIGxvbmcgZGlzdGFuY2UgY2Fs bHMuICBPdGhlciBsb25nIGRpc3RhbmNlIGNhcnJpZXJzJyBzdWJzY3JpYmVycyBuZWVkZWQgdG8g ZGlhbCBleHRyYSBkaWdpdHMgdG8gcmVhY2ggdGhlaXIgbG9uZyBkaXN0YW5jZSBjYXJyaWVycy4g IEZvciBmYWlyIGNvbXBldGl0aW9uLCB0aGUgRmVkZXJhbCBDb21tdW5pY2F0aW9uIENvbW1pc3Np b24gaW4gdGhlIFUuUy4gbWFuZGF0ZWQgdGhlIHN1cHBvcnQgZm9yIGVxdWFsIGFjY2VzcyB0aGF0 IGFsbG93ZWQgYW55IGxvbmcgZGlzdGFuY2UgY2FycmllcidzIHN1YnNjcmliZXIgdG8gZm9sbG93 IHRoZSBzYW1lIGRpYWxpbmcgcGxhbiB0byByZWFjaCBoaXMvaGVyIHByZS1zdWJzY3JpYmVkIGxv bmcgZGlzdGFuY2UgY2Fycmllci4gIFRoZSByZWd1bGF0b3J5IGJvZGllcyBpbiBtYW55IG90aGVy IGNvdW50cmllcyBhbHNvIGhhdmUgbWFuZGF0ZWQgZXF1YWwgYWNjZXNzLg0KVG8gYWxsb3cgYSB0 ZWxlcGhvbnkgc3Vic2NyaWJlciB0byB1c2UgYSBub24tcHJlLXN1YnNjcmliZWQgbG9uZyBkaXN0 YW5jZSBjYXJyaWVyIGZvciBzb21lIG9mIHRoZWlyIGxvbmcgZGlzdGFuY2UgY2FsbHMsIHRoZSBV LlMuIGhhcyBpbXBsZW1lbnRlZCB0aGUgZGlhbGluZyBwcmVmaXggIjEwWFhYIiB0aGF0IHdhcyBs YXRlciBleHBhbmRlZCB0byAiMTAxWFhYWCIgaW4gdGhlIGRpYWxpbmcgcGxhbi4gIFRoZSBwcmVm aXggYWxsb3dzIHRoZSBjYWxsZXIgdG8gdXNlICJYWFgiIG9yICJYWFhYIiB0byBzcGVjaWZ5IHRo ZSBsb25nIGRpc3RhbmNlIGNhcnJpZXIgdG8gaGFuZGxlIHRoYXQgcGFydGljdWxhciBjYWxsLiAg VGhpcyBkaWFsaW5nIHByZWZpeCB3YXMgYWxzbyB1c2VkIHRvIGlkZW50aWZ5IHRoZSBsb2NhbCB0 b2xsIGNhcnJpZXIgaW4gdGhlIFVuaXRlZCBTdGF0ZXMgd2hlbiBlcXVhbCBhY2Nlc3MgYWxzbyBh cHBsaWVkIHRvIHRoZSBsb2NhbCB0b2xsIGNhbGxzLg0KT25lIG9mIHRoZSBwdXJwb3NlcyBvZiB0 aGUgREFJIGlzIHRvIGluZGljYXRlIHRvIHRoZSBsb25nIGRpc3RhbmNlIGNhcnJpZXIgdGhhdCBy ZWNlaXZlcyBhIGNhbGwgZnJvbSB0aGUgbG9jYWwgZXhjaGFuZ2UgY2FycmllciB3aGV0aGVyIHRo ZSBjYWxsIGNhbWUgZnJvbSBhIHByZS1zdWJzY3JpYmVkIGN1c3RvbWVyIG9yIG5vdC4gICBEdWUg dG8gb3BlcmF0b3ItYXNzaXN0ZWQgY2FsbHMsIHdoZXJlIHRoZSBjYWxsZWQgcGFydHkgb3IgYSB0 aGlyZCBwYXJ0eSBtYXkgYmUgY2hhcmdlZCBmb3IgdGhlIGNhbGwgaW4gc29tZSBjYXNlcywgdGhl IERBSSBpcyBhbHNvIHVzZWQgdG8gaW5kaWNhdGUgdG8gdGhlIHJlY2VpdmluZyBsb25nIGRpc3Rh bmNlIGNhcnJpZXIgaWYgaXQgaXMgdGhlIHByaW1hcnkgb3IgYWx0ZXJuYXRlIHByZWZlcnJlZCBs b25nIGRpc3RhbmNlIGNhcnJpZXIgb2YgdGhlIGNoYXJnZWQgcGFydHkuIA0KIFRoZSBsb25nIGRp c3RhbmNlIGNhcnJpZXIgaW5mb3JtYXRpb24sIHRoZSBDYXJyaWVyIElkZW50aWZpY2F0aW9uIENv ZGUgKENJQyksIGNhbiBiZSBjYXJyaWVkIGluIHRoZSAiY2ljIiBwYXJhbWV0ZXIsICAgc3BlY2lm aWVkIGluIFJGQzQ2OTQsIGEgcGFyYW1ldGVyIG9mIHRoZSAidGVsIiBVbmlmb3JtIFJlc291cmNl IElkZW50aWZpZXIgKFVSSSkuIFRoZSAiY2ljIiBwYXJhbWV0ZXIgZGVmaW5lZCBpbiBpZGVudGlm aWVzIHRoZSBmcmVlcGhvbmUgc2VydmljZSBwcm92aWRlciB0aGF0IHNlcnZlcyB0aGUgZnJlZXBo b25lIG51bWJlci4gIEFzIGRlc2NyaWJlZCBpbiBSRkMgNDY5NCwgaXQgY2FuIGFsc28gYmUgdXNl ZCB0byBjYXJyeSB0aGUgQ0lDIGFzc29jaWF0ZWQgd2l0aCB0aGUgY2FycmllciB3aG8gaXMgdG8g aGFuZGxlIGEgY2FsbCB0byBhIGdlb2dyYXBoaWMgdGVsZXBob25lIG51bWJlci4gIFdoZW4gdGhl IGNhcnJpZXIgdGhhdCBpcyBhc3NpZ25lZCB0aGUgQ0lDIHJlY2VpdmVzIHRoZSBjYWxsLCB0aGUg ImRhaSIgcGFyYW1ldGVyIGluZGljYXRlcyB0byB0aGF0IGNhcnJpZXIgaG93IGl0IHdhcyBzZWxl Y3RlZC4NClRoZSBSTiBwYXJhbWV0ZXIgaXMgdXNlZCBmb3IgY2FzZXMgd2hlcmUgc3BlY2lmaWMg cHJlZml4ZXMgYXJlIHVzZWQgdG8gcm91dCB0aGUgY2FsbCB0aHJvdWdoIHRoZSBuZXR3b3JrLiBU aGUgInJuIiBwYXJhbWV0ZXIgY2FycmllcyB0aGUgcm91dGluZyBudW1iZXIgaW5mb3JtYXRpb24u DQoNClNTNyBJU1VQIGRlZmluZXMgYSBDYWxsaW5nIFBhcnR5J3MgQ2F0ZWdvcnkgKENQQykgcGFy YW1ldGVyIHRoYXQgY2hhcmFjdGVyaXplcyB0aGUgc3RhdGlvbiB1c2VkIHRvIG9yaWdpbmF0ZSBh IGNhbGwgYW5kIGNhcnJpZXMgb3RoZXIgaW1wb3J0YW50IHN0YXRlIHRoYXQgY2FuIGRlc2NyaWJl IHRoZSBvcmlnaW5hdGluZyBwYXJ0eS4gIE9uZSBleGFtcGxlIG9mIHN1Y2ggaW5mb3JtYXRpb24g aXMgdGhlIGNhbGwgbWF5IG9yaWdpbmF0ZSBmcm9tIGEgcGF5cGhvbmU7IHN1Y2ggaW5mb3JtYXRp b24gY2FuIGJlIHVzZWQgYnkgdGhlIG5ldHdvcmsgdG8gaGFuZGxlIHRoZSBjYWxsIGluIGEgc3Bl Y2lmaWMgd2F5LiAgV2hlbiB0ZWxlcGhvbmUgbnVtYmVycyBhcmUgY29udGFpbmVkIGluIFVSSXMs IHN1Y2ggYXMgdGhlIHRlbCBVUkkgb3IgZXF1aXZhbGVudCBTSVAgVVJJLCBpdCBtYXkgYmUgZGVz aXJhYmxlIHRvIGNvbW11bmljYXRlIGFueSBDUEMgYXNzb2NpYXRlZCB3aXRoIHRoYXQgdGVsZXBo b25lIG51bWJlciBvciwgaW4gdGhlIGNvbnRleHQgb2YgYSBjYWxsLCB0aGUgcGFydHkgY2FsbGlu ZyBmcm9tIGl0LiAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIG1ldGhvZCBvZiBjYXJyeWluZyBD UEMgZGF0YSBpbiBTSVAgbWVzc2FnZXMuDQpJbiBzb21lIG5ldHdvcmtzIChpbmNsdWRpbmcgTm9y dGggQW1lcmljYSksIHRoZSBPcmlnaW5hdGluZyBMaW5lIEluZm9ybWF0aW9uIChPTEkpIHBhcmFt ZXRlciBkZWZpbmVkIGluIEFOU0kgSVNVUCBpcyB1c2VkIHRvIGNhcnJ5IGluZm9ybWF0aW9uIHJl bGF0ZWQgdG8gdGhlIGNhbGxpbmcgcGFydHkgYW5kIHRoZSBjbGFzcyBvZiBzZXJ2aWNlIGZvciBh IGNhbGwuICBMZWdhY3kgbXVsdGlmcmVxdWVuY3kgKE1GKSBzaWduYWxsaW5nIG5ldHdvcmtzIGNh cnJ5IHRoaXMgaW5mb3JtYXRpb24gaW4gdGhlIEFOSSBJSSBEaWdpdHMgPGh0dHA6Ly93d3cubmFu cGEuY29tL251bWJlcl9yZXNvdXJjZV9pbmZvL2FuaV9paV9hc3NpZ25tZW50cy5odG1sPi4gVGhl IGNhbGwgY2FuIG9yaWdpbmF0ZSBmcm9tIGEgbXVsdGl0dWRlIG9mIGRldmljZXMgb3Igc3RhdGlv bnMuICBGb3IgZXhhbXBsZSwgYSBjb2luIG9wZXJhdGVkIHBob25lIG9yIGEgcGhvbmUgbG9jYXRl ZCBpbnNpZGUgYSBwcmlzb24gY2FuIGJlIHVzZWQgdG8gb3JpZ2luYXRlIGEgY2FsbC4gIEluIHN1 Y2ggY2FzZXMsIGl0IGNhbiBiZSBkZXNpcmFibGUgdG8gaGFuZGxlIGNhbGxzIG9yaWdpbmF0aW5n IGZyb20gc3VjaCBzdGF0aW9ucyBpbiBhIHNwZWNpZmljIG1hbm5lciwgb3IgdG8gcmVzdHJpY3Qg Y2VydGFpbiBzZXJ2aWNlcyB0byB0aGUgY2FsbGluZyBwYXJ0eS4gIFRoaXMgZG9jdW1lbnQgcHJv cG9zZXMgYSBtZXRob2Qgb2YgY2FycnlpbmcgT0xJIGRhdGEgaW4gU0lQIG1lc3NhZ2VzLg0KVGhl IHByaW1hcnkgdXNlIGNhc2UgZm9yIHRoZXNlIHBhcmFtZXRlcnMgaXMgZm9yIGludGVyd29ya2lu ZyBDUEMgYW5kIE9MSSBpbmZvcm1hdGlvbiBiZXR3ZWVuIFNJUCBhbmQgSVNVUC4gIE90aGVyIHVz ZSBjYXNlcyBtYXkgZXhpc3Qgd2hlcmUgaXQgaXMgdXNlZnVsIHRvIHRyYW5zZmVyIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBlbmRwb2ludCBldmVuIHdoZW4gaW50ZXJ3b3JraW5nIHdpdGggdGhlIFBT VE4gZG9lcyBub3Qgb2NjdXIuDQpUaGUgb2JqZWN0aXZlIG9mIHRoZSB3b3JraW5nIGdyb3VwIGlz IGFzIGZvbGxvd3M6DQoxLiBUbyBzcGVjaWZ5IHBhcmFtZXRlcnMgcGVydGFpbmluZyB0byB0aGUg dGVsIFVSSSBhZGRyZXNzIHNjaGVtZSB0byBjYXJyeSBpbmZvcm1hdGlvbiBzdWNoIGFzIERBSSwg Q1BDLCBSTiBhbmQgT0xJLiANCjIuIFRvIHNwZWNpZnkgaG93IHRoZXNlIHBhcmFtZXRlcnMgYXJl IHBvcHVsYXRlZCBhbmQgdXNlZCBpbiBhbiBJUCBUZWxlcGhvbnkgbmV0d29yaw0KDQpUaGUgd29y a2luZyBncm91cCB3aWxsIHdvcmsgb24gdGhlIGZvbGxvd2luZyBkZWxpdmVyYWJsZXM6DQoxLiBB IGRvY3VtZW50IGZvciBleHRlbmRpbmcgdGhlIFRlbCBVUkkgcGFyYW1ldGVycyB0byBzdXBwb3J0 IERBSQ0KMi4gQSBkb2N1bWVudCBmb3IgZXh0ZW5kaW5nIHRoZSBUZWwgVVJJIHBhcmFtZXRlciBk ZWZpbml0aW9uIHRvIHN1cHBvcnQgQ1BDIGFuZCBPTEkNCg0KSW50ZXJuZXQgRHJhZnRzOg0KaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGF0ZWwtZGlzcGF0Y2gtY3BjLW9saS1wYXJh bWV0ZXItMDINCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXl1LXRlbC1kYWktMDgN Ck1pbGVzdG9uZXMNCkp1bmUgMjAxMCBjaGFydGVyIHByb3Bvc2FsIGZvciB4eHh4IFdHDQpOb3Zl bWJlciAyMDEwIHB1Ymxpc2ggdGhlIGFib3ZlIGRyYWZ0cw0KSmFudWFyeSAyMDExIGNsb3NlL3Jl LWNoYXJ0ZXIgV0cNCg== ------_=_NextPart_001_01CAFE67.827ABD3E-- From pkyzivat@cisco.com Fri May 28 06:57:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5A683A68F0 for ; Fri, 28 May 2010 06:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.833 X-Spam-Level: X-Spam-Status: No, score=-8.833 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvwfjYORfrjM for ; Fri, 28 May 2010 06:57:38 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9A6A73A67EF for ; Fri, 28 May 2010 06:57:38 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,318,1272844800"; d="scan'208";a="115660492" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 May 2010 13:57:28 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4SDvSnM026350; Fri, 28 May 2010 13:57:28 GMT Message-ID: <4BFFCBC7.3070506@cisco.com> Date: Fri, 28 May 2010 09:57:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Patel, Milan" References: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com> In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 13:57:39 -0000 A comment on this proposal: It presumes that this information should be conveyed by encoding it within a tel URI (or presumably in a sip URI using telephone-subscriber syntax.) While that *may* be an appropriate solution for some of the intended data, its far from clear that is the most appropriate encoding for all of it. Some of that information describes the caller, some the callee, and some describes the circumstances of a particular call. Some may even be determined by intermediaries. Also, some of this information may be appropriate for calls using non-tel URI syntax. I do agree that determining how to convey this information is important. But I think presuming a tel-based solution is overreaching. I suggest something along the lines of: The working group will work on the following deliverables: 1. A document defining - sip analogs to the ISUP parameters DAI, CPC, and OLI, - where/how they are provided and consumed in sip sessions - how they are interworked with ISUP. 2. A document specifying how these parameters are to be transported within sip messages. This document will define extensions to SIP and/or TEL URI syntax as needed to accomplish this. Thanks, Paul Patel, Milan wrote: > Hello, > > Attached is a charter proposal for a WG to be formed for work pertaining > to extensions to the tel URI – specifically, parameters for carrying the > DAI, CPC, OLI and RN required for primarily interworking scenarios to > ISUP/PSTN. > > Feedback is appreciated. > > Regards, > > Milan > ------------------------------------------------------------------------ > > *From:* Patel, Milan > *Sent:* Tuesday, May 25, 2010 11:16 AM > *To:* Cullen Jennings; 'mary.ietf.barnes@gmail.com'; Robert Sparks; > 'Gonzalo Camarillo' > *Cc:* R.Jesske@telekom.de; 'Sumanth Channabasappa' > *Subject:* Charter proposal > > > > Hi all, > > > > Attached is a charter proposal for a WG to be formed to handle Internet > Drafts pertaining to the Tel URI. Specifically these are the DAI draft > and the CPC/OLI draft and some further work on the RN parameter. > > Feedback is welcome. > > > > Kind regards, > > Milan > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Milan.Patel@InterDigital.com Fri May 28 07:33:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502813A68A7 for ; Fri, 28 May 2010 07:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qz3mryEkXfF for ; Fri, 28 May 2010 07:33:34 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id F3ED13A68F0 for ; Fri, 28 May 2010 07:33:33 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 May 2010 10:33:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 May 2010 10:33:23 -0400 Message-ID: <61CAF342FE1EE34EAC8FB19B765914000E6FB138@SABRE.InterDigital.com> In-Reply-To: <4BFFCBC7.3070506@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposal for drafts related to the tel URI Thread-Index: Acr+bbZD1m+4fAuqRZGvsAcYb9y2ZQABItig From: "Patel, Milan" To: "Paul Kyzivat" X-OriginalArrivalTime: 28 May 2010 14:33:24.0038 (UTC) FILETIME=[BA64DE60:01CAFE72] Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 14:33:35 -0000 Hi Paul, The approach we have taken is not unique since other URI parameters that have previously been specified have not always been a characteristic of the entity identified by the URI. 3GPP have sent DISPATCH a liaison related to some of the comments that have been raised concerning the use of a tel URI parameter for the CPC/OLI. If you are available for the 3GPP-IETF coordination call hosted by Hannu next month, I would like this to be discussed on the call. Regards, Milan -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Friday, May 28, 2010 2:57 PM To: Patel, Milan Cc: dispatch@ietf.org; mary.ietf.barnes@gmail.com; Cullen Jennings Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI A comment on this proposal: It presumes that this information should be conveyed by encoding it=20 within a tel URI (or presumably in a sip URI using telephone-subscriber=20 syntax.) While that *may* be an appropriate solution for some of the intended=20 data, its far from clear that is the most appropriate encoding for all=20 of it. Some of that information describes the caller, some the callee,=20 and some describes the circumstances of a particular call. Some may even be determined by intermediaries. Also, some of this information may be=20 appropriate for calls using non-tel URI syntax. I do agree that determining how to convey this information is important. But I think presuming a tel-based solution is overreaching. I suggest=20 something along the lines of: The working group will work on the following deliverables: 1. A document defining - sip analogs to the ISUP parameters DAI, CPC, and OLI, - where/how they are provided and consumed in sip sessions - how they are interworked with ISUP. 2. A document specifying how these parameters are to be transported within sip messages. This document will define extensions to SIP and/or TEL URI syntax as needed to accomplish this. Thanks, Paul Patel, Milan wrote: > Hello, >=20 > Attached is a charter proposal for a WG to be formed for work pertaining=20 > to extensions to the tel URI - specifically, parameters for carrying the=20 > DAI, CPC, OLI and RN required for primarily interworking scenarios to=20 > ISUP/PSTN. >=20 > Feedback is appreciated. >=20 > Regards, >=20 > Milan > ------------------------------------------------------------------------ >=20 > *From:* Patel, Milan > *Sent:* Tuesday, May 25, 2010 11:16 AM > *To:* Cullen Jennings; 'mary.ietf.barnes@gmail.com'; Robert Sparks;=20 > 'Gonzalo Camarillo' > *Cc:* R.Jesske@telekom.de; 'Sumanth Channabasappa' > *Subject:* Charter proposal >=20 > =20 >=20 > Hi all, >=20 > =20 >=20 > Attached is a charter proposal for a WG to be formed to handle Internet=20 > Drafts pertaining to the Tel URI. Specifically these are the DAI draft > and the CPC/OLI draft and some further work on the RN parameter. >=20 > Feedback is welcome. >=20 > =20 >=20 > Kind regards, >=20 > Milan >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Fri May 28 09:37:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7030928C0F3 for ; Fri, 28 May 2010 09:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.744 X-Spam-Level: X-Spam-Status: No, score=-9.744 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA-uodqBF6qK for ; Fri, 28 May 2010 09:37:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 991D328C0E0 for ; Fri, 28 May 2010 09:37:49 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,319,1272844800"; d="scan'208";a="115852830" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 28 May 2010 16:37:39 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4SGbdPD025704; Fri, 28 May 2010 16:37:39 GMT Message-ID: <4BFFF152.4060507@cisco.com> Date: Fri, 28 May 2010 12:37:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Patel, Milan" References: <61CAF342FE1EE34EAC8FB19B765914000E6FB138@SABRE.InterDigital.com> In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000E6FB138@SABRE.InterDigital.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 16:37:55 -0000 Patel, Milan wrote: > Hi Paul, > > The approach we have taken is not unique since other URI parameters that > have previously been specified have not always been a characteristic of > the entity identified by the URI. That doesn't make it the right thing to do. > 3GPP have sent DISPATCH a liaison > related to some of the comments that have been raised concerning the use > of a tel URI parameter for the CPC/OLI. Can you tell me where to get a copy to read? > If you are available for the > 3GPP-IETF coordination call hosted by Hannu next month, I would like > this to be discussed on the call. Maybe. Is there a particular date/time? Thanks, Paul > Regards, > Milan > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, May 28, 2010 2:57 PM > To: Patel, Milan > Cc: dispatch@ietf.org; mary.ietf.barnes@gmail.com; Cullen Jennings > Subject: Re: [dispatch] Charter proposal for drafts related to the tel > URI > > A comment on this proposal: > > It presumes that this information should be conveyed by encoding it > within a tel URI (or presumably in a sip URI using telephone-subscriber > syntax.) > > While that *may* be an appropriate solution for some of the intended > data, its far from clear that is the most appropriate encoding for all > of it. Some of that information describes the caller, some the callee, > and some describes the circumstances of a particular call. Some may even > > be determined by intermediaries. Also, some of this information may be > appropriate for calls using non-tel URI syntax. > > I do agree that determining how to convey this information is important. > > But I think presuming a tel-based solution is overreaching. I suggest > something along the lines of: > > The working group will work on the following deliverables: > 1. A document defining > - sip analogs to the ISUP parameters DAI, CPC, and OLI, > - where/how they are provided and consumed in sip sessions > - how they are interworked with ISUP. > > 2. A document specifying how these parameters are to be transported > within sip messages. This document will define extensions to > SIP and/or TEL URI syntax as needed to accomplish this. > > Thanks, > Paul > > Patel, Milan wrote: >> Hello, >> >> Attached is a charter proposal for a WG to be formed for work > pertaining >> to extensions to the tel URI - specifically, parameters for carrying > the >> DAI, CPC, OLI and RN required for primarily interworking scenarios to >> ISUP/PSTN. >> >> Feedback is appreciated. >> >> Regards, >> >> Milan >> > ------------------------------------------------------------------------ >> *From:* Patel, Milan >> *Sent:* Tuesday, May 25, 2010 11:16 AM >> *To:* Cullen Jennings; 'mary.ietf.barnes@gmail.com'; Robert Sparks; >> 'Gonzalo Camarillo' >> *Cc:* R.Jesske@telekom.de; 'Sumanth Channabasappa' >> *Subject:* Charter proposal >> >> >> >> Hi all, >> >> >> >> Attached is a charter proposal for a WG to be formed to handle > Internet >> Drafts pertaining to the Tel URI. Specifically these are the DAI draft > >> and the CPC/OLI draft and some further work on the RN parameter. >> >> Feedback is welcome. >> >> >> >> Kind regards, >> >> Milan >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From dworley@avaya.com Fri May 28 09:58:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2483A6832 for ; Fri, 28 May 2010 09:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmapUgYWFlTj for ; Fri, 28 May 2010 09:58:29 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 421AD3A6852 for ; Fri, 28 May 2010 09:58:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,319,1272859200"; d="scan'208";a="18127186" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 28 May 2010 12:58:18 -0400 X-IronPort-AV: E=Sophos;i="4.53,319,1272859200"; d="scan'208";a="467527893" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 May 2010 12:57:39 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 28 May 2010 12:57:38 -0400 From: "WORLEY, Dale R (Dale)" To: Paul Kyzivat , "Patel, Milan" Date: Fri, 28 May 2010 12:55:29 -0400 Thread-Topic: [dispatch] Charter proposal for drafts related to the tel URI Thread-Index: Acr+bb4WC99ZYaI+SrKjhn1lTIubfQAGNW5K Message-ID: References: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com>, <4BFFCBC7.3070506@cisco.com> In-Reply-To: <4BFFCBC7.3070506@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 16:58:30 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat [pkyzivat@cisco.com] > [The proposed charter] presumes that this information should be conveyed = by encoding it > within a tel URI (or presumably in a sip URI using telephone-subscriber > syntax.) _______________________________________________ I most vigorously second Paul's objection. Let me add that the fact that 3GPP has done similar things in the past is n= ot exactly evidence that it is the architecturally-sound solution to the pr= oblem. dale From jgunn6@csc.com Fri May 28 11:28:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711473A6407; Fri, 28 May 2010 11:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9aAYiVd1s6L; Fri, 28 May 2010 11:28:47 -0700 (PDT) Received: from mail130.messagelabs.com (mail130.messagelabs.com [216.82.250.163]) by core3.amsl.com (Postfix) with ESMTP id 1A2023A6805; Fri, 28 May 2010 11:28:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-130.messagelabs.com!1275071315!37749339!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 22432 invoked from network); 28 May 2010 18:28:36 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-10.tower-130.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 May 2010 18:28:36 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id o4SISYIo010425; Fri, 28 May 2010 14:28:34 -0400 In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com> References: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com> To: "Patel, Milan" MIME-Version: 1.0 X-KeepSent: 0770ACC1:58DCD557-85257731:00653D21; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Fri, 28 May 2010 14:28:30 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 05/28/2010 02:29:07 PM, Serialize complete at 05/28/2010 02:29:07 PM Content-Type: multipart/alternative; boundary="=_alternative 00657DF385257731_=" Cc: dispatch-bounces@ietf.org, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 18:28:48 -0000 This is a multipart message in MIME format. --=_alternative 00657DF385257731_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SXMgdGhlIHNjb3BlIG9mIHRoaXMgd29ya2luZyBncm91cCBzdXBwb3NlZCB0byBiZSDigJxOb3J0 aCBBbWVyaWNhbuKAnSBvciANCuKAnFdvcmxkd2lkZeKAnT8gIEJlY2F1c2UgdGhlcmUgYXJlIG1h bnkgbmF0aW9uYWwg4oCcZmxhdm9yc+KAnSBvZiBJU1VQLCB0aGVyZSBhcmUgDQptYW55IGRpZmZl cmVudCBmbGF2b3JzIG9mIENQQy4gIEkgdGhpbmsgdGhhdCDigJxFcXVhbCBBY2Nlc3PigJ0gaXMg Tm9ydGggDQpBbWVyaWNhIHNwZWNpZmljLiAgQW5kIGV2ZW4gd2l0aGluIE5vcnRoIEFtZXJpY2Es IGl0IGRvZXMgbm90IGFwcGVhciB0byANCmFwcGx5IHRvIG1vYmlsZS9jZWxsIHBob25lcy4gIFRo ZSB3b3JraW5nIGdyb3VwIG5lZWRzIHRvIGRlZmluZSBpdHMgDQpnZW9ncmFwaGljYWwvanVyaXNk aWN0aW9uYWwgIHNjb3BlLCBhbmQgYWRkcmVzcyB3YXlzIHRvIGRlYWwgd2l0aCB0aGUgDQpkaWZm ZXJlbmNlcyBiZXR3ZWVuIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBJU1VQLg0KRnVydGhlcm1vcmUs IHNvbWUgQ1BDIHZhbHVlcyBhcmUgYWxyZWFkeSBiZWluZyB0cmFuc2xhdGVkL21hcHBlZCBpbnRv IA0Kc3BlY2lmaWMgU0lQIGhlYWRlcnMgKGUuZy4sIFJQSCAoUkZDNDQxMikpLiAgVGhlIHdvcmtp bmcgZ3JvdXAgbmVlZHMgdG8gDQphZGRyZXNzIHRoZSBjb29yZGluYXRpb24gYmV0d2VlbiBlbmNh cHN1bGF0aW5nIElTVVAsIG1hcHBpbmcgdG8gVVJJLCBhbmQgDQptYXBwaW5nIHRvIFNJUCBoZWFk ZXJzLCBlc3BlY2lhbGx5IG1hcHBpbmcgYmFjayB0byBDUEMgYXQgdGhlIOKAnG90aGVyIGVuZOKA nS4NCiBJcyDigJxSTuKAnSBpbiBzY29wZSBvciBub3Q/ICBJdCBpcyBsaXN0ZWQgaW4gdGhlIG9i amVjdGl2ZXMsIGJ1dCBub3QgaW4gdGhlIA0KZGVsaXZlcmFibGVzLg0KVGhpcyBpcyBhdCBsZWFz dCB0aGUgdGhpcmQgdGltZSBpbiBhIGRlY2FkZSB0aGF0IENQQyBoYXMgYmVlbiBhZGRyZXNzZWQg aW4gDQp0aGUgU0lQIGNvbnRleHQuIEVhY2ggb2YgdGhlIHByZXZpb3VzIHRpbWVzIGl0IGRpZG7i gJl0IGdvIHZlcnkgZmFyLiAgSSBhbSANCmN1cmlvdXMgd2hhdCBoYXMgY2hhbmdlZCB0byBtYWtl IGl0IHZpYWJsZSBub3cuIA0KTml0cw0KNXRoIHBhcmENCuKAnFRoZSAiY2ljIiBwYXJhbWV0ZXIg ZGVmaW5lZCBpbiBpZGVudGlmaWVzIHRoZSBmcmVlcGhvbmUgc2VydmljZSBwcm92aWRlciANCnRo YXQgc2VydmVzIHRoZSBmcmVlcGhvbmUgbnVtYmVyLiDigJwgRGVmaW5lZCBpbiBXSEFUPw0KNnRo IHBhcmENCuKAnFRoZSBSTiBwYXJhbWV0ZXIgaXMgdXNlZCBmb3IgY2FzZXMgd2hlcmUgc3BlY2lm aWMgcHJlZml4ZXMgYXJlIHVzZWQgdG8gDQpyb3V0IHRoZSBjYWxsIHRocm91Z2ggdGhlIG5ldHdv cmsu4oCdIFNob3VsZCBiZSDigKbigJ1yb3V0ZSB0aGUgY2FsbOKAnQ0KSmFuZXQNCg0KVGhpcyBp cyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIA0KZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBi eSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gDQpkZWxpdmVyeS4gDQpOT1RFOiBSZWdhcmRsZXNz IG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRlIHRvIGJpbmQgQ1NDIHRv IA0KYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNp dCB3cml0dGVuIGFncmVlbWVudCANCm9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkg cGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbCBmb3Igc3VjaCANCnB1cnBvc2UuDQoNCg0KDQpG cm9tOg0KIlBhdGVsLCBNaWxhbiIgPE1pbGFuLlBhdGVsQEludGVyRGlnaXRhbC5jb20+DQpUbzoN CjxkaXNwYXRjaEBpZXRmLm9yZz4sIDxtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbT4sICJDdWxs ZW4gSmVubmluZ3MiIA0KPGZsdWZmeUBjaXNjby5jb20+DQpEYXRlOg0KMDUvMjgvMjAxMCAwOTox MyBBTQ0KU3ViamVjdDoNCltkaXNwYXRjaF0gQ2hhcnRlciBwcm9wb3NhbCBmb3IgZHJhZnRzIHJl bGF0ZWQgdG8gdGhlIHRlbCBVUkkNCg0KDQoNCkhlbGxvLA0KIA0KQXR0YWNoZWQgaXMgYSBjaGFy dGVyIHByb3Bvc2FsIGZvciBhIFdHIHRvIGJlIGZvcm1lZCBmb3Igd29yayBwZXJ0YWluaW5nIA0K dG8gZXh0ZW5zaW9ucyB0byB0aGUgdGVsIFVSSSDigJMgc3BlY2lmaWNhbGx5LCBwYXJhbWV0ZXJz IGZvciBjYXJyeWluZyB0aGUgDQpEQUksIENQQywgT0xJIGFuZCBSTiByZXF1aXJlZCBmb3IgcHJp bWFyaWx5IGludGVyd29ya2luZyBzY2VuYXJpb3MgdG8gDQpJU1VQL1BTVE4uIA0KRmVlZGJhY2sg aXMgYXBwcmVjaWF0ZWQuIA0KUmVnYXJkcywNCk1pbGFuDQogDQogDQoNCkZyb206IFBhdGVsLCBN aWxhbiANClNlbnQ6IFR1ZXNkYXksIE1heSAyNSwgMjAxMCAxMToxNiBBTQ0KVG86IEN1bGxlbiBK ZW5uaW5nczsgJ21hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tJzsgUm9iZXJ0IFNwYXJrczsgJ0dv bnphbG8gDQpDYW1hcmlsbG8nDQpDYzogUi5KZXNza2VAdGVsZWtvbS5kZTsgJ1N1bWFudGggQ2hh bm5hYmFzYXBwYScNClN1YmplY3Q6IENoYXJ0ZXIgcHJvcG9zYWwNCiANCkhpIGFsbCwNCiANCkF0 dGFjaGVkIGlzIGEgY2hhcnRlciBwcm9wb3NhbCBmb3IgYSBXRyB0byBiZSBmb3JtZWQgdG8gaGFu ZGxlIEludGVybmV0IA0KRHJhZnRzIHBlcnRhaW5pbmcgdG8gdGhlIFRlbCBVUkkuIFNwZWNpZmlj YWxseSB0aGVzZSBhcmUgdGhlIERBSSBkcmFmdCBhbmQgDQp0aGUgQ1BDL09MSSBkcmFmdCBhbmQg c29tZSBmdXJ0aGVyIHdvcmsgb24gdGhlIFJOIHBhcmFtZXRlci4gDQpGZWVkYmFjayBpcyB3ZWxj b21lLiANCiANCktpbmQgcmVnYXJkcywNCk1pbGFuW2F0dGFjaG1lbnQgIlhYWFggV0cgY2hhcnRl ciBwcm9wb3NhbC50eHQiIGRlbGV0ZWQgYnkgSmFuZXQgUCANCkd1bm4vVVNBL0NTQ10gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNoIG1haWxp bmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGlzcGF0Y2gNCg0KDQoNCg== --=_alternative 00657DF385257731_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklzIHRoZSBzY29wZSBvZiB0aGlz IHdvcmtpbmcgZ3JvdXAgc3VwcG9zZWQNCnRvIGJlIOKAnE5vcnRoIEFtZXJpY2Fu4oCdIG9yIOKA nFdvcmxkd2lkZeKAnT8gJm5ic3A7QmVjYXVzZSB0aGVyZSBhcmUgbWFueQ0KbmF0aW9uYWwg4oCc Zmxhdm9yc+KAnSBvZiBJU1VQLCB0aGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgZmxhdm9ycyBvZiBD UEMuDQombmJzcDtJIHRoaW5rIHRoYXQg4oCcRXF1YWwgQWNjZXNz4oCdIGlzIE5vcnRoIEFtZXJp Y2Egc3BlY2lmaWMuICZuYnNwO0FuZA0KZXZlbiB3aXRoaW4gTm9ydGggQW1lcmljYSwgaXQgZG9l cyBub3QgYXBwZWFyIHRvIGFwcGx5IHRvIG1vYmlsZS9jZWxsIHBob25lcy4NCiZuYnNwO1RoZSB3 b3JraW5nIGdyb3VwIG5lZWRzIHRvIGRlZmluZSBpdHMgZ2VvZ3JhcGhpY2FsL2p1cmlzZGljdGlv bmFsDQombmJzcDtzY29wZSwgYW5kIGFkZHJlc3Mgd2F5cyB0byBkZWFsIHdpdGggdGhlIGRpZmZl cmVuY2VzIGJldHdlZW4gZGlmZmVyZW50DQp2ZXJzaW9ucyBvZiBJU1VQLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RnVydGhlcm1vcmUsIHNvbWUgQ1BDIHZhbHVl cyBhcmUgYWxyZWFkeQ0KYmVpbmcgdHJhbnNsYXRlZC9tYXBwZWQgaW50byBzcGVjaWZpYyBTSVAg aGVhZGVycyAoZS5nLiwgUlBIIChSRkM0NDEyKSkuDQombmJzcDtUaGUgd29ya2luZyBncm91cCBu ZWVkcyB0byBhZGRyZXNzIHRoZSBjb29yZGluYXRpb24gYmV0d2VlbiBlbmNhcHN1bGF0aW5nDQpJ U1VQLCBtYXBwaW5nIHRvIFVSSSwgYW5kIG1hcHBpbmcgdG8gU0lQIGhlYWRlcnMsIGVzcGVjaWFs bHkgbWFwcGluZyBiYWNrDQp0byBDUEMgYXQgdGhlIOKAnG90aGVyIGVuZOKAnS48L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7SXMg4oCcUk7igJ0gaW4gc2Nv cGUgb3Igbm90PyAmbmJzcDtJdA0KaXMgbGlzdGVkIGluIHRoZSBvYmplY3RpdmVzLCBidXQgbm90 IGluIHRoZSBkZWxpdmVyYWJsZXMuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPlRoaXMgaXMgYXQgbGVhc3QgdGhlIHRoaXJkIHRpbWUgaW4gYQ0KZGVjYWRlIHRoYXQg Q1BDIGhhcyBiZWVuIGFkZHJlc3NlZCBpbiB0aGUgU0lQIGNvbnRleHQuIEVhY2ggb2YgdGhlIHBy ZXZpb3VzDQp0aW1lcyBpdCBkaWRu4oCZdCBnbyB2ZXJ5IGZhci4gJm5ic3A7SSBhbSBjdXJpb3Vz IHdoYXQgaGFzIGNoYW5nZWQgdG8gbWFrZQ0KaXQgdmlhYmxlIG5vdy4gPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk5pdHM8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+NTxzdXA+dGg8L3N1cD4gcGFyYTwvZm9udD4NCjxwPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj7igJxUaGUgJnF1b3Q7Y2ljJnF1b3Q7IHBhcmFtZXRlciBk ZWZpbmVkDQppbiBpZGVudGlmaWVzIHRoZSBmcmVlcGhvbmUgc2VydmljZSBwcm92aWRlciB0aGF0 IHNlcnZlcyB0aGUgZnJlZXBob25lDQpudW1iZXIuIOKAnCBEZWZpbmVkIGluIFdIQVQ/PC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjY8c3VwPnRoPC9zdXA+IHBhcmE8 L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+4oCcVGhlIFJOIHBhcmFt ZXRlciBpcyB1c2VkIGZvciBjYXNlcw0Kd2hlcmUgc3BlY2lmaWMgcHJlZml4ZXMgYXJlIHVzZWQg dG8gcm91dCB0aGUgY2FsbCB0aHJvdWdoIHRoZSBuZXR3b3JrLuKAnQ0KU2hvdWxkIGJlIOKApuKA nXJvdXRlIHRoZSBjYWxs4oCdPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkphbmV0PGJyPg0KPGJyPg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlDQpkZWxldGUgd2l0aG91dCBjb3B5 aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbg0KZGVs aXZlcnkuIDxicj4NCk5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hh bGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MNCnRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFj dCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQNCm9yIGdvdmVy bm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbCBm b3Igc3VjaA0KcHVycG9zZS48L2ZvbnQ+DQo8cD4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFj ZT0ic2Fucy1zZXJpZiI+RnJvbTo8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPiZxdW90O1BhdGVsLCBNaWxhbiZxdW90OyAmbHQ7TWlsYW4uUGF0ZWxASW50ZXJEaWdp dGFsLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD48Zm9udCBzaXplPTEgY29s b3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5Ubzo8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPiZsdDtkaXNwYXRjaEBpZXRmLm9yZyZndDssICZsdDttYXJ5Lmll dGYuYmFybmVzQGdtYWlsLmNvbSZndDssDQomcXVvdDtDdWxsZW4gSmVubmluZ3MmcXVvdDsgJmx0 O2ZsdWZmeUBjaXNjby5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQg c2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RGF0ZTo8L2ZvbnQ+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjA1LzI4LzIwMTAgMDk6MTMgQU08L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJz YW5zLXNlcmlmIj5TdWJqZWN0OjwvZm9udD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+W2Rpc3BhdGNoXSBDaGFydGVyIHByb3Bvc2FsIGZvciBkcmFmdHMNCnJlbGF0ZWQgdG8g dGhlIHRlbCBVUkk8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj5IZWxsbyw8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+QXR0YWNo ZWQgaXMgYSBjaGFydGVyIHByb3Bvc2FsDQpmb3IgYSBXRyB0byBiZSBmb3JtZWQgZm9yIHdvcmsg cGVydGFpbmluZyB0byBleHRlbnNpb25zIHRvIHRoZSB0ZWwgVVJJDQrigJMgc3BlY2lmaWNhbGx5 LCBwYXJhbWV0ZXJzIGZvciBjYXJyeWluZyB0aGUgREFJLCBDUEMsIE9MSSBhbmQgUk4gcmVxdWly ZWQNCmZvciBwcmltYXJpbHkgaW50ZXJ3b3JraW5nIHNjZW5hcmlvcyB0byBJU1VQL1BTVE4uIDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+RmVlZGJh Y2sgaXMgYXBwcmVjaWF0ZWQuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4 MCBmYWNlPSJBcmlhbCI+UmVnYXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMw MDAwODAgZmFjZT0iQXJpYWwiPk1pbGFuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxkaXYgYWxpZ249Y2VudGVyPg0K PGJyPg0KPGhyPjwvZGl2Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206 PC9iPiBQYXRlbCwgTWlsYW4gPGI+PGJyPg0KU2VudDo8L2I+IFR1ZXNkYXksIE1heSAyNSwgMjAx MCAxMToxNiBBTTxiPjxicj4NClRvOjwvYj4gQ3VsbGVuIEplbm5pbmdzOyAnbWFyeS5pZXRmLmJh cm5lc0BnbWFpbC5jb20nOyBSb2JlcnQgU3BhcmtzOyAnR29uemFsbw0KQ2FtYXJpbGxvJzxiPjxi cj4NCkNjOjwvYj4gUi5KZXNza2VAdGVsZWtvbS5kZTsgJ1N1bWFudGggQ2hhbm5hYmFzYXBwYSc8 Yj48YnI+DQpTdWJqZWN0OjwvYj4gQ2hhcnRlciBwcm9wb3NhbDwvZm9udD4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj5IaSBhbGwsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+QXR0YWNo ZWQgaXMgYSBjaGFydGVyIHByb3Bvc2FsIGZvciBhIFdHIHRvDQpiZSBmb3JtZWQgdG8gaGFuZGxl IEludGVybmV0IERyYWZ0cyBwZXJ0YWluaW5nIHRvIHRoZSBUZWwgVVJJLiBTcGVjaWZpY2FsbHkN CnRoZXNlIGFyZSB0aGUgREFJIGRyYWZ0IGFuZCB0aGUgQ1BDL09MSSBkcmFmdCBhbmQgc29tZSBm dXJ0aGVyIHdvcmsgb24NCnRoZSBSTiBwYXJhbWV0ZXIuIDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPkZlZWRiYWNrIGlzIHdlbGNvbWUuIDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPktpbmQgcmVnYXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij5NaWxhblthdHRhY2htZW50ICZxdW90O1hYWFggV0cgY2hhcnRlciBwcm9wb3NhbC50eHQmcXVv dDsNCmRlbGV0ZWQgYnkgSmFuZXQgUCBHdW5uL1VTQS9DU0NdIDwvZm9udD48dHQ+PGZvbnQgc2l6 ZT0yPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K ZGlzcGF0Y2ggbWFpbGluZyBsaXN0PGJyPg0KZGlzcGF0Y2hAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+ PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0 Y2g+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Rpc3BhdGNoPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250Pjwv dHQ+DQo8YnI+DQo8YnI+DQo= --=_alternative 00657DF385257731_=-- From richard@shockey.us Fri May 28 12:01:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E40A3A6806 for ; Fri, 28 May 2010 12:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.168 X-Spam-Level: X-Spam-Status: No, score=0.168 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfmgAI5lIZHA for ; Fri, 28 May 2010 12:01:22 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 61A1C3A681F for ; Fri, 28 May 2010 12:01:22 -0700 (PDT) Received: (qmail 17378 invoked by uid 0); 28 May 2010 19:01:12 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 28 May 2010 19:01:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=kDnUcIYUqUX4cLT7DZZd1v+4V9JpnGyvmWDmE2zL7gCuAMpIdanQ868YUuOCRmRihKXyvUQGOpLyvreBzFIa1VNcbynmj6PWFcl/AEYaKNszL+SkHF+DO4TcPPRvf1xj; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OI4nw-0006Yn-6d; Fri, 28 May 2010 13:01:12 -0600 From: "Richard Shockey" To: "'WORLEY, Dale R \(Dale\)'" , "'Paul Kyzivat'" , "'Patel, Milan'" References: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com>, <4BFFCBC7.3070506@cisco.com> In-Reply-To: Date: Fri, 28 May 2010 15:01:04 -0400 Message-ID: <006d01cafe98$1fc94a50$5f5bdef0$@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: Acr+bb4WC99ZYaI+SrKjhn1lTIubfQAGNW5KAAROPeA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 19:01:23 -0000 Though the larger issue of how to carry these types of messages or metadata (CNAM,CIC,SPID) in SIP has not been fully addressed either. Needless to say we have had a vigorous discussion over this ongoing issue in both DRINKS and the E2MD BOF ( NGN ENUM ) list. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of WORLEY, Dale R (Dale) Sent: Friday, May 28, 2010 12:55 PM To: Paul Kyzivat; Patel, Milan Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > [The proposed charter] presumes that this information should be conveyed by encoding it > within a tel URI (or presumably in a sip URI using telephone-subscriber > syntax.) _______________________________________________ I most vigorously second Paul's objection. Let me add that the fact that 3GPP has done similar things in the past is not exactly evidence that it is the architecturally-sound solution to the problem. dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From jgunn6@csc.com Fri May 28 12:48:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB983A681F; Fri, 28 May 2010 12:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajFsg0EVODgk; Fri, 28 May 2010 12:48:55 -0700 (PDT) Received: from mail130.messagelabs.com (mail130.messagelabs.com [216.82.250.163]) by core3.amsl.com (Postfix) with ESMTP id D423E3A6806; Fri, 28 May 2010 12:48:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-9.tower-130.messagelabs.com!1275076123!13755196!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 17062 invoked from network); 28 May 2010 19:48:44 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-9.tower-130.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 May 2010 19:48:44 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id o4SJmhmg018988; Fri, 28 May 2010 15:48:43 -0400 In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com> References: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com> To: "Patel, Milan" MIME-Version: 1.0 X-KeepSent: 99FCAB45:F72B3EDA-85257731:006CAA3A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Fri, 28 May 2010 15:48:39 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 05/28/2010 03:49:16 PM, Serialize complete at 05/28/2010 03:49:16 PM Content-Type: multipart/alternative; boundary="=_alternative 006CD43A85257731_=" Cc: dispatch-bounces@ietf.org, dispatch@ietf.org Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 19:48:56 -0000 This is a multipart message in MIME format. --=_alternative 006CD43A85257731_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SXMgdGhlIHNjb3BlIG9mIHRoaXMgd29ya2luZyBncm91cCBzdXBwb3NlZCB0byBiZSDigJxOb3J0 aCBBbWVyaWNhbuKAnSBvciANCuKAnFdvcmxkd2lkZeKAnT8gIEJlY2F1c2UgdGhlcmUgYXJlIG1h bnkgbmF0aW9uYWwg4oCcZmxhdm9yc+KAnSBvZiBJU1VQLCB0aGVyZSBhcmUgDQptYW55IGRpZmZl cmVudCBmbGF2b3JzIG9mIENQQy4gIEkgdGhpbmsgdGhhdCDigJxFcXVhbCBBY2Nlc3PigJ0gaXMg Tm9ydGggDQpBbWVyaWNhIHNwZWNpZmljLiAgQW5kIGV2ZW4gd2l0aGluIE5vcnRoIEFtZXJpY2Es IGl0IGRvZXMgbm90IGFwcGVhciB0byANCmFwcGx5IHRvIG1vYmlsZS9jZWxsIHBob25lcy4gIFRo ZSB3b3JraW5nIGdyb3VwIG5lZWRzIHRvIGRlZmluZSBpdHMgDQpnZW9ncmFwaGljYWwvanVyaXNk aWN0aW9uYWwgIHNjb3BlLCBhbmQgYWRkcmVzcyB3YXlzIHRvIGRlYWwgd2l0aCB0aGUgDQpkaWZm ZXJlbmNlcyBiZXR3ZWVuIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBJU1VQLg0KDQpGdXJ0aGVybW9y ZSwgc29tZSBDUEMgdmFsdWVzIGFyZSBhbHJlYWR5IGJlaW5nIHRyYW5zbGF0ZWQvbWFwcGVkIGlu dG8gDQpzcGVjaWZpYyBTSVAgaGVhZGVycyAoZS5nLiwgUlBIIChSRkM0NDEyKSkuICBUaGUgd29y a2luZyBncm91cCBuZWVkcyB0byANCmFkZHJlc3MgdGhlIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIGVu Y2Fwc3VsYXRpbmcgSVNVUCwgbWFwcGluZyB0byBVUkksIGFuZCANCm1hcHBpbmcgdG8gU0lQIGhl YWRlcnMsIGVzcGVjaWFsbHkgbWFwcGluZyBiYWNrIHRvIENQQyBhdCB0aGUg4oCcb3RoZXIgZW5k 4oCdLg0KDQogSXMg4oCcUk7igJ0gaW4gc2NvcGUgb3Igbm90PyAgSXQgaXMgbGlzdGVkIGluIHRo ZSBvYmplY3RpdmVzLCBidXQgbm90IGluIHRoZSANCmRlbGl2ZXJhYmxlcy4NCg0KVGhpcyBpcyBh dCBsZWFzdCB0aGUgdGhpcmQgdGltZSBpbiBhIGRlY2FkZSB0aGF0IENQQyBoYXMgYmVlbiBhZGRy ZXNzZWQgaW4gDQp0aGUgU0lQIGNvbnRleHQuIEVhY2ggb2YgdGhlIHByZXZpb3VzIHRpbWVzIGl0 IGRpZG7igJl0IGdvIHZlcnkgZmFyLiAgSSBhbSANCmN1cmlvdXMgd2hhdCBoYXMgY2hhbmdlZCB0 byBtYWtlIGl0IHZpYWJsZSBub3cgDQoNCk5pdHMNCg0KNXRoIHBhcmENCuKAnFRoZSAiY2ljIiBw YXJhbWV0ZXIgZGVmaW5lZCBpbiBpZGVudGlmaWVzIHRoZSBmcmVlcGhvbmUgc2VydmljZSBwcm92 aWRlciANCnRoYXQgc2VydmVzIHRoZSBmcmVlcGhvbmUgbnVtYmVyLiDigJwgRGVmaW5lZCBpbiBX SEFUPw0KDQo2dGggcGFyYQ0K4oCcVGhlIFJOIHBhcmFtZXRlciBpcyB1c2VkIGZvciBjYXNlcyB3 aGVyZSBzcGVjaWZpYyBwcmVmaXhlcyBhcmUgdXNlZCB0byANCnJvdXQgdGhlIGNhbGwgdGhyb3Vn aCB0aGUgbmV0d29yay7igJ0gU2hvdWxkIGJlIOKApuKAnXJvdXRlIHRoZSBjYWxs4oCdDQoNCkph bmV0DQoNCmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGUgb24gMDUvMjgvMjAxMCAwOTox MzowNSBBTToNCg0KPiBbaW1hZ2UgcmVtb3ZlZF0gDQo+IA0KPiBbZGlzcGF0Y2hdIENoYXJ0ZXIg cHJvcG9zYWwgZm9yIGRyYWZ0cyByZWxhdGVkIHRvIHRoZSB0ZWwgVVJJDQo+IA0KPiBQYXRlbCwg TWlsYW4gDQo+IA0KPiB0bzoNCj4gDQo+IGRpc3BhdGNoLCBtYXJ5LmlldGYuYmFybmVzLCBDdWxs ZW4gSmVubmluZ3MNCj4gDQo+IDA1LzI4LzIwMTAgMDk6MTMgQU0NCj4gDQo+IFNlbnQgYnk6DQo+ IA0KPiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnDQo+IA0KPiBIZWxsbywNCj4gDQo+IEF0dGFj aGVkIGlzIGEgY2hhcnRlciBwcm9wb3NhbCBmb3IgYSBXRyB0byBiZSBmb3JtZWQgZm9yIHdvcmsg DQo+IHBlcnRhaW5pbmcgdG8gZXh0ZW5zaW9ucyB0byB0aGUgdGVsIFVSSSDigJMgc3BlY2lmaWNh bGx5LCBwYXJhbWV0ZXJzIA0KPiBmb3IgY2FycnlpbmcgdGhlIERBSSwgQ1BDLCBPTEkgYW5kIFJO IHJlcXVpcmVkIGZvciBwcmltYXJpbHkgDQo+IGludGVyd29ya2luZyBzY2VuYXJpb3MgdG8gSVNV UC9QU1ROLiANCj4gRmVlZGJhY2sgaXMgYXBwcmVjaWF0ZWQuIA0KPiBSZWdhcmRzLA0KPiBNaWxh bg0KPiANCj4gDQo+IA0KPiBGcm9tOiBQYXRlbCwgTWlsYW4gDQo+IFNlbnQ6IFR1ZXNkYXksIE1h eSAyNSwgMjAxMCAxMToxNiBBTQ0KPiBUbzogQ3VsbGVuIEplbm5pbmdzOyAnbWFyeS5pZXRmLmJh cm5lc0BnbWFpbC5jb20nOyBSb2JlcnQgU3BhcmtzOyANCj4gJ0dvbnphbG8gQ2FtYXJpbGxvJw0K PiBDYzogUi5KZXNza2VAdGVsZWtvbS5kZTsgJ1N1bWFudGggQ2hhbm5hYmFzYXBwYScNCj4gU3Vi amVjdDogQ2hhcnRlciBwcm9wb3NhbA0KPiANCj4gSGkgYWxsLA0KPiANCj4gQXR0YWNoZWQgaXMg YSBjaGFydGVyIHByb3Bvc2FsIGZvciBhIFdHIHRvIGJlIGZvcm1lZCB0byBoYW5kbGUgDQo+IElu dGVybmV0IERyYWZ0cyBwZXJ0YWluaW5nIHRvIHRoZSBUZWwgVVJJLiBTcGVjaWZpY2FsbHkgdGhl c2UgYXJlIA0KPiB0aGUgREFJIGRyYWZ0IGFuZCB0aGUgQ1BDL09MSSBkcmFmdCBhbmQgc29tZSBm dXJ0aGVyIHdvcmsgb24gdGhlIFJOIA0KPiBwYXJhbWV0ZXIuIA0KPiBGZWVkYmFjayBpcyB3ZWxj b21lLiANCj4gDQo+IEtpbmQgcmVnYXJkcywNCj4gTWlsYW5bYXR0YWNobWVudCAiWFhYWCBXRyBj aGFydGVyIHByb3Bvc2FsLnR4dCIgZGVsZXRlZCBieSBKYW5ldCBQIA0KPiBHdW5uL1VTQS9DU0Nd IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRpc3Bh dGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQoNCg== --=_alternative 006CD43A85257731_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8cD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SXMgdGhlIHNjb3BlIG9mIHRoaXMg d29ya2luZyBncm91cCBzdXBwb3NlZA0KdG8gYmUg4oCcTm9ydGggQW1lcmljYW7igJ0gb3Ig4oCc V29ybGR3aWRl4oCdPyAmbmJzcDtCZWNhdXNlIHRoZXJlIGFyZSBtYW55DQpuYXRpb25hbCDigJxm bGF2b3Jz4oCdIG9mIElTVVAsIHRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCBmbGF2b3JzIG9mIENQ Qy4NCiZuYnNwO0kgdGhpbmsgdGhhdCDigJxFcXVhbCBBY2Nlc3PigJ0gaXMgTm9ydGggQW1lcmlj YSBzcGVjaWZpYy4gJm5ic3A7QW5kDQpldmVuIHdpdGhpbiBOb3J0aCBBbWVyaWNhLCBpdCBkb2Vz IG5vdCBhcHBlYXIgdG8gYXBwbHkgdG8gbW9iaWxlL2NlbGwgcGhvbmVzLg0KJm5ic3A7VGhlIHdv cmtpbmcgZ3JvdXAgbmVlZHMgdG8gZGVmaW5lIGl0cyBnZW9ncmFwaGljYWwvanVyaXNkaWN0aW9u YWwNCiZuYnNwO3Njb3BlLCBhbmQgYWRkcmVzcyB3YXlzIHRvIGRlYWwgd2l0aCB0aGUgZGlmZmVy ZW5jZXMgYmV0d2VlbiBkaWZmZXJlbnQNCnZlcnNpb25zIG9mIElTVVAuPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GdXJ0aGVybW9yZSwgc29tZSBDUEMg dmFsdWVzIGFyZSBhbHJlYWR5DQpiZWluZyB0cmFuc2xhdGVkL21hcHBlZCBpbnRvIHNwZWNpZmlj IFNJUCBoZWFkZXJzIChlLmcuLCBSUEggKFJGQzQ0MTIpKS4NCiZuYnNwO1RoZSB3b3JraW5nIGdy b3VwIG5lZWRzIHRvIGFkZHJlc3MgdGhlIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIGVuY2Fwc3VsYXRp bmcNCklTVVAsIG1hcHBpbmcgdG8gVVJJLCBhbmQgbWFwcGluZyB0byBTSVAgaGVhZGVycywgZXNw ZWNpYWxseSBtYXBwaW5nIGJhY2sNCnRvIENQQyBhdCB0aGUg4oCcb3RoZXIgZW5k4oCdLjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7SXMg4oCc Uk7igJ0gaW4gc2NvcGUgb3Igbm90PyAmbmJzcDtJdA0KaXMgbGlzdGVkIGluIHRoZSBvYmplY3Rp dmVzLCBidXQgbm90IGluIHRoZSBkZWxpdmVyYWJsZXMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGlzIGlzIGF0IGxlYXN0IHRoZSB0aGlyZCB0aW1l IGluIGENCmRlY2FkZSB0aGF0IENQQyBoYXMgYmVlbiBhZGRyZXNzZWQgaW4gdGhlIFNJUCBjb250 ZXh0LiBFYWNoIG9mIHRoZSBwcmV2aW91cw0KdGltZXMgaXQgZGlkbuKAmXQgZ28gdmVyeSBmYXIu ICZuYnNwO0kgYW0gY3VyaW91cyB3aGF0IGhhcyBjaGFuZ2VkIHRvIG1ha2UNCml0IHZpYWJsZSBu b3cgPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5OaXRz PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj41dGggcGFy YTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+4oCcVGhlICZxdW90 O2NpYyZxdW90OyBwYXJhbWV0ZXIgZGVmaW5lZA0KaW4gaWRlbnRpZmllcyB0aGUgZnJlZXBob25l IHNlcnZpY2UgcHJvdmlkZXIgdGhhdCBzZXJ2ZXMgdGhlIGZyZWVwaG9uZQ0KbnVtYmVyLiDigJwg RGVmaW5lZCBpbiBXSEFUPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+NnRoIHBhcmE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPuKAnFRoZSBSTiBwYXJhbWV0ZXIgaXMgdXNlZCBmb3IgY2FzZXMNCndoZXJlIHNwZWNpZmlj IHByZWZpeGVzIGFyZSB1c2VkIHRvIHJvdXQgdGhlIGNhbGwgdGhyb3VnaCB0aGUgbmV0d29yay7i gJ0NClNob3VsZCBiZSDigKbigJ1yb3V0ZSB0aGUgY2FsbOKAnTwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SmFuZXQ8YnI+DQo8L2ZvbnQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5kaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIHdyb3RlIG9uIDA1LzI4LzIw MTAgMDk6MTM6MDUNCkFNOjxicj4NCjxicj4NCiZndDsgW2ltYWdlIHJlbW92ZWRdIDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFtkaXNwYXRjaF0gQ2hh cnRlciBwcm9wb3NhbCBmb3IgZHJhZnRzIHJlbGF0ZWQgdG8gdGhlIHRlbCBVUkk8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBQYXRlbCwgTWlsYW4gPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgdG86PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgZGlzcGF0Y2gsIG1h cnkuaWV0Zi5iYXJuZXMsIEN1bGxlbiBKZW5uaW5nczwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDA1LzI4LzIwMTAgMDk6MTMgQU08L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBTZW50IGJ5OjwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IGRpc3BhdGNoLWJvdW5jZXNA aWV0Zi5vcmc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0 OyBIZWxsbyw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEF0dGFjaGVkIGlzIGEgY2hhcnRl ciBwcm9wb3NhbCBmb3IgYSBXRyB0byBiZQ0KZm9ybWVkIGZvciB3b3JrIDxicj4NCiZndDsgcGVy dGFpbmluZyB0byBleHRlbnNpb25zIHRvIHRoZSB0ZWwgVVJJIOKAkyBzcGVjaWZpY2FsbHksIHBh cmFtZXRlcnMNCjxicj4NCiZndDsgZm9yIGNhcnJ5aW5nIHRoZSBEQUksIENQQywgT0xJIGFuZCBS TiByZXF1aXJlZCBmb3IgcHJpbWFyaWx5IDxicj4NCiZndDsgaW50ZXJ3b3JraW5nIHNjZW5hcmlv cyB0byBJU1VQL1BTVE4uIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBG ZWVkYmFjayBpcyBhcHByZWNpYXRlZC4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IFJlZ2FyZHMsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE1p bGFuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBGcm9tOiBQYXRlbCwgTWlsYW4gPGJyPg0K Jmd0OyBTZW50OiBUdWVzZGF5LCBNYXkgMjUsIDIwMTAgMTE6MTYgQU08YnI+DQomZ3Q7IFRvOiBD dWxsZW4gSmVubmluZ3M7ICdtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbSc7IFJvYmVydCBTcGFy a3M7DQo8YnI+DQomZ3Q7ICdHb256YWxvIENhbWFyaWxsbyc8YnI+DQomZ3Q7IENjOiBSLkplc3Nr ZUB0ZWxla29tLmRlOyAnU3VtYW50aCBDaGFubmFiYXNhcHBhJzxicj4NCiZndDsgU3ViamVjdDog Q2hhcnRlciBwcm9wb3NhbDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm bmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSGkgYWxsLDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQXR0YWNoZWQgaXMgYSBjaGFydGVyIHByb3Bvc2FsIGZv ciBhIFdHIHRvIGJlDQpmb3JtZWQgdG8gaGFuZGxlIDxicj4NCiZndDsgSW50ZXJuZXQgRHJhZnRz IHBlcnRhaW5pbmcgdG8gdGhlIFRlbCBVUkkuIFNwZWNpZmljYWxseSB0aGVzZSBhcmUNCjxicj4N CiZndDsgdGhlIERBSSBkcmFmdCBhbmQgdGhlIENQQy9PTEkgZHJhZnQgYW5kIHNvbWUgZnVydGhl ciB3b3JrIG9uIHRoZSBSTg0KPGJyPg0KJmd0OyBwYXJhbWV0ZXIuIDwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGZWVkYmFjayBpcyB3ZWxjb21lLiA8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IEtpbmQgcmVnYXJkcyw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgTWlsYW5bYXR0YWNobWVudCAmcXVvdDtYWFhYIFdHIGNoYXJ0ZXIgcHJvcG9z YWwudHh0JnF1b3Q7DQpkZWxldGVkIGJ5IEphbmV0IFAgPGJyPg0KJmd0OyBHdW5uL1VTQS9DU0Nd IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyBkaXNwYXRjaCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IGRpc3BhdGNoQGlldGYub3JnPGJyPg0K Jmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGlzcGF0Y2g+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Rpc3BhdGNoPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJy Pg0KPC9mb250PjwvdHQ+DQo= --=_alternative 006CD43A85257731_=-- From thomas.belling@nsn.com Mon May 31 04:01:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA1B3A681D for ; Mon, 31 May 2010 04:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6-AFM2egGeZ for ; Mon, 31 May 2010 04:01:21 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id E04E93A6A31 for ; Mon, 31 May 2010 04:01:20 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o4VB14p3019750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 31 May 2010 13:01:05 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o4VB14s1000912; Mon, 31 May 2010 13:01:04 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 May 2010 13:01:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 May 2010 13:01:03 +0200 Message-ID: <744A66DF31B5B34EA8B08BBD8187A72201C76DA0@DEMUEXC014.nsn-intra.net> In-Reply-To: <4BFFF152.4060507@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposal for drafts related to the tel URI thread-index: Acr+hB0bKmLgOw2ITa+2luPNbVlW4QCK5jiA References: <61CAF342FE1EE34EAC8FB19B765914000E6FB138@SABRE.InterDigital.com> <4BFFF152.4060507@cisco.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Paul Kyzivat" , "Patel, Milan" X-OriginalArrivalTime: 31 May 2010 11:01:04.0165 (UTC) FILETIME=[9013C550:01CB00B0] Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 11:01:22 -0000 >> 3GPP have sent DISPATCH a liaison >> related to some of the comments that have been raised concerning the=20 >> use of a tel URI parameter for the CPC/OLI. >Can you tell me where to get a copy to read? http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_64_Kyoto/Docs/C 1-101810.zip