From gonzalo.camarillo@ericsson.com Tue Oct 1 01:59:46 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B047521F9BBD for ; Tue, 1 Oct 2013 01:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.734 X-Spam-Level: X-Spam-Status: No, score=-105.734 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s77+AEsiYVl for ; Tue, 1 Oct 2013 01:59:41 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BE7EE21F9BFA for ; Tue, 1 Oct 2013 01:59:35 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-0f-524a8ef6df97 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FB.87.03802.6FE8A425; Tue, 1 Oct 2013 10:59:34 +0200 (CEST) Received: from [147.214.22.70] (153.88.183.17) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.328.9; Tue, 1 Oct 2013 10:59:34 +0200 Message-ID: <524A8EF6.4030604@ericsson.com> Date: Tue, 1 Oct 2013 10:59:34 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <524A8EB1.5080009@ericsson.com> In-Reply-To: <524A8EB1.5080009@ericsson.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <524A8EB1.5080009@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3Vvdbn1eQwdEjNhZLJy1gdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsK+RvaCfq6K2/suMTcwzuLoYuTgkBAwkeicqdrFyAlkiklc uLeerYuRi0NI4DCjxK7lm9ghnJWMEscPLWYCqeIV0JbYNPkxC4jNIqAi0bXvFiuIzSZgIbHl 1n2wuKhAlMSG7RdYIOoFJU7OfAJmiwiISzR0v2MGsYUFrCUu/7nLCGILAc38fHYCG4jNKaAj Mev3L2aIiyQltrxoZ4ewzSXeN98Gq2EW0JOYcrWFEcKWl9j+dg4zzJzlz1pYJjAKzUKyehaS lllIWhYwMq9iZM9NzMxJLzfaxAgMy4NbfqvuYLxzTuQQozQHi5I474e3zkFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGBN+m83323FBylp53cfJ3t7Tn9Q8yQ1QDVV6ZV/S3yHZ+NS21KGc +7OrukmOyW47sZUajmtXx/0tXLphc8IejhtKgov6Mxy5fymIy68I3rGUOWlN1DwB6ccr/AU3 37YR+NJ3tvr6VL05mZkiM9555dTfn/NfIukT416ufzPLd+iGGOk93ZYwQ4mlOCPRUIu5qDgR AFC0sFMZAgAA Subject: [dispatch] Fwd: [RAI] RAI AD - Gonzalo will not be re-running X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 08:59:46 -0000 FYI. Gonzalo -------- Original Message -------- Subject: [RAI] RAI AD - Gonzalo will not be re-running Date: Tue, 1 Oct 2013 10:58:25 +0200 From: Gonzalo Camarillo To: Folks, this email is to inform everyone that I am not going to be seeking a third term as RAI Area Director. This means that the nomcom will need to choose someone else to serve as RAI AD after my current term ends in March. The consensus in the community seems to be that ADs SHOULD NOT serve more than 4 years, and I fully agree with that. Such a limit is good for the IETF and good for the ADs as well for a number of reasons. The main reason I am writing this email is to give potential candidates enough time to secure management support (or, in general, funding) in order to provide the nomcom with enough good candidates. You can find the expertise required for the position in the following link: https://datatracker.ietf.org/nomcom/2013/expertise/ Additionally, RAI ADs have traditionally selected the beverages for the IESG social gatherings, which is also an important skill ;-) Cheers, Gonzalo _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai From Peter.Dawes@vodafone.com Tue Oct 1 08:31:10 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248C521E80C7 for ; Tue, 1 Oct 2013 08:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5k4j0agtTxe for ; Tue, 1 Oct 2013 08:31:04 -0700 (PDT) Received: from mailout03.vodafone.com (mailout03.vodafone.com [195.232.224.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1D48F21E81BA for ; Tue, 1 Oct 2013 08:30:36 -0700 (PDT) Received: from mailint03.vodafone.com (localhost [127.0.0.1]) by mailout03.vodafone.com (Postfix) with ESMTP id 1A1CF1401D2 for ; Tue, 1 Oct 2013 17:30:34 +0200 (CEST) Received: from VOEXC03W.internal.vodafone.com (voexc03w.dc-ratingen.de [145.230.101.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint03.vodafone.com (Postfix) with ESMTPS id 061DE1401B4; Tue, 1 Oct 2013 17:30:34 +0200 (CEST) Received: from VOEXC17W.internal.vodafone.com (145.230.101.19) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.146.2; Tue, 1 Oct 2013 17:30:33 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.164]) by voexc17w.internal.vodafone.com ([145.230.101.19]) with mapi id 14.03.0146.002; Tue, 1 Oct 2013 17:30:32 +0200 From: "Dawes, Peter, Vodafone Group" To: Mary Barnes , DISPATCH Thread-Topic: [dispatch] Reminder: IETF-88 deadlines Thread-Index: AQHOsySSXS0h+VSd+EyKGkre4HKfoJngDacw Date: Tue, 1 Oct 2013 15:30:31 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EEA1BFA@VOEXM31W.internal.vodafone.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D996EEA1BFAVOEXM31Winterna_" MIME-Version: 1.0 Cc: Cullen Jennings Subject: Re: [dispatch] Reminder: IETF-88 deadlines X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 15:31:10 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D996EEA1BFAVOEXM31Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mary, All, I have added a problem statement to the beginning of http://www.ietf.org/id= /draft-dawes-dispatch-mediasec-parameter-07.txt in order to explain why I t= hink dispatch should consider the draft, and have copied the problem statem= ent below. I will not be at IETF-88 but I am posting this now to meet the O= ct. 1 deadline in case dispatch would like to discuss the topic in Vancouve= r. Regards, Peter 1. Problem Statement In the 3GPP defined architecture and SIP profile for packet-domain communication, SIP signalling is security protected at the network layer but media-plane traffic is not (it is protected by the cellular wireless access). The SIP signalling security used by 3GPP runs from the user device to the first hop proxy and negotiation of security mechanism and the start of security protection is described in RFC 3329 [4]. Because the 3GPP architecture also allows access technologies that do not protect media, e.g. WiFi, this document extends the negotiation of security mechanism to the media plane. During previous discussion of the topic of media plane security it was suggested that DTLS-SRTP should be used, but 3GPP considered this impractical to implement in the 3GPP-defined architecture and also limited in terms of meeting all 3GPP requirements which include protection of non-RTP media such as MSRP. The purpose of this specification is to define a new header field parameter for the Session Initiation Protocol (SIP) [1] that distinguishes security mechanisms that apply to the media plane and to create an IANA registry for these mechanisms. This header field parameter may be used with the Security-Client, Security-Server, and Security-Verify header fields defined by RFC 3329 [4]. From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Mary Barnes Sent: 16 September 2013 22:35 To: DISPATCH Cc: Cullen Jennings Subject: [dispatch] Reminder: IETF-88 deadlines As a reminder, the DISPATCH deadlines for IETF-88 per the wiki are as follo= ws: http://trac.tools.ietf.org/wg/dispatch/trac/wiki * Oct 1, 2013. Cutoff date to notify the chairs/DISPATCH WG of plans to= submit a proposal. * Oct 7, 2013. Cutoff for charter proposals for topics. * Oct 21, 2013. Draft deadline. We do not assume that just because you've submitted a draft that you might = want agenda time. We need explicit emails - you can send those directly to= the chairs. Including "IETF-88 Agenda request" or "IETF-88 Topic Proposal= " in the subject line will ensure we don't miss your request. As a reminder, we don't need solutions at this stage in DISPATCH - we need = problem statements, objectives, milestones, etc. We need to understand why= you want to do the work and exactly what work you believe needs to be done= . You should be starting threads of discussion on the mailing list and inc= lude a link to any relevant drafts. We generally do not allocate agenda tim= e or dispatch topics unless there is mailing list discussion. Regards, Mary DISPATCH WG co-chair --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D996EEA1BFAVOEXM31Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mary, All,<= /span>

I have added a problem st= atement to the beginning of http://www.ietf.org/id/draft-dawes-dispatch-med= iasec-parameter-07.txt in order to explain why I think dispatch should consider the draft, and have copied the problem statement below. I = will not be at IETF-88 but I am posting this now to meet the Oct. 1 deadlin= e in case dispatch would like to discuss the topic in Vancouver.=

 <= /p>

Regards,

Peter

 <= /p>

1.  Problem Statement=

 

   In the 3GPP defined architectur= e and SIP profile for packet-domain

   communication, SIP signalling i= s security protected at the network

   layer but media-plane traffic i= s not (it is protected by the cellular

   wireless access).  The SIP= signalling security used by 3GPP runs from

   the user device to the first ho= p proxy and negotiation of security

   mechanism and the start of secu= rity protection is described in RFC

   3329 [4].  Because the 3GP= P architecture also allows access

   technologies that do not protec= t media, e.g. WiFi, this document

   extends the negotiation of secu= rity mechanism to the media plane.

   During previous discussion of t= he topic of media plane security it

   was suggested that DTLS-SRTP sh= ould be used, but 3GPP considered this

   impractical to implement in the= 3GPP-defined architecture and also

   limited in terms of meeting all= 3GPP requirements which include

   protection of non-RTP media suc= h as MSRP.

 

   The purpose of this specificati= on is to define a new header field

   parameter for the Session Initi= ation Protocol (SIP) [1] that

   distinguishes security mechanis= ms that apply to the media plane and

   to create an IANA registry for = these mechanisms.  This header field

   parameter may be used with the = Security-Client, Security-Server, and

   Security-Verify header fields d= efined by RFC 3329 [4].

 <= /p>

 <= /p>

 <= /p>

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ie= tf.org] On Behalf Of Mary Barnes
Sent: 16 September 2013 22:35
To: DISPATCH
Cc: Cullen Jennings
Subject: [dispatch] Reminder: IETF-88 deadlines

 

As a reminder, the DISPATCH deadlines for IETF-88 pe= r the wiki are as follows:  http://trac.tools= .ietf.org/wg/dispatch/trac/wiki

  • Oct 1, 2013. Cutoff date to notify the cha= irs/DISPATCH WG of plans to submit a proposal.
  • Oct 7, 2013. Cutoff for charter proposals = for topics.
  • Oct 21, 2013. Draft deadline.

We do not assume that just because you've subm= itted a draft that you might want agenda time.  We need explicit email= s - you can send those directly to the chairs.  Including "IETF-8= 8 Agenda request" or "IETF-88 Topic Proposal" in the subject = line will ensure we don't miss your request.  

 =

As a reminder, we don't need solutions at this= stage in DISPATCH - we need problem statements, objectives, milestones, et= c.  We need to understand why you want to do the work and exactly what work you believe needs to be done.  You should be starti= ng threads of discussion on the mailing list and include a link to any rele= vant drafts. We generally do not allocate agenda time or dispatch topics un= less there is mailing list discussion.

 =

Regards,

Mary <= o:p>

DISPATCH WG co-chair

--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D996EEA1BFAVOEXM31Winterna_-- From richard.ejzak@alcatel-lucent.com Mon Oct 7 11:19:00 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BCF11E8103 for ; Mon, 7 Oct 2013 11:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvDJDfNtdlM9 for ; Mon, 7 Oct 2013 11:18:51 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 74ABD11E810E for ; Mon, 7 Oct 2013 11:18:50 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r97IIi9V004244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Oct 2013 13:18:44 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r97IIh7a010158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Oct 2013 14:18:44 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 7 Oct 2013 14:18:43 -0400 From: "Ejzak, Richard P (Richard)" To: Mary Barnes , DISPATCH Thread-Topic: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols Thread-Index: AQHOw4mndZ+P4bp2bECnJHhuGAN9ig== Date: Mon, 7 Oct 2013 18:18:43 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86823C@US70UWXCHMBA04.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F3D86823CUS70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: Cullen Jennings Subject: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 18:19:00 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F3D86823CUS70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a charter proposal for "SDP negotiation of DataChannel sub-protocol= s" in accordance with the Oct. 7 deadline for dispatch. The rtcweb DataChannel is the primary mechanism available for a WebRTC appl= ication to establish transport for media protocols other than audio and vid= eo, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol. While W= ebSockets is an option for transport of some of these protocols, DataChanne= ls provides a more general solution that works in all cases, particularly p= eer-to-peer cases. Many applications using these kinds of protocols (usual= ly based on SIP or XMPP) also expect to negotiate their use with SDP. The rtcweb DataChannel design allows two means of creating a DataChannel: e= ither via in-band negotiation, or external negotiation. No external negoti= ation mechanism is defined in the core DataChannel specification to allow a= pplications the freedom to choose how to perform the external negotiation. We propose to charter work to: 1. Define generic SDP procedures to enable external negotiation of Da= taChannel sub-protocols to establish DataChannel transport for sub-protocol= sessions, and to negotiate the use of sub-protocol specific options. 2. Describe how to use the generic SDP procedures defined in 1 to neg= otiate DataChannel transport for specific protocols, potentially including = MSRP, BFCP, T.140, T.38 and the CLUE control protocol. We envision that one draft is sufficient for item 1, and one draft per prot= ocol is needed for item 2. We provided an early draft in http://datatracke= r.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/ that describes = a solution for 1 and provides details specific to MSRP. We have split this= document in two parts and made some significant revisions based on off-lin= e discussions (including a bar bof in Berlin). We intend to upload both ne= w documents well in advance of the doc deadline. Two high level issues were identified, which the new docs will attempt to a= ddress: 1. How will DataChannel sub-protocols be registered (re-use an existi= ng registry or create a new one) and if it's a new registry how to define t= he relationship to existing protocols. This issue deserves additional revi= ew and discussion. 2. Issues related to SCTP stream id assignment. We have very recentl= y concluded that there should be no impact on the DataChannel design as lon= g as the application has free reign to create a DataChannel at each peer us= ing the same stream id number. Comments/support are encouraged. Richard --_000_03FBA798AC24E3498B74F47FD082A92F3D86823CUS70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a charter proposa= l for “SDP negotiation of DataChannel sub-protocols” in accorda= nce with the Oct.  7 deadline for dispatch.

 <= /p>

The rtcweb DataChannel is= the primary mechanism available for a WebRTC application to establish tran= sport for media protocols other than audio and video, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol.  While WebS= ockets is an option for transport of some of these protocols, DataChannels = provides a more general solution that works in all cases, particularly peer= -to-peer cases.  Many applications using these kinds of protocols (usually based on SIP or XMPP) also expect to neg= otiate their use with SDP.

 <= /p>

The rtcweb DataChannel de= sign allows two means of creating a DataChannel: either via in-band negotia= tion, or external negotiation.  No external negotiation mechanism is defined in the core DataChannel specification to allow applic= ations the freedom to choose how to perform the external negotiation.<= /o:p>

 <= /p>

We propose to charter wor= k to:

1. = ;      Define generic SD= P procedures to enable external negotiation of DataChannel sub-protocols to= establish DataChannel transport for sub-protocol sessions, and to negotiate the use of sub-protocol specific options.

2. = ;      Describe how to u= se the generic SDP procedures defined in 1 to negotiate DataChannel transpo= rt for specific protocols, potentially including MSRP, BFCP, T.140, T.38 and the CLUE control protocol.

 <= /p>

We envision that one draf= t is sufficient for item 1, and one draft per protocol is needed for item 2= .  We provided an early draft in http://datatracker.ietf.org/doc/draft-marcon-msrp-over= -webrtc-data-channels/ that describes a solution for 1 and provides details specific to MSRP.  We= have split this document in two parts and made some significant revisions = based on off-line discussions (including a bar bof in Berlin).  We int= end to upload both new documents well in advance of the doc deadline.

 <= /p>

Two high level issues wer= e identified, which the new docs will attempt to address:=

1. = ;      How will DataChan= nel sub-protocols be registered (re-use an existing registry or create a ne= w one) and if it’s a new registry how to define the relationship to existing protocols.  This issue deserves additional review and dis= cussion.

2. = ;      Issues related to= SCTP stream id assignment.  We have very recently concluded that ther= e should be no impact on the DataChannel design as long as the application has free reign to create a DataChannel at each peer using = the same stream id number. 

 <= /p>

Comments/support are enco= uraged.

 <= /p>

Richard=

 <= /p>

 <= /p>

--_000_03FBA798AC24E3498B74F47FD082A92F3D86823CUS70UWXCHMBA04z_-- From carl_klatsky@cable.comcast.com Mon Oct 7 19:50:40 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4B921E8107 for ; Mon, 7 Oct 2013 19:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.704 X-Spam-Level: * X-Spam-Status: No, score=1.704 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEiENINXoGw5 for ; Mon, 7 Oct 2013 19:50:34 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 713BD21E8123 for ; Mon, 7 Oct 2013 19:50:30 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.68136364; Mon, 07 Oct 2013 22:50:27 -0400 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Mon, 7 Oct 2013 22:50:27 -0400 Received: from PACDCEXMB15.cable.comcast.com ([169.254.2.26]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Mon, 7 Oct 2013 22:50:27 -0400 From: "Klatsky, Carl" To: "'dispatch@ietf.org'" Thread-Topic: Updated draft-klatsky-dispatch-ipv6-impact-ipv4 Thread-Index: Ac7D0Ru4cQQTImqqTiSkl5EvPwMBOg== Date: Tue, 8 Oct 2013 02:50:27 +0000 Message-ID: <6C15A6B88541034E912E94C2D8BC3E87E136CF3A@PACDCEXMB15.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.248] Content-Type: multipart/alternative; boundary="_000_6C15A6B88541034E912E94C2D8BC3E87E136CF3APACDCEXMB15cabl_" MIME-Version: 1.0 Subject: [dispatch] Updated draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 02:50:40 -0000 --_000_6C15A6B88541034E912E94C2D8BC3E87E136CF3APACDCEXMB15cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, On behalf of the authors of this draft, a new version has been uploaded wit= h just some minor updates to Appendix A and the Informal References section= . Considering this is an informational document and should be non-controve= rsial, at this point in the process we ask for A-D sponsorship to move for= ward. Htmlized: http://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-imp= act-ipv4-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-klatsky-dispatch-= ipv6-impact-ipv4-02 Thanks & Regards, Carl Klatsky Comcast --_000_6C15A6B88541034E912E94C2D8BC3E87E136CF3APACDCEXMB15cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

On behalf of the authors of this draft, a new versio= n has been uploaded with just some minor updates to Appendix A and the Info= rmal References section.  Considering this is an informational documen= t and should be non-controversial,  at this point in the process we ask for A-D sponsorship to move forward.=

 

Htmlized:      &nbs= p; http://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-impact-ipv4-02

Diff:       &n= bsp;    http://www.ietf.org/rfcdiff?url2=3Ddraft-klatsky-dispatch-ipv6-impact-ipv4-= 02

 

Thanks &  Regards,

 

Carl Klatsky

Comcast

--_000_6C15A6B88541034E912E94C2D8BC3E87E136CF3APACDCEXMB15cabl_-- From R.Jesske@telekom.de Tue Oct 8 10:00:54 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C20421E828D for ; Tue, 8 Oct 2013 10:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyJyKqDW0eVv for ; Tue, 8 Oct 2013 10:00:43 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1A48021E828B for ; Tue, 8 Oct 2013 09:59:06 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 08 Oct 2013 18:58:54 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 8 Oct 2013 18:58:54 +0200 From: To: Date: Tue, 8 Oct 2013 18:58:52 +0200 Thread-Topic: New Version Notification for draft-drage-sipping-rfc3455bis-09.txt Thread-Index: Ac7EGyiEjqXzLZjSTWeCmqRubl8EhQAJbC7Q Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DEB76B2E1D@HE113667.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: dean.willis@softarmor.com Subject: [dispatch] WG: New Version Notification for draft-drage-sipping-rfc3455bis-09.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 17:00:54 -0000 RGVhciBhbGwsDQpJIHdvdWxkIGxpa2UgdG8gaW5mb3JtIHlvdSB0aGF0IEkgaGF2ZSBpbXBsZW1l bnRlZCBhbGwgY29tbWVudHMgY29taW5nIGZyb20gdGhlIGV4cGVydCByZXZpZXcgZG9uZSBieSBE ZWFuIFdpbGxpcy4gQWxzbyBhbiBlZGl0b3JpYWwgY2xlYW51cCB3YXMgbWFkZS4gDQoNCklmIHRo ZXJlIGFyZSBzdGlsbCBzb21lIGNvbW1lbnRzIHRoYXQgbmVlZHMgdG8gYmUgaW1wbGVtZW50ZWQg cGxlYXNlIGluZm9ybSBtZS4NCg0KRnJvbSBteSBzaWRlIEkgd291bGQgYmUgaGFwcHkgdG8gcHJv Y2VlZCB0aGUgZHJhZnQgZnVydGhlciB0b3dhcmRzIHB1YmxpY2F0aW9uLg0KDQpUaGFuayB5b3Ug YW5kIEJlc3QgUmVnYXJkcw0KDQpSb2xhbmQgDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNo cmljaHQtLS0tLQ0KVm9uOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0KR2VzZW5kZXQ6IERpZW5zdGFnLCA4LiBPa3RvYmVyIDIwMTMg MTM6NDANCkFuOiBDaHJpc3RlciBIb2xtYmVyZzsgS2VpdGggRHJhZ2U7IEplc3NrZSwgUm9sYW5k DQpCZXRyZWZmOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRyYWdlLXNpcHBp bmctcmZjMzQ1NWJpcy0wOS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZHJh Z2Utc2lwcGluZy1yZmMzNDU1YmlzLTA5LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBLZWl0aCBEcmFnZSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN CkZpbGVuYW1lOgkgZHJhZnQtZHJhZ2Utc2lwcGluZy1yZmMzNDU1YmlzDQpSZXZpc2lvbjoJIDA5 DQpUaXRsZToJCSBQcml2YXRlIEhlYWRlciAoUC1IZWFkZXIpIEV4dGVuc2lvbnMgdG8gdGhlIFNl c3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBmb3IgdGhlIDNyZC1HZW5lcmF0aW9uIFBh cnRuZXJzaGlwIFByb2plY3QgKDNHUFApDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0wOA0KR3Jv dXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDQ3DQpVUkw6ICAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRyYWdl LXNpcHBpbmctcmZjMzQ1NWJpcy0wOS50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMNCkh0bWxp emVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHJhZ2Utc2lwcGlu Zy1yZmMzNDU1YmlzLTA5DQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJpcy0wOQ0KDQpBYnN0cmFjdDoN CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2V0IG9mIHByaXZhdGUgU2Vzc2lvbiBJbml0 aWF0aW9uIFByb3RvY29sDQogICAoU0lQKSBoZWFkZXIgZmllbGRzIChQLWhlYWRlcnMpIHVzZWQg YnkgdGhlIDNyZC1HZW5lcmF0aW9uDQogICBQYXJ0bmVyc2hpcCBQcm9qZWN0ICgzR1BQKSwgYWxv bmcgd2l0aCB0aGVpciBhcHBsaWNhYmlsaXR5LCB3aGljaCBpcw0KICAgbGltaXRlZCB0byBwYXJ0 aWN1bGFyIGVudmlyb25tZW50cy4gIFRoZSBQLWhlYWRlciBmaWVsZHMgYXJlIGZvciBhDQogICB2 YXJpZXR5IG9mIHB1cnBvc2VzIHdpdGhpbiB0aGUgbmV0d29ya3MgdGhhdCB0aGUgcGFydG5lcnMg dXNlLA0KICAgaW5jbHVkaW5nIGNoYXJnaW5nIGFuZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmV0 d29ya3MgYSBjYWxsDQogICB0cmF2ZXJzZXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg== From richard.ejzak@alcatel-lucent.com Sun Oct 13 16:00:22 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D4D11E812F; Sun, 13 Oct 2013 16:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzogSgXQi7S1; Sun, 13 Oct 2013 16:00:16 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D2B4611E80EE; Sun, 13 Oct 2013 16:00:13 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9DN0Bsc028960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 Oct 2013 18:00:11 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r9DN0AHG030789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Oct 2013 19:00:10 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Sun, 13 Oct 2013 19:00:10 -0400 From: "Ejzak, Richard P (Richard)" To: DISPATCH , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [dispatch] [MMUSIC] [rtcweb] FW: New Version Notification for draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt Thread-Index: AQHOyGf3HKB+ufbKaUuqcHLlUeseLg== Date: Sun, 13 Oct 2013 23:00:09 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86A163@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [dispatch] [MMUSIC] [rtcweb] FW: New Version Notification for draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 23:00:22 -0000 UGxlYXNlIG5vdGUgdGhlIHN1Ym1pc3Npb24gb2YgZHJhZnQtZWp6YWstZGlzcGF0Y2gtd2VicnRj LWRhdGEtY2hhbm5lbC1zZHBuZWcuICBJdCBkZXNjcmliZXMgRGF0YUNoYW5uZWwgZXh0ZXJuYWwg bmVnb3RpYXRpb24gcHJvY2VkdXJlcyBiYXNlZCBvbiBTRFAgdG8gc2V0IHVwIERhdGFDaGFubmVs IHRyYW5zcG9ydCBmb3Igd2VsbC1rbm93biBzdWItcHJvdG9jb2xzIGxpa2UgTVNSUCwgQkZDUCwg VDE0MCwgVDM4LCBhbmQgcG9zc2libHkgdGhlIENMVUUgY29udHJvbCBwcm90b2NvbC4gIEl0IG1h a2VzIG5vIGFkZGl0aW9uYWwgZGVtYW5kcyBvbiB0aGUgRGF0YUNoYW5uZWwgZGVzaWduLCBhbHRo b3VnaCB0aGUgZG9jdW1lbnQgcmFpc2VzIG9uZSBzbWFsbCBpc3N1ZSBhbmQgc3VnZ2VzdHMgc29t ZSBjbGFyaWZpY2F0aW9ucyBpbiBleGlzdGluZyBEYXRhQ2hhbm5lbCBkb2N1bWVudHMuIFBsZWFz ZSBleHBlY3Qgb25lIG1vcmUgZG9jdW1lbnQgc29vbiB0aGF0IGRlc2NyaWJlcyB0aGUgYXBwbGlj YXRpb24gb2YgdGhlIGRyYWZ0IHRvIG5lZ290aWF0aW9uIG9mIERhdGFDaGFubmVsIHRyYW5zcG9y dCBmb3IgTVNSUC4NCg0KUmljaGFyZCBFanphaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXSANClNlbnQ6IFN1bmRheSwgT2N0b2JlciAxMywgMjAxMyA1OjQ1IFBNDQpUbzog RWp6YWssIFJpY2hhcmQgUCAoUmljaGFyZCk7IE1BUkNPTiwgSkVST01FIChKRVJPTUUpDQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWVqemFrLWRpc3BhdGNoLXdl YnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1lanphay1kaXNwYXRjaC13ZWJydGMtZGF0YS1jaGFubmVsLXNkcG5lZy0wMC50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmljaGFyZCBFanphayBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtZWp6YWstZGlz cGF0Y2gtd2VicnRjLWRhdGEtY2hhbm5lbC1zZHBuZWcNClJldmlzaW9uOgkgMDANClRpdGxlOgkJ IFNEUC1iYXNlZCBXZWJSVEMgZGF0YSBjaGFubmVsIG5lZ290aWF0aW9uDQpDcmVhdGlvbiBkYXRl OgkgMjAxMy0xMC0xNA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2Yg cGFnZXM6IDE0DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWVqemFrLWRpc3BhdGNoLXdlYnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAw LnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWVqemFrLWRpc3BhdGNoLXdlYnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnDQpIdG1saXplZDog ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWVqemFrLWRpc3BhdGNoLXdl YnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGUgUmVhbC1U aW1lIENvbW11bmljYXRpb24gaW4gV0VCLWJyb3dzZXJzIChSVENXZWIpIHdvcmtpbmcgZ3JvdXAg aXMNCiAgIGNoYXJnZWQgdG8gcHJvdmlkZSBwcm90b2NvbHMgdG8gc3VwcG9ydCBkaXJlY3QgaW50 ZXJhY3RpdmUgcmljaA0KICAgY29tbXVuaWNhdGlvbiB1c2luZyBhdWRpbywgdmlkZW8sIGFuZCBk YXRhIGJldHdlZW4gdHdvIHBlZXJzJyB3ZWItDQogICBicm93c2Vycy4gIEZvciB0aGUgc3VwcG9y dCBvZiBkYXRhIGNvbW11bmljYXRpb24sIHRoZSBSVENXZWIgd29ya2luZw0KICAgZ3JvdXAgaGFz IGluIHBhcnRpY3VsYXIgZGVmaW5lZCB0aGUgY29uY2VwdCBvZiBiaS1kaXJlY3Rpb25hbCBkYXRh DQogICBjaGFubmVscyBvdmVyIFNDVFAsIHdoZXJlIGVhY2ggZGF0YSBjaGFubmVsIG1pZ2h0IGJl IHVzZWQgdG8NCiAgIHRyYW5zcG9ydCBvdGhlciBwcm90b2NvbHMsIGNhbGxlZCBzdWItcHJvdG9j b2xzLiAgRGF0YSBjaGFubmVsIHNldHVwDQogICBjYW4gYmUgZG9uZSB1c2luZyBlaXRoZXIgdGhl IGluLWJhbmQgV2ViUlRDIERhdGEgQ2hhbm5lbCBwcm90b2NvbCBvcg0KICAgc29tZSBleHRlcm5h bCAoaW4tYmFuZCBvciBvdXQtb2YtYmFuZCkgbmVnb3RpYXRpb24uICBUaGlzIGRvY3VtZW50DQog ICBzcGVjaWZpZXMgaG93IHRoZSBTRFAgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGNhbiBiZSB1c2Vk IHRvIGFjaGlldmUNCiAgIHN1Y2ggYW4gZXh0ZXJuYWwgbmVnb3RpYXRpb24uDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From harald@alvestrand.no Mon Oct 14 02:12:05 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D527E21E80BE for ; Mon, 14 Oct 2013 02:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muS8VzI64+cV for ; Mon, 14 Oct 2013 02:12:00 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 64BAA21E80C3 for ; Mon, 14 Oct 2013 02:11:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED6F439E132 for ; Mon, 14 Oct 2013 11:11:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJZbK+L9nWIx for ; Mon, 14 Oct 2013 11:11:53 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DE3EE39E10F for ; Mon, 14 Oct 2013 11:11:52 +0200 (CEST) Message-ID: <525BB558.3090507@alvestrand.no> Date: Mon, 14 Oct 2013 11:11:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F3D86823C@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86823C@US70UWXCHMBA04.zam.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------050501040704080404060208" Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 09:12:05 -0000 This is a multi-part message in MIME format. --------------050501040704080404060208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit For the purposes of RTCWEB, this option was discussed at the IETF meeting in Orlando, and soundly rejected in favour of using an inband approach (with the option of leaving the negotiation to be done by non-standardized means). As long as the approach proposed is that of using WebRTC data channels, I do not see any advantage to revising that decision. Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 and CLUE control seems like perfectly reasonable things to do. I don't see any reason to believe that revisiting RTCWEB's decision about SDP usage for such negotiation is reasonable. On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote: > > This is a charter proposal for "SDP negotiation of DataChannel > sub-protocols" in accordance with the Oct. 7 deadline for dispatch. > > The rtcweb DataChannel is the primary mechanism available for a WebRTC > application to establish transport for media protocols other than > audio and video, such as MSRP, BFCP, T.140, T.38 and the CLUE control > protocol. While WebSockets is an option for transport of some of > these protocols, DataChannels provides a more general solution that > works in all cases, particularly peer-to-peer cases. Many > applications using these kinds of protocols (usually based on SIP or > XMPP) also expect to negotiate their use with SDP. > > The rtcweb DataChannel design allows two means of creating a > DataChannel: either via in-band negotiation, or external negotiation. > No external negotiation mechanism is defined in the core DataChannel > specification to allow applications the freedom to choose how to > perform the external negotiation. > > We propose to charter work to: > > 1.Define generic SDP procedures to enable external negotiation of > DataChannel sub-protocols to establish DataChannel transport for > sub-protocol sessions, and to negotiate the use of sub-protocol > specific options. > > 2.Describe how to use the generic SDP procedures defined in 1 to > negotiate DataChannel transport for specific protocols, potentially > including MSRP, BFCP, T.140, T.38 and the CLUE control protocol. > > We envision that one draft is sufficient for item 1, and one draft per > protocol is needed for item 2. We provided an early draft in > http://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/that > describes a solution for 1 and provides details specific to MSRP. We > have split this document in two parts and made some significant > revisions based on off-line discussions (including a bar bof in > Berlin). We intend to upload both new documents well in advance of > the doc deadline. > > Two high level issues were identified, which the new docs will attempt > to address: > > 1.How will DataChannel sub-protocols be registered (re-use an existing > registry or create a new one) and if it's a new registry how to define > the relationship to existing protocols. This issue deserves > additional review and discussion. > > 2.Issues related to SCTP stream id assignment. We have very recently > concluded that there should be no impact on the DataChannel design as > long as the application has free reign to create a DataChannel at each > peer using the same stream id number. > > Comments/support are encouraged. > > Richard > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------050501040704080404060208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
For the purposes of RTCWEB, this option was discussed at the IETF meeting in Orlando, and soundly rejected in favour of using an inband approach (with the option of leaving the negotiation to be done by non-standardized means).

As long as the approach proposed is that of using WebRTC data channels, I do not see any advantage to revising that decision.

Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 and CLUE control seems like perfectly reasonable things to do.

I don't see any reason to believe that revisiting RTCWEB's decision about SDP usage for such negotiation is reasonable.

On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote:

This is a charter proposal for “SDP negotiation of DataChannel sub-protocols” in accordance with the Oct.  7 deadline for dispatch.

 

The rtcweb DataChannel is the primary mechanism available for a WebRTC application to establish transport for media protocols other than audio and video, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol.  While WebSockets is an option for transport of some of these protocols, DataChannels provides a more general solution that works in all cases, particularly peer-to-peer cases.  Many applications using these kinds of protocols (usually based on SIP or XMPP) also expect to negotiate their use with SDP.

 

The rtcweb DataChannel design allows two means of creating a DataChannel: either via in-band negotiation, or external negotiation.  No external negotiation mechanism is defined in the core DataChannel specification to allow applications the freedom to choose how to perform the external negotiation.

 

We propose to charter work to:

1.       Define generic SDP procedures to enable external negotiation of DataChannel sub-protocols to establish DataChannel transport for sub-protocol sessions, and to negotiate the use of sub-protocol specific options.

2.       Describe how to use the generic SDP procedures defined in 1 to negotiate DataChannel transport for specific protocols, potentially including MSRP, BFCP, T.140, T.38 and the CLUE control protocol.

 

We envision that one draft is sufficient for item 1, and one draft per protocol is needed for item 2.  We provided an early draft in http://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/ that describes a solution for 1 and provides details specific to MSRP.  We have split this document in two parts and made some significant revisions based on off-line discussions (including a bar bof in Berlin).  We intend to upload both new documents well in advance of the doc deadline.

 

Two high level issues were identified, which the new docs will attempt to address:

1.       How will DataChannel sub-protocols be registered (re-use an existing registry or create a new one) and if it’s a new registry how to define the relationship to existing protocols.  This issue deserves additional review and discussion.

2.       Issues related to SCTP stream id assignment.  We have very recently concluded that there should be no impact on the DataChannel design as long as the application has free reign to create a DataChannel at each peer using the same stream id number. 

 

Comments/support are encouraged.

 

Richard

 

 



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

--------------050501040704080404060208-- From richard.ejzak@alcatel-lucent.com Mon Oct 14 06:46:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0EE21E809E for ; Mon, 14 Oct 2013 06:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyK2lPz3KMGf for ; Mon, 14 Oct 2013 06:46:47 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8E58E21E8173 for ; Mon, 14 Oct 2013 06:46:42 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9EDkbMO016557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Oct 2013 08:46:37 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r9EDkRRs025750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Oct 2013 09:46:37 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 14 Oct 2013 09:46:29 -0400 From: "Ejzak, Richard P (Richard)" To: Harald Alvestrand , "dispatch@ietf.org" Thread-Topic: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols Thread-Index: AQHOyL2G1nIf4VcemUOjSqZiHicWuJn0M9bw Date: Mon, 14 Oct 2013 13:46:28 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86A284@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F3D86823C@US70UWXCHMBA04.zam.alcatel-lucent.com> <525BB558.3090507@alvestrand.no> In-Reply-To: <525BB558.3090507@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F3D86A284US70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 13:46:53 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F3D86A284US70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Harald, We are not proposing to revisit any decision of the rtcweb group. We are n= ot proposing to change the design of the data channel (although we identify= one small issue where a small change might be appropriate but is not neces= sary). The data channel design allows for use of an external negotiation m= echanism as an alternative to in-band negotiation. This draft simply descr= ibes how one can use SDP to facilitate such an external negotiation mechani= sm. Please see the draft that we uploaded yesterday on the topic. BR, Richard From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Harald Alvestrand Sent: Monday, October 14, 2013 4:12 AM To: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols For the purposes of RTCWEB, this option was discussed at the IETF meeting i= n Orlando, and soundly rejected in favour of using an inband approach (with= the option of leaving the negotiation to be done by non-standardized means= ). As long as the approach proposed is that of using WebRTC data channels, I d= o not see any advantage to revising that decision. Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 a= nd CLUE control seems like perfectly reasonable things to do. I don't see any reason to believe that revisiting RTCWEB's decision about S= DP usage for such negotiation is reasonable. On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote: This is a charter proposal for "SDP negotiation of DataChannel sub-protocol= s" in accordance with the Oct. 7 deadline for dispatch. The rtcweb DataChannel is the primary mechanism available for a WebRTC appl= ication to establish transport for media protocols other than audio and vid= eo, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol. While W= ebSockets is an option for transport of some of these protocols, DataChanne= ls provides a more general solution that works in all cases, particularly p= eer-to-peer cases. Many applications using these kinds of protocols (usual= ly based on SIP or XMPP) also expect to negotiate their use with SDP. The rtcweb DataChannel design allows two means of creating a DataChannel: e= ither via in-band negotiation, or external negotiation. No external negoti= ation mechanism is defined in the core DataChannel specification to allow a= pplications the freedom to choose how to perform the external negotiation. We propose to charter work to: 1. Define generic SDP procedures to enable external negotiation of Dat= aChannel sub-protocols to establish DataChannel transport for sub-protocol = sessions, and to negotiate the use of sub-protocol specific options. 2. Describe how to use the generic SDP procedures defined in 1 to nego= tiate DataChannel transport for specific protocols, potentially including M= SRP, BFCP, T.140, T.38 and the CLUE control protocol. We envision that one draft is sufficient for item 1, and one draft per prot= ocol is needed for item 2. We provided an early draft in http://datatracke= r.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/ that describes = a solution for 1 and provides details specific to MSRP. We have split this= document in two parts and made some significant revisions based on off-lin= e discussions (including a bar bof in Berlin). We intend to upload both ne= w documents well in advance of the doc deadline. Two high level issues were identified, which the new docs will attempt to a= ddress: 1. How will DataChannel sub-protocols be registered (re-use an existin= g registry or create a new one) and if it's a new registry how to define th= e relationship to existing protocols. This issue deserves additional revie= w and discussion. 2. Issues related to SCTP stream id assignment. We have very recently= concluded that there should be no impact on the DataChannel design as long= as the application has free reign to create a DataChannel at each peer usi= ng the same stream id number. Comments/support are encouraged. Richard _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_03FBA798AC24E3498B74F47FD082A92F3D86A284US70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Harald,

We are not proposing to r= evisit any decision of the rtcweb group.  We are not proposing to chan= ge the design of the data channel (although we identify one small issue where a small change might be appropriate but is not necessary).&nbs= p; The data channel design allows for use of an external negotiation mechan= ism as an alternative to in-band negotiation.  This draft simply descr= ibes how one can use SDP to facilitate such an external negotiation mechanism.

 <= /p>

Please see the draft that= we uploaded yesterday on the topic.

 <= /p>

BR, Richard

 <= /p>

From: dispatch-bounces@ietf.org [mailto:dispatch-bounce= s@ietf.org] On Behalf Of Harald Alvestrand
Sent: Monday, October 14, 2013 4:12 AM
To: dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

For the purposes of RTCWEB, this option was discusse= d at the IETF meeting in Orlando, and soundly rejected in favour of using a= n inband approach (with the option of leaving the negotiation to be done by= non-standardized means).

As long as the approach proposed is that of using WebRTC data channels, I d= o not see any advantage to revising that decision.

Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 a= nd CLUE control seems like perfectly reasonable things to do.

I don't see any reason to believe that revisiting RTCWEB's decision about S= DP usage for such negotiation is reasonable.

On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote:

This is a charter proposa= l for “SDP negotiation of DataChannel sub-protocols” in accorda= nce with the Oct.  7 deadline for dispatch.

 <= /p>

The rtcweb DataChannel is= the primary mechanism available for a WebRTC application to establish tran= sport for media protocols other than audio and video, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol.  While WebS= ockets is an option for transport of some of these protocols, DataChannels = provides a more general solution that works in all cases, particularly peer= -to-peer cases.  Many applications using these kinds of protocols (usually based on SIP or XMPP) also expect to neg= otiate their use with SDP.

 <= /p>

The rtcweb DataChannel de= sign allows two means of creating a DataChannel: either via in-band negotia= tion, or external negotiation.  No external negotiation mechanism is defined in the core DataChannel specification to allow applic= ations the freedom to choose how to perform the external negotiation.

 <= /p>

We propose to charter wor= k to:

1.      Define generic SDP proce= dures to enable external negotiation of DataChannel sub-protocols to establ= ish DataChannel transport for sub-protocol sessions, and to negotiate the use of sub-protocol specific options.

2.      Describe how to use the = generic SDP procedures defined in 1 to negotiate DataChannel transport for = specific protocols, potentially including MSRP, BFCP, T.140, T.38 and the CLUE control protocol.

 <= /p>

We envision that one draf= t is sufficient for item 1, and one draft per protocol is needed for item 2= .  We provided an early draft in http://datatracker.ietf.org/doc/draft-marcon-msrp-over= -webrtc-data-channels/ that describes a solution for 1 and provides details specific to MSRP.  We= have split this document in two parts and made some significant revisions = based on off-line discussions (including a bar bof in Berlin).  We int= end to upload both new documents well in advance of the doc deadline.

 <= /p>

Two high level issues wer= e identified, which the new docs will attempt to address:=

1.      How will DataChannel sub= -protocols be registered (re-use an existing registry or create a new one) = and if it’s a new registry how to define the relationship to existing protocols.  This issue deserves additional review and dis= cussion.

2.      Issues related to SCTP s= tream id assignment.  We have very recently concluded that there shoul= d be no impact on the DataChannel design as long as the application has free reign to create a DataChannel at each peer using the same stream = id number. 

 <= /p>

Comments/support are enco= uraged.

 <= /p>

Richard=

 <= /p>

 <= /p> 




_______________________________________________
dispatch mailing list
dispatch@ietf.org<=
/pre>

https://www=
.ietf.org/mailman/listinfo/dispatch

 

--_000_03FBA798AC24E3498B74F47FD082A92F3D86A284US70UWXCHMBA04z_-- From richard.ejzak@alcatel-lucent.com Mon Oct 14 15:49:09 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAAC21F9F2B for ; Mon, 14 Oct 2013 15:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh7sDEVI8+ur for ; Mon, 14 Oct 2013 15:49:04 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1AF21F9FF1 for ; Mon, 14 Oct 2013 15:48:23 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r9EMmIxZ004747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Oct 2013 17:48:19 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r9EMmHrw002981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Oct 2013 18:48:18 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 14 Oct 2013 18:48:16 -0400 From: "Ejzak, Richard P (Richard)" To: Harald Alvestrand , "dispatch@ietf.org" Thread-Topic: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols Thread-Index: AQHOyS94v80hVpscq0K5JREoQPVivw== Date: Mon, 14 Oct 2013 22:48:16 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86A53E@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F3D86823C@US70UWXCHMBA04.zam.alcatel-lucent.com> <525BB558.3090507@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86A284@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86A284@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F3D86A53EUS70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 22:49:09 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F3D86A53EUS70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Harald, I just realized that there may be some confusion over the role of the brows= er in preparing SDP for external negotiation of DataChannels in our proposa= l. The answer is zip/nada/zero/nothing/nichevo. The browser just prepares= the m line for the SCTP association, while the JS application creates Data= Channels using the existing API (selecting to not use the in-band Open mess= age) and adds the DataChannel-specific attributes defined in the document t= o the SDP (to perform the external DataChannel negotiation with the peer). = The browser's role in supporting external DataChannel negotiation is exact= ly what is documented in the current DC drafts (although some minor clarifi= cations might be appropriate). BR, Richard From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Ejzak, Richard P (Richard) Sent: Monday, October 14, 2013 8:46 AM To: Harald Alvestrand; dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols Hi Harald, We are not proposing to revisit any decision of the rtcweb group. We are n= ot proposing to change the design of the data channel (although we identify= one small issue where a small change might be appropriate but is not neces= sary). The data channel design allows for use of an external negotiation m= echanism as an alternative to in-band negotiation. This draft simply descr= ibes how one can use SDP to facilitate such an external negotiation mechani= sm. Please see the draft that we uploaded yesterday on the topic. BR, Richard From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Harald Alvestrand Sent: Monday, October 14, 2013 4:12 AM To: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols For the purposes of RTCWEB, this option was discussed at the IETF meeting i= n Orlando, and soundly rejected in favour of using an inband approach (with= the option of leaving the negotiation to be done by non-standardized means= ). As long as the approach proposed is that of using WebRTC data channels, I d= o not see any advantage to revising that decision. Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 a= nd CLUE control seems like perfectly reasonable things to do. I don't see any reason to believe that revisiting RTCWEB's decision about S= DP usage for such negotiation is reasonable. On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote: This is a charter proposal for "SDP negotiation of DataChannel sub-protocol= s" in accordance with the Oct. 7 deadline for dispatch. The rtcweb DataChannel is the primary mechanism available for a WebRTC appl= ication to establish transport for media protocols other than audio and vid= eo, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol. While W= ebSockets is an option for transport of some of these protocols, DataChanne= ls provides a more general solution that works in all cases, particularly p= eer-to-peer cases. Many applications using these kinds of protocols (usual= ly based on SIP or XMPP) also expect to negotiate their use with SDP. The rtcweb DataChannel design allows two means of creating a DataChannel: e= ither via in-band negotiation, or external negotiation. No external negoti= ation mechanism is defined in the core DataChannel specification to allow a= pplications the freedom to choose how to perform the external negotiation. We propose to charter work to: 1. Define generic SDP procedures to enable external negotiation of Dat= aChannel sub-protocols to establish DataChannel transport for sub-protocol = sessions, and to negotiate the use of sub-protocol specific options. 2. Describe how to use the generic SDP procedures defined in 1 to nego= tiate DataChannel transport for specific protocols, potentially including M= SRP, BFCP, T.140, T.38 and the CLUE control protocol. We envision that one draft is sufficient for item 1, and one draft per prot= ocol is needed for item 2. We provided an early draft in http://datatracke= r.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/ that describes = a solution for 1 and provides details specific to MSRP. We have split this= document in two parts and made some significant revisions based on off-lin= e discussions (including a bar bof in Berlin). We intend to upload both ne= w documents well in advance of the doc deadline. Two high level issues were identified, which the new docs will attempt to a= ddress: 1. How will DataChannel sub-protocols be registered (re-use an existin= g registry or create a new one) and if it's a new registry how to define th= e relationship to existing protocols. This issue deserves additional revie= w and discussion. 2. Issues related to SCTP stream id assignment. We have very recently= concluded that there should be no impact on the DataChannel design as long= as the application has free reign to create a DataChannel at each peer usi= ng the same stream id number. Comments/support are encouraged. Richard _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_03FBA798AC24E3498B74F47FD082A92F3D86A53EUS70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Harald,

I just realized that ther= e may be some confusion over the role of the browser in preparing SDP for e= xternal negotiation of DataChannels in our proposal.  The answer is zip/nada/zero/nothing/nichevo.  The browser just prepares t= he m line for the SCTP association, while the JS application creates DataCh= annels using the existing API (selecting to not use the in-band Open messag= e) and adds the DataChannel-specific attributes defined in the document to the SDP (to perform the external Dat= aChannel negotiation with the peer).  The browser’s role in supp= orting external DataChannel negotiation is exactly what is documented in th= e current DC drafts (although some minor clarifications might be appropriate).

 <= /p>

BR, Richard

 <= /p>

From: dispatch-bounces@ietf.org [mailto:dispatch-bounce= s@ietf.org] On Behalf Of Ejzak, Richard P (Richard)
Sent: Monday, October 14, 2013 8:46 AM
To: Harald Alvestrand; dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

Hi Harald,

We are not proposing to r= evisit any decision of the rtcweb group.  We are not proposing to chan= ge the design of the data channel (although we identify one small issue where a small change might be appropriate but is not necessary).&nbs= p; The data channel design allows for use of an external negotiation mechan= ism as an alternative to in-band negotiation.  This draft simply descr= ibes how one can use SDP to facilitate such an external negotiation mechanism.

 <= /p>

Please see the draft that= we uploaded yesterday on the topic.

 <= /p>

BR, Richard

 <= /p>

From: dispatch-bounces@ietf.org [mailto:dispatch-bounce= s@ietf.org] On Behalf Of Harald Alvestrand
Sent: Monday, October 14, 2013 4:12 AM
To: dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

For the purposes of RTCWEB, this option was discusse= d at the IETF meeting in Orlando, and soundly rejected in favour of using a= n inband approach (with the option of leaving the negotiation to be done by= non-standardized means).

As long as the approach proposed is that of using WebRTC data channels, I d= o not see any advantage to revising that decision.

Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 a= nd CLUE control seems like perfectly reasonable things to do.

I don't see any reason to believe that revisiting RTCWEB's decision about S= DP usage for such negotiation is reasonable.

On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote:

This is a charter proposa= l for “SDP negotiation of DataChannel sub-protocols” in accorda= nce with the Oct.  7 deadline for dispatch.

 <= /p>

The rtcweb DataChannel is= the primary mechanism available for a WebRTC application to establish tran= sport for media protocols other than audio and video, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol.  While WebS= ockets is an option for transport of some of these protocols, DataChannels = provides a more general solution that works in all cases, particularly peer= -to-peer cases.  Many applications using these kinds of protocols (usually based on SIP or XMPP) also expect to neg= otiate their use with SDP.

 <= /p>

The rtcweb DataChannel de= sign allows two means of creating a DataChannel: either via in-band negotia= tion, or external negotiation.  No external negotiation mechanism is defined in the core DataChannel specification to allow applic= ations the freedom to choose how to perform the external negotiation.

 <= /p>

We propose to charter wor= k to:

1.      Define generic SDP proce= dures to enable external negotiation of DataChannel sub-protocols to establ= ish DataChannel transport for sub-protocol sessions, and to negotiate the use of sub-protocol specific options.

2.      Describe how to use the = generic SDP procedures defined in 1 to negotiate DataChannel transport for = specific protocols, potentially including MSRP, BFCP, T.140, T.38 and the CLUE control protocol.

 <= /p>

We envision that one draf= t is sufficient for item 1, and one draft per protocol is needed for item 2= .  We provided an early draft in http://datatracker.ietf.org/doc/draft-marcon-msrp-over= -webrtc-data-channels/ that describes a solution for 1 and provides details specific to MSRP.  We= have split this document in two parts and made some significant revisions = based on off-line discussions (including a bar bof in Berlin).  We int= end to upload both new documents well in advance of the doc deadline.

 <= /p>

Two high level issues wer= e identified, which the new docs will attempt to address:=

1.      How will DataChannel sub= -protocols be registered (re-use an existing registry or create a new one) = and if it’s a new registry how to define the relationship to existing protocols.  This issue deserves additional review and dis= cussion.

2.      Issues related to SCTP s= tream id assignment.  We have very recently concluded that there shoul= d be no impact on the DataChannel design as long as the application has free reign to create a DataChannel at each peer using the same stream = id number. 

 <= /p>

Comments/support are enco= uraged.

 <= /p>

Richard=

 <= /p>

 <= /p> 



_______________________________________________
dispatch mailing list
dispatch@ietf.org<=
/pre>

https://www=
.ietf.org/mailman/listinfo/dispatch

 

--_000_03FBA798AC24E3498B74F47FD082A92F3D86A53EUS70UWXCHMBA04z_-- From harald@alvestrand.no Mon Oct 14 23:40:28 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9F321F9D92 for ; Mon, 14 Oct 2013 23:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.448 X-Spam-Level: X-Spam-Status: No, score=-110.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPKXn5nvmIx9 for ; Mon, 14 Oct 2013 23:40:18 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB1321F9DAA for ; Mon, 14 Oct 2013 23:40:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D64F839E085; Tue, 15 Oct 2013 08:40:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf648YGi69WJ; Tue, 15 Oct 2013 08:40:09 +0200 (CEST) Received: from [172.30.42.84] (unknown [62.109.39.85]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0FD4B39E031; Tue, 15 Oct 2013 08:40:09 +0200 (CEST) Message-ID: <525CE348.7070208@alvestrand.no> Date: Tue, 15 Oct 2013 08:40:08 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Ejzak, Richard P (Richard)" , "dispatch@ietf.org" References: <03FBA798AC24E3498B74F47FD082A92F3D86823C@US70UWXCHMBA04.zam.alcatel-lucent.com> <525BB558.3090507@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86A284@US70UWXCHMBA04.zam.alcatel-lucent.com> <03FBA798AC24E3498B74F47FD082A92F3D86A53E@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86A53E@US70UWXCHMBA04.zam.alcatel-lucent.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------020201070608030808060208" Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 06:40:28 -0000 This is a multi-part message in MIME format. --------------020201070608030808060208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/15/2013 12:48 AM, Ejzak, Richard P (Richard) wrote: > > Hi Harald, > > I just realized that there may be some confusion over the role of the > browser in preparing SDP for external negotiation of DataChannels in > our proposal. The answer is zip/nada/zero/nothing/nichevo. The > browser just prepares the m line for the SCTP association, while the > JS application creates DataChannels using the existing API (selecting > to not use the in-band Open message) and adds the DataChannel-specific > attributes defined in the document to the SDP (to perform the external > DataChannel negotiation with the peer). The browser's role in > supporting external DataChannel negotiation is exactly what is > documented in the current DC drafts (although some minor > clarifications might be appropriate). > Re-reading the proposal, and matching up with draft-ietf-mmusic-sctp-sdp-04.txt, I'm less worried about this proposal than I initially was. The attributes you are defining aren't extensions of attributes defined there (which worried me), they're new, and therefore, by the rules of SDP, ignorable. I still think it's a Bad Idea, for all the reasons that came up in the RTCWEB meeting in Florida, but it shouldn't be actively harmful. > > > BR, Richard > > > > *From:*dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > *On Behalf Of *Ejzak, Richard P (Richard) > *Sent:* Monday, October 14, 2013 8:46 AM > *To:* Harald Alvestrand; dispatch@ietf.org > *Subject:* Re: [dispatch] Charter proposal: SDP negotiation of > DataChannel sub-protocols > > > > Hi Harald, > > We are not proposing to revisit any decision of the rtcweb group. We > are not proposing to change the design of the data channel (although > we identify one small issue where a small change might be appropriate > but is not necessary). The data channel design allows for use of an > external negotiation mechanism as an alternative to in-band > negotiation. This draft simply describes how one can use SDP to > facilitate such an external negotiation mechanism. > > > > Please see the draft that we uploaded yesterday on the topic. > > > > BR, Richard > > > > *From:*dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > *On Behalf Of *Harald Alvestrand > *Sent:* Monday, October 14, 2013 4:12 AM > *To:* dispatch@ietf.org > *Subject:* Re: [dispatch] Charter proposal: SDP negotiation of > DataChannel sub-protocols > > > > For the purposes of RTCWEB, this option was discussed at the IETF > meeting in Orlando, and soundly rejected in favour of using an inband > approach (with the option of leaving the negotiation to be done by > non-standardized means). > > As long as the approach proposed is that of using WebRTC data > channels, I do not see any advantage to revising that decision. > > Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, > T.38 and CLUE control seems like perfectly reasonable things to do. > > I don't see any reason to believe that revisiting RTCWEB's decision > about SDP usage for such negotiation is reasonable. > > On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote: > > This is a charter proposal for "SDP negotiation of DataChannel > sub-protocols" in accordance with the Oct. 7 deadline for dispatch. > > > > The rtcweb DataChannel is the primary mechanism available for a > WebRTC application to establish transport for media protocols > other than audio and video, such as MSRP, BFCP, T.140, T.38 and > the CLUE control protocol. While WebSockets is an option for > transport of some of these protocols, DataChannels provides a more > general solution that works in all cases, particularly > peer-to-peer cases. Many applications using these kinds of > protocols (usually based on SIP or XMPP) also expect to negotiate > their use with SDP. > > > > The rtcweb DataChannel design allows two means of creating a > DataChannel: either via in-band negotiation, or external > negotiation. No external negotiation mechanism is defined in the > core DataChannel specification to allow applications the freedom > to choose how to perform the external negotiation. > > > > We propose to charter work to: > > 1. Define generic SDP procedures to enable external > negotiation of DataChannel sub-protocols to establish DataChannel > transport for sub-protocol sessions, and to negotiate the use of > sub-protocol specific options. > > 2. Describe how to use the generic SDP procedures defined in > 1 to negotiate DataChannel transport for specific protocols, > potentially including MSRP, BFCP, T.140, T.38 and the CLUE control > protocol. > > > > We envision that one draft is sufficient for item 1, and one draft > per protocol is needed for item 2. We provided an early draft in > http://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/that > describes a solution for 1 and provides details specific to MSRP. > We have split this document in two parts and made some significant > revisions based on off-line discussions (including a bar bof in > Berlin). We intend to upload both new documents well in advance > of the doc deadline. > > > > Two high level issues were identified, which the new docs will > attempt to address: > > 1. How will DataChannel sub-protocols be registered (re-use > an existing registry or create a new one) and if it's a new > registry how to define the relationship to existing protocols. > This issue deserves additional review and discussion. > > 2. Issues related to SCTP stream id assignment. We have very > recently concluded that there should be no impact on the > DataChannel design as long as the application has free reign to > create a DataChannel at each peer using the same stream id number. > > > > Comments/support are encouraged. > > > > Richard > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > -- Surveillance is pervasive. Go Dark. --------------020201070608030808060208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/15/2013 12:48 AM, Ejzak, Richard P (Richard) wrote:

Hi Harald,

I just realized that there may be some confusion over the role of the browser in preparing SDP for external negotiation of DataChannels in our proposal.  The answer is zip/nada/zero/nothing/nichevo.  The browser just prepares the m line for the SCTP association, while the JS application creates DataChannels using the existing API (selecting to not use the in-band Open message) and adds the DataChannel-specific attributes defined in the document to the SDP (to perform the external DataChannel negotiation with the peer).  The browser’s role in supporting external DataChannel negotiation is exactly what is documented in the current DC drafts (although some minor clarifications might be appropriate).


Re-reading the proposal, and matching up with draft-ietf-mmusic-sctp-sdp-04.txt, I'm less worried about this proposal than I initially was. The attributes you are defining aren't extensions of attributes defined there (which worried me), they're new, and therefore, by the rules of SDP, ignorable.

I still think it's a Bad Idea, for all the reasons that came up in the RTCWEB meeting in Florida, but it shouldn't be actively harmful.

 

BR, Richard

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard)
Sent: Monday, October 14, 2013 8:46 AM
To: Harald Alvestrand; dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols

 

Hi Harald,

We are not proposing to revisit any decision of the rtcweb group.  We are not proposing to change the design of the data channel (although we identify one small issue where a small change might be appropriate but is not necessary).  The data channel design allows for use of an external negotiation mechanism as an alternative to in-band negotiation.  This draft simply describes how one can use SDP to facilitate such an external negotiation mechanism.

 

Please see the draft that we uploaded yesterday on the topic.

 

BR, Richard

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: Monday, October 14, 2013 4:12 AM
To: dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols

 

For the purposes of RTCWEB, this option was discussed at the IETF meeting in Orlando, and soundly rejected in favour of using an inband approach (with the option of leaving the negotiation to be done by non-standardized means).

As long as the approach proposed is that of using WebRTC data channels, I do not see any advantage to revising that decision.

Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 and CLUE control seems like perfectly reasonable things to do.

I don't see any reason to believe that revisiting RTCWEB's decision about SDP usage for such negotiation is reasonable.

On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote:

This is a charter proposal for “SDP negotiation of DataChannel sub-protocols” in accordance with the Oct.  7 deadline for dispatch.

 

The rtcweb DataChannel is the primary mechanism available for a WebRTC application to establish transport for media protocols other than audio and video, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol.  While WebSockets is an option for transport of some of these protocols, DataChannels provides a more general solution that works in all cases, particularly peer-to-peer cases.  Many applications using these kinds of protocols (usually based on SIP or XMPP) also expect to negotiate their use with SDP.

 

The rtcweb DataChannel design allows two means of creating a DataChannel: either via in-band negotiation, or external negotiation.  No external negotiation mechanism is defined in the core DataChannel specification to allow applications the freedom to choose how to perform the external negotiation.

 

We propose to charter work to:

1.      Define generic SDP procedures to enable external negotiation of DataChannel sub-protocols to establish DataChannel transport for sub-protocol sessions, and to negotiate the use of sub-protocol specific options.

2.      Describe how to use the generic SDP procedures defined in 1 to negotiate DataChannel transport for specific protocols, potentially including MSRP, BFCP, T.140, T.38 and the CLUE control protocol.

 

We envision that one draft is sufficient for item 1, and one draft per protocol is needed for item 2.  We provided an early draft in http://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/ that describes a solution for 1 and provides details specific to MSRP.  We have split this document in two parts and made some significant revisions based on off-line discussions (including a bar bof in Berlin).  We intend to upload both new documents well in advance of the doc deadline.

 

Two high level issues were identified, which the new docs will attempt to address:

1.      How will DataChannel sub-protocols be registered (re-use an existing registry or create a new one) and if it’s a new registry how to define the relationship to existing protocols.  This issue deserves additional review and discussion.

2.      Issues related to SCTP stream id assignment.  We have very recently concluded that there should be no impact on the DataChannel design as long as the application has free reign to create a DataChannel at each peer using the same stream id number. 

 

Comments/support are encouraged.

 

Richard

 

 



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

 



-- 
Surveillance is pervasive. Go Dark.
--------------020201070608030808060208-- From richard.ejzak@alcatel-lucent.com Tue Oct 15 12:52:02 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A346611E81F3 for ; Tue, 15 Oct 2013 12:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlN3X6GnVcmO for ; Tue, 15 Oct 2013 12:51:56 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E245E11E8156 for ; Tue, 15 Oct 2013 12:51:55 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9FJppIn015501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Oct 2013 14:51:51 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r9FJppFa020638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 15:51:51 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Tue, 15 Oct 2013 15:51:51 -0400 From: "Ejzak, Richard P (Richard)" To: Harald Alvestrand , "dispatch@ietf.org" Thread-Topic: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols Thread-Index: AQHOyXFpmsrsnLo/JkSWxLuPpwN6vpn182nA Date: Tue, 15 Oct 2013 19:51:50 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86A82B@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F3D86823C@US70UWXCHMBA04.zam.alcatel-lucent.com> <525BB558.3090507@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86A284@US70UWXCHMBA04.zam.alcatel-lucent.com> <03FBA798AC24E3498B74F47FD082A92F3D86A53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <525CE348.7070208@alvestrand.no> In-Reply-To: <525CE348.7070208@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F3D86A82BUS70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:52:02 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F3D86A82BUS70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Harald, At least we are making some progress... My recollection of the Florida rtcweb session was that external data channe= l negotiation was considered to be a useful concept (which is why it was i= ncluded in the data channel design), but that it was premature to assume th= at SDP should be the primary mechanism to realize it. So the application h= as the responsibility to implement whatever external negotiation mechanism = it chooses to use. Options include using another data channel to transport= external negotiation messages, and using other non-SDP format protocols. = I don't recall any specific arguments against using SDP for external data c= hannel negotiation, other than the general anti-SDP comments. Please correct/elaborate my recollection of the Florida discussion to help = me understand your position here, as "Bad Idea" is a bit too ambiguous to b= e helpful. I fully concur that there can be multiple ways to realize external data cha= nnel negotiation, and encourage specification of any useful alternative mec= hanisms. We are simply proposing A mechanism to perform external data chan= nel negotiation using SDP for use in applications that desire to negotiate = the use of specific protocols, such as MSRP and T140, that are usually nego= tiated using SDP. One advantage of using SDP is to ease interworking throu= gh gateways to endpoints that only support other transport options for the = negotiated protocols (e.g., TLS/TCP for MSRP). We specifically selected MS= RP, BFCP, T140 and T38 as example protocols for this because of their commo= n use by SIP and XMPP endpoints that expect to negotiate their use with SDP= . It becomes even more valuable when the protocol comes with various SDP a= ttributes that also need to be negotiated (like accept-types and other file= attributes for MSRP). BR, Richard From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Tuesday, October 15, 2013 1:40 AM To: Ejzak, Richard P (Richard); dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols On 10/15/2013 12:48 AM, Ejzak, Richard P (Richard) wrote: Hi Harald, I just realized that there may be some confusion over the role of the brows= er in preparing SDP for external negotiation of DataChannels in our proposa= l. The answer is zip/nada/zero/nothing/nichevo. The browser just prepares= the m line for the SCTP association, while the JS application creates Data= Channels using the existing API (selecting to not use the in-band Open mess= age) and adds the DataChannel-specific attributes defined in the document t= o the SDP (to perform the external DataChannel negotiation with the peer). = The browser's role in supporting external DataChannel negotiation is exact= ly what is documented in the current DC drafts (although some minor clarifi= cations might be appropriate). Re-reading the proposal, and matching up with draft-ietf-mmusic-sctp-sdp-04= .txt, I'm less worried about this proposal than I initially was. The attrib= utes you are defining aren't extensions of attributes defined there (which = worried me), they're new, and therefore, by the rules of SDP, ignorable. I still think it's a Bad Idea, for all the reasons that came up in the RTCW= EB meeting in Florida, but it shouldn't be actively harmful. BR, Richard From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard) Sent: Monday, October 14, 2013 8:46 AM To: Harald Alvestrand; dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols Hi Harald, We are not proposing to revisit any decision of the rtcweb group. We are n= ot proposing to change the design of the data channel (although we identify= one small issue where a small change might be appropriate but is not neces= sary). The data channel design allows for use of an external negotiation m= echanism as an alternative to in-band negotiation. This draft simply descr= ibes how one can use SDP to facilitate such an external negotiation mechani= sm. Please see the draft that we uploaded yesterday on the topic. BR, Richard From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: Monday, October 14, 2013 4:12 AM To: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols For the purposes of RTCWEB, this option was discussed at the IETF meeting i= n Orlando, and soundly rejected in favour of using an inband approach (with= the option of leaving the negotiation to be done by non-standardized means= ). As long as the approach proposed is that of using WebRTC data channels, I d= o not see any advantage to revising that decision. Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 a= nd CLUE control seems like perfectly reasonable things to do. I don't see any reason to believe that revisiting RTCWEB's decision about S= DP usage for such negotiation is reasonable. On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote: This is a charter proposal for "SDP negotiation of DataChannel sub-protocol= s" in accordance with the Oct. 7 deadline for dispatch. The rtcweb DataChannel is the primary mechanism available for a WebRTC appl= ication to establish transport for media protocols other than audio and vid= eo, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol. While W= ebSockets is an option for transport of some of these protocols, DataChanne= ls provides a more general solution that works in all cases, particularly p= eer-to-peer cases. Many applications using these kinds of protocols (usual= ly based on SIP or XMPP) also expect to negotiate their use with SDP. The rtcweb DataChannel design allows two means of creating a DataChannel: e= ither via in-band negotiation, or external negotiation. No external negoti= ation mechanism is defined in the core DataChannel specification to allow a= pplications the freedom to choose how to perform the external negotiation. We propose to charter work to: 1. Define generic SDP procedures to enable external negotiation of Dat= aChannel sub-protocols to establish DataChannel transport for sub-protocol = sessions, and to negotiate the use of sub-protocol specific options. 2. Describe how to use the generic SDP procedures defined in 1 to nego= tiate DataChannel transport for specific protocols, potentially including M= SRP, BFCP, T.140, T.38 and the CLUE control protocol. We envision that one draft is sufficient for item 1, and one draft per prot= ocol is needed for item 2. We provided an early draft in http://datatracke= r.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/ that describes = a solution for 1 and provides details specific to MSRP. We have split this= document in two parts and made some significant revisions based on off-lin= e discussions (including a bar bof in Berlin). We intend to upload both ne= w documents well in advance of the doc deadline. Two high level issues were identified, which the new docs will attempt to a= ddress: 1. How will DataChannel sub-protocols be registered (re-use an existin= g registry or create a new one) and if it's a new registry how to define th= e relationship to existing protocols. This issue deserves additional revie= w and discussion. 2. Issues related to SCTP stream id assignment. We have very recently= concluded that there should be no impact on the DataChannel design as long= as the application has free reign to create a DataChannel at each peer usi= ng the same stream id number. Comments/support are encouraged. Richard _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch -- Surveillance is pervasive. Go Dark. --_000_03FBA798AC24E3498B74F47FD082A92F3D86A82BUS70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Harald,

At least we are making so= me progress…

 <= /p>

My recollection of the Fl= orida rtcweb session was that external data channel negotiation was conside= red to  be a useful concept (which is why it was included in the data channel design), but that it was premature to assume that SDP = should be the primary mechanism to realize it.  So the application has= the responsibility to implement whatever external negotiation mechanism it= chooses to use.  Options include using another data channel to transport external negotiation messages, and using= other non-SDP format protocols.  I don’t recall any specific ar= guments against using SDP for external data channel negotiation, other than= the general anti-SDP comments.

 <= /p>

Please correct/elaborate = my recollection of the Florida discussion to help me understand your positi= on here, as “Bad Idea” is a bit too ambiguous to be helpful.

 <= /p>

I fully concur that there= can be multiple ways to realize external data channel negotiation, and enc= ourage specification of any useful alternative mechanisms.  We are simply proposing A mechanism to perform external data channel negot= iation using SDP for use in applications that desire to negotiate the use o= f specific protocols, such as MSRP and T140, that are usually negotiated us= ing SDP.  One advantage of using SDP is to ease interworking through gateways to endpoints that only suppor= t other transport options for the negotiated protocols (e.g., TLS/TCP for M= SRP).  We specifically selected MSRP, BFCP, T140 and T38 as example pr= otocols for this because of their common use by SIP and XMPP endpoints that expect to negotiate their use with SDP.=   It becomes even more valuable when the protocol comes with various S= DP attributes that also need to be negotiated (like accept-types and other = file attributes for MSRP).

 <= /p>

BR, Richard

 <= /p>

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Tuesday, October 15, 2013 1:40 AM
To: Ejzak, Richard P (Richard); dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

On 10/15/2013 12:48 AM, Ejzak, Richard P (Richard) w= rote:

Hi Harald,

I just realized that ther= e may be some confusion over the role of the browser in preparing SDP for e= xternal negotiation of DataChannels in our proposal.  The answer is zip/nada/zero/nothing/nichevo.  The browser just prepares t= he m line for the SCTP association, while the JS application creates DataCh= annels using the existing API (selecting to not use the in-band Open messag= e) and adds the DataChannel-specific attributes defined in the document to the SDP (to perform the external Dat= aChannel negotiation with the peer).  The browser’s role in supp= orting external DataChannel negotiation is exactly what is documented in th= e current DC drafts (although some minor clarifications might be appropriate).


Re-reading the proposal, and matching up with draft-ietf-mmusic-sctp-sdp-04= .txt, I'm less worried about this proposal than I initially was. The attrib= utes you are defining aren't extensions of attributes defined there (which = worried me), they're new, and therefore, by the rules of SDP, ignorable.

I still think it's a Bad Idea, for all the reasons that came up in the RTCW= EB meeting in Florida, but it shouldn't be actively harmful.


 <= /p>

BR, Richard

 <= /p>

From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.= org] On Behalf Of Ejzak, Richard P (Richard)
Sent: Monday, October 14, 2013 8:46 AM
To: Harald Alvestrand; dispatch= @ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

Hi Harald,

We are not proposing to r= evisit any decision of the rtcweb group.  We are not proposing to chan= ge the design of the data channel (although we identify one small issue where a small change might be appropriate but is not necessary).&nbs= p; The data channel design allows for use of an external negotiation mechan= ism as an alternative to in-band negotiation.  This draft simply descr= ibes how one can use SDP to facilitate such an external negotiation mechanism.

 <= /p>

Please see the draft that= we uploaded yesterday on the topic.

 <= /p>

BR, Richard

 <= /p>

From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.= org] On Behalf Of Harald Alvestrand
Sent: Monday, October 14, 2013 4:12 AM
To: dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

For the purposes of RTCWEB, this option was discusse= d at the IETF meeting in Orlando, and soundly rejected in favour of using a= n inband approach (with the option of leaving the negotiation to be done by= non-standardized means).

As long as the approach proposed is that of using WebRTC data channels, I d= o not see any advantage to revising that decision.

Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 a= nd CLUE control seems like perfectly reasonable things to do.

I don't see any reason to believe that revisiting RTCWEB's decision about S= DP usage for such negotiation is reasonable.

On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote:

This is a charter proposa= l for “SDP negotiation of DataChannel sub-protocols” in accorda= nce with the Oct.  7 deadline for dispatch.

 <= /p>

The rtcweb DataChannel is= the primary mechanism available for a WebRTC application to establish tran= sport for media protocols other than audio and video, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol.  While WebS= ockets is an option for transport of some of these protocols, DataChannels = provides a more general solution that works in all cases, particularly peer= -to-peer cases.  Many applications using these kinds of protocols (usually based on SIP or XMPP) also expect to neg= otiate their use with SDP.

 <= /p>

The rtcweb DataChannel de= sign allows two means of creating a DataChannel: either via in-band negotia= tion, or external negotiation.  No external negotiation mechanism is defined in the core DataChannel specification to allow applic= ations the freedom to choose how to perform the external negotiation.

 <= /p>

We propose to charter wor= k to:

1.      Define generic SDP proce= dures to enable external negotiation of DataChannel sub-protocols to establ= ish DataChannel transport for sub-protocol sessions, and to negotiate the use of sub-protocol specific options.

2.      Describe how to use the = generic SDP procedures defined in 1 to negotiate DataChannel transport for = specific protocols, potentially including MSRP, BFCP, T.140, T.38 and the CLUE control protocol.

 <= /p>

We envision that one draf= t is sufficient for item 1, and one draft per protocol is needed for item 2= .  We provided an early draft in http://datatracker.ietf.org/doc/draft-marcon-msrp-over= -webrtc-data-channels/ that describes a solution for 1 and provides details specific to MSRP.  We= have split this document in two parts and made some significant revisions = based on off-line discussions (including a bar bof in Berlin).  We int= end to upload both new documents well in advance of the doc deadline.

 <= /p>

Two high level issues wer= e identified, which the new docs will attempt to address:=

1.      How will DataChannel sub= -protocols be registered (re-use an existing registry or create a new one) = and if it’s a new registry how to define the relationship to existing protocols.  This issue deserves additional review and dis= cussion.

2.      Issues related to SCTP s= tream id assignment.  We have very recently concluded that there shoul= d be no impact on the DataChannel design as long as the application has free reign to create a DataChannel at each peer using the same stream = id number. 

 <= /p>

Comments/support are enco= uraged.

 <= /p>

Richard=

 <= /p>

 <= /p> 




_______________________________________________
dispatch mailing list
dispatch@ietf.org<=
/pre>

https://www=
.ietf.org/mailman/listinfo/dispatch

 




-- 
Surveillance is pervasive. Go Dark.
--_000_03FBA798AC24E3498B74F47FD082A92F3D86A82BUS70UWXCHMBA04z_-- From pkyzivat@alum.mit.edu Tue Oct 15 15:23:39 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D33E11E821D for ; Tue, 15 Oct 2013 15:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zF1WPYpqSCu for ; Tue, 15 Oct 2013 15:23:33 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id A1DBD11E821B for ; Tue, 15 Oct 2013 15:22:44 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta10.westchester.pa.mail.comcast.net with comcast id dQTx1m00416LCl05AaNkPr; Tue, 15 Oct 2013 22:22:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id daNj1m01E3ZTu2S3SaNk4B; Tue, 15 Oct 2013 22:22:44 +0000 Message-ID: <525DC032.2060107@alum.mit.edu> Date: Tue, 15 Oct 2013 18:22:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dispatch@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F3D86823C@US70UWXCHMBA04.zam.alcatel-lucent.com> <525BB558.3090507@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86A284@US70UWXCHMBA04.zam.alcatel-lucent.com> <03FBA798AC24E3498B74F47FD082A92F3D86A53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <525CE348.7070208@alvestrand.no> In-Reply-To: <525CE348.7070208@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381875764; bh=3PXdKy5gm2/duEbZOeCeBEYBoXfRCuXIt6H0btbDAmM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IDhD0hrgBWHCNl4XBpQG1y54oGbgCo/B4Wz8IdrnzrRgCXPsZK6mr7nJQDgsZhslV OByqMl/sg8dfpo8rZqGfT/NqL9XIGRS2gchm10hcvuvOybQU8viOrMZbeJTebYphYe RrMaR67f6Q3ackPX+Bt/VLMDV2aShXsaY1pIUPFCQh3fWW8Ko/2MjJ2lWLgFLWCI8v Ljd1SyAs/ead4d+VLsLwmwoyJgg5PQSWax2eMjTMF6s2ax5pCQ68RfEmk+4zwqCJSw YD8PTm4QYkmNhgwSvKwybZ3yg4ozGG7sD/ynlg9fSZIhDdNuPTGOPPJAKFiK6LrBz9 fIN83pPpt1mew== Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:23:39 -0000 Harald, On 10/15/13 2:40 AM, Harald Alvestrand wrote: > I still think it's a Bad Idea, for all the reasons that came up in the > RTCWEB meeting in Florida, but it shouldn't be actively harmful. What do you imagine is a reasonable alternative for SIP? The fundamental difference between SIP and WebRTC here is that with WebRTC there is one application in charge of both ends, while in SIP there are separate applications at each end. With one application you can preplan how you want to assign channels. With two applications, if SDP only allows you to set up the SCTP association, and not the channels, then some other mechanism for that must be negotiated by the two ends. And that mechanism would generally entail devising a protocol and a way to transport it. Or else we become very restrictive. E.g., in clue we could dedicate the entire SCTP association to the one clue channel. But it would be nice if some independent things that can work with CLUE could also have the option of using channels on the same SCTP association. Thanks, Paul From uwe.rauschenbach@nsn.com Wed Oct 16 08:40:20 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C141911E82F2 for ; Wed, 16 Oct 2013 08:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjQU4Eb8BbVo for ; Wed, 16 Oct 2013 08:40:15 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DA4D311E82F5 for ; Wed, 16 Oct 2013 08:40:14 -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 r9GFe7NK017649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Oct 2013 17:40:08 +0200 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r9GFe7MK031482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 17:40:07 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.164]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Wed, 16 Oct 2013 17:40:07 +0200 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: "Ejzak, Richard P (Richard)" , "Harald Alvestrand" , "dispatch@ietf.org" Thread-Topic: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols Thread-Index: AQHOyeAHLlcS7UEp0EmZNhjMFU9UrZn3d6/A Date: Wed, 16 Oct 2013 15:40:06 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF812409F@DEMUMBX005.nsn-intra.net> References: <03FBA798AC24E3498B74F47FD082A92F3D86823C@US70UWXCHMBA04.zam.alcatel-lucent.com> <525BB558.3090507@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86A284@US70UWXCHMBA04.zam.alcatel-lucent.com> <03FBA798AC24E3498B74F47FD082A92F3D86A53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <525CE348.7070208@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86A82B@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86A82B@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF812409FDEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 36343 X-purgate-ID: 151667::1381938008-00005753-7E3FE653/0-0/0-0 Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:40:20 -0000 --_000_56C2F665D49E0341B9DF5938005ACDF812409FDEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard, For T.140, there is an RTP payload format defined (RFC4103). What would be the benefit for standardizing an additional Data Channel bind= ing for it, as opposed to using RTP? Kind regards, Uwe From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel-lucent.com] Sent: Tuesday, October 15, 2013 9:52 PM To: Harald Alvestrand; dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols Hi Harald, At least we are making some progress... My recollection of the Florida rtcweb session was that external data channe= l negotiation was considered to be a useful concept (which is why it was i= ncluded in the data channel design), but that it was premature to assume th= at SDP should be the primary mechanism to realize it. So the application h= as the responsibility to implement whatever external negotiation mechanism = it chooses to use. Options include using another data channel to transport= external negotiation messages, and using other non-SDP format protocols. = I don't recall any specific arguments against using SDP for external data c= hannel negotiation, other than the general anti-SDP comments. Please correct/elaborate my recollection of the Florida discussion to help = me understand your position here, as "Bad Idea" is a bit too ambiguous to b= e helpful. I fully concur that there can be multiple ways to realize external data cha= nnel negotiation, and encourage specification of any useful alternative mec= hanisms. We are simply proposing A mechanism to perform external data chan= nel negotiation using SDP for use in applications that desire to negotiate = the use of specific protocols, such as MSRP and T140, that are usually nego= tiated using SDP. One advantage of using SDP is to ease interworking throu= gh gateways to endpoints that only support other transport options for the = negotiated protocols (e.g., TLS/TCP for MSRP). We specifically selected MS= RP, BFCP, T140 and T38 as example protocols for this because of their commo= n use by SIP and XMPP endpoints that expect to negotiate their use with SDP= . It becomes even more valuable when the protocol comes with various SDP a= ttributes that also need to be negotiated (like accept-types and other file= attributes for MSRP). BR, Richard From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Tuesday, October 15, 2013 1:40 AM To: Ejzak, Richard P (Richard); dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols On 10/15/2013 12:48 AM, Ejzak, Richard P (Richard) wrote: Hi Harald, I just realized that there may be some confusion over the role of the brows= er in preparing SDP for external negotiation of DataChannels in our proposa= l. The answer is zip/nada/zero/nothing/nichevo. The browser just prepares= the m line for the SCTP association, while the JS application creates Data= Channels using the existing API (selecting to not use the in-band Open mess= age) and adds the DataChannel-specific attributes defined in the document t= o the SDP (to perform the external DataChannel negotiation with the peer). = The browser's role in supporting external DataChannel negotiation is exact= ly what is documented in the current DC drafts (although some minor clarifi= cations might be appropriate). Re-reading the proposal, and matching up with draft-ietf-mmusic-sctp-sdp-04= .txt, I'm less worried about this proposal than I initially was. The attrib= utes you are defining aren't extensions of attributes defined there (which = worried me), they're new, and therefore, by the rules of SDP, ignorable. I still think it's a Bad Idea, for all the reasons that came up in the RTCW= EB meeting in Florida, but it shouldn't be actively harmful. BR, Richard From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard) Sent: Monday, October 14, 2013 8:46 AM To: Harald Alvestrand; dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols Hi Harald, We are not proposing to revisit any decision of the rtcweb group. We are n= ot proposing to change the design of the data channel (although we identify= one small issue where a small change might be appropriate but is not neces= sary). The data channel design allows for use of an external negotiation m= echanism as an alternative to in-band negotiation. This draft simply descr= ibes how one can use SDP to facilitate such an external negotiation mechani= sm. Please see the draft that we uploaded yesterday on the topic. BR, Richard From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: Monday, October 14, 2013 4:12 AM To: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols For the purposes of RTCWEB, this option was discussed at the IETF meeting i= n Orlando, and soundly rejected in favour of using an inband approach (with= the option of leaving the negotiation to be done by non-standardized means= ). As long as the approach proposed is that of using WebRTC data channels, I d= o not see any advantage to revising that decision. Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 a= nd CLUE control seems like perfectly reasonable things to do. I don't see any reason to believe that revisiting RTCWEB's decision about S= DP usage for such negotiation is reasonable. On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote: This is a charter proposal for "SDP negotiation of DataChannel sub-protocol= s" in accordance with the Oct. 7 deadline for dispatch. The rtcweb DataChannel is the primary mechanism available for a WebRTC appl= ication to establish transport for media protocols other than audio and vid= eo, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol. While W= ebSockets is an option for transport of some of these protocols, DataChanne= ls provides a more general solution that works in all cases, particularly p= eer-to-peer cases. Many applications using these kinds of protocols (usual= ly based on SIP or XMPP) also expect to negotiate their use with SDP. The rtcweb DataChannel design allows two means of creating a DataChannel: e= ither via in-band negotiation, or external negotiation. No external negoti= ation mechanism is defined in the core DataChannel specification to allow a= pplications the freedom to choose how to perform the external negotiation. We propose to charter work to: 1. Define generic SDP procedures to enable external negotiation of Dat= aChannel sub-protocols to establish DataChannel transport for sub-protocol = sessions, and to negotiate the use of sub-protocol specific options. 2. Describe how to use the generic SDP procedures defined in 1 to nego= tiate DataChannel transport for specific protocols, potentially including M= SRP, BFCP, T.140, T.38 and the CLUE control protocol. We envision that one draft is sufficient for item 1, and one draft per prot= ocol is needed for item 2. We provided an early draft in http://datatracke= r.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/ that describes = a solution for 1 and provides details specific to MSRP. We have split this= document in two parts and made some significant revisions based on off-lin= e discussions (including a bar bof in Berlin). We intend to upload both ne= w documents well in advance of the doc deadline. Two high level issues were identified, which the new docs will attempt to a= ddress: 1. How will DataChannel sub-protocols be registered (re-use an existin= g registry or create a new one) and if it's a new registry how to define th= e relationship to existing protocols. This issue deserves additional revie= w and discussion. 2. Issues related to SCTP stream id assignment. We have very recently= concluded that there should be no impact on the DataChannel design as long= as the application has free reign to create a DataChannel at each peer usi= ng the same stream id number. Comments/support are encouraged. Richard _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch -- Surveillance is pervasive. Go Dark. --_000_56C2F665D49E0341B9DF5938005ACDF812409FDEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Richard,

 <= /p>

For T.140, there is an RT= P payload format defined (RFC4103).

What would be the benefit= for standardizing an additional Data Channel binding for it, as opposed to= using RTP?

 <= /p>

Kind regards,
Uwe

 

 

From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@= alcatel-lucent.com]
Sent: Tuesday, October 15, 2013 9:52 PM
To: Harald Alvestrand; dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

Hi Harald,

At least we are making so= me progress…

 <= /p>

My recollection of the Fl= orida rtcweb session was that external data channel negotiation was conside= red to  be a useful concept (which is why it was included in the data channel design), but that it was premature to assume that SDP = should be the primary mechanism to realize it.  So the application has= the responsibility to implement whatever external negotiation mechanism it= chooses to use.  Options include using another data channel to transport external negotiation messages, and using= other non-SDP format protocols.  I don’t recall any specific ar= guments against using SDP for external data channel negotiation, other than= the general anti-SDP comments.

 <= /p>

Please correct/elaborate = my recollection of the Florida discussion to help me understand your positi= on here, as “Bad Idea” is a bit too ambiguous to be helpful.

 <= /p>

I fully concur that there= can be multiple ways to realize external data channel negotiation, and enc= ourage specification of any useful alternative mechanisms.  We are simply proposing A mechanism to perform external data channel negot= iation using SDP for use in applications that desire to negotiate the use o= f specific protocols, such as MSRP and T140, that are usually negotiated us= ing SDP.  One advantage of using SDP is to ease interworking through gateways to endpoints that only suppor= t other transport options for the negotiated protocols (e.g., TLS/TCP for M= SRP).  We specifically selected MSRP, BFCP, T140 and T38 as example pr= otocols for this because of their common use by SIP and XMPP endpoints that expect to negotiate their use with SDP.=   It becomes even more valuable when the protocol comes with various S= DP attributes that also need to be negotiated (like accept-types and other = file attributes for MSRP).

 <= /p>

BR, Richard

 <= /p>

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Tuesday, October 15, 2013 1:40 AM
To: Ejzak, Richard P (Richard); dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

On 10/15/2013 12:48 AM, Ejzak, Richard P (Richard) w= rote:

Hi Harald,

I just realized that ther= e may be some confusion over the role of the browser in preparing SDP for e= xternal negotiation of DataChannels in our proposal.  The answer is zip/nada/zero/nothing/nichevo.  The browser just prepares t= he m line for the SCTP association, while the JS application creates DataCh= annels using the existing API (selecting to not use the in-band Open messag= e) and adds the DataChannel-specific attributes defined in the document to the SDP (to perform the external Dat= aChannel negotiation with the peer).  The browser’s role in supp= orting external DataChannel negotiation is exactly what is documented in th= e current DC drafts (although some minor clarifications might be appropriate).


Re-reading the proposal, and matching up with draft-ietf-mmusic-sctp-sdp-04= .txt, I'm less worried about this proposal than I initially was. The attrib= utes you are defining aren't extensions of attributes defined there (which = worried me), they're new, and therefore, by the rules of SDP, ignorable.

I still think it's a Bad Idea, for all the reasons that came up in the RTCW= EB meeting in Florida, but it shouldn't be actively harmful.

 <= /p>

BR, Richard

 <= /p>

From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.= org] On Behalf Of Ejzak, Richard P (Richard)
Sent: Monday, October 14, 2013 8:46 AM
To: Harald Alvestrand; dispatch= @ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

Hi Harald,

We are not proposing to r= evisit any decision of the rtcweb group.  We are not proposing to chan= ge the design of the data channel (although we identify one small issue where a small change might be appropriate but is not necessary).&nbs= p; The data channel design allows for use of an external negotiation mechan= ism as an alternative to in-band negotiation.  This draft simply descr= ibes how one can use SDP to facilitate such an external negotiation mechanism.

 <= /p>

Please see the draft that= we uploaded yesterday on the topic.

 <= /p>

BR, Richard

 <= /p>

From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.= org] On Behalf Of Harald Alvestrand
Sent: Monday, October 14, 2013 4:12 AM
To: dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

For the purposes of RTCWEB, this option was discusse= d at the IETF meeting in Orlando, and soundly rejected in favour of using a= n inband approach (with the option of leaving the negotiation to be done by= non-standardized means).

As long as the approach proposed is that of using WebRTC data channels, I d= o not see any advantage to revising that decision.

Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 a= nd CLUE control seems like perfectly reasonable things to do.

I don't see any reason to believe that revisiting RTCWEB's decision about S= DP usage for such negotiation is reasonable.

On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote:

This is a charter proposa= l for “SDP negotiation of DataChannel sub-protocols” in accorda= nce with the Oct.  7 deadline for dispatch.

 <= /p>

The rtcweb DataChannel is= the primary mechanism available for a WebRTC application to establish tran= sport for media protocols other than audio and video, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol.  While WebS= ockets is an option for transport of some of these protocols, DataChannels = provides a more general solution that works in all cases, particularly peer= -to-peer cases.  Many applications using these kinds of protocols (usually based on SIP or XMPP) also expect to neg= otiate their use with SDP.

 <= /p>

The rtcweb DataChannel de= sign allows two means of creating a DataChannel: either via in-band negotia= tion, or external negotiation.  No external negotiation mechanism is defined in the core DataChannel specification to allow applic= ations the freedom to choose how to perform the external negotiation.

 <= /p>

We propose to charter wor= k to:

1.      Define generic SDP proce= dures to enable external negotiation of DataChannel sub-protocols to establ= ish DataChannel transport for sub-protocol sessions, and to negotiate the use of sub-protocol specific options.

2.      Describe how to use the = generic SDP procedures defined in 1 to negotiate DataChannel transport for = specific protocols, potentially including MSRP, BFCP, T.140, T.38 and the CLUE control protocol.

 <= /p>

We envision that one draf= t is sufficient for item 1, and one draft per protocol is needed for item 2= .  We provided an early draft in http://datatracker.ietf.org/doc/draft-marcon-msrp-over= -webrtc-data-channels/ that describes a solution for 1 and provides details specific to MSRP.  We= have split this document in two parts and made some significant revisions = based on off-line discussions (including a bar bof in Berlin).  We int= end to upload both new documents well in advance of the doc deadline.

 <= /p>

Two high level issues wer= e identified, which the new docs will attempt to address:=

1.      How will DataChannel sub= -protocols be registered (re-use an existing registry or create a new one) = and if it’s a new registry how to define the relationship to existing protocols.  This issue deserves additional review and dis= cussion.

2.      Issues related to SCTP s= tream id assignment.  We have very recently concluded that there shoul= d be no impact on the DataChannel design as long as the application has free reign to create a DataChannel at each peer using the same stream = id number. 

 <= /p>

Comments/support are enco= uraged.

 <= /p>

Richard=

 <= /p>

 <= /p> 



_______________________________________________
dispatch mailing list
dispatch@ietf.org<=
/pre>

https://www=
.ietf.org/mailman/listinfo/dispatch

 



-- 
Surveillance is pervasive. Go Dark.
--_000_56C2F665D49E0341B9DF5938005ACDF812409FDEMUMBX005nsnintr_-- From richard.ejzak@alcatel-lucent.com Wed Oct 16 08:52:21 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC511E8146 for ; Wed, 16 Oct 2013 08:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEqj424RlEz3 for ; Wed, 16 Oct 2013 08:52:15 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF8311E8304 for ; Wed, 16 Oct 2013 08:51:58 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9GFpr9A006961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Oct 2013 10:51:54 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r9GFpnCI011035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 11:51:52 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 16 Oct 2013 11:51:51 -0400 From: "Ejzak, Richard P (Richard)" To: "Rauschenbach, Uwe (NSN - DE/Munich)" , "Harald Alvestrand" , "dispatch@ietf.org" Thread-Topic: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols Thread-Index: AQHOyXFpmsrsnLo/JkSWxLuPpwN6vpn182nAgAHIuwD//70dAA== Date: Wed, 16 Oct 2013 15:51:51 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86AAA9@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F3D86823C@US70UWXCHMBA04.zam.alcatel-lucent.com> <525BB558.3090507@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86A284@US70UWXCHMBA04.zam.alcatel-lucent.com> <03FBA798AC24E3498B74F47FD082A92F3D86A53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <525CE348.7070208@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86A82B@US70UWXCHMBA04.zam.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF812409F@DEMUMBX005.nsn-intra.net> In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF812409F@DEMUMBX005.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F3D86AAA9US70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:52:21 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F3D86AAA9US70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Uwe, Of course this would be the easiest approach. But I have seen no support f= or such an option in WebRTC, even after lengthy discussion on the list some= months ago. WebRTC only supports audio and video media over SRTP. If a W= ebRTC application is to be able to use T140, the only option in the media p= lane is to use DataChannel transport. We could potentially define a signal= ing plane option based on WebSockets, and we can have the discussion about = which is the better option (in my opinion DataChannel transport wins), but = it seems quite reasonable to at least propose the option for discussion. BR, Richard From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:uwe.rauschenbach@nsn.com] Sent: Wednesday, October 16, 2013 10:40 AM To: Ejzak, Richard P (Richard); Harald Alvestrand; dispatch@ietf.org Subject: RE: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols Hi Richard, For T.140, there is an RTP payload format defined (RFC4103). What would be the benefit for standardizing an additional Data Channel bind= ing for it, as opposed to using RTP? Kind regards, Uwe From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel-lucent.com] Sent: Tuesday, October 15, 2013 9:52 PM To: Harald Alvestrand; dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols Hi Harald, At least we are making some progress... My recollection of the Florida rtcweb session was that external data channe= l negotiation was considered to be a useful concept (which is why it was i= ncluded in the data channel design), but that it was premature to assume th= at SDP should be the primary mechanism to realize it. So the application h= as the responsibility to implement whatever external negotiation mechanism = it chooses to use. Options include using another data channel to transport= external negotiation messages, and using other non-SDP format protocols. = I don't recall any specific arguments against using SDP for external data c= hannel negotiation, other than the general anti-SDP comments. Please correct/elaborate my recollection of the Florida discussion to help = me understand your position here, as "Bad Idea" is a bit too ambiguous to b= e helpful. I fully concur that there can be multiple ways to realize external data cha= nnel negotiation, and encourage specification of any useful alternative mec= hanisms. We are simply proposing A mechanism to perform external data chan= nel negotiation using SDP for use in applications that desire to negotiate = the use of specific protocols, such as MSRP and T140, that are usually nego= tiated using SDP. One advantage of using SDP is to ease interworking throu= gh gateways to endpoints that only support other transport options for the = negotiated protocols (e.g., TLS/TCP for MSRP). We specifically selected MS= RP, BFCP, T140 and T38 as example protocols for this because of their commo= n use by SIP and XMPP endpoints that expect to negotiate their use with SDP= . It becomes even more valuable when the protocol comes with various SDP a= ttributes that also need to be negotiated (like accept-types and other file= attributes for MSRP). BR, Richard From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Tuesday, October 15, 2013 1:40 AM To: Ejzak, Richard P (Richard); dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols On 10/15/2013 12:48 AM, Ejzak, Richard P (Richard) wrote: Hi Harald, I just realized that there may be some confusion over the role of the brows= er in preparing SDP for external negotiation of DataChannels in our proposa= l. The answer is zip/nada/zero/nothing/nichevo. The browser just prepares= the m line for the SCTP association, while the JS application creates Data= Channels using the existing API (selecting to not use the in-band Open mess= age) and adds the DataChannel-specific attributes defined in the document t= o the SDP (to perform the external DataChannel negotiation with the peer). = The browser's role in supporting external DataChannel negotiation is exact= ly what is documented in the current DC drafts (although some minor clarifi= cations might be appropriate). Re-reading the proposal, and matching up with draft-ietf-mmusic-sctp-sdp-04= .txt, I'm less worried about this proposal than I initially was. The attrib= utes you are defining aren't extensions of attributes defined there (which = worried me), they're new, and therefore, by the rules of SDP, ignorable. I still think it's a Bad Idea, for all the reasons that came up in the RTCW= EB meeting in Florida, but it shouldn't be actively harmful. BR, Richard From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard) Sent: Monday, October 14, 2013 8:46 AM To: Harald Alvestrand; dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols Hi Harald, We are not proposing to revisit any decision of the rtcweb group. We are n= ot proposing to change the design of the data channel (although we identify= one small issue where a small change might be appropriate but is not neces= sary). The data channel design allows for use of an external negotiation m= echanism as an alternative to in-band negotiation. This draft simply descr= ibes how one can use SDP to facilitate such an external negotiation mechani= sm. Please see the draft that we uploaded yesterday on the topic. BR, Richard From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: Monday, October 14, 2013 4:12 AM To: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel su= b-protocols For the purposes of RTCWEB, this option was discussed at the IETF meeting i= n Orlando, and soundly rejected in favour of using an inband approach (with= the option of leaving the negotiation to be done by non-standardized means= ). As long as the approach proposed is that of using WebRTC data channels, I d= o not see any advantage to revising that decision. Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 a= nd CLUE control seems like perfectly reasonable things to do. I don't see any reason to believe that revisiting RTCWEB's decision about S= DP usage for such negotiation is reasonable. On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote: This is a charter proposal for "SDP negotiation of DataChannel sub-protocol= s" in accordance with the Oct. 7 deadline for dispatch. The rtcweb DataChannel is the primary mechanism available for a WebRTC appl= ication to establish transport for media protocols other than audio and vid= eo, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol. While W= ebSockets is an option for transport of some of these protocols, DataChanne= ls provides a more general solution that works in all cases, particularly p= eer-to-peer cases. Many applications using these kinds of protocols (usual= ly based on SIP or XMPP) also expect to negotiate their use with SDP. The rtcweb DataChannel design allows two means of creating a DataChannel: e= ither via in-band negotiation, or external negotiation. No external negoti= ation mechanism is defined in the core DataChannel specification to allow a= pplications the freedom to choose how to perform the external negotiation. We propose to charter work to: 1. Define generic SDP procedures to enable external negotiation of Dat= aChannel sub-protocols to establish DataChannel transport for sub-protocol = sessions, and to negotiate the use of sub-protocol specific options. 2. Describe how to use the generic SDP procedures defined in 1 to nego= tiate DataChannel transport for specific protocols, potentially including M= SRP, BFCP, T.140, T.38 and the CLUE control protocol. We envision that one draft is sufficient for item 1, and one draft per prot= ocol is needed for item 2. We provided an early draft in http://datatracke= r.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/ that describes = a solution for 1 and provides details specific to MSRP. We have split this= document in two parts and made some significant revisions based on off-lin= e discussions (including a bar bof in Berlin). We intend to upload both ne= w documents well in advance of the doc deadline. Two high level issues were identified, which the new docs will attempt to a= ddress: 1. How will DataChannel sub-protocols be registered (re-use an existin= g registry or create a new one) and if it's a new registry how to define th= e relationship to existing protocols. This issue deserves additional revie= w and discussion. 2. Issues related to SCTP stream id assignment. We have very recently= concluded that there should be no impact on the DataChannel design as long= as the application has free reign to create a DataChannel at each peer usi= ng the same stream id number. Comments/support are encouraged. Richard _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch -- Surveillance is pervasive. Go Dark. --_000_03FBA798AC24E3498B74F47FD082A92F3D86AAA9US70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Uwe,=

Of course this would be t= he easiest approach.  But I have seen no support for such an option in= WebRTC, even after lengthy discussion on the list some months ago.  WebRTC only supports audio and video media over SRTP.  If = a WebRTC application is to be able to use T140, the only option in the medi= a plane is to use DataChannel transport.  We could potentially define = a signaling plane option based on WebSockets, and we can have the discussion about which is the better option (in my opinion= DataChannel transport wins), but it seems quite reasonable to at least pro= pose the option for discussion.

 <= /p>

BR, Richard

 <= /p>

From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:uwe.r= auschenbach@nsn.com]
Sent: Wednesday, October 16, 2013 10:40 AM
To: Ejzak, Richard P (Richard); Harald Alvestrand; dispatch@ietf.org=
Subject: RE: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

Hi Richard,

 <= /p>

For T.140, there is an RT= P payload format defined (RFC4103).

What would be the benefit= for standardizing an additional Data Channel binding for it, as opposed to= using RTP?

 <= /p>

Kind regards,
Uwe

 

 

From: Ejzak, Richard P (Richard) [mailto:richard.ejzak@alcatel-lucent.com]
Sent: Tuesday, October 15, 2013 9:52 PM
To: Harald Alvestrand; dispatch= @ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

Hi Harald,

At least we are making so= me progress…

 <= /p>

My recollection of the Fl= orida rtcweb session was that external data channel negotiation was conside= red to  be a useful concept (which is why it was included in the data channel design), but that it was premature to assume that SDP = should be the primary mechanism to realize it.  So the application has= the responsibility to implement whatever external negotiation mechanism it= chooses to use.  Options include using another data channel to transport external negotiation messages, and using= other non-SDP format protocols.  I don’t recall any specific ar= guments against using SDP for external data channel negotiation, other than= the general anti-SDP comments.

 <= /p>

Please correct/elaborate = my recollection of the Florida discussion to help me understand your positi= on here, as “Bad Idea” is a bit too ambiguous to be helpful.

 <= /p>

I fully concur that there= can be multiple ways to realize external data channel negotiation, and enc= ourage specification of any useful alternative mechanisms.  We are simply proposing A mechanism to perform external data channel negot= iation using SDP for use in applications that desire to negotiate the use o= f specific protocols, such as MSRP and T140, that are usually negotiated us= ing SDP.  One advantage of using SDP is to ease interworking through gateways to endpoints that only suppor= t other transport options for the negotiated protocols (e.g., TLS/TCP for M= SRP).  We specifically selected MSRP, BFCP, T140 and T38 as example pr= otocols for this because of their common use by SIP and XMPP endpoints that expect to negotiate their use with SDP.=   It becomes even more valuable when the protocol comes with various S= DP attributes that also need to be negotiated (like accept-types and other = file attributes for MSRP).

 <= /p>

BR, Richard

 <= /p>

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Tuesday, October 15, 2013 1:40 AM
To: Ejzak, Richard P (Richard); dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

On 10/15/2013 12:48 AM, Ejzak, Richard P (Richard) w= rote:

Hi Harald,

I just realized that ther= e may be some confusion over the role of the browser in preparing SDP for e= xternal negotiation of DataChannels in our proposal.  The answer is zip/nada/zero/nothing/nichevo.  The browser just prepares t= he m line for the SCTP association, while the JS application creates DataCh= annels using the existing API (selecting to not use the in-band Open messag= e) and adds the DataChannel-specific attributes defined in the document to the SDP (to perform the external Dat= aChannel negotiation with the peer).  The browser’s role in supp= orting external DataChannel negotiation is exactly what is documented in th= e current DC drafts (although some minor clarifications might be appropriate).


Re-reading the proposal, and matching up with draft-ietf-mmusic-sctp-sdp-04= .txt, I'm less worried about this proposal than I initially was. The attrib= utes you are defining aren't extensions of attributes defined there (which = worried me), they're new, and therefore, by the rules of SDP, ignorable.

I still think it's a Bad Idea, for all the reasons that came up in the RTCW= EB meeting in Florida, but it shouldn't be actively harmful.

 <= /p>

BR, Richard

 <= /p>

From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.= org] On Behalf Of Ejzak, Richard P (Richard)
Sent: Monday, October 14, 2013 8:46 AM
To: Harald Alvestrand; dispatch= @ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

Hi Harald,

We are not proposing to r= evisit any decision of the rtcweb group.  We are not proposing to chan= ge the design of the data channel (although we identify one small issue where a small change might be appropriate but is not necessary).&nbs= p; The data channel design allows for use of an external negotiation mechan= ism as an alternative to in-band negotiation.  This draft simply descr= ibes how one can use SDP to facilitate such an external negotiation mechanism.

 <= /p>

Please see the draft that= we uploaded yesterday on the topic.

 <= /p>

BR, Richard

 <= /p>

From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.= org] On Behalf Of Harald Alvestrand
Sent: Monday, October 14, 2013 4:12 AM
To: dispatch@ietf.org
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataCha= nnel sub-protocols

 

For the purposes of RTCWEB, this option was discusse= d at the IETF meeting in Orlando, and soundly rejected in favour of using a= n inband approach (with the option of leaving the negotiation to be done by= non-standardized means).

As long as the approach proposed is that of using WebRTC data channels, I d= o not see any advantage to revising that decision.

Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 a= nd CLUE control seems like perfectly reasonable things to do.

I don't see any reason to believe that revisiting RTCWEB's decision about S= DP usage for such negotiation is reasonable.

On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote:

This is a charter proposa= l for “SDP negotiation of DataChannel sub-protocols” in accorda= nce with the Oct.  7 deadline for dispatch.

 <= /p>

The rtcweb DataChannel is= the primary mechanism available for a WebRTC application to establish tran= sport for media protocols other than audio and video, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol.  While WebS= ockets is an option for transport of some of these protocols, DataChannels = provides a more general solution that works in all cases, particularly peer= -to-peer cases.  Many applications using these kinds of protocols (usually based on SIP or XMPP) also expect to neg= otiate their use with SDP.

 <= /p>

The rtcweb DataChannel de= sign allows two means of creating a DataChannel: either via in-band negotia= tion, or external negotiation.  No external negotiation mechanism is defined in the core DataChannel specification to allow applic= ations the freedom to choose how to perform the external negotiation.

 <= /p>

We propose to charter wor= k to:

1.      Define generic SDP proce= dures to enable external negotiation of DataChannel sub-protocols to establ= ish DataChannel transport for sub-protocol sessions, and to negotiate the use of sub-protocol specific options.

2.      Describe how to use the = generic SDP procedures defined in 1 to negotiate DataChannel transport for = specific protocols, potentially including MSRP, BFCP, T.140, T.38 and the CLUE control protocol.

 <= /p>

We envision that one draf= t is sufficient for item 1, and one draft per protocol is needed for item 2= .  We provided an early draft in http://datatracker.ietf.org/doc/draft-marcon-msrp-over= -webrtc-data-channels/ that describes a solution for 1 and provides details specific to MSRP.  We= have split this document in two parts and made some significant revisions = based on off-line discussions (including a bar bof in Berlin).  We int= end to upload both new documents well in advance of the doc deadline.

 <= /p>

Two high level issues wer= e identified, which the new docs will attempt to address:=

1.      How will DataChannel sub= -protocols be registered (re-use an existing registry or create a new one) = and if it’s a new registry how to define the relationship to existing protocols.  This issue deserves additional review and dis= cussion.

2.      Issues related to SCTP s= tream id assignment.  We have very recently concluded that there shoul= d be no impact on the DataChannel design as long as the application has free reign to create a DataChannel at each peer using the same stream = id number. 

 <= /p>

Comments/support are enco= uraged.

 <= /p>

Richard=

 <= /p>

 <= /p>

 

_______________________________________________
dispatch mailing list
dispatch@ietf.org<=
/pre>

https://www=
.ietf.org/mailman/listinfo/dispatch

 

 

-- 
Surveillance is pervasive. Go Dark.
--_000_03FBA798AC24E3498B74F47FD082A92F3D86AAA9US70UWXCHMBA04z_-- From mary.ietf.barnes@gmail.com Fri Oct 18 15:24:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D1D21F8423 for ; Fri, 18 Oct 2013 15:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTSGXAltx3XK for ; Fri, 18 Oct 2013 15:24:25 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id D782421F9A43 for ; Fri, 18 Oct 2013 15:24:19 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id d4so2370209qej.35 for ; Fri, 18 Oct 2013 15:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=+zFp8hyHh0YZjq1IWW2Xc/xXCeWMNhWYYhZ/DTsvbN4=; b=jfYRmKthMX3bovM5skiVR2MRMdM8ZdDAYTCCKcD4q4jmOkZU7CY5etI2m1eMpmHk4R 3U0yWdKfBpLx4HDe1+zrEuUuRfkQFDjAdAm2/d7e/aWyDz4pwhYXWG6u6U2ioF6uzH0Z AGzjc19zQoCTtkejiEHL1ocY+k4ijLPLCMxZXjT7A2qw28KOSr6OrOl3EOpWBf/DulNr IonB+s02yJQiudMurRA8v3ABkLqWVVEZB2YnEjIyHp46uNlX2Jdy9AtqJfSTJ9yf+T1F RDn8aPAcfDVmWP9BY8qYLnwG9dZAQXJ8clvGKJRRw5uWGVlZzrFSupcVcN1y2ZjFmjoX 1X9Q== MIME-Version: 1.0 X-Received: by 10.224.165.129 with SMTP id i1mr5334469qay.114.1382135059113; Fri, 18 Oct 2013 15:24:19 -0700 (PDT) Received: by 10.49.117.234 with HTTP; Fri, 18 Oct 2013 15:24:19 -0700 (PDT) Date: Fri, 18 Oct 2013 17:24:19 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=089e0158b11e3af7bb04e90b65c2 Cc: Cullen Jennings , "rai-ads@tools.ietf.org" Subject: [dispatch] DISPATCH Topics - IETF-88 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 22:24:26 -0000 --089e0158b11e3af7bb04e90b65c2 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Based on WG discussions and consultation with the ADs, the following topic is proposed for discussion at the DISPATCH WG session at the IETF-88 meeting: 1) SDP negotiation of DataChannel sub-protocols: Document: http://datatracker.ietf.org/doc/draft-ejzak-dispatch-webrtc-data-channel-sdpneg/ Charter Proposal: http://www.ietf.org/mail-archive/web/dispatch/current/msg05072.html We will post the preliminary agenda shortly, but the plan is to allocate 45-50 minutes for this discussion. Since we have been allocated a 2.5 hour slot, the ADs are considering options for using the other 1.5 hours of the slot. The following topics/documents (items 2-6) that have been put forth since IETF-87 (and some before) will not be discussed because a problem statement is needed and/or needs refinement, and additional WG feedback/discussion is required. The proponents should have already received feedback from the WG chairs. 2) http://datatracker.ietf.org/doc/draft-klatsky-dispatch-ipv6-impact-ipv4/ 3) http://www.ietf.org/id/draft-ilan-dispatch-subscription-diff-list-01.txt Discussion: http://www.ietf.org/mail-archive/web/dispatch/current/msg05063.html 4) Call Management and USSD Discussion: http://www.ietf.org/mail-archive/web/dispatch/current/msg05062.html 5) SIP Problem statement Discussion: http://www.ietf.org/mail-archive/web/dispatch/current/msg05017.html http://www.ietf.org/mail-archive/web/dispatch/current/msg05041.html The following document(s) is not planned to be progressed: 6) https://datatracker.ietf.org/doc/draft-kaplan-dispatch-sip-205-response/ This document was motivated by the STRAW WG, however, that WG has decided to just the 200 response code, so there does not appear to be a need for this new response code: http://www.ietf.org/mail-archive/web/straw/current/threads.html#00162 The following document has been dispatched since the IETF-87 meeting: 7) http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01 Dispatched to the SIPCORE WG. Note: SIPCORE WG is NOT meeting at IETF-88. Discussion of this document should continue on the SIPCORE WG mailing list. Note, this document has not yet been agreed as a WG document - the chairs will make that call for consensus at some point in the future. Thanks, Mary DISPATCH WG co-chair --089e0158b11e3af7bb04e90b65c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Based on =A0WG discussion= s and consultation with the ADs, the following topic is proposed for discus= sion at the DISPATCH WG session at the IETF-88 meeting:
1)=A0SDP negotiation of DataChannel sub-protocols:=A0
Char= ter Proposal:=A0

We will post the preliminary agenda shortly= , but the plan is to allocate 45-50 minutes for this discussion. =A0Since w= e have been allocated a 2.5 hour slot, the ADs are considering options for = using the other 1.5 hours of the slot. =A0

The following topics/documents (items= 2-6) =A0that have been put forth since IETF-87 (and some before) will not = be discussed because a problem statement is needed and/or needs refinement,= and additional WG feedback/discussion is required. =A0=A0The proponents sh= ould have already received feedback from the WG chairs.=A0



4) =A0Call Management and USSD

5)=A0SIP Problem state= ment
Discus= sion: =A0
 --089e0158b11e3af7bb04e90b65c2-- From richard.ejzak@alcatel-lucent.com Mon Oct 21 15:22:56 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7A511E86DB for ; Mon, 21 Oct 2013 15:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.447 X-Spam-Level: X-Spam-Status: No, score=-10.447 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCOxtyl2ZVQk for ; Mon, 21 Oct 2013 15:22:51 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFCD11E8796 for ; Mon, 21 Oct 2013 15:22:46 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r9LMMjNj029179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 21 Oct 2013 17:22:45 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r9LMMg3V007421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Oct 2013 18:22:45 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 21 Oct 2013 18:22:43 -0400 From: "Ejzak, Richard P (Richard)" To: "dispatch@ietf.org" Thread-Topic: [dispatch] FW: New Version Notification for draft-ejzak-dispatch-msrp-data-channel-00.txt Thread-Index: AQHOzqwO0xvIymEeRUekfKkopmak4g== Date: Mon, 21 Oct 2013 22:22:41 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86B510@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [dispatch] FW: New Version Notification for draft-ejzak-dispatch-msrp-data-channel-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:22:56 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBP Y3RvYmVyIDIxLCAyMDEzIDU6MTggUE0NClRvOiBFanphaywgUmljaGFyZCBQIChSaWNoYXJkKTsg TUFSQ09OLCBKRVJPTUUgKEpFUk9NRSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtZWp6YWstZGlzcGF0Y2gtbXNycC1kYXRhLWNoYW5uZWwtMDAudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWVqemFrLWRpc3BhdGNoLW1zcnAtZGF0YS1jaGFu bmVsLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSaWNoYXJkIEVq emFrIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFm dC1lanphay1kaXNwYXRjaC1tc3JwLWRhdGEtY2hhbm5lbA0KUmV2aXNpb246CSAwMA0KVGl0bGU6 CQkgTVNSUCBvdmVyIFdlYlJUQyBkYXRhIGNoYW5uZWxzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0x MC0yMg0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEx DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWVqemFrLWRpc3BhdGNoLW1zcnAtZGF0YS1jaGFubmVsLTAwLnR4dA0KU3RhdHVzOiAgICAg ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWVqemFrLWRpc3BhdGNo LW1zcnAtZGF0YS1jaGFubmVsDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWVqemFrLWRpc3BhdGNoLW1zcnAtZGF0YS1jaGFubmVsLTAwDQoNCg0KQWJz dHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgdGhlIE1lc3NhZ2UgU2Vzc2lv biBSZWxheSBQcm90b2NvbCAoTVNSUCkNCiAgIGNhbiBiZSBpbnN0YW50aWF0ZWQgYXMgYSBXZWJS VEMgZGF0YSBjaGFubmVsIHN1Yi1wcm90b2NvbCwgdXNpbmcgdGhlDQogICB0aGUgU0RQIG9mZmVy L2Fuc3dlciBleGNoYW5nZS1iYXNlZCBleHRlcm5hbCBuZWdvdGlhdGlvbiBkZWZpbmVkIGluDQog ICBbSS1ELmVqemFrLWRpc3BhdGNoLXdlYnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnXS4gIFR3byBu ZXR3b3JrDQogICBjb25maWd1cmF0aW9ucyBhcmUgZG9jdW1lbnRlZDogYSBXZWJSVEMgZW5kLXRv LWVuZCBjb25maWd1cmF0aW9uDQogICAoY29ubmVjdGluZyB0d28gTVNSUCBvdmVyIGRhdGEgY2hh bm5lbCBlbmRwb2ludHMpLCBhbmQgYSBnYXRld2F5DQogICBjb25maWd1cmF0aW9uIChjb25uZWN0 aW5nIGFuIE1TUlAgb3ZlciBkYXRhIGNoYW5uZWwgZW5kcG9pbnQgd2l0aCBhbg0KICAgTVNSUCBv dmVyIFRDUCBlbmRwb2ludCkuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From mary.ietf.barnes@gmail.com Wed Oct 23 06:36:46 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A8F11E8395; Wed, 23 Oct 2013 06:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-KuSsfyr13o; Wed, 23 Oct 2013 06:36:45 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 46FA411E83EA; Wed, 23 Oct 2013 06:35:34 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id q59so801972wes.37 for ; Wed, 23 Oct 2013 06:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tDNLfBo/miobbdi0aYXtvNC3+Lbbela7+NAiOI+Z3Y4=; b=WODByasIgW19qy+4qc0db9D34A3NggOtnwrN+Co4ybguUFUnsuo4/XfIWIqsYQDmDD gub12bflkl86SSkM0xwLWqoDHa75RgNsKCwScVkqpbwV8P7hnnd+WwCIiloj06NGGEkm DMpMKCYDQMnGVOe0g7CzGvbVS3ZL3m5timb3UyTVzuy5THsXNRPZLcn5dbghyJDNqIE7 IG/E5M224BWCW38S/C4geWrFc2ayq0GqefzZvkbuwVSwfvAzh4G0hWZSLPRwqEfYqTuv TebMGudbA7LfVCT5SC6gdayyjb+Rcx6PgHON/CoDfjMe5nNv2wHmLfsCey8mDtmI1ySE aHYw== MIME-Version: 1.0 X-Received: by 10.180.73.239 with SMTP id o15mr2199677wiv.36.1382535330901; Wed, 23 Oct 2013 06:35:30 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Wed, 23 Oct 2013 06:35:30 -0700 (PDT) In-Reply-To: <5267A98E.5030902@gmail.com> References: <5267A98E.5030902@gmail.com> Date: Wed, 23 Oct 2013 08:35:30 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" , DISPATCH Content-Type: multipart/alternative; boundary=f46d0435c00849b7d104e9689783 Subject: [dispatch] Fwd: Draft agenda for the IETF-88 Transport Area Open Meeting (TSVAREA) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 13:36:46 -0000 --f46d0435c00849b7d104e9689783 Content-Type: text/plain; charset=ISO-8859-1 This might be of interest to folks. We are fortunate that there is not any RAI WG sessions scheduled opposite this, although I know some folks will want to be in JOSE, which might be why there isn't a conflict with other RAI sessions. Regards, Mary. ---------- Forwarded message ---------- From: Martin Stiemerling Date: Wed, Oct 23, 2013 at 5:48 AM Subject: Draft agenda for the IETF-88 Transport Area Open Meeting (TSVAREA) To: tsv-area@ietf.org Hi all, Please find below the draft agenda for the Transport Area Open Meeting (TSVAREA). The always up to date agenda is availabe here: http://www.ietf.org/**proceedings/88/agenda/agenda-**88-tsvarea Draft agenda for the Transport Area Open Meeting (TSVAREA) IETF-88, Vancouver THURSDAY, November 7, 2013 0900-1130 PST Responsible ADs: Spencer Dawkins Martin Stiemerling Mailing list: tsv-area@ietf.org Draft agenda: - Note Well and agenda bashing (5 minutes) - Latency workshop report (15 mins + 5 mins Q&A) Mat Ford -- http://www.internetsociety.**org/latency2013 - Evolution of IETF Transport Protocols (60 mins) -- http://www.ietf.org/mail-**archive/web/tsv-area/current/**msg00973.html - Google QUIC protocol (30 mins + 10 mins Q&A) Jim Roskind - Re-thinking ECN (20 + 5 mins) Bob Briscoe --f46d0435c00849b7d104e9689783 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This might be of interest to folks. =A0We are fortunate th= at there is not any RAI WG sessions scheduled opposite this, although I kno= w some folks will want to be in JOSE, which might be why there isn't a = conflict with other RAI sessions. =A0

Regards,
Mary.=A0

---------- Forwarded message ----------
From: Martin Stiemerling <mls.ietf@gmail.com>
Date: Wed, Oct 23, 2013 at 5:48 AM
Subject: Draft agenda for the IETF-88= Transport Area Open Meeting (TSVAREA)
To: tsv-area@ietf.org


Hi all,

Please find below the draft agenda for the Transport Area Open Meeting (TSV= AREA).

The always up to date agenda is availabe here:
http://www.ietf.org/proceedings/88/agenda/agenda-<= /u>88-tsvarea


Draft agenda for the =A0Transport Area Open Meeting (TSVAREA)
IETF-88, Vancouver
THURSDAY, November 7, 2013
0900-1130 PST

Responsible ADs:
Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Martin Stiemerling <mls.ietf@gmail.com>

Mailing list:
tsv-area@ietf.org


Draft agenda:
- Note Well and agenda bashing (5 minutes)
- Latency workshop report (15 mins + 5 mins Q&A)
=A0 Mat Ford
=A0 -- http://www.internetsociety.org/latency2013

- Evolution of IETF Transport Protocols =A0(60 mins)
=A0 -- http://www.ietf.org/mail-archive/web/t= sv-area/current/msg00973.html

- Google QUIC protocol (30 mins + 10 mins Q&A)
=A0 Jim Roskind

- Re-thinking ECN (20 + 5 mins)
=A0 Bob Briscoe

--f46d0435c00849b7d104e9689783-- From mary.ietf.barnes@gmail.com Wed Oct 23 07:23:23 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B9811E83B6 for ; Wed, 23 Oct 2013 07:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99-U7hAs2249 for ; Wed, 23 Oct 2013 07:23:22 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id EC24311E838A for ; Wed, 23 Oct 2013 07:23:21 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w61so866659wes.24 for ; Wed, 23 Oct 2013 07:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=QhRr8PH4skwKzSPkaWHpQps0CV2nh6L5PhLCcPhfOeU=; b=sA0fP0dGLbC13KOJZOIbQ2EHEpq9oYyHC5ububV1CLKYi6QYuFEg9bE+AIHXfhaCm1 AUsusxS6//F9flXK37/bJe0ypXZirR6J43kU/LnZ1nggu7uobtL9qjUNr8wH5C+ReTn9 CBYuVUfoYjBYNmn0qqRLjS+AUqTseSCrWnXFl04pTbL16KDMFuyGFMUSXdT2Adud6eqq EY2PK/jL1WMyooJ/XwDiarniCCLHgfJPtxcziMwltpx3sWFsrek3kButh6n7WxJ6Lxbh cfMQZZvWlOs9KMtKR8Iz1twRtEX7P5PxqhNR5s1ASZsZINuwbgufnFT9y3rszsDjTcdO R+IQ== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr1843259wic.36.1382538201122; Wed, 23 Oct 2013 07:23:21 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Wed, 23 Oct 2013 07:23:21 -0700 (PDT) In-Reply-To: References: <20131008184514.32189.48777.idtracker@ietfa.amsl.com> Date: Wed, 23 Oct 2013 09:23:21 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=047d7b6242525dd60d04e969420d Subject: [dispatch] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:23:23 -0000 --047d7b6242525dd60d04e969420d Content-Type: text/plain; charset=ISO-8859-1 Since this mailing list has twice as many members as the RAI area list, I thought it reasonable to forward here as well. As an aside, the RAI area list is not very busy at all and you might occasionally find discussions of interest. Regards, Mary. ---------- Forwarded message ---------- From: Mary Barnes Date: Tue, Oct 22, 2013 at 6:12 PM Subject: Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV To: "rai@ietf.org" , "rai-chairs@tools.ietf.org" < rai-chairs@tools.ietf.org> For folks that haven't be following Nomcom too closely, the nominations period is over and now is the time to provide feedback: https://datatracker.ietf.org/nomcom/2013/feedback/ Please consider providing feedback as we will have an new RAI AD starting in March. The most constructive feedback is specific examples and experiences you've had working with these folks that re-enforce whether or not you believe they can fulfill the job requirements. I will note that I think the RAI specific expertise is lacking in detail and as noted below (at the end of the email) the nomcom also welcomes input on that. Other areas list specific technical expertise that is required, for example. Regards, Mary. - Past Nomcom chair who knows what woefully inadequate comments that the community provides. ---------- Forwarded message ---------- From: NomCom Chair Date: Tue, Oct 8, 2013 at 1:45 PM Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV To: IETF Announcement List Cc: ietf@ietf.org UPDATE: nominations are too sparse in several of the IESG areas: APP, OAM, RAI, and TSV. If you know one or more of those areas, exercise your social network and submit nominations. We'll be very grateful! Is there someone you work with at IETF who has leadership potential and a growing track record? Please read this Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. If you're nominated, even if you support the present incumbent, being reviewed by Nomcom is great IETF experience. The questionnaire offers a chance to think about IETF and about your area. Whether or not your candidacy progresses this time, you'll have gained some valuable insights, and you'll have contributed greatly. This process only works because many IETFers take part; please join in. Lots more, including which positions are open, how to make a nomination (including nomination of yourself), and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees! --047d7b6242525dd60d04e969420d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Since this mailing list has twice as many members as the R= AI area list, I thought it reasonable to forward here as well. =A0As an asi= de, the RAI area list is not very busy at all and you might occasionally fi= nd discussions of interest.

Regards,
Mary.

-= --------- Forwarded message ----------
From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Tue, Oct 22, 2013 at 6:12 PM
Subject: Fwd: NOMCOM 2013 - UPDATED 2= nd Call for Nominations - APP, OAM, RAI, TSV
To: "rai@ietf.org" <r= ai@ietf.org>, "rai= -chairs@tools.ietf.org" <rai-chairs@tools.ietf.org>


For folks that haven't be following Nomcom too= closely, the nominations period is over and now is the time to provide fee= dback:
https://datatracker.ietf.org/nomcom/2013/feedback/

Please consider providing feedback as we will have an n= ew RAI AD starting in March. =A0The most constructive feedback is specific = examples and experiences you've had working with these folks that re-en= force whether or not you believe they can fulfill the job requirements. =A0= I will note that I think the RAI specific expertise is lacking in detail a= nd as noted below (at the end of the email) the nomcom also welcomes input = on that. =A0Other areas list specific technical expertise that is required,= for example.

Regards,
Mary.=A0
- Past Nomcom= chair who knows what woefully inadequate comments that the community provi= des. =A0

---------- For= warded message ----------
From: NomCom Chair <= nomcom-chair@iet= f.org>
Date: Tue, Oct 8, 2013 at 1:45 PM
Subject: NOMCO= M 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: ietf@ietf.org


UPDATE: nominations are too sparse in several of the IESG areas: = =A0APP, OAM,
RAI, and TSV. =A0If you know one or more of those areas, exercise your soci= al
network and submit nominations. =A0We'll be very grateful!

Is there someone you work with at IETF who has leadership potential and a growing track record? Please read this Nomcom call for nominations and cons= ider
nominating her or him. Or several folks! Deadline for nominations is Octobe= r 18.
Nominate soon to give your nominee(s) plenty time to fill in the questionna= ire.

If you're nominated, even if you support the present incumbent, being r= eviewed
by Nomcom is great IETF experience. =A0The questionnaire offers a chance to=
think about IETF and about your area. =A0Whether or not your candidacy prog= resses
this time, you'll have gained some valuable insights, and you'll ha= ve contributed
greatly. This process only works because many IETFers take part; please joi= n in.

Lots more, including which positions are open, how to make a nomination
(including nomination of yourself), and how to send us your feedback on
the desired expertise, follows.

IETFers, let's hear from you! =A0Make nominations, accept nominations!<= br>
If you have any questions about the process, feel free to get in touch with= me.

Best regards,

Allison for the Nomcom

Allison Mankin
Nomcom Chair 2013-14

----- The Info You Need for Nominating -----

The 2013-14 Nominating Committee (Nomcom) is seeking nominations
from now until October 18, 2013. The open positions being considered
by this year's Nomcom can be found later in this section, and also on this year's Nomcom website:

htt= ps://datatracker.ietf.org/nomcom/2013/

Information about the desired expertise for positions is here:
=A0 =A0 =A0 =A0 =A0 https://datatracker.ietf.org/nomcom/2013/expertis= e

Nominations may be made by selecting the Nominate link at the top of
the Nomcom 2013 home page, or by visiting the following URL:

https://datatracker.ietf.org/nomcom/2013/nominate/

Note that nominations made using the web tool require an ietf.org
datatracker account. You can create a datatracker ietf.org account
if you don't have one already by visiting the following URL:

https://datatracker.ietf.org/accounts/create/

Nominations may also be made by email to nomcom13 at ietf.org.
If you nominate by email, please include the word "Nominate" in t= he Subject
and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you
are making the nomination. If you use email, please use a separate email fo= r
each person you nominate, and for each position (if you are nominating one<= br> person for multiple positions).

Self-nomination is welcome! =A0No need to be shy.

Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing<= br> Nominees" described in RFC 5680. =A0As stated in RFC 5680: "The l= ist of
nominees willing to be considered for positions under review in the
current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a
datatracker account may access the lists. =A0In all other ways, the
confidentiality requirements of RFC 3777/BCP10 remain in effect. =A0All
feedback and all Nomcom deliberations will remain confidential and will
not be disclosed.

In order to ensure time to collect sufficient community feedback about
each of the willing nominees, nominations must be received by the
Nomcom on or before October 18, 2013. =A0Please submit your nominations
as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013.

The list of people and posts whose terms end with the March 2014 IETF meeti= ng,
and thus the positions for which we are accepting nominations:

IAOC
Chris Griffiths

IAB
Bernard Aboba
Marc Blanchet
Ross Callon
Eliot Lear
Hannes Tschofenig

IESG
Barry Leiba (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant (Routing)
Sean Turner (Security)
Martin Stiemerling (Transport)

Please be resourceful in identifying possible candidates for these
positions, as developing our talent is a very crucial requirement for
the IETF. =A0Also, please give serious consideration to accepting nominatio= ns
you receive.

The summaries of the desired expertise for the positions, developed by the<= br> respective bodies, are found at:

https://datatracker.ietf.org/nomcom/2013/expertise/

In addition to nominations, the Nomcom seeks community input on
the positions themselves. =A0We need and welcome the community's
views and input on the jobs within each organization. If you
have ideas on the positions' responsibilities (more, less,
different), please let us know. =A0You can send us email about this to
nomcom13 at ietf.org, and= we will use this feedback actively.

Thank you for your help in nominating a great pool of strong and interestin= g
nominees!


--047d7b6242525dd60d04e969420d-- From aallen@blackberry.com Thu Oct 24 09:53:25 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE2B11E8349 for ; Thu, 24 Oct 2013 09:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=1.096, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6UmcRIvHI-d for ; Thu, 24 Oct 2013 09:53:18 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id B515F11E8194 for ; Thu, 24 Oct 2013 09:52:16 -0700 (PDT) Received: from xct103ads.rim.net ([10.67.111.44]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 24 Oct 2013 12:51:42 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.03.0123.003; Thu, 24 Oct 2013 11:51:41 -0500 From: Andrew Allen To: "dispatch@ietf.org" Thread-Topic: draft-montemurro-gsma-imei-urn-17 and draft-allen-dispatch-imei-urn-as-instanceid-11 Thread-Index: Ac7Q2Frg6WAp2n8kShi0oIH/YyIftQ== Date: Thu, 24 Oct 2013 16:51:41 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338E3BCA2XMB104ADSrimnet_" MIME-Version: 1.0 Subject: [dispatch] draft-montemurro-gsma-imei-urn-17 and draft-allen-dispatch-imei-urn-as-instanceid-11 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:53:27 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338E3BCA2XMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Revisions of the following drafts were recently submitted to address the IE= TF last call comments. http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-17.txt http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-11.txt Offline discussion indicates that there are still concerns over the ABNF fo= r the IMEI and the privacy text in draft-montemurro-gsma-imei-urn-17. Main question on the ABNF is whether the ABNF should be extensible to suppo= rt additional NSS under the GSMA NID. The concern seems to be that new NSS= might be created without going through the IETF consensus process. The dra= ft states that this process will be used for approval of any additional NSS= . My concern is if we remove extensibility from the ANF now does that crea= te problems for parsers if new NSS are defined and approved in the future? I request comments on the list. Constructive criticism would be helpful wit= h proposed text to include to address the concerns particularly on the priv= acy issue. Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338E3BCA2XMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

 

Revisions of the following drafts were recently subm= itted to address the IETF last call comments.

 

http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-= 17.txt

 

http://www.ietf.org/id/draft-allen-dispat= ch-imei-urn-as-instanceid-11.txt

 

Offline discussion indicates that there are still co= ncerns over the ABNF for the IMEI and the privacy text in draft-montemurro-= gsma-imei-urn-17.

 

Main question on the ABNF is whether the ABNF should= be extensible to support additional NSS under the GSMA NID.  The conc= ern seems to be that new NSS might be created without going through the IET= F consensus process. The draft states that this process will be used for approval of any additional NSS.  My con= cern is if we remove extensibility from the ANF now does that create proble= ms for parsers if new NSS are defined and approved in the future?

 

I request comments on the list. Constructive critici= sm would be helpful with proposed text to include to address the concerns p= articularly on the privacy issue.

 

Andrew

 

 

---------------------------------------------------------------------
Th= is transmission (including any attachments) may contain confidential inform= ation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immed= iately reply to the sender and delete this information from your system. Us= e, dissemination, distribution, or reproduction of this transmission by uni= ntended recipients is not authorized and may be unlawful.
--_000_BBF5DDFE515C3946BC18D733B20DAD2338E3BCA2XMB104ADSrimnet_-- From wangjinzhu@chinamobile.com Fri Oct 25 02:08:47 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F99611E8172; Fri, 25 Oct 2013 02:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kmCg-uA0BVQ; Fri, 25 Oct 2013 02:08:43 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id ECDFA11E8301; Fri, 25 Oct 2013 02:08:39 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2526a34a6551-e4551; Fri, 25 Oct 2013 17:06:46 +0800 (CST) X-RM-TRANSID: 2ee2526a34a6551-e4551 Received: from cmccPC (unknown[10.2.43.175]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee2526a34a1287-d97e6; Fri, 25 Oct 2013 17:06:46 +0800 (CST) X-RM-TRANSID: 2ee2526a34a1287-d97e6 From: "wangjinzhu" To: , References: In-Reply-To: Date: Fri, 25 Oct 2013 17:08:17 +0800 Message-ID: <015a01ced161$be570550$3b050ff0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7M1qX5mj8t1rjSSm2cL2AWArn57ABMPHnQANM0JKA= Content-Language: zh-cn Cc: =?utf-8?B?J+mCk+eBteiOiS9MaW5nbGkgRGVuZyc=?= Subject: [dispatch] Request for discussion of end2end SIP Overload Control X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 09:08:47 -0000 Dear all Request for discussion of a proposal to end2end SIP Overload Control = (http://datatracker.ietf.org/doc/draft-wang-appsawg-end2end-overload-cont= rol). Since I cannot find the SOC session in this IETF meeting, I = submitted the draft to the appsawg. The submission cannot be changed as = the system is closed. I will re-submit the draft to the Soc wg or = Dispatch wg when the system is re-open. Any comments or suggestions will be greatly appreciated. Best Regards Jinzhu Wang China Mobile -----Original Mail----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2013=E5=B9=B410=E6=9C=8819=E6=97=A5 22:10 =E6=94=B6=E4=BB=B6=E4=BA=BA: Yu Qing; Deng Lingli; wangjinzhu; Qing Yu; = Jinzhu Wang; Lingli Deng =E4=B8=BB=E9=A2=98: New Version Notification for = draft-wang-appsawg-end2end-overload-control-00.txt A new version of I-D, draft-wang-appsawg-end2end-overload-control-00.txt has been successfully submitted by Jinzhu Wang and posted to the IETF = repository. Filename: draft-wang-appsawg-end2end-overload-control Revision: 00 Title: End-to-end Session Initiation Protocol (SIP) overload control Creation date: 2013-10-18 Group: Individual Submission Number of pages: 6 URL: = http://www.ietf.org/internet-drafts/draft-wang-appsawg-end2end-overload-c= ontrol-00.txt Status: = http://datatracker.ietf.org/doc/draft-wang-appsawg-end2end-overload-contr= ol Htmlized: = http://tools.ietf.org/html/draft-wang-appsawg-end2end-overload-control-00= Abstract: This draft proposes end-to-end Session Initiation Protocol (SIP) overload control, in which the edge servers of the SIP network throttle the arriving calls in order to control overload for the SIP network. Compared to the local and hop-by-hop SIP overload control, the end-to-end SIP overload control can achieve best performance. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From pkyzivat@alum.mit.edu Sun Oct 27 10:48:10 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C5C11E82A1 for ; Sun, 27 Oct 2013 10:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.123 X-Spam-Level: X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YilLVAqjjfIa for ; Sun, 27 Oct 2013 10:48:04 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id AE63A11E82A6 for ; Sun, 27 Oct 2013 10:48:02 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta02.westchester.pa.mail.comcast.net with comcast id iH9v1m00C0vyq2s51Ho2yd; Sun, 27 Oct 2013 17:48:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id iHo11m00f3ZTu2S3RHo1f5; Sun, 27 Oct 2013 17:48:02 +0000 Message-ID: <526D51D1.3090106@alum.mit.edu> Date: Sun, 27 Oct 2013 13:48:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382896082; bh=Da/9XSRzMJg1VSPxNW9dUhBxLKlwhXiT2vtq1i6lZGo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TbNqlG/JzyItgHOrwVh8bZFUTI8L8Rng8rsJR5kzHwWUl0DyZqQA2VRiFKzzeCzA8 o06QmyZ007Bgi6rfYUL8NBuKSfp7hB9ABMFzh2OBLm7GwJ1o+FPlTzxC7qtVagbbeC 8FvNtTHfbLlJQkDRbinnk/tnLJIu+3mbPBxXbS/yrmTU1Wx+SYatVXQ1wCsdeADfRd N/pWnS3YPrKGt5+PSs+5uSPty00bgNPX61HB9wohTAKXSJ77Vk8C3k7EIs/r8+bXtS l8ocgI3DkVAEuhoD6dOxY78rTm16cptNcaqrfhHWra549nT7S4NENiOwbUHgAOCnKL /IAcTu33a2QnQ== Subject: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 17:48:10 -0000 In general I think this document is looking pretty good. It is going in the right direction from my perspective. And I think its starting to become clear how to have this be an optional mechanism for webrtc. I'm starting to see how it could be used for CLUE, with and without webrtc. One thing bothers me: this is an ietf document, defining signaling. But it talks quite a lot about the webrtc API. It is certainly possible to use this specification in contexts where there are no browsers and no use of webrtc. ISTM it would be better to segregate all the webrtc stuff into an annex. Or maybe two documents are needed: one for SDP negotiation of sctp data channels, and one for webrtc external negotiation of data channels via the SDP mechanism. Esthetically I find the names "webrtc-DataChannel" and "wdcsa" quite unappealing. In particular, these data channels are usable (and will be used) in non-webrtc applications, so why do we need "webrtc" in the name? Thanks, Paul From richard.ejzak@alcatel-lucent.com Mon Oct 28 08:07:31 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9FF21F9EB6 for ; Mon, 28 Oct 2013 08:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8avrvcgrTzZF for ; Mon, 28 Oct 2013 08:07:25 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E418F11E8232 for ; Mon, 28 Oct 2013 08:07:14 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9SF7ALY012624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Oct 2013 10:07:10 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r9SF70ed018446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Oct 2013 11:07:10 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 28 Oct 2013 11:07:07 -0400 From: "Ejzak, Richard P (Richard)" To: "dispatch@ietf.org" Thread-Topic: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 Thread-Index: AQHO0zy+sKSI4kedvEmpZ63or4Q2CJoKNmXQ Date: Mon, 28 Oct 2013 15:07:06 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86D026@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <526D51D1.3090106@alum.mit.edu> In-Reply-To: <526D51D1.3090106@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 15:07:31 -0000 Thanks, Paul. I agree that the WebRTC specific aspects need to be clearly separated from = the core protocol aspects. I'll do that in the next version. I also agree= that "WebRTC" is not needed in either name. Are you ok with just "DataCha= nnel" and "dcsa" instead of "WebRTC-DataChannel" and "wdcsa"? I'm not real= ly picky about the names and am open to any reasonable alternative... BR, Richard > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Sunday, October 27, 2013 12:48 PM > To: dispatch@ietf.org > Subject: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data- > channel-sdpneg-00 >=20 > In general I think this document is looking pretty good. It is going in > the right direction from my perspective. And I think its starting to > become clear how to have this be an optional mechanism for webrtc. I'm > starting to see how it could be used for CLUE, with and without webrtc. >=20 > One thing bothers me: this is an ietf document, defining signaling. But > it talks quite a lot about the webrtc API. It is certainly possible to > use this specification in contexts where there are no browsers and no > use of webrtc. ISTM it would be better to segregate all the webrtc > stuff into an annex. Or maybe two documents are needed: one for SDP > negotiation of sctp data channels, and one for webrtc external > negotiation of data channels via the SDP mechanism. >=20 > Esthetically I find the names "webrtc-DataChannel" and "wdcsa" quite > unappealing. In particular, these data channels are usable (and will be > used) in non-webrtc applications, so why do we need "webrtc" in the > name? >=20 > Thanks, > Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Mon Oct 28 09:08:31 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29EF21E8087 for ; Mon, 28 Oct 2013 09:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPfITIpZwnN2 for ; Mon, 28 Oct 2013 09:08:27 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 957FD21E8093 for ; Mon, 28 Oct 2013 09:08:22 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta06.westchester.pa.mail.comcast.net with comcast id ibry1m0040ldTLk56g8M8v; Mon, 28 Oct 2013 16:08:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id ig8M1m00b3ZTu2S01g8M1E; Mon, 28 Oct 2013 16:08:21 +0000 Message-ID: <526E8BF5.7080206@alum.mit.edu> Date: Mon, 28 Oct 2013 12:08:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <526D51D1.3090106@alum.mit.edu> <03FBA798AC24E3498B74F47FD082A92F3D86D026@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86D026@US70UWXCHMBA04.zam.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382976501; bh=CMf1adCxf1uoYuLHSKKA065qjOuVjWPG3ydXrT7bNh4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Q86AYskg1oQhsA4xpI5JpMXJoYFzaQBOseTnIOQcFXTKLiyc4AnUJw6admtMz0itH VlDPnLeGhjmb0t7SzpeReLaqqGV010Y4s9a+jKQ0qy4zA4jmuu7YwaiH/0Gwb++3pn 3RX59wC/xL01sGCG683mtWfr/DvAZ0bIcIQzdsSw8g9JAIWrpHznLeP+9ZAsU1ruZv gEvc08X+H3VfebRJDAwo8RzBLb4P/b+Kjy8CAQFfm/pfw6b/n7dFE/1pn+h/4Is25r PHMSFWoaitg31lYLtnbi+yZyWp9Iox62eoCpWeq53PVgwmM3NdHsmHANLWm4wJ8dSC T/J61+VhcmK8g== Subject: Re: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:08:31 -0000 On 10/28/13 11:07 AM, Ejzak, Richard P (Richard) wrote: > Thanks, Paul. > > I agree that the WebRTC specific aspects need to be clearly separated from the core protocol aspects. I'll do that in the next version. Thanks! > I also agree that "WebRTC" is not needed in either name. Are you ok with just "DataChannel" and "dcsa" instead of "WebRTC-DataChannel" and "wdcsa"? I'm not really picky about the names and am open to any reasonable alternative... Its just an esthetic issue, so I'm not too picky. DataChannel is better than WebRTC-DataChannel. But IMO CamelCase identifiers aren't in stylistic agreement with SDP. So perhaps data-channel? "dcsa" seems reasonable. Thanks, Paul > BR, Richard > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Sunday, October 27, 2013 12:48 PM >> To: dispatch@ietf.org >> Subject: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data- >> channel-sdpneg-00 >> >> In general I think this document is looking pretty good. It is going in >> the right direction from my perspective. And I think its starting to >> become clear how to have this be an optional mechanism for webrtc. I'm >> starting to see how it could be used for CLUE, with and without webrtc. >> >> One thing bothers me: this is an ietf document, defining signaling. But >> it talks quite a lot about the webrtc API. It is certainly possible to >> use this specification in contexts where there are no browsers and no >> use of webrtc. ISTM it would be better to segregate all the webrtc >> stuff into an annex. Or maybe two documents are needed: one for SDP >> negotiation of sctp data channels, and one for webrtc external >> negotiation of data channels via the SDP mechanism. >> >> Esthetically I find the names "webrtc-DataChannel" and "wdcsa" quite >> unappealing. In particular, these data channels are usable (and will be >> used) in non-webrtc applications, so why do we need "webrtc" in the >> name? >> >> 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 brett@broadsoft.com Tue Oct 29 04:32:35 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3F421E8131 for ; Tue, 29 Oct 2013 04:32: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRJJyTmVPYgL for ; Tue, 29 Oct 2013 04:32:24 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 06DB811E816B for ; Tue, 29 Oct 2013 04:32:18 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 29 Oct 2013 04:33:32 -0700 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Tue, 29 Oct 2013 04:33:07 -0700 From: Brett Tate To: wangjinzhu , "dispatch@ietf.org" Thread-Topic: [dispatch] Request for discussion of end2end SIP Overload Control Thread-Index: Ac7M1qX5mj8t1rjSSm2cL2AWArn57ABMPHnQANM0JKAA0CzDkA== Date: Tue, 29 Oct 2013 11:33:06 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A066983@MBX08.citservers.local> References: <015a01ced161$be570550$3b050ff0$@com> In-Reply-To: <015a01ced161$be570550$3b050ff0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dispatch] Request for discussion of end2end SIP Overload Control X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 11:32:35 -0000 PiBBbnkgY29tbWVudHMgb3Igc3VnZ2VzdGlvbnMgd2lsbCBiZSBncmVhdGx5IGFwcHJlY2lhdGVk Lg0KDQpIaSwNCg0KQ29uY2VybmluZyBkcmFmdC13YW5nLWFwcHNhd2ctZW5kMmVuZC1vdmVybG9h ZC1jb250cm9sLTAwLCB0aGUgaG9wLWJ5LWhvcCBuYXR1cmUgb2YgdGhlIDUwMyBsaWtlbHkgbWVh bnMgdGhhdCBpdCBjYW5ub3QgYmUgdXNlZCB0byBzYXRpc2Z5IHRoZSBkZXNpcmVkIGVuZC10by1l bmQgYWxnb3JpdGhtLiAgTW9yZSBzcGVjaWZpY2FsbHksIHRoZSBhbGdvcml0aG0gdG8gdXNlIDUw MyBhcyBtZW50aW9uZWQgd2l0aGluIHNlY3Rpb24gMi4yIGFwcGVhcnMgdG8gaGF2ZSB0d28gZmxh d3Mgd291bGQgbGlrZWx5IG5lZWQgdG8gYmUgYWRkcmVzc2VkLg0KDQoxKSBUaGUgNTAzIG1pZ2h0 IHRyaWdnZXIgYWR2YW5jaW5nIHRvIHRoZSBuZXh0IGxvY2F0aW9uLiAgVGh1cyB0aGUgZWRnZSBz ZXJ2ZXIgd291bGQgbm90IGFsd2F5cyByZWNlaXZlIHRoZSA1MDMuDQoNCjIpIFJGQyAzMjYxIHNl Y3Rpb24gMTYuNyBpbmRpY2F0ZXMgIkEgcHJveHkgd2hpY2ggcmVjZWl2ZXMgYSA1MDMgKFNlcnZp Y2UgVW5hdmFpbGFibGUpIHJlc3BvbnNlIFNIT1VMRCBOT1QgZm9yd2FyZCBpdCB1cHN0cmVhbSB1 bmxlc3MgaXQgY2FuIGRldGVybWluZSB0aGF0IGFueSBzdWJzZXF1ZW50IHJlcXVlc3RzIGl0IG1p Z2h0IHByb3h5IHdpbGwgYWxzbyBnZW5lcmF0ZSBhIDUwMyIuICBUaHVzIG1pZGRsZSBib3hlcyBm cmVxdWVudGx5IGNvbnZlcnQgYSA1MDMgaW50byBhIDUwMC4NCg0KRHJhZnQtd2FuZy1hcHBzYXdn LWVuZDJlbmQtb3ZlcmxvYWQtY29udHJvbC0wMCBzZWN0aW9uIDIuMjoNCg0KIkluIGVuZC10by1l bmQgb3ZlcmxvYWQgY29udHJvbCwgdGhlIGNvcmUgc2VydmVycyBTSE9VTEQgb25seQ0KIGltcGxl bWVudCBsb2NhbCBvdmVybG9hZCBjb250cm9sIHRoYXQgcmVqZWN0cyByZXF1ZXN0cyBieSB1c2lu ZyA1MDMNCiByZXNwb25zZXMuICBXaGVuIHJlY2VpdmluZyBhIDUwMyByZXNwb25zZSBmcm9tIGEg ZG93bnN0cmVhbSBuZWlnaGJvciwNCiB0aGUgc2VydmVyIFNIT1VMRCBmb3J3YXJkIHRoaXMgcmVz cG9uc2UgdG8gdGhlIHVwc3RyZWFtIG5laWdoYm9yLA0KIGZyb20gd2hpY2ggdGhlIElOVklURSBy ZXF1ZXN0IHJlbGF0ZWQgdG8gdGhpcyByZXNwb25zZSBoYXMgYmVlbg0KIHJlY2VpdmVkLiAgSW4g dGhpcyB3YXksIHRoZSA1MDMgcmVzcG9uc2Ugd2lsbCBmaW5hbGx5IGJlIGZvcndhcmRlZCB0bw0K IHRoZSBlZGdlIHNlcnZlci4gIFRoZSBlZGdlIHNlcnZlcnMgU0hPVUxEIGNhbGN1bGF0ZSBhbmQg Zm9sbG93IHRoZQ0KIHJlc3RyaWN0aW9ucyBvbiB0aGUgdHJhZmZpYyBhZG1pdHRlZCB0byB0aGUg U0lQIG5ldHdvcmsgYmFzZWQgb24gdGhlDQogcmVjZWl2ZWQgNTAzIHJlc3BvbnNlcy4iDQoNClRo YW5rcywNCkJyZXR0DQoNCg0K From mary.ietf.barnes@gmail.com Tue Oct 29 07:11:41 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C7511E815F for ; Tue, 29 Oct 2013 07:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.614 X-Spam-Level: X-Spam-Status: No, score=-101.614 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McBYkRe8NEoA for ; Tue, 29 Oct 2013 07:11:40 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 24CC111E8179 for ; Tue, 29 Oct 2013 07:11:34 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id z12so8423289wgg.24 for ; Tue, 29 Oct 2013 07:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OMD8JYRI6VR+YPG3OPatlN9ankLL26mNWTWiBfRs4eQ=; b=W0YlIaY13KoiHnRnEXlkQzeGsNIr1asT786enbyvem7EQM4ZbGPjUZgEipxneNKCZS PjDPV7LRI+BJWTa+V9q1wrQK1uQveQG75I7F79g3b+yjp/EmPew55juMibla1nI54sM5 8BfGL+CbXWfaWuCfKbPNtQKSgs3t5VYepUuO766ETCtkOP7ZnQQY2c341f02S2xKiOYA /JrCC4Fmz/KaP2oFvpWrAnFPCMcE48IFCu+iDthCMYaN8qeWxqKyQ8527IKVfoMPyrjs nCMPQ7hOZuc1+OCe7eHG5Tcf0yWIC2oBG5/HwIo7xxIyVf25dfD1VVuo6RngEOWCRK17 EW3g== MIME-Version: 1.0 X-Received: by 10.194.232.4 with SMTP id tk4mr2243022wjc.79.1383055894088; Tue, 29 Oct 2013 07:11:34 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Tue, 29 Oct 2013 07:11:33 -0700 (PDT) In-Reply-To: <523124B0.2000305@ntt-at.co.jp> References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> <523124B0.2000305@ntt-at.co.jp> Date: Tue, 29 Oct 2013 09:11:33 -0500 Message-ID: From: Mary Barnes To: Mayumi Ohsugi Content-Type: multipart/alternative; boundary=001a11348472459d1404e9e1cbfb Cc: DISPATCH Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 14:11:41 -0000 --001a11348472459d1404e9e1cbfb Content-Type: text/plain; charset=ISO-8859-1 In reviewing the document in preparation for the PROTO write-up, I have a few comments (minor and nits) that should be addressed prior to the document being progressed. Regards, Mary. Comments: --------------- - General: domains used in this document must use a reserved domain such as "example.com" and must not use real domains. Thus, all occurrences of ericsson.com need to be changed to example.com - Section 1.5. Bulleted list, first bullet. I would suggest you just leave out the mention of LI. Emergency services should be a sufficient example. - Section 1.5, last numbered list, item 2. I had a hard time groking this sentence and had to read several times. I would suggest rewording something like (if I've properly interpreted the intent): OLD: Different nodes spanning over different networks may need to be able to act differently on type of traffic, when implicit schemes are used, it would require distribution of such enterprise specific logic over multiple nodes in multiple operators. That is clearly not a manageable architecture and solution. NEW: Nodes spanning multiple networks often need to have different behavior depending upon the type of traffic. When this is done using implicit schemes, enterprise specific logic must be distributed across multiple nodes in multiple operator's networks. That is clearly not a manageable architecture and solution. - Section 1.5, last sentence. I don't think that statement is sufficient for what this document is doing. I would suggest you change that sentence to something like the following: OLD: Given the above background this document will formulate requirements for SIP to support an explicit private network indication. NEW: Based on the background provided, this document formulates requirements for SIP to support an explicit private network indication and defines a P-header, P-Private-Network-Indication, to support those requirements. - Section 3, next to last paragraph. I'm not sure what is meant by "the filling out a Spec(T)". I don't see "filling" used as a concept in RFC 3324. Perhaps, "specifying a Spec(T)" is more consistent with terminology in RFC 3324. - Section 5. In general, the requirements are not specific consistently - i.e., some use 2119 language and others not and there is not consistent capitalization. I would suggest the following changes. R2: "The indication from R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be inserted by a SIP proxy" R3: "The indication from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be removed by a SIP proxy" R6: "must" -> "MUST" - Section 6, 2nd paragraph. The "can" in the first sentence should be a "MAY" and the sentence needs to be split into two: OLD: A proxy server which handles a message can insert such a P-Private- Network-Indication header field into the message based on authentication of the source of a message, configuration or local policy, and forward it to other proxies in the same administrative domain or proxies in trusted domain to be handled as private network traffic. NEW: A proxy server which handles a message MAY insert such a P-Private- Network-Indication header field into the message based on authentication of the source of a message, configuration or local policy. A proxy server MAY forward the message to other proxies in the same administrative domain or proxies in a trusted domain to be handled as private network traffic. Section 9. You should be explicit about the header name in this section. The text in the first paragraph needs some work. At a minimum you need to change the "not supposed to" to something more definitive as all security issues arise because someone does something they're not supposed to. I would suggest at least making the following change: OLD: The private network indication defined in this document is to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPsec and sometimes by physical protection of the network. In any case, the environment where the private network indication will be used ensures the integrity and the confidentiality of the contents of this header field. NEW: The private network indication defined in this document MUST only be used in an environment where elements are trusted and where attackers are do not have access to the protocol messages between those elements. Traffic protection between network elements can be achieved by using IPsec and sometimes by physical protection of the network. In any case, the environment where the private network indication will be used ensures the integrity and the confidentiality of the contents of this header field. Nits: ------ - Section 1.1: "3rd-Generqation" -> 3rd-Generation - The terms "break-in" and "break-out" traffic are used several places in the document, but this term is never defined. These terms should be defined in Section 3. - Figures should have Titles for readability On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi wrote: > Hi, > > I have submitted the following draft: > > http://www.ietf.org/internet-**drafts/draft-vanelburg-** > dispatch-private-network-ind-**03.txt > > The draft reflects all the comments discussed in DISPATCH list. > > The major changes are as follows: > > - corrected the abstract > - corrected the term "common domain" to "pre-arranged domain" > - added 7.1.4 "P-Private-Network-Indication verification" > - editorial changes > > Regards, > Mayumi > ______________________________**_________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/**listinfo/dispatch > --001a11348472459d1404e9e1cbfb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In reviewing the document in preparation for the PROTO wri= te-up, I have a few comments (minor and nits) that should be addressed prio= r to the document being progressed.

Regards,
Mary.

Comments:
--------------= -

- General: domains used in this docu= ment must use a reserved domain such as "example.com" and must not use real domains. Thus, all occurrence= s of ericsson.com need to be changed to= example.com

- Section 1.5. =A0Bulleted list, first bull= et. I would suggest you just leave out the mention of LI. =A0Emergency serv= ices should be a sufficient example. =A0

- Section 1.5, last numbered list, item 2. =A0I had a hard time groking thi= s sentence and had to read several times. I would suggest rewording somethi= ng like (if I've properly interpreted the intent):
OLD:= 
       Different nodes spanning over diff=
erent networks may need to be
       able to act differently on type of traffic, when implicit schemes
       are used, it would require distribution of such enterprise
       specific logic over multiple nodes in multiple operators.  That
       is clearly not a manageable architecture and solution.

NEW:=A0
       behavior depending upon the type of traffic.  When this is done using implicit
       schemes, enterprise specific logic must be di=
stributed across multiple
       nodes in multiple operator's networks.  
       That is clearly not a manageable architecture and solution.


- Se= ction 1.5, last sentence. =A0I don't think that statement is sufficient= for what this document is doing. I would suggest you change that sentence = to something like the following:
OLD:
   Given the above b=
ackground this document will formulate requirements
   for SIP to support an explicit private network indication.

NEW:=A0
   Based on the background provided, this document formulates requirements
   for SIP to support an explicit private network indication and defines 
   a P-header, P-Private-Network-Indication, to =
support those requirements.


- Section 3, next to last paragraph. =A0I'm not sure what is meant by &= quot;the filling out a Spec(T)". I don't see "filling" u= sed as a concept in RFC 3324. =A0Perhaps, "specifying a Spec(T)" = is more consistent with terminology in RFC 3324.=A0

- Section 5. =A0In general, the requirement= s are not specific consistently - i.e., some use 2119 language and others n= ot and there is not consistent capitalization. =A0I would suggest the follo= wing changes.
R2: =A0 "The indication from R1 can be inserted by a SIP proxy"= -> "The indication from R1 MAY be inserted by a SIP proxy" =A0= =A0
R3: "The indication from R1 can be removed by a SIP proxy" ->= ; "The indication from R1 MAY be removed by a SIP proxy"
R6: &qu= ot;must" -> "MUST"

- Section 6, 2nd p= aragraph. The "can" in the first sentence should be a "MAY&q= uot; and the=A0sentence needs to be split into two:
OLD:
   A proxy server which handles a mess=
age can insert such a P-Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy, and forward it to other proxies in the same administrative
   domain or proxies in trusted domain to be handled as private network
   traffic.

NEW:=A0
   A proxy server which handles a message MAY insert such a P-Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy.  A proxy server MAY forward the message to other proxies in the=
=A0
   same administrative domain or proxies in=
 a trusted=A0
   domain to be handled as private network traffic. =


Section 9. =A0You should be explicit abo= ut the header name in this section. =A0The text in the first paragraph need= s some work. =A0At a minimum you need to change the "not supposed to&q= uot; to something more definitive as all security issues arise because some= one does something they're not supposed to. =A0 I would suggest at leas= t making the following change:
OLD:
   The private network indication defi=
ned in this document is to be used
   in an environment where elements are trusted and where attackers are
   not supposed to have access to the protocol messages between those
   elements.  Traffic protection between network elements is sometimes
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.
NEW:
   The private network indication defin=
ed in this document MUST only be used
   in an environment where elements are trusted and where attackers are
   do not have access to the protocol messages between those
   elements.  Traffic protection between network elements can be
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.


Nits:
------
= - Section 1.1: =A0"3rd-Generqation" ->=A03rd-Generation =A0
- The terms "break-in" and "break-out" traffic are us= ed several places in the document, but this term is never defined. =A0These= terms should be defined in Section 3.=A0
- Figures should have Titles for readability



O= n Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <mayumi.ohsugi@ntt-= at.co.jp> wrote:
Hi,

I have submitted the following draft:

http://www.ietf.org/internet-= drafts/draft-vanelburg-dispatch-private-network-ind-03.tx= t

The draft reflects all the comments discussed in DISPATCH list.

The major changes are as follows:

- corrected the abstract
- corrected the term "common domain" to "pre-arranged domain= "
- added 7.1.4 "P-Private-Network-Indication verification"
- editorial changes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Regards,
Mayumi
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--001a11348472459d1404e9e1cbfb-- From pkyzivat@alum.mit.edu Tue Oct 29 07:32:01 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E379C11E8288 for ; Tue, 29 Oct 2013 07:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.242 X-Spam-Level: X-Spam-Status: No, score=-0.242 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbaqEhrrUY4N for ; Tue, 29 Oct 2013 07:31:46 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id E6C8211E826D for ; Tue, 29 Oct 2013 07:31:45 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta09.westchester.pa.mail.comcast.net with comcast id j1rF1m00Q0mv7h0592Xllk; Tue, 29 Oct 2013 14:31:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id j2Xl1m00D3ZTu2S3X2XlRs; Tue, 29 Oct 2013 14:31:45 +0000 Message-ID: <526FC6D1.5040109@alum.mit.edu> Date: Tue, 29 Oct 2013 10:31:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> <523124B0.2000305@ntt-at.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383057105; bh=8IPAm0l/6EpXzW9Sl0nrBt57fiIOpdkpBikghNzkaPw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XKSwwmzyV3e3c0U/fPsA2Z+zNZ/G9keYAqIXKve1zPHIIXOs5AppCVSt2bWgIOt7t GvmD9cK+opI+mBUclli+okrY6vODdT1RZ/WDuc+dQ03zpIlqQQeh0QHmDDE/HPL6Gh SVOSIhZDxDw1p/TeyElbgc+zM3EaLFLoq5FD34J0mC1OQRzJE6aNoeFOSHXrAYeNNr Gu6ZP9myYIvb679S5vMHukI7JdHbWoF4SW0H2CnzDr9m7fY8AHGlrA2s8oqmAaUaB4 mKxw4QKAj7MhzEt3tBQlnDAjpzm1RAgtAP1rK7zr5jbDbMTDw3t/HB8FMSQVFA+jyu BtdBAjV/RQ2gw== Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 14:32:02 -0000 A couple of additional nits. On 10/29/13 10:11 AM, Mary Barnes wrote: > - General: domains used in this document must use a reserved domain such > as "example.com " and must not use real domains. > Thus, all occurrences of ericsson.com need to be > changed to example.com Or foo.example.com > NEW: > > The private network indication defined in this document MUST only be used > in an environment where elements are trusted and where attackers are delete the last "are" > do not have access to the protocol messages between those > elements. Traffic protection between network elements can be > achieved by using IPsec and sometimes by physical protection of the > network. In any case, the environment where the private network > indication will be used ensures the integrity and the confidentiality > of the contents of this header field. Thanks, Paul From mary.ietf.barnes@gmail.com Tue Oct 29 09:26:37 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA76C11E81B9 for ; Tue, 29 Oct 2013 09:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.285 X-Spam-Level: X-Spam-Status: No, score=-102.285 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COA0cJqb0Hm8 for ; Tue, 29 Oct 2013 09:26:35 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 38EAC11E8185 for ; Tue, 29 Oct 2013 09:26:34 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id cb5so5474395wib.7 for ; Tue, 29 Oct 2013 09:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=KMBQeeXnvh3Rs0vF2CM23ZVbVMhmGOKysr0hHv2mbNk=; b=HXFk2ZSIzzSVaFjPdgz7v+bnOnEj6wENpEF6RyrR6A7Oab2MywR46+/9lnbsCM3n2Y uThfiITx+QAUBoW+c+bAK4zxPLEy2MM3Iu7OwwEVIi9rcE14i6316rmj/saa/iKBclWz KItFtWNehCW6vUlDRdL4XcWiSfgnbUwkot6Oe5IX0DHHddZ6lEgLWYce2VAjwGaYTSkE ElIxVvGVS7u4RUQm8BxZbXMmRhxs+/xHKb1S80iyuYufiyo73tGOjU1K/ZxAf9tOUbCm vBsmrMQ1M5OS5KMuztGbRLFfUCxISH9Q5F8MxZJ6IwFA0YWdh0j2sHxWGbQyQBilbEyA 169w== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr222918wic.33.1383063993215; Tue, 29 Oct 2013 09:26:33 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Tue, 29 Oct 2013 09:26:33 -0700 (PDT) Date: Tue, 29 Oct 2013 11:26:33 -0500 Message-ID: From: Mary Barnes To: "R.Jesske@telekom.de" Content-Type: multipart/alternative; boundary=001a11c3844c04888304e9e3ae55 Cc: DISPATCH , Dean Willis Subject: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis-09.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 16:26:38 -0000 --001a11c3844c04888304e9e3ae55 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In preparation for the PROTO write-up, I have reviewed the document in detail. My detailed review was originally based on the -08, but I also reviewed the 09 diff. There are a few errors that have been introduced in the -09 and many of my -08 comments remain - I've separated comments from nits below. A number of these comments are with regards to text that was not changed from RFC 3455, but I think some of the text requires updating and we need to keep in mind that this an entirely new IESG that will be reviewing this document, so they won't have the same context of the IESG that approved RFC 3455. I will note that I also have not validated the content of section 9 against a diff of this document and RFC 3455. I will need to do that before I progress the document unless the authors can point me to another review that has done that. Regards, Mary. Summary: This document needs some work prior to being progressed. Comments: ---------------- - Section 1. I think you should be explicit that these extensions apply only to a private network - saying they are "generally not applicable" is too soft, so I would suggest some minor rewording something like: OLD: The SIP extensions specified in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions are generally NOT APPLICABLE in the Internet as a whole. NEW: The SIP extensions specified in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions apply only to private networks and are not appropriate for use in an Internet environment. - Section 3. This section needs to be updated. I don't think that 10 year old background is relevant in the current context. You should be able to model this after the text in more recent 3GPP P-header documents, referring to the SIP change process. - Section 4.1. "registered address-of-record" -> "registered SIP address-of-record" - Section 4.1, 3rd paragraph. "Note that, generally speaking," -> "Note that in standard SIP usage [RFC3261]" - Section 4.1.2.3. I don't think this is stated properly. I think the intent is that this header is not applicable to proxies, therefore the proxy MUST relay the header field unchanged. I would suggest rewording something like: OLD: This memo does not define any procedure at the proxy. The proxy does not add, read, modify or delete the header field, and therefore any proxy will relay this header field unchanged. NEW: This header is not intended to be used by proxies - a proxy does not add, read, modify or delete the header field, and therefore any proxy MUST relay this header field unchanged. Section 4.2, 1st paragraph. The behavior in this sentence is not normative from a SIP protocol perspective, thus MAY is not appropriate. I suggest the MAY be changed to "can". The UAS MAY use the information to render different distinctive audiovisual alerting tones, depending on the URI used to receive the invitation to the session. Section 4.2.2.2, 2nd paragraph. The behavior in this sentence is not normative from a SIP protocol perspective, thus I suggest the MAY be changed to "can". - Section 4.3.3, last paragraph. I think this ought to be a MUST: "The identifier should be globally unique.." - Section 4.3.2.1. This text has changed from the -08. I don't know what a "normal User Equipment" is and the term "User Equipment" is not defined in this specification. I think it would be better to say something like. However, even with this proposed change, I think you also need text for user agent server behavior - i.e., what would a UAS do if it received this header. OLD: A normal User Equipment has normally no knowledge of the P-Visited- Network-ID when sending the REGISTER. Therefore user agent clients do not insert a P-Visited-Network-ID header field in any SIP message. NEW: In the context of the network to which the header fields defined in this document apply, a User Agent has no knowledge of the P-Visited-Network-ID when sending the REGISTER request. Therefore user agent clients MUST NOT insert a P-Visited-Network-ID header field in any SIP message. - Section 4.3.2.2:, 2nd paragraph: "home network MAY use" -> "home network can use" - Section 4.3.2.2, last paragraph: OLD: Note that a received P-Visited-Network-ID from a UA is a failure case and must be deleted. NEW: Note that a received P-Visited-Network-ID from a UA is a failure case and MUST be deleted when the request is forwarded. Section 4.4.2.1, 2nd paragraph: "MUST trust the proxy" -> "MUST have a trust relationship with the proxy" Section 4.4.2.1, 3rd paragraph: "there must also be a transitive trust" -> "there MUST also be a transitive trust" Section 4.4.2.2, 2nd paragraph: "MAY act upon any information present" -> "can act upon any information present", "MAY use the call id" -> "can use the call id" Section 4.5.2: 2nd paragraph: "MAY use the hostnames" -> "can use the hostnames" Section 4.5.2.1 2nd paragraph: "MAY use the contents" -> "can use the conte= nts" - Section 4.6.2, 3rd paragraph: "M=10AY use the values" -> "can use the val= ues" - Section 4.6.3, 3rd paragraph: needs some editorial work. Maybe the following change would work: OLD: Depending on the call scenario it is needed to add for each transit network either a transit network name or a void value. Nevertheless it can not be guaranteed that all values will appear within the P-Charging-Vector header field. NEW: Depending on the call scenario, each transit network can add either a transit network name or a void value. However, it can not be guaranteed that all the values that are added will appear within the P-Charging-Vector header field. - Section 4.6.3, next to last paragraph: "which needs to be incremented" -> "which MUST be incremented" - Section 4.6.3, last paragraph. I have no idea what that is trying to say other than void values have no index. What does "taken into consideration" mean. Are you talking about limits on the number of entries or are you suggesting that the number of void values must be considered when setting the index for the transit network names? - Section 4.6.4.2: I don't know what this means: "A deletion of the elements could appear depending on the network policy and trust rules". Is it just trying to say that along with the adding and modifying in the previous sentence that the elements can also be deleted by the proxy? - Section 5.7. Delete this text and table. We aren't these tables anymore as they really don't provide any useful information. You just need to verbally state what messages these headers can appear in. - Section 6.1: this needs some tighter wording. What is meant by "potentially annoying" for example? - Section 6.2: I think you need to be more specific about the "nature" that makes this header not of particular concern with regards to security. Does it reveal additional, unique information about an individual that isn't available in other headers. Also, the 2nd paragraph needs some work - maybe something like: OLD: An eavesdropper may collect the list of identities a user is registered. This may have privacy implications. To mitigate this problem, this extension SHOULD only be used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop. NEW: An eavesdropper could possibly collect the list of identities a user is registered. This can have privacy implications. To mitigate this problem, this extension MUST only be used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop. - Section 6.4, --3rd paragraph: "should not" -> "MUST NOT" -- 7th paragraph: "SHOULD NOT be sent" -> "MUST NOT be sent" -- 8th paragraph: "SHOULD NOT send sensitive information" -> "MUST NOT send sensitive information" -- 9th paragraph: "is required to delete" -> "is REQUIRED to delete" -- 10th paragraph: How does a network ensure the information is not of a sensitive nature? I would think that the information just should not be sent outside of the trust domain. I believe that's consistent with the scope of these headers, is it not? -- 11th paragraph: So, what does a proxy do with that information. What are the implications if the information is used and it's not valid? - Section 9, item 2. I think you need to add this text with regards to the recommendation to use RFC 4244 (bis) to the body of this document and include a real reference. *Nits:* - Section 4.1, 2nd paragraph. "has associated to an address-of-record" -> "has associated with an address-of-record" - Section 4.1.2.2, 2nd paragraph, "In case" -> "If", "shall not" -> SHALL = NOT - Section 4.3.2.2, last sentence. The -09 introduced a typo: "T means" -> "This means" - Section 4.3.2.3, 1st paragraph after 1st example. The -09 introduced another typo: "the REGISTRAR" -> "at the REGISTRAR" Section 4.2.2.1, 3rd paragraph: "there must also be a transitive trust" -> "there MUST also be a transitive trust" Section 4.6, 2nd paragraph: "includes, includes but is not limited to" -> "includes, but is not limited to," Section 4.6.2.2, 1st paragraph: "one ore more" -> "one or more" On Tue, Oct 8, 2013 at 11:58 AM, wrote: > Dear all, > I would like to inform you that I have implemented all comments coming > from the expert review done by Dean Willis. Also an editorial cleanup was > made. > > If there are still some comments that needs to be implemented please > inform me. > > From my side I would be happy to proceed the draft further towards > publication. > > Thank you and Best Regards > > Roland > > > -----Urspr=FCngliche Nachricht----- > Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Gesendet: Dienstag, 8. Oktober 2013 13:40 > An: Christer Holmberg; Keith Drage; Jesske, Roland > Betreff: New Version Notification for draft-drage-sipping-rfc3455bis-09.t= xt > > > A new version of I-D, draft-drage-sipping-rfc3455bis-09.txt > has been successfully submitted by Keith Drage and posted to the IETF > repository. > > Filename: draft-drage-sipping-rfc3455bis > Revision: 09 > Title: Private Header (P-Header) Extensions to the Session > Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GP= P) > Creation date: 2013-10-08 > Group: Individual Submission > Number of pages: 47 > URL: > http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-09.txt > Status: > http://datatracker.ietf.org/doc/draft-drage-sipping-rfc3455bis > Htmlized: > http://tools.ietf.org/html/draft-drage-sipping-rfc3455bis-09 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-drage-sipping-rfc3455bis-09 > > Abstract: > This document describes a set of private Session Initiation Protocol > (SIP) header fields (P-headers) used by the 3rd-Generation > Partnership Project (3GPP), along with their applicability, which is > limited to particular environments. The P-header fields are for a > variety of purposes within the networks that the partners use, > including charging and information about the networks a call > traverses. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > - --001a11c3844c04888304e9e3ae55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In preparation for the PROTO write-up, I have reviewed the= document in detail. =A0My detailed review was originally based on the -08,= but I also reviewed the 09 diff. =A0There are a few errors that have been = introduced in the -09 and many of my -08 comments remain - I've separat= ed comments from nits below. =A0A number of these comments are with regards= to text that was not changed from RFC 3455, but I think some of the text r= equires updating and we need to keep in mind that this an entirely new IESG= that will be reviewing this document, so they won't have the same cont= ext of the IESG that approved RFC 3455. =A0I will note that I also have not= validated the content of section 9 against a diff of this document and RFC= 3455. =A0I will need to do that before I progress the document unless the = authors can point me to another review that has done that.

Regards,
Mary.

Summary: = =A0This document needs some work prior to being progressed.=A0

=
Comments:
----------------
- Section 1. =A0I= think you should be explicit that these extensions apply only to a private= network - saying they are "generally not applicable" is too soft= , so I would suggest some minor rewording something like:
OLD:
   The SIP extensions specified in this document make ce=
rtain
   assumptions regarding network topology, linkage between SIP and lower
   layers, and the availability of transitive trust.  These assumptions
   are generally NOT APPLICABLE in the Internet as a whole.

=
NEW:=A0
   The SIP extensions specified in this document make certain
   assumptions regarding network topology, linkage between SIP and lower
   layers, and the availability of transitive trust.  These assumptions
   apply only to private networks and are not appropriate for use in an=A0I=
nternet environment.

- Section 3. =A0This se=
ction needs to be updated. =A0I don't think that 10 year old background=
 is relevant in the current context. =A0 You should be able to model this a=
fter the text in more recent 3GPP P-header documents, referring to the SIP =
change process.=A0


- Section 4.1. "registered address-of-rec=
ord" -> "registered SIP address-of-record"<=
/pre>

- Section 4.1, 3rd paragraph. =A0"Note that, generall=
y speaking," -> "Note that in standard SIP usage [RFC3261]&quo=
t;


- Section 4.1.2.3. =A0I don't think this is stated pro=
perly. =A0I think the intent is that this header is not applicable to proxi=
es, therefore the proxy MUST relay the header field unchanged. =A0I would s=
uggest rewording something like:


OLD:=A0
   This memo does not define any procedure at the proxy.  The proxy doe=
s
   not add, read, modify or delete the header field, and therefore any
   proxy will relay this header field unchanged.
N=
EW:
   This header is not intended to be used by proxies - a proxy does
   not add, read, modify or delete the header field, and therefore any
   proxy MUST relay this header field unchanged.
Section 4.2, 1st p=
aragraph. =A0The behavior in this sentence is not normative from a SIP prot=
ocol perspective, thus MAY is not appropriate. =A0I suggest the MAY be chan=
ged to "can". =A0=A0


 =
  The UAS MAY use the information to render different distinctive audiovisu=
al alerting
   tones, depending on the URI used to receive the invitation to the
   session.
Section 4.2.2.2, 2nd para=
graph. =A0The behavior in this sentence is not normative from a SIP protoco=
l perspective, thus =A0I suggest the MAY be changed to "can".=A0<=
/span>


- Section 4.3.3, last paragraph. =A0I think this ought to =
be a MUST: "The identifier should be globally unique.."=A0=



- Section 4.3.2.1. =A0This text has changed from the -08. =
=A0 I don't know what a "normal User Equipment" is and the te=
rm "User Equipment" is not defined in this specification. =A0I th=
ink it would be better to say something like. However, even with this propo=
sed change, I think you also need text for user agent server behavior - i.e=
., what would a UAS do if it received this header.=A0


OLD:
   A normal User Equipment has normally no kn=
owledge of the P-Visited-
   Network-ID when sending the REGISTER.  Therefore user agent clients
   do not insert a P-Visited-Network-ID header field in any SIP message.

NEW:=A0
   In the context of the network t=
o which the header fields defined in this document apply, a User Agent has=
=A0no knowledg=
e of the P-Visited-Network-ID when sending the REGISTER request. =A0Therefore user agent clients MUST NOT insert a P-=
Visited-Network-ID=A0header field=A0in any SIP message.


- Section 4.3.2.2:, 2nd paragra=
ph: =A0"home network MAY use" -> "home network can use&qu=
ot;


- Section 4.3.2.2=
, last paragraph: =A0
OLD: Note that =
a received P-Visited-Network-ID from a UA is a failure case and must be del=
eted.
NEW: =A0Note th=
at a received P-Visited-Network-ID from a UA is a failure case and MUST be =
deleted when the request is forwarded. 
Se=
ction 4.4.2.1, 2nd paragraph: =A0"MUST trust the proxy" -> &qu=
ot;MUST have a trust relationship with the proxy"=A0
Se=
ction 4.4.2.1, 3rd paragraph: =A0"there must also be a transitive trus=
t" -> =A0"there MUST also be a transitive trust"=A0


Section 4.4.2.2, 2nd paragraph: "MAY=
 act upon any information present" -> "can act upon any inform=
ation present", =A0"MAY use the call id" -> "can use=
 the=A0call =
id"=A0


Section 4.5.2: 2nd paragraph: "MAY use the hostnames&=
quot; -> "can use the hostnames"=A0
Section 4.5.2.1 2nd=
 paragraph: "MAY use the contents" -> "can use the=A0cont=
ents"=A0
- Section 4.6.2, 3rd para=
graph: "M=10AY use the values" -> "can use the values&quo=
t;=A0


- Section 4.6.3, 3rd paragraph: needs some editorial work.=
 =A0Maybe the following change would work:=A0
OLD:<=
/pre>
   Depending on the call scenario it is needed to add for each transit
   network either a transit network name or a void value.  Nevertheless
   it can not be guaranteed that all values will appear within the P-Chargi=
ng-Vector header field.=A0
NEW:=A0
 =
  Depending on the call scenario, each transit network can add either a tra=
nsit network name=A0or a void    value.  However, it can not be guaranteed =
that all the values that are added will appear within the P-Charging-Vector=
 header field.


- Section 4.6.3, next to last paragraph:=A0"which n=
eeds to be incremented" -> "which MUST be incremented"


- Section 4.6.3, =
last paragraph. =A0I have no idea what that is trying to say other than voi=
d values have no index. =A0What does "taken into consideration" m=
ean. Are you talking about limits on the number of entries or are you sugge=
sting that the number of void values must be considered when setting the in=
dex for the transit network names? =A0


- Secti=
on 4.6.4.2: I don't know what this means=
:=A0=
=A0"A deletion of the elements could appear depending on the network p=
olicy and trust rules". =A0Is it just trying to say that along with th=
e adding and modifying in the previous sentence that the elements can also =
be deleted by the proxy?=A0


- Section 5.7. Delete this text and table. =A0 We aren'=
;t these tables anymore as they really don't provide any useful informa=
tion. =A0You just need to verbally state what messages these headers can ap=
pear in.=A0


- Section 6.1: this needs some tighter wording. =A0What is=
 meant by "potentially annoying" =A0for example? =A0
- Section 6.2: I th=
ink you need to be more specific about the "nature" that makes th=
is header not of particular concern with regards to security. Does it revea=
l additional, unique information about an individual that isn't availab=
le in other headers. =A0Also, the 2nd paragraph needs some work - maybe som=
ething like:


OLD:
An eavesdropper may collect the lis=
t of identities a user is registered.  This may have privacy implications. =
 To mitigate this problem, this extension SHOULD only be used in a secured =
environment, where encryption of SIP messages is provided either end-to-end=
 or

hop-by-hop.=A0
  =A0
NEW:=A0<=
/span>


=A0An eavesdropper could possibly collect the list of identities a user is =
registered.  This can have privacy implications.  To mitigate this problem,=
 this extension MUST only be used in a secured environment, where encryptio=
n of SIP messages is provided either end-to-end or hop-by-hop.=A0


- Section 6.4,=A0
--3r=
d paragraph: "should not" -> "MUST NOT"=A0


-- 7th paragraph: =A0"SHOULD NOT be sent" -> =
"MUST NOT be sent"=A0
-- 8th paragraph: &=
quot;SHOULD NOT send sensitive information" -> "MUST NOT send =
sensitive information"
-- 9th paragraph: &=
quot;is required to delete" -> "is REQUIRED to delete"=A0=

-- 10th paragraph: =A0How does a netwo=
rk ensure the information is not of a sensitive nature? =A0 I would think t=
hat the information just should not be sent outside of the trust domain. =
=A0I believe that's consistent with the scope of these headers, is it n=
ot?


-- 11th paragraph: So, what does a proxy do with that info=
rmation. =A0What are the implications if the information is used and it'=
;s not valid? =A0


- Section 9, item 2. =A0I think you need to add this text =
with regards to the recommendation to use RFC 4244 (bis) to the body of thi=
s document and include a real reference.



Nits:


<=
span style=3D"color:rgb(34,34,34);font-family:arial;white-space:normal">- S=
ection 4.1, 2nd paragraph. =A0"has associated to an address-of-record&=
quot; -> "has associated with an address-of-record"

<=
span style=3D"color:rgb(34,34,34);font-family:arial;white-space:normal">- S=
ection 4.1.2.2, 2nd paragraph, "In case" -> "If", =
=A0"shall not" -> SHALL NOT


<=
pre style=3D"word-wrap:break-word;white-space:pre-wrap">- Section 4.3.2.2, last sentence. =A0The =
-09 introduced a typo: "T means" -> "This means"=A0<=
/span>


- Section 4.3.2.3, 1st paragraph after 1=
st example. =A0The -09 introduced another typo: "the REGISTRAR" -=
> "at the REGISTRAR"


Section 4.2.2.1, 3rd=
 paragraph: =A0"there must also be a transitive trust" -> =A0&=
quot;there MUST also be a transitive trust"=A0


Section 4.6, 2nd par=
agraph: "includes, includes but is not limited to" -> "in=
cludes, but is not limited to,"=A0


Section 4.6.2.2, 1st=
 paragraph: "one ore more" -> "one or more"=A0
On Tue, Oct 8, 2013 at 11:58 AM, <R.Jesske@telekom.de> wrote:
Dear all,
I would like to inform you that I have implemented all comments coming from= the expert review done by Dean Willis. Also an editorial cleanup was made.=

If there are still some comments that needs to be implemented please inform= me.

>From my side I would be happy to proceed the draft further towards publicat= ion.

Thank you and Best Regards

Roland


-----Urspr=FCngliche Nachricht-----
Von: internet= -drafts@ietf.org [mailto:internet-drafts@ietf.org]
Gesendet: Dienstag, 8. Oktober 2013 13:40
An: Christer Holmberg; Keith Drage; Jesske, Roland
Betreff: New Version Notification for draft-drage-sipping-rfc3455bis-09.txt=


A new version of I-D, draft-drage-sipping-rfc3455bis-09.txt
has been successfully submitted by Keith Drage and posted to the IETF repos= itory.

Filename: =A0 =A0 =A0 =A0draft-drage-sipping-rfc3455bis
Revision: =A0 =A0 =A0 =A009
Title: =A0 =A0 =A0 =A0 =A0 Private Header (P-Header) Extensions to the Sess= ion Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3= GPP)
Creation date: =A0 2013-10-08
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 47
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.o= rg/internet-drafts/draft-drage-sipping-rfc3455bis-09.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/do= c/draft-drage-sipping-rfc3455bis
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-d= rage-sipping-rfc3455bis-09
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rf= cdiff?url2=3Ddraft-drage-sipping-rfc3455bis-09

Abstract:
=A0 =A0This document describes a set of private Session Initiation Protocol=
=A0 =A0(SIP) header fields (P-headers) used by the 3rd-Generation
=A0 =A0Partnership Project (3GPP), along with their applicability, which is=
=A0 =A0limited to particular environments. =A0The P-header fields are for a=
=A0 =A0variety of purposes within the networks that the partners use,
=A0 =A0including charging and information about the networks a call
=A0 =A0traverses.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=A0 -
--001a11c3844c04888304e9e3ae55-- From shida@agnada.com Thu Oct 31 00:08:39 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CDE11E80F6 for ; Thu, 31 Oct 2013 00:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va63zq5qvF3i for ; Thu, 31 Oct 2013 00:08:35 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [74.52.222.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB0C21E80C4 for ; Thu, 31 Oct 2013 00:08:25 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 6D24D65BD9546; Thu, 31 Oct 2013 02:08:23 -0500 (CDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 5DF5465BD950D for ; Thu, 31 Oct 2013 02:08:23 -0500 (CDT) Received: from [98.210.227.187] (port=56085 helo=[192.168.1.25]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VbmMg-0005rC-7e; Thu, 31 Oct 2013 02:08:22 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_6E85F653-FB6B-4EEA-8898-EC70DC36D0FD" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Shida Schubert In-Reply-To: Date: Thu, 31 Oct 2013 00:08:22 -0700 Message-Id: <40A3F8FB-F599-4DA8-B2CE-7100D9C89854@agnada.com> References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> <523124B0.2000305@ntt-at.co.jp> To: Mary Barnes X-Mailer: Apple Mail (2.1510) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - agnada.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.25]) [98.210.227.187]:56085 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== X-Mailman-Approved-At: Thu, 31 Oct 2013 06:25:40 -0700 Cc: DISPATCH Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 07:08:39 -0000 --Apple-Mail=_6E85F653-FB6B-4EEA-8898-EC70DC36D0FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Mary; Thanks for the thorough reviews and suggestions.=20 I will prepare a revised draft reflecting the suggestions and=20 comments.=20 Many Thanks Shida On Oct 29, 2013, at 7:11 AM, Mary Barnes = wrote: > In reviewing the document in preparation for the PROTO write-up, I = have a few comments (minor and nits) that should be addressed prior to = the document being progressed. >=20 > Regards, > Mary. >=20 > Comments: > --------------- >=20 > - General: domains used in this document must use a reserved domain = such as "example.com" and must not use real domains. Thus, all = occurrences of ericsson.com need to be changed to example.com >=20 > - Section 1.5. Bulleted list, first bullet. I would suggest you just = leave out the mention of LI. Emergency services should be a sufficient = example. =20 >=20 > - Section 1.5, last numbered list, item 2. I had a hard time groking = this sentence and had to read several times. I would suggest rewording = something like (if I've properly interpreted the intent): > OLD: > Different nodes spanning over different networks may need to be > able to act differently on type of traffic, when implicit = schemes > are used, it would require distribution of such enterprise > specific logic over multiple nodes in multiple operators. That > is clearly not a manageable architecture and solution. >=20 > NEW:=20 > Nodes spanning multiple networks often need to have different=20= > behavior depending upon the type of traffic. When this is done = using implicit > schemes, enterprise specific logic must be distributed across = multiple > nodes in multiple operator's networks. =20 > That is clearly not a manageable architecture and solution. >=20 >=20 > - Section 1.5, last sentence. I don't think that statement is = sufficient for what this document is doing. I would suggest you change = that sentence to something like the following: > OLD: > Given the above background this document will formulate = requirements > for SIP to support an explicit private network indication. >=20 > NEW:=20 > Based on the background provided, this document formulates = requirements > for SIP to support an explicit private network indication and = defines=20 > a P-header, P-Private-Network-Indication, to support those = requirements.=20 >=20 >=20 > - Section 3, next to last paragraph. I'm not sure what is meant by = "the filling out a Spec(T)". I don't see "filling" used as a concept in = RFC 3324. Perhaps, "specifying a Spec(T)" is more consistent with = terminology in RFC 3324.=20 >=20 > - Section 5. In general, the requirements are not specific = consistently - i.e., some use 2119 language and others not and there is = not consistent capitalization. I would suggest the following changes. > R2: "The indication from R1 can be inserted by a SIP proxy" -> "The = indication from R1 MAY be inserted by a SIP proxy" =20 > R3: "The indication from R1 can be removed by a SIP proxy" -> "The = indication from R1 MAY be removed by a SIP proxy" > R6: "must" -> "MUST" >=20 > - Section 6, 2nd paragraph. The "can" in the first sentence should be = a "MAY" and the sentence needs to be split into two: > OLD: > A proxy server which handles a message can insert such a P-Private- > Network-Indication header field into the message based on > authentication of the source of a message, configuration or local > policy, and forward it to other proxies in the same administrative > domain or proxies in trusted domain to be handled as private = network > traffic.=20 >=20 > NEW:=20 > A proxy server which handles a message MAY insert such a P-Private- > Network-Indication header field into the message based on > authentication of the source of a message, configuration or local > policy. A proxy server MAY forward the message to other proxies in = the=20 > same administrative domain or proxies in a trusted=20 > domain to be handled as private network traffic.=20 >=20 >=20 > Section 9. You should be explicit about the header name in this = section. The text in the first paragraph needs some work. At a minimum = you need to change the "not supposed to" to something more definitive as = all security issues arise because someone does something they're not = supposed to. I would suggest at least making the following change: > OLD: > The private network indication defined in this document is to be = used > in an environment where elements are trusted and where attackers = are > not supposed to have access to the protocol messages between those > elements. Traffic protection between network elements is sometimes > achieved by using IPsec and sometimes by physical protection of the > network. In any case, the environment where the private network > indication will be used ensures the integrity and the = confidentiality > of the contents of this header field. > NEW: > The private network indication defined in this document MUST only = be used > in an environment where elements are trusted and where attackers = are > do not have access to the protocol messages between those > elements. Traffic protection between network elements can be > achieved by using IPsec and sometimes by physical protection of the > network. In any case, the environment where the private network > indication will be used ensures the integrity and the = confidentiality > of the contents of this header field. >=20 >=20 > Nits: > ------ > - Section 1.1: "3rd-Generqation" -> 3rd-Generation =20 > - The terms "break-in" and "break-out" traffic are used several places = in the document, but this term is never defined. These terms should be = defined in Section 3.=20 > - Figures should have Titles for readability >=20 >=20 >=20 > On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi = wrote: > Hi, >=20 > I have submitted the following draft: >=20 > = http://www.ietf.org/internet-drafts/draft-vanelburg-dispatch-private-netwo= rk-ind-03.txt >=20 > The draft reflects all the comments discussed in DISPATCH list. >=20 > The major changes are as follows: >=20 > - corrected the abstract > - corrected the term "common domain" to "pre-arranged domain" > - added 7.1.4 "P-Private-Network-Indication verification" > - editorial changes > = Regards, > Mayumi > _______________________________________________ > 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 --Apple-Mail=_6E85F653-FB6B-4EEA-8898-EC70DC36D0FD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

Hi Mary;

 Thanks for the thorough reviews and suggestions. 

 I will prepare a revised draft reflecting the suggestions and 
comments. 

 Many Thanks
  Shida

On Oct 29, 2013, at 7:11 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

In reviewing the document in preparation for the PROTO write-up, I have a few comments (minor and nits) that should be addressed prior to the document being progressed.

Regards,
Mary.

Comments:
---------------

- General: domains used in this document must use a reserved domain such as "example.com" and must not use real domains. Thus, all occurrences of ericsson.com need to be changed to example.com

- Section 1.5.  Bulleted list, first bullet. I would suggest you just leave out the mention of LI.  Emergency services should be a sufficient example.  

- Section 1.5, last numbered list, item 2.  I had a hard time groking this sentence and had to read several times. I would suggest rewording something like (if I've properly interpreted the intent):
OLD:
       Different nodes spanning over different networks may need to be
       able to act differently on type of traffic, when implicit schemes
       are used, it would require distribution of such enterprise
       specific logic over multiple nodes in multiple operators.  That
       is clearly not a manageable architecture and solution.

NEW: 
       Nodes spanning multiple networks often need to have different 
       behavior depending upon the type of traffic.  When this is done using implicit
       schemes, enterprise specific logic must be distributed across multiple
       nodes in multiple operator's networks.  
       That is clearly not a manageable architecture and solution.


- Section 1.5, last sentence.  I don't think that statement is sufficient for what this document is doing. I would suggest you change that sentence to something like the following:
OLD:
   Given the above background this document will formulate requirements
   for SIP to support an explicit private network indication.

NEW: 
   Based on the background provided, this document formulates requirements
   for SIP to support an explicit private network indication and defines 
   a P-header, P-Private-Network-Indication, to support those requirements.


- Section 3, next to last paragraph.  I'm not sure what is meant by "the filling out a Spec(T)". I don't see "filling" used as a concept in RFC 3324.  Perhaps, "specifying a Spec(T)" is more consistent with terminology in RFC 3324. 

- Section 5.  In general, the requirements are not specific consistently - i.e., some use 2119 language and others not and there is not consistent capitalization.  I would suggest the following changes.
R2:   "The indication from R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be inserted by a SIP proxy"   
R3: "The indication from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be removed by a SIP proxy"
R6: "must" -> "MUST"

- Section 6, 2nd paragraph. The "can" in the first sentence should be a "MAY" and the sentence needs to be split into two:
OLD:
   A proxy server which handles a message can insert such a P-Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy, and forward it to other proxies in the same administrative
   domain or proxies in trusted domain to be handled as private network
   traffic.

NEW: 
   A proxy server which handles a message MAY insert such a P-Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy.  A proxy server MAY forward the message to other proxies in the 
   same administrative domain or proxies in a trusted 
   domain to be handled as private network traffic.


Section 9.  You should be explicit about the header name in this section.  The text in the first paragraph needs some work.  At a minimum you need to change the "not supposed to" to something more definitive as all security issues arise because someone does something they're not supposed to.   I would suggest at least making the following change:
OLD:
   The private network indication defined in this document is to be used
   in an environment where elements are trusted and where attackers are
   not supposed to have access to the protocol messages between those
   elements.  Traffic protection between network elements is sometimes
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.
NEW:
   The private network indication defined in this document MUST only be used
   in an environment where elements are trusted and where attackers are
   do not have access to the protocol messages between those
   elements.  Traffic protection between network elements can be
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.


Nits:
------
- Section 1.1:  "3rd-Generqation" -> 3rd-Generation  
- The terms "break-in" and "break-out" traffic are used several places in the document, but this term is never defined.  These terms should be defined in Section 3. 
- Figures should have Titles for readability



On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <mayumi.ohsugi@ntt-at.co.jp> wrote:
Hi,

I have submitted the following draft:

http://www.ietf.org/internet-drafts/draft-vanelburg-dispatch-private-network-ind-03.txt

The draft reflects all the comments discussed in DISPATCH list.

The major changes are as follows:

- corrected the abstract
- corrected the term "common domain" to "pre-arranged domain"
- added 7.1.4 "P-Private-Network-Indication verification"
- editorial changes
                                                                                  Regards,
Mayumi
_______________________________________________
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

--Apple-Mail=_6E85F653-FB6B-4EEA-8898-EC70DC36D0FD-- From shida@ntt-at.com Thu Oct 31 08:12:36 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E9311E8171 for ; Thu, 31 Oct 2013 08:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.765 X-Spam-Level: X-Spam-Status: No, score=-101.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOTQvU2gRgoa for ; Thu, 31 Oct 2013 08:12:32 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) by ietfa.amsl.com (Postfix) with ESMTP id EE95D11E8196 for ; Thu, 31 Oct 2013 08:12:31 -0700 (PDT) Received: from [98.210.227.187] (port=49647 helo=[192.168.1.25]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VbtvB-0005Rc-IA; Thu, 31 Oct 2013 10:12:29 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_0B93EA64-DDD3-4097-83FB-E7102EADF90B" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Shida Schubert In-Reply-To: Date: Thu, 31 Oct 2013 08:12:27 -0700 Message-Id: <5B2B0410-7F09-4C6A-B084-2A0CF1C9347F@ntt-at.com> References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> <523124B0.2000305@ntt-at.co.jp> To: Mary Barnes X-Mailer: Apple Mail (2.1510) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.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 X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.25]) [98.210.227.187]:49647 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Cc: DISPATCH Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 15:12:36 -0000 --Apple-Mail=_0B93EA64-DDD3-4097-83FB-E7102EADF90B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Mary; Thanks for the thorough reviews and suggestions.=20 I will prepare a revised draft before and submit the=20 draft after the blackout period is cleared reflecting=20 the suggestions and comments you and Paul provided.=20 Many Thanks Shida On Oct 29, 2013, at 7:11 AM, Mary Barnes = wrote: > In reviewing the document in preparation for the PROTO write-up, I = have a few comments (minor and nits) that should be addressed prior to = the document being progressed. >=20 > Regards, > Mary. >=20 > Comments: > --------------- >=20 > - General: domains used in this document must use a reserved domain = such as "example.com" and must not use real domains. Thus, all = occurrences of ericsson.com need to be changed to example.com >=20 > - Section 1.5. Bulleted list, first bullet. I would suggest you just = leave out the mention of LI. Emergency services should be a sufficient = example. =20 >=20 > - Section 1.5, last numbered list, item 2. I had a hard time groking = this sentence and had to read several times. I would suggest rewording = something like (if I've properly interpreted the intent): > OLD: > Different nodes spanning over different networks may need to be > able to act differently on type of traffic, when implicit = schemes > are used, it would require distribution of such enterprise > specific logic over multiple nodes in multiple operators. That > is clearly not a manageable architecture and solution. >=20 > NEW:=20 > Nodes spanning multiple networks often need to have different=20= > behavior depending upon the type of traffic. When this is done = using implicit > schemes, enterprise specific logic must be distributed across = multiple > nodes in multiple operator's networks. =20 > That is clearly not a manageable architecture and solution. >=20 >=20 > - Section 1.5, last sentence. I don't think that statement is = sufficient for what this document is doing. I would suggest you change = that sentence to something like the following: > OLD: > Given the above background this document will formulate = requirements > for SIP to support an explicit private network indication. >=20 > NEW:=20 > Based on the background provided, this document formulates = requirements > for SIP to support an explicit private network indication and = defines=20 > a P-header, P-Private-Network-Indication, to support those = requirements.=20 >=20 >=20 > - Section 3, next to last paragraph. I'm not sure what is meant by = "the filling out a Spec(T)". I don't see "filling" used as a concept in = RFC 3324. Perhaps, "specifying a Spec(T)" is more consistent with = terminology in RFC 3324.=20 >=20 > - Section 5. In general, the requirements are not specific = consistently - i.e., some use 2119 language and others not and there is = not consistent capitalization. I would suggest the following changes. > R2: "The indication from R1 can be inserted by a SIP proxy" -> "The = indication from R1 MAY be inserted by a SIP proxy" =20 > R3: "The indication from R1 can be removed by a SIP proxy" -> "The = indication from R1 MAY be removed by a SIP proxy" > R6: "must" -> "MUST" >=20 > - Section 6, 2nd paragraph. The "can" in the first sentence should be = a "MAY" and the sentence needs to be split into two: > OLD: > A proxy server which handles a message can insert such a P-Private- > Network-Indication header field into the message based on > authentication of the source of a message, configuration or local > policy, and forward it to other proxies in the same administrative > domain or proxies in trusted domain to be handled as private = network > traffic.=20 >=20 > NEW:=20 > A proxy server which handles a message MAY insert such a P-Private- > Network-Indication header field into the message based on > authentication of the source of a message, configuration or local > policy. A proxy server MAY forward the message to other proxies in = the=20 > same administrative domain or proxies in a trusted=20 > domain to be handled as private network traffic.=20 >=20 >=20 > Section 9. You should be explicit about the header name in this = section. The text in the first paragraph needs some work. At a minimum = you need to change the "not supposed to" to something more definitive as = all security issues arise because someone does something they're not = supposed to. I would suggest at least making the following change: > OLD: > The private network indication defined in this document is to be = used > in an environment where elements are trusted and where attackers = are > not supposed to have access to the protocol messages between those > elements. Traffic protection between network elements is sometimes > achieved by using IPsec and sometimes by physical protection of the > network. In any case, the environment where the private network > indication will be used ensures the integrity and the = confidentiality > of the contents of this header field. > NEW: > The private network indication defined in this document MUST only = be used > in an environment where elements are trusted and where attackers = are > do not have access to the protocol messages between those > elements. Traffic protection between network elements can be > achieved by using IPsec and sometimes by physical protection of the > network. In any case, the environment where the private network > indication will be used ensures the integrity and the = confidentiality > of the contents of this header field. >=20 >=20 > Nits: > ------ > - Section 1.1: "3rd-Generqation" -> 3rd-Generation =20 > - The terms "break-in" and "break-out" traffic are used several places = in the document, but this term is never defined. These terms should be = defined in Section 3.=20 > - Figures should have Titles for readability >=20 >=20 >=20 > On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi = wrote: > Hi, >=20 > I have submitted the following draft: >=20 > = http://www.ietf.org/internet-drafts/draft-vanelburg-dispatch-private-netwo= rk-ind-03.txt >=20 > The draft reflects all the comments discussed in DISPATCH list. >=20 > The major changes are as follows: >=20 > - corrected the abstract > - corrected the term "common domain" to "pre-arranged domain" > - added 7.1.4 "P-Private-Network-Indication verification" > - editorial changes > = Regards, > Mayumi > _______________________________________________ > 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 --Apple-Mail=_0B93EA64-DDD3-4097-83FB-E7102EADF90B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 mary.ietf.barnes@gmail.com&= gt; wrote:

In reviewing the document in preparation = for the PROTO write-up, I have a few comments (minor and nits) that = should be addressed prior to the document being = progressed.

Regards,
Mary.

Comments:
---------------

- General: domains used in this document must use a reserved = domain such as "example.com" and = must not use real domains. Thus, all occurrences of ericsson.com need to be changed to example.com

- Section 1.5.  Bulleted = list, first bullet. I would suggest you just leave out the mention of = LI.  Emergency services should be a sufficient example. =  

- Section 1.5, last numbered list, item 2.  I had a hard time = groking this sentence and had to read several times. I would suggest = rewording something like (if I've properly interpreted the = intent):
OLD:
       Different nodes spanning =
over different networks may need to be
       able to act differently on type of traffic, when implicit schemes
       are used, it would require distribution of such enterprise
       specific logic over multiple nodes in multiple operators.  That
       is clearly not a manageable architecture and =
solution.

NEW: 
      =
 Nodes spanning multiple networks often need to have =
different 
       behavior depending upon the type of traffic.  When =
this is done using implicit
       schemes, enterprise specific logic must be =
distributed across multiple
       nodes in =
multiple operator's networks.  
       That is =
clearly not a manageable architecture and solution.


- Section 1.5, last sentence.  I don't think that = statement is sufficient for what this document is doing. I would suggest = you change that sentence to something like the following:
OLD:
   Given =
the above background this document will formulate requirements
   for SIP to support an explicit private network indication.

NEW: 
   Based on the background =
provided, this document formulates requirements
   for SIP to support an explicit private network indication and defines =

   a P-header, P-Private-Network-Indication, to =
support those requirements. 

- Section 3, next to last paragraph.  I'm not sure what is meant by =
"the filling out a Spec(T)". I don't see "filling" used as a concept in =
RFC 3324.  Perhaps, "specifying a Spec(T)" is more consistent with =
terminology in RFC 3324. 

- Section 5.  In general, = the requirements are not specific consistently - i.e., some use 2119 = language and others not and there is not consistent capitalization. =  I would suggest the following changes.
R2:   "The indication from R1 can be inserted by a SIP proxy" -> = "The = indication from R1 MAY be inserted by a SIP proxy" =   
R3: "The = indication from R1 MAY be removed by a SIP proxy"
R6: "must" -> = "MUST"

- Section 6, 2nd paragraph. The = "can" in the first sentence should be a "MAY" and the sentence needs to be split into = two:
   A proxy =
server which handles a message can insert such a P-Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy, and forward it to other proxies in the same administrative
   domain or proxies in trusted domain to be handled as private network
   traffic.

NEW: 
   A =
proxy server which handles a message MAY insert such a P-Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy.  A proxy server MAY forward the message to other proxies in =
the 
   same administrative domain or =
proxies in a trusted 
   domain to be handled as private network traffic. =


   The private =
network indication defined in this document is to be used
   in an environment where elements are trusted and where attackers are
   not supposed to have access to the protocol messages between those
   elements.  Traffic protection between network elements is sometimes
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.
NEW:
   The =
private network indication defined in this document MUST only be used
   in an environment where elements are trusted and where attackers are
   do not have access to the protocol messages between those
   elements.  Traffic protection between network elements can be
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.


Nits:
------
- = Section 1.1:  "3rd-Generation  
- = The terms "break-in" and "break-out" traffic are used several places in = the document, but this term is never defined.  These terms should = be defined in Section 3. 
- = Figures should have Titles for readability


On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi = <mayumi.ohsugi@ntt-at.co.jp> wrote:
Hi,

I have submitted the following draft:

http://www.ietf.org/internet-drafts/draft-vanelbu= rg-dispatch-private-network-ind-03.txt

The draft reflects all the comments discussed in DISPATCH list.

The major changes are as follows:

- corrected the abstract
- corrected the term "common domain" to "pre-arranged domain"
- added 7.1.4 "P-Private-Network-Indication verification"
- editorial changes
                    =                     =                     =                     =   Regards,
Mayumi
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

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

= --Apple-Mail=_0B93EA64-DDD3-4097-83FB-E7102EADF90B-- From richard@shockey.us Thu Oct 31 10:11:47 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9686211E81D2 for ; Thu, 31 Oct 2013 10:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knx8jnHFpe81 for ; Thu, 31 Oct 2013 10:11:43 -0700 (PDT) Received: from outbound-ss-1033.hostmonster.com (outbound-ss-1033.hostmonster.com [74.220.205.131]) by ietfa.amsl.com (Postfix) with SMTP id 03D2B11E8173 for ; Thu, 31 Oct 2013 10:11:42 -0700 (PDT) Received: (qmail 5101 invoked by uid 0); 31 Oct 2013 12:49:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.mail.unifiedlayer.com with SMTP; 31 Oct 2013 12:49:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=bW2RqQaBKWGeS+oTx02WEx5rOdELK1jov0TLAUUOMak=; b=IOQy7/YE+rGzETpepYJhFD5ljWZ67nJb4x2WgzpMJA9HBA7sqZWpIMVjZbHIa20v2htuClooEscpH5hgmCRTsP6B5vSm8n0WfFuaaRii2tD7R3it6V+j//AuGCHHuuAL; Received: from [173.79.179.104] (port=49445 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vbrge-0007Rd-6Z; Thu, 31 Oct 2013 06:49:20 -0600 From: "Richard Shockey" To: "'Brian Rosen'" References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> In-Reply-To: <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> Date: Thu, 31 Oct 2013 08:49:19 -0400 Message-ID: <00d901ced637$9e8143a0$db83cae0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8Pl7ss6oA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: cnit@ietf.org, 'DISPATCH' Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 17:11:47 -0000 Brian please.. Look at the mail. I'm using the CNIT list. =20 The issue is can we use the tools at hand to increase both the accuracy, reliability and the amount of data that is delivered to the CUA over who = is attempting to establish a session. The larger issue is the integrity of the entire real time communications system as it moves to an all IP world. Irrespective if CNAM it is = delivered as part of From: or PAI its not very useful to the consumer.=20 CNAM as it is currently defined in SS7 is a terrible service. 15 = Character ASCII. No support for International character sets the usual. It is not a hard stretch to postulate that called parties might like a richer set of data displayed on their UA's and that can be delivered by = the SIP headers in some relatively simple form. Modification of the = Call-Info header for instance. It is equally not a stretch to think that National Regulators would be delighted with consumers having a richer set of information displayed on their handsets in order to make more decisions. = In addition if we can achieve better all IP to IP interconnection among providers it would be really really useful if Enterprise systems could extract more data from their internal directory systems and pass that = along in the new format for enterprise calling as well. I would certainly argue that we are not going to see ubiquitous Point to Point video calling using WebRTC or SIP if there is not better display = of calling party information.=20 In addition network operators could insert other 'hints' as to the = nature of the session based on its ability to validate the Caller ID or other = forms on analysis. I'm well aware of how CNAM is delivered in North America and I'm equally aware the CNAM business model is broken.=20 What I'd like to know is what interest there is in this proposition and = are there parties interested in working on it in advance of say London.=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, October 30, 2013 5:39 PM To: Richard Shockey Cc: cnit@ietf.org Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications More useful in what way? Improving the reliability of caller name? = Please use the cnit list to discuss this. On that list, the current direction seems to be using the display name = part of the uri to carry a caller name, which is put on the call by the origination side, and signed as the number is. That is a significant change to the current infrastructure, which at = least in North America relies on a termination service provider dip in an origination service provider database, but it seems feasible to consider that. Brian On Oct 30, 2013, at 5:18 PM, Richard Shockey wrote: >=20 > Ok since Brian is being picky.. >=20 > I'm actually interested if anyone is interested in the possibility of=20 > making SIP Identity to the UA more useful. >=20 >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Richard Shockey > Sent: Wednesday, October 30, 2013 3:05 PM > To: stir@ietf.org > Subject: Re: [stir] Application servers - Re: Call Center Implications >=20 > Dan great post. I couldn't agree more. There needs to be some rules = here. > Some may be regulatory some may be technical. >=20 > First the voice application service providers need to provide the=20 > terminating CUA, "an accurate and truthful" Caller-ID for the call=20 > even if it is originated from a source that is not directly associated with the > business entity for whom the call is being made. That could be an = 800 > number for instance but I won't bore you with the issues with SMS800=20 > RESPORGS. >=20 > If the originating UA can prove/assert it is legally authorized to use = > such an identity on behalf of a customer then that is step one. The=20 > presumption after that is there is some contractual obligation between = > the service provider and the network about the use of such identities. = > The network can then "validate" such an assertion. >=20 > There is something larger here to consider. Though the focus of STIR=20 > is validation of a Caller-ID number at some point the RAI area should = take a > look at the other side of the coin so to speak. =20 >=20 > CNAM. That is NOT something STIR can do but I do believe there is an=20 > emerging requirement that under some cases the calling party wants to=20 > or should provide more substantive information about themselves to the = > called party and frankly 15 character ASCII is not enough. Consumers=20 > or businesses should be able to see more complete and validated=20 > information about the session in order to make an better and informed=20 > decision on whether to accept the 'call' or not. Regulators may want=20 > to require telemarketing firms to display NG CNAM or CNAM + like data=20 > as a condition of doing business. >=20 > All of the examples you cite are excellent examples where such verbose = > calling party identification could be displayed. I certainly want to=20 > answer a call from my doctor on my test results just as I wish to=20 > ignore a call from Bill Clinton begging me to vote in the Virginia=20 > Governors election next Tuesday. This is a case where annominity is = not a good idea. >=20 >=20 > All you need now is a little standardization. > Technically this should is very easy to understand in SIP. It would=20 > probably a reasonable modification of the Call INFO header in SIP with = > something like a XML based VCARD or JCARD URI whatever and probably=20 > 3GPP would need to look at how such data is displayed on the mobile=20 > VoLTE handsets. The network operators would have to understand not to=20 > modify the contents of such a URI and its source validated but that is = > a task for another day. >=20 >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Dan York > Sent: Tuesday, October 29, 2013 5:10 PM > To: Brian Rosen; Cullen Jennings > Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 > Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 > Schulzrinne > Subject: [stir] Application servers - Re: Call Center Implications >=20 > Getting caught up on some of the STIR discussions, I'd just note that=20 > when we talk about "call centers" or "BPOs" we also need to remember=20 > that we're not only talking about "traditional" call centers but also=20 > what I'll call "voice application service providers". They are=20 > generally automated platforms running applications that a company uses = > for some kind of outbound service. Examples include: >=20 > - calling everyone in a school district with a weather-related=20 > cancellation (or, unfortunately, a school shooting or similar event) > - calling patients to provide reminders of appointments or=20 > notifications of subscriptions available > - calling customers to let them know that a package was delivered or=20 > could be picked up, etc. > - calling people scheduled for a flight to let know they are going to=20 > be delayed > - calling members of an organization with an automated survey about=20 > current issues > - performing a call-back to provide an additional layer of=20 > authentication for some service >=20 > There is a large (and growing) market for these kind of automated=20 > tools and services and the distinction between these calls and=20 > "robocalls" is really only one of intent and the fact that the = recipient has "opted in" > through some kind of system. >=20 > Generally, though, many of the companies want the application to=20 > appear as if it is coming from their own phone number in the same way=20 > that they want an outbound call center to appear as if it is coming=20 > from one of their own phone numbers. >=20 > You could think of these in the same way as "call centers", but I=20 > point this out because some of these new services are very automated=20 > and there are always new startups now emerging in this space. Some of = > them are very "self-service" where the customer does it all while=20 > others have teams of people involved. Some of the companies involved=20 > include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 > former employer), Tropo, Twilio, Convergys and many more[1]. >=20 > If STIR is to succeed, these kind of application platforms will also=20 > need to be able to make calls on behalf of the companies using those platforms. >=20 > Dan >=20 > [1] One report about this market: > http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >=20 >=20 > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org > Skype: danyork http://twitter.com/danyork >=20 > http://www.internetsociety.org/deploy360/ >=20 >=20 >=20 >=20 > On 10/21/13 9:15 AM, "Brian Rosen" wrote: >=20 >> We really need to give each BPO different keys I think. The notion = that >> we are sharing private keys among multiple competing entities who=20 >> provide services for a single enterprise strikes me as a VBI (Very=20 >> Bad Idea). I can't see any real difficulty in having more than one=20 >> authorized entity, each with it's own credentials. Who would have a=20 >> problem? We're already agreeing that there are multiple credentials=20 >> for a number, because the number gets delegated multiple times. >> Consider, just as an example, the BPO and the contracting enterprise=20 >> that was actually delegated the number can both send calls from that=20 >> number. You certainly don't want the enterprise giving out IT'S key=20 >> to it's contractors. At best it's a key it authorizes to one or more = >> of it's > BPOs. >>=20 >> Brian >>=20 >> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >> >> wrote: >>=20 >>>=20 >>> What Fernando is saying makes sense to me a desirable property of=20 >>> the solution and I agree that if we gave each BPO a different=20 >>> private key that would solve it but that might be pretty hard to=20 >>> mange in other ways. I like the requirements but the solution is not = >>> 100% obvious to me. >>>=20 >>>=20 >>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>=20 >>>> Sure. >>>>=20 >>>> Each BPO would have a different private/public key pair. >>>>=20 >>>> So you can trace which one placed the call. >>>>=20 >>>> Brian >>>>=20 >>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>> wrote: >>>>=20 >>>>> Point taken on PAI, but am still struggling with this BPO model. >>>>> Apologies >>>>> upfront if this is obvious and I'm just failing to understand. >>>>>=20 >>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>> originator (specific >>>>> BPO) >>>>> later on? I suppose that at some level the actual caller must be=20 >>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>> person infiltrated in an otherwise legitimate BPO). >>>>>=20 >>>>> Via headers would be the obvious pick, but they don't survive the=20 >>>>> plethora of SBCs that the call is likely to transverse. Or maybe=20 >>>>> the certs themselves can carry this type of data (actual caller=20 >>>>> identity). >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>=20 >>>>>> Don't think that would work without related changes in the = networks. >>>>>> In >>>>>> some networks, PAI is used for called id. They would have to=20 >>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>> definition of PAI. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>> wrote: >>>>>>=20 >>>>>>> Could a signed PAI be a potential solution to the BPO use case? >>>>>>> "From" >>>>>>> identifies the BPO, "PAI" the c >>>>>>> ompany hiring the BPO - based on the delegation process Rosen=20 >>>>>>> mentions. >>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>> solve anyway. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Alex Bobotek >>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>> Cc: stir@ietf.org >>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>=20 >>>>>>>> +1 >>>>>>>> I've assumed that we are headed towards a "sign whatever extras = >>>>>>>> you wish, and indicate what your signature covers" mechanism. >>>>>>>>=20 >>>>>>>> Based on this, standards would need to identify only a minimal=20 >>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>> required group of signed items survives transit intact. >>>>>>>>=20 >>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>> standard, and an appropriate place for all but the most basic=20 >>>>>>>> 'what to sign' >>>>>>>> recommendations. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Alex >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> I see no reason not to allow signing any number-related field=20 >>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>> parties.) >>>>>>>>>=20 >>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>> somewhat limited use for a >>>>>>>> while. >>>>>>>>>=20 >>>>>>>>> ________________________________________ >>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf=20 >>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>> br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>> approved this message." >>>>>>>>>=20 >>>>>>>>> Originating number, display number, and call-back number could = >>>>>>>>> be >>>>>>>>> 3 >>>>>>>>> different things. >>>>>>>>> Should all of them be verifiable? >>>>>>>>>=20 >>>>>>>>> Mike >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>> hires a BPO to place outbound calls, but expect customers to = >>>>>>>>> return these calls to a different place (say, their own and=20 >>>>>>>>> operated call center). This way, this client is authorizing=20 >>>>>>>>> the BPO to use an identity that it >>>>>>>>> (BPO) >>>>>>>> doesn't own. >>>>>>>>> These numbers in this scenario are always operational, just at = >>>>>>>>> a different place. >>>>>>>>>=20 >>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>> belonging to the >>>>>>>> telemarketer. >>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>> announcement, fundraiser, >>>>>>>> etc. >>>>>>>>>=20 >>>>>>>>> If the telemarketer happens to own the inbound call center as=20 >>>>>>>>> well, it very likely owns the number as well and this would=20 >>>>>>>>> necessarily be a special case >>>>>>>>> - it would fall under the same characteristics of any call = center. >>>>>>>>>=20 >>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>> terminology. >>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it = may=20 >>>>>>>>> be hard for others to follow the discussion later. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>> sales!) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>=20 >>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>> company "responsible" for the sales campaign (the "company"=20 >>>>>>>>>> in your >>>>>>>>>> scenario) >>>>>>>>>> and the company operating the sales campaign (the call center = >>>>>>>>>> in your scenario). For the use in forensics (after the=20 >>>>>>>>>> fact >>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>> can follow both paths. >>>>>>>>>>=20 >>>>>>>>>> However can you clarify the following - >>>>>>>>>> - If a SP "signs" the call, is it attesting to the = "responsible" >>>>>>>>>> party for the telemarketing call or the party executing the=20 >>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>=20 >>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>> attesting to >>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>=20 >>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>> telephones (or call center >>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call=20 >>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>> under most national numbering regimes? >>>>>>>>>>=20 >>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>> number as the caller id as part of a telemarketing campaign? >>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>> number that is known or >>>>>>>> recognized. >>>>>>>>>>=20 >>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>> (telemarketing campaign operator) is using their own set of=20 >>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>> campaigns using the same originating numbers, what will they = >>>>>>>>>> sign? Will they just have a credential representing the=20 >>>>>>>>>> call center alone, or a different credential per=20 >>>>>>>>>> telemarketing campaign, or a different credential per =20 >>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>> possible for >>>>>>>> any forensic activity. >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Brian Rosen >>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>> To: Fernando Mousinho >>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>=20 >>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>> acting on its behalf, signs. >>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>> delegates numbers to the company. The company "delegates"=20 >>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>> calls, using that delegation. >>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>> those of the company, but would cover the same number. =20 >>>>>>>>>> Having multiple credentials covering the same number will be = >>>>>>>>>> very common due to the way delegation happens. In order to=20 >>>>>>>>>> allow SPs to sign, without creating credential per TN, we=20 >>>>>>>>>> allow credentials with ranges. >>>>>>>>>> The >>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>=20 >>>>>>>>>> Consider the following complex US case: >>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has a = >>>>>>>>>> credential covering the entire 10K block. >>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. SP = >>>>>>>>>> A has a credential for the entire 1K block SP A resells=20 >>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>> 202-555-123x to Company C. Company C has a credential for a >>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = >>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>=20 >>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>> never sign a call. >>>>>>>>>>=20 >>>>>>>>>> However, SP A or SP B could sign a call from either Company C = >>>>>>>>>> or BPO D using the credential they have. >>>>>>>>>>=20 >>>>>>>>>> The SP for the call center could acquire credentials from the = >>>>>>>>>> BPO and sign on its behalf. I suspect than many service=20 >>>>>>>>>> providers would be reluctant to do so unless the numbers=20 >>>>>>>>>> were from their own inventory (that is, the company got its=20 >>>>>>>>>> numbers from the same SP as the call >>>>>>>> center). >>>>>>>>>> Since that won't be the common case, the call center probably = >>>>>>>>>> has to do the signing itself. >>>>>>>>>>=20 >>>>>>>>>> Brian >>>>>>>>>>=20 >>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs,=20 >>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>> special arrangements with SPs, the majority (small to=20 >>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>> the "originating" SP's willingness to provide this =20 >>>>>>>>>>> signature is a critical success factor for the proposal's adoption. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>> different numbers based on the clients they represent. >>>>>>>>>>> Wouldn't that create a billing issue though? >>>>>>>>>>> This is not an area I understand well, but I would suspect=20 >>>>>>>>>>> that SP >>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>> using a number registered to SP 2 could be a no-no. If this = >>>>>>>>>>> hypothesis is correct, then we are back to the case where=20 >>>>>>>>>>> the SP is signing all calls, >>>>>>>>> even for BPOs. >>>>>>>>>>>=20 >>>>>>>>>>> Or maybe this is another problem we are trying to fix in the = >>>>>>>>>>> working group, in which case we perhaps should state as a=20 >>>>>>>>>>> goal or >>>>>>>> benefit: >>>>>>>>>>> "providing a reliable mechanism to let calls originated from = >>>>>>>>>>> one >>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>=20 >>>>>>>>>>> Fernando >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>> and can source calls using the same number(s) out through=20 >>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>=20 >>>>>>>>>>>> -hadriel >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>> background is). It seems that many of the problems we are = >>>>>>>>>>>>> trying to fix are related to contact centers anyway, so=20 >>>>>>>>>>>>> it is probably a good idea to have everyone in the same >>>>>>>>> page. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>> components in a "typical call center architecture" do you = >>>>>>>>>>>>> see signature and verification taking place? Such = "typical" >>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>> session border controller >>>>>>>>>>>>> (SBC) >>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>> potentially be used throughout the authorization process. >>>>>>>>>>>>> There are different ramifications depending on where your = >>>>>>>>>>>>> mind is at. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> ________________________________ >>>>>>>>>>=20 >>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>> others is prohibited. >>>>>>>>>> If >>>>>>>>>> you are not the intended recipient, please contact the sender = >>>>>>>>>> and delete all copies of the message. >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From br@brianrosen.net Thu Oct 31 10:19:38 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62D921F9FF0 for ; Thu, 31 Oct 2013 10:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.508 X-Spam-Level: X-Spam-Status: No, score=-103.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKCOREG0GvWs for ; Thu, 31 Oct 2013 10:19:33 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5D30411E8173 for ; Thu, 31 Oct 2013 10:19:33 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id e16so1811358qcx.6 for ; Thu, 31 Oct 2013 10:19:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=f82e7eAEYhgiMxXizC1JCfcg3LyxAIxi8yKTiWkKXxs=; b=Fpxbl4kxrZ9/P5fqx8j4cGraZXSdoDBTD1EXJWweoc9+bZg6jsPnaRnTS4o9qWeMzs VgYBuB7pwHWLhPZzy7NemnD3Hk99TUIU09zwcjuj6J2eRd+AHmZhqEt6HMHcIKrPpVfu LWfa6WAxan598GHwPf5If1UVsVgzqinVOmKsIqBrM+PBSdBiCEifXcmxAXKDSbwe0BkS mDqyNof7hgGGsb7vVfOMu6G+KZzuFQL46BuhCSMqLim6YlNRbMnITNpuVra4O/60nRIR ye0gE92CLX7cuPIozGXwxa4M9PEuEere8RSzXH6TpzEbZj2YUn+cmp0YAmXyaEhAALO1 nrKw== X-Gm-Message-State: ALoCoQmOnLRngdk4pz4wf1YoG6ouCyWQIY6QNZIoOT2XJRSygLXnfHOtgqxRAjCl8ogoLJvtXLy9 X-Received: by 10.224.75.200 with SMTP id z8mr6607062qaj.71.1383239972475; Thu, 31 Oct 2013 10:19:32 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id kz8sm8826249qeb.0.2013.10.31.10.19.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 10:19:31 -0700 (PDT) Content-Type: text/plain; charset=windows-1250 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: <00d901ced637$9e8143a0$db83cae0$@shockey.us> Date: Thu, 31 Oct 2013 13:19:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1816) Cc: cnit@ietf.org, DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 17:19:38 -0000 I think the issue is whether we think what is usually called =93contact=94= information is reasonable to send on every call. I do think if we were to do anything like that, we would do it with = xCard and Call-Info, so mechanism is something I agree with you on. If we did use display name for caller name, we get the SIP version of = that, which fixes the 15 US-ASCII character problem of the name. If we were to go farther, I=92d probably want a request, rather than = automatic sending. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the = accuracy, > reliability and the amount of data that is delivered to the CUA over = who is > attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time = communications > system as it moves to an all IP world. Irrespective if CNAM it is = delivered > as part of From: or PAI its not very useful to the consumer.=20 >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15 = Character > ASCII. No support for International character sets the usual. >=20 > It is not a hard stretch to postulate that called parties might like a > richer set of data displayed on their UA's and that can be delivered = by the > SIP headers in some relatively simple form. Modification of the = Call-Info > header for instance. It is equally not a stretch to think that = National > Regulators would be delighted with consumers having a richer set of > information displayed on their handsets in order to make more = decisions. In > addition if we can achieve better all IP to IP interconnection among > providers it would be really really useful if Enterprise systems could > extract more data from their internal directory systems and pass that = along > in the new format for enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point = to > Point video calling using WebRTC or SIP if there is not better display = of > calling party information.=20 >=20 > In addition network operators could insert other 'hints' as to the = nature of > the session based on its ability to validate the Caller ID or other = forms on > analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm = equally > aware the CNAM business model is broken.=20 >=20 > What I'd like to know is what interest there is in this proposition = and are > there parties interested in working on it in advance of say London.=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center > Implications >=20 > More useful in what way? Improving the reliability of caller name? = Please > use the cnit list to discuss this. >=20 > On that list, the current direction seems to be using the display name = part > of the uri to carry a caller name, which is put on the call by the > origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at = least > in North America relies on a termination service provider dip in an > origination service provider database, but it seems feasible to = consider > that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of=20= >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center = Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules = here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly = associated > with the >> business entity for whom the call is being made. That could be an = 800 >> number for instance but I won't bore you with the issues with SMS800=20= >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to = use=20 >> such an identity on behalf of a customer then that is step one. The=20= >> presumption after that is there is some contractual obligation = between=20 >> the service provider and the network about the use of such = identities.=20 >> The network can then "validate" such an assertion. >>=20 >> There is something larger here to consider. Though the focus of STIR=20= >> is validation of a Caller-ID number at some point the RAI area should = take > a >> look at the other side of the coin so to speak. =20 >>=20 >> CNAM. That is NOT something STIR can do but I do believe there is an=20= >> emerging requirement that under some cases the calling party wants to=20= >> or should provide more substantive information about themselves to = the=20 >> called party and frankly 15 character ASCII is not enough. Consumers=20= >> or businesses should be able to see more complete and validated=20 >> information about the session in order to make an better and informed=20= >> decision on whether to accept the 'call' or not. Regulators may want=20= >> to require telemarketing firms to display NG CNAM or CNAM + like data=20= >> as a condition of doing business. >>=20 >> All of the examples you cite are excellent examples where such = verbose=20 >> calling party identification could be displayed. I certainly want to=20= >> answer a call from my doctor on my test results just as I wish to=20 >> ignore a call from Bill Clinton begging me to vote in the Virginia=20 >> Governors election next Tuesday. This is a case where annominity is = not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20= >> probably a reasonable modification of the Call INFO header in SIP = with=20 >> something like a XML based VCARD or JCARD URI whatever and probably=20= >> 3GPP would need to look at how such data is displayed on the mobile=20= >> VoLTE handsets. The network operators would have to understand not to=20= >> modify the contents of such a URI and its source validated but that = is=20 >> a task for another day. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20= >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> Getting caught up on some of the STIR discussions, I'd just note that=20= >> when we talk about "call centers" or "BPOs" we also need to remember=20= >> that we're not only talking about "traditional" call centers but also=20= >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company = uses=20 >> for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20= >> could be picked up, etc. >> - calling people scheduled for a flight to let know they are going to=20= >> be delayed >> - calling members of an organization with an automated survey about=20= >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the = recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> appear as if it is coming from their own phone number in the same way=20= >> that they want an outbound call center to appear as if it is coming=20= >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20= >> and there are always new startups now emerging in this space. Some = of=20 >> them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved=20= >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20= >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion = that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20= >>> Bad Idea). I can't see any real difficulty in having more than one=20= >>> authorized entity, each with it's own credentials. Who would have a=20= >>> problem? We're already agreeing that there are multiple credentials=20= >>> for a number, because the number gets delegated multiple times. >>> Consider, just as an example, the BPO and the contracting enterprise=20= >>> that was actually delegated the number can both send calls from that=20= >>> number. You certainly don't want the enterprise giving out IT'S key=20= >>> to it's contractors. At best it's a key it authorizes to one or = more=20 >>> of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20= >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is = not=20 >>>> 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> Point taken on PAI, but am still struggling with this BPO model. >>>>>> Apologies >>>>>> upfront if this is obvious and I'm just failing to understand. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20= >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20= >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20= >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> Via headers would be the obvious pick, but they don't survive the=20= >>>>>> plethora of SBCs that the call is likely to transverse. Or maybe=20= >>>>>> the certs themselves can carry this type of data (actual caller=20= >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> Don't think that would work without related changes in the = networks. >>>>>>> In >>>>>>> some networks, PAI is used for called id. They would have to=20 >>>>>>> change to use =46rom (if signed maybe). It also doesn't fit = the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Could a signed PAI be a potential solution to the BPO use case? >>>>>>>> "From" >>>>>>>> identifies the BPO, "PAI" the c >>>>>>>> ompany hiring the BPO - based on the delegation process Rosen=20= >>>>>>>> mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20= >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20= >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20= >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever = extras=20 >>>>>>>>> you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal=20= >>>>>>>>> subset of what shall/should be signed, and ensure that any=20= >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic=20= >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20= >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field=20= >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf=20= >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20= >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number = could=20 >>>>>>>>>> be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20= >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers = to=20 >>>>>>>>>> return these calls to a different place (say, their own and=20= >>>>>>>>>> operated call center). This way, this client is authorizing=20= >>>>>>>>>> the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just = at=20 >>>>>>>>>> a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20= >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20= >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> If the telemarketer happens to own the inbound call center as=20= >>>>>>>>>> well, it very likely owns the number as well and this would=20= >>>>>>>>>> necessarily be a special case >>>>>>>>>> - it would fall under the same characteristics of any call = center. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20= >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=8A it = may=20 >>>>>>>>>> be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company"=20= >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call = center=20 >>>>>>>>>>> in your scenario). For the use in forensics (after the=20 >>>>>>>>>>> fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20= >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> However can you clarify the following - >>>>>>>>>>> - If a SP "signs" the call, is it attesting to the = "responsible" >>>>>>>>>>> party for the telemarketing call or the party executing the=20= >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20= >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call=20= >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20= >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of=20= >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will = they=20 >>>>>>>>>>> sign? Will they just have a credential representing the=20 >>>>>>>>>>> call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per =20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] = On=20 >>>>>>>>>>> Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20= >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates"=20= >>>>>>>>>>> use of those numbers to the call center. The call center=20= >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20= >>>>>>>>>>> those of the company, but would cover the same number. =20 >>>>>>>>>>> Having multiple credentials covering the same number will = be=20 >>>>>>>>>>> very common due to the way delegation happens. In order to=20= >>>>>>>>>>> allow SPs to sign, without creating credential per TN, we=20= >>>>>>>>>>> allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has = a=20 >>>>>>>>>>> credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. = SP=20 >>>>>>>>>>> A has a credential for the entire 1K block SP A resells=20 >>>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for = a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company = C=20 >>>>>>>>>>> or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from = the=20 >>>>>>>>>>> BPO and sign on its behalf. I suspect than many service=20= >>>>>>>>>>> providers would be reluctant to do so unless the numbers=20 >>>>>>>>>>> were from their own inventory (that is, the company got its=20= >>>>>>>>>>> numbers from the same SP as the call >>>>>>>>> center). >>>>>>>>>>> Since that won't be the common case, the call center = probably=20 >>>>>>>>>>> has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs,=20= >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to=20 >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20= >>>>>>>>>>>> vouch for their identity. This would probably be the case=20= >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20= >>>>>>>>>>>> the "originating" SP's willingness to provide this =20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20= >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> different numbers based on the clients they represent. >>>>>>>>>>>> Wouldn't that create a billing issue though? >>>>>>>>>>>> This is not an area I understand well, but I would suspect=20= >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20= >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If = this=20 >>>>>>>>>>>> hypothesis is correct, then we are back to the case where=20= >>>>>>>>>>>> the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in = the=20 >>>>>>>>>>>> working group, in which case we perhaps should state as a=20= >>>>>>>>>>>> goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated = from=20 >>>>>>>>>>>> one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20= >>>>>>>>>>>>> and can source calls using the same number(s) out through=20= >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20= >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we = are=20 >>>>>>>>>>>>>> trying to fix are related to contact centers anyway, so=20= >>>>>>>>>>>>>> it is probably a good idea to have everyone in the same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do = you=20 >>>>>>>>>>>>>> see signature and verification taking place? Such = "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where = your=20 >>>>>>>>>>>>>> mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20= >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the = sender=20 >>>>>>>>>>> and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 From Henning.Schulzrinne@fcc.gov Thu Oct 31 10:37:34 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF1D11E822D; Thu, 31 Oct 2013 10:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_COMPNY=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KOptAL-Ap3E; Thu, 31 Oct 2013 10:37:27 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1911E8231; Thu, 31 Oct 2013 10:37:10 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' , Richard Shockey Thread-Topic: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications Thread-Index: AQHO1lxcjDutnFkddUaRrL0uS5DUkpoPUQuA///BJaA= Date: Thu, 31 Oct 2013 17:37:03 +0000 References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> In-Reply-To: <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" , DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 17:37:34 -0000 Call-info: ;purpose=3Dcard or purpose=3Dinfo would seem to address part of that need. Obviously, there has to be a crypt= ographic binding to the calling number, but this could be relatively simple= if the vCard/xCard is signed with the same key as the TN. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Brian Rosen Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center= Implications I think the issue is whether we think what is usually called "contact" info= rmation is reasonable to send on every call. I do think if we were to do anything like that, we would do it with xCard a= nd Call-Info, so mechanism is something I agree with you on. If we did use display name for caller name, we get the SIP version of that,= which fixes the 15 US-ASCII character problem of the name. If we were to go farther, I'd probably want a request, rather than automati= c sending. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > communications system as it moves to an all IP world. Irrespective if=20 > CNAM it is delivered as part of From: or PAI its not very useful to the c= onsumer. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the usual. >=20 > It is not a hard stretch to postulate that called parties might like a=20 > richer set of data displayed on their UA's and that can be delivered=20 > by the SIP headers in some relatively simple form. Modification of the=20 > Call-Info header for instance. It is equally not a stretch to think=20 > that National Regulators would be delighted with consumers having a=20 > richer set of information displayed on their handsets in order to make=20 > more decisions. In addition if we can achieve better all IP to IP=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for enterprise c= alling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say Londo= n. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > On that list, the current direction seems to be using the display name=20 > part of the uri to carry a caller name, which is put on the call by=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in=20 > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of=20 >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules her= e. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> associated > with the >> business entity for whom the call is being made. That could be an 800 >> number for instance but I won't bore you with the issues with SMS800=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. =20 >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such ident= ities. >> The network can then "validate" such an assertion. >>=20 >> There is something larger here to consider. Though the focus of STIR=20 >> is validation of a Caller-ID number at some point the RAI area should=20 >> take > a >> look at the other side of the coin so to speak. =20 >>=20 >> CNAM. That is NOT something STIR can do but I do believe there is an=20 >> emerging requirement that under some cases the calling party wants to=20 >> or should provide more substantive information about themselves to=20 >> the called party and frankly 15 character ASCII is not enough.=20 >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> and informed decision on whether to accept the 'call' or not. =20 >> Regulators may want to require telemarketing firms to display NG CNAM=20 >> or CNAM + like data as a condition of doing business. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly=20 >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> probably 3GPP would need to look at how such data is displayed on the=20 >> mobile VoLTE handsets. The network operators would have to understand=20 >> not to modify the contents of such a URI and its source validated but=20 >> that is a task for another day. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> Getting caught up on some of the STIR discussions, I'd just note that=20 >> when we talk about "call centers" or "BPOs" we also need to remember=20 >> that we're not only talking about "traditional" call centers but also=20 >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> could be picked up, etc. >> - calling people scheduled for a flight to let know they are going to=20 >> be delayed >> - calling members of an organization with an automated survey about=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> appear as if it is coming from their own phone number in the same way=20 >> that they want an outbound call center to appear as if it is coming=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved=20 >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion th= at >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> authorized entity, each with it's own credentials. Who would have a=20 >>> problem? We're already agreeing that there are multiple credentials=20 >>> for a number, because the number gets delegated multiple times. >>> Consider, just as an example, the BPO and the contracting enterprise=20 >>> that was actually delegated the number can both send calls from that=20 >>> number. You certainly don't want the enterprise giving out IT'S key=20 >>> to it's contractors. At best it's a key it authorizes to one or=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> Point taken on PAI, but am still struggling with this BPO model. >>>>>> Apologies >>>>>> upfront if this is obvious and I'm just failing to understand. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> Via headers would be the obvious pick, but they don't survive the=20 >>>>>> plethora of SBCs that the call is likely to transverse. Or maybe=20 >>>>>> the certs themselves can carry this type of data (actual caller=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> Don't think that would work without related changes in the networks= . >>>>>>> In >>>>>>> some networks, PAI is used for called id. They would have to=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Could a signed PAI be a potential solution to the BPO use case? >>>>>>>> "From" >>>>>>>> identifies the BPO, "PAI" the c ompany hiring the BPO - based=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechani= sm. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal=20 >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic=20 >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field=20 >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf=20 >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> If the telemarketer happens to own the inbound call center as=20 >>>>>>>>>> well, it very likely owns the number as well and this would=20 >>>>>>>>>> necessarily be a special case >>>>>>>>>> - it would fall under the same characteristics of any call cente= r. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after=20 >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> However can you clarify the following - >>>>>>>>>>> - If a SP "signs" the call, is it attesting to the "responsible= " >>>>>>>>>>> party for the telemarketing call or the party executing the=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call=20 >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of=20 >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order=20 >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> SP A has a credential for the entire 1K block SP A resells=20 >>>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> numbers were from their own inventory (that is, the company=20 >>>>>>>>>>> got its numbers from the same SP as the call >>>>>>>>> center). >>>>>>>>>>> Since that won't be the common case, the call center=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs,=20 >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> different numbers based on the clients they represent. >>>>>>>>>>>> Wouldn't that create a billing issue though? >>>>>>>>>>>> This is not an area I understand well, but I would suspect=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as=20 >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through=20 >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway,=20 >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the =20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typi= cal" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From michael.hammer@yaanatech.com Thu Oct 31 11:11:33 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F7721F9EAF; Thu, 31 Oct 2013 11:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_COMPNY=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWUSE7WOl7ey; Thu, 31 Oct 2013 11:11:30 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id ED94421F9D90; Thu, 31 Oct 2013 11:11:29 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 31 Oct 2013 11:11:29 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "br@brianrosen.net" , "richard@shockey.us" Thread-Topic: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications Thread-Index: AQHO1l/vPBmavPqkd0evJj3dEIAHMJoPHFMw Date: Thu, 31 Oct 2013 18:11:27 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEF4DB6@sc9-ex2k10mb1.corp.yaanatech.com> References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.113] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01FF_01CED643.16603600" MIME-Version: 1.0 Cc: "cnit@ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:11:33 -0000 ------=_NextPart_000_01FF_01CED643.16603600 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable It might also be nice to have an options indication, so we can tell the other side that we are not just a limited rotary dial phone. Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Henning Schulzrinne Sent: Thursday, October 31, 2013 1:37 PM To: 'Brian Rosen'; Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Call-info: ;purpose=3Dcard or purpose=3Dinfo would seem to address part of that need. Obviously, there has to be a cryptographic binding to the calling number, but this could be = relatively simple if the vCard/xCard is signed with the same key as the TN. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Brian Rosen Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications I think the issue is whether we think what is usually called "contact" information is reasonable to send on every call. I do think if we were to do anything like that, we would do it with = xCard and Call-Info, so mechanism is something I agree with you on. If we did use display name for caller name, we get the SIP version of = that, which fixes the 15 US-ASCII character problem of the name. If we were to go farther, I'd probably want a request, rather than = automatic sending. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > communications system as it moves to an all IP world. Irrespective if = > CNAM it is delivered as part of From: or PAI its not very useful to = the consumer. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the = usual. >=20 > It is not a hard stretch to postulate that called parties might like a = > richer set of data displayed on their UA's and that can be delivered=20 > by the SIP headers in some relatively simple form. Modification of the = > Call-Info header for instance. It is equally not a stretch to think=20 > that National Regulators would be delighted with consumers having a=20 > richer set of information displayed on their handsets in order to make = > more decisions. In addition if we can achieve better all IP to IP=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for = enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > On that list, the current direction seems to be using the display name = > part of the uri to carry a caller name, which is put on the call by=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of = >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> associated > with the >> business entity for whom the call is being made. That could be an = 800 >> number for instance but I won't bore you with the issues with SMS800=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such identities. >> The network can then "validate" such an assertion. >>=20 >> There is something larger here to consider. Though the focus of STIR = >> is validation of a Caller-ID number at some point the RAI area should = >> take > a >> look at the other side of the coin so to speak. =20 >>=20 >> CNAM. That is NOT something STIR can do but I do believe there is an = >> emerging requirement that under some cases the calling party wants to = >> or should provide more substantive information about themselves to=20 >> the called party and frankly 15 character ASCII is not enough. >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> and informed decision on whether to accept the 'call' or not. >> Regulators may want to require telemarketing firms to display NG CNAM = >> or CNAM + like data as a condition of doing business. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> probably 3GPP would need to look at how such data is displayed on the = >> mobile VoLTE handsets. The network operators would have to understand = >> not to modify the contents of such a URI and its source validated but = >> that is a task for another day. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> Getting caught up on some of the STIR discussions, I'd just note that = >> when we talk about "call centers" or "BPOs" we also need to remember=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> could be picked up, etc. >> - calling people scheduled for a flight to let know they are going to = >> be delayed >> - calling members of an organization with an automated survey about=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> appear as if it is coming from their own phone number in the same way = >> that they want an outbound call center to appear as if it is coming=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> authorized entity, each with it's own credentials. Who would have a = >>> problem? We're already agreeing that there are multiple credentials = >>> for a number, because the number gets delegated multiple times. >>> Consider, just as an example, the BPO and the contracting enterprise = >>> that was actually delegated the number can both send calls from that = >>> number. You certainly don't want the enterprise giving out IT'S key = >>> to it's contractors. At best it's a key it authorizes to one or=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> Point taken on PAI, but am still struggling with this BPO model. >>>>>> Apologies >>>>>> upfront if this is obvious and I'm just failing to understand. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> Via headers would be the obvious pick, but they don't survive the = >>>>>> plethora of SBCs that the call is likely to transverse. Or maybe = >>>>>> the certs themselves can carry this type of data (actual caller=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> Don't think that would work without related changes in the = networks. >>>>>>> In >>>>>>> some networks, PAI is used for called id. They would have to=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Could a signed PAI be a potential solution to the BPO use case? >>>>>>>> "From" >>>>>>>> identifies the BPO, "PAI" the c ompany hiring the BPO - based=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal = >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field = >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> If the telemarketer happens to own the inbound call center as = >>>>>>>>>> well, it very likely owns the number as well and this would = >>>>>>>>>> necessarily be a special case >>>>>>>>>> - it would fall under the same characteristics of any call center. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> However can you clarify the following - >>>>>>>>>>> - If a SP "signs" the call, is it attesting to the = "responsible" >>>>>>>>>>> party for the telemarketing call or the party executing the=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> SP A has a credential for the entire 1K block SP A resells = >>>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> numbers were from their own inventory (that is, the company = >>>>>>>>>>> got its numbers from the same SP as the call >>>>>>>>> center). >>>>>>>>>>> Since that won't be the common case, the call center=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> different numbers based on the clients they represent. >>>>>>>>>>>> Wouldn't that create a billing issue though? >>>>>>>>>>>> This is not an area I understand well, but I would suspect=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through = >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the=20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_01FF_01CED643.16603600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTAz MTE4MTEyNlowIwYJKoZIhvcNAQkEMRYEFMguhiHOL/FiPdRacVnZj++4ea7ZMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAOy7f+gTrnu5vNMXf11sX22puffkIlH83H+GFhout D60uYkRQNU5ZvK4WdGNnjS9JkLfJ5CY7BOnAWrBh84eFHOT34M5BfjMILlBUY/gk/Tl6jfVmpWDM 9uPJXuVpvzQxGIHqixyfsB+1iuLuTBQRW7IY4lMQrebBVigIVlzbeYwyarqenLwy1iM672k0xJK3 WXZa2L2C5fQPKHZ8UV04z0qL05WLW2gqDKihGu3p6NwJF+W9Y5d8SagQuCOsu/Vn7PwjNpjCe3J+ 30/aBdbmb+jp1cM7vEURuvm9xaqtbEmUDPgAIVZnn6GmWzSuRrIubCmC3Z/oMfTVDaJYp0QeggAA AAAAAA== ------=_NextPart_000_01FF_01CED643.16603600-- From richard@shockey.us Thu Oct 31 14:34:09 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C032D11E826C for ; Thu, 31 Oct 2013 14:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.092 X-Spam-Level: X-Spam-Status: No, score=-101.092 tagged_above=-999 required=5 tests=[AWL=-1.127, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_COMPNY=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scdttWwY7FnE for ; Thu, 31 Oct 2013 14:34:04 -0700 (PDT) Received: from oproxy13-pub.mail.unifiedlayer.com (oproxy13-pub.mail.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id DE65311E81A6 for ; Thu, 31 Oct 2013 14:33:34 -0700 (PDT) Received: (qmail 19129 invoked by uid 0); 31 Oct 2013 21:33:09 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.mail.unifiedlayer.com with SMTP; 31 Oct 2013 21:33:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=LdbuowNHufpaX/WZkhXqZ/JfE9P3E5uUrY7xWGHLmsw=; b=SYoc+WuipIeFIuaMc326JXAiaRUg2NQsslJcTZ2i2b3V9ry5MdIZgTigTVzO2wFGKH1yk6Jsw9whGf+Js+Qw5dBtawQvCzIoAQ/SpD+x7t0f4i2nxtDn6as3MyBMxGni; Received: from [173.79.179.104] (port=54345 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbzrY-0002OE-5x; Thu, 31 Oct 2013 15:33:08 -0600 From: "Richard Shockey" To: "'Brian Rosen'" References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> In-Reply-To: <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> Date: Thu, 31 Oct 2013 17:33:07 -0400 Message-ID: <020a01ced680$caf4ec90$60dec5b0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8PAdOJjcEBFampjJela41g X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: cnit@ietf.org, 'DISPATCH' Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 21:34:09 -0000 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications I think the issue is whether we think what is usually called "contact" information is reasonable to send on every call. I do think if we were to do anything like that, we would do it with = xCard and Call-Info, so mechanism is something I agree with you on. [RS> ] Exactly we have a big tool box and the tools are there. The = larger point I was trying to make is as we look at the larger Caller ID = Spoofing security area one of the thinks Henning and others have pointed out is = we are actually trying to preserve the integrity of the whole system and = giving consumers something that is actually better is a useful thing to do.=20 If we did use display name for caller name, we get the SIP version of = that, which fixes the 15 US-ASCII character problem of the name. [RS> ] You could transmit both but if CNAM + were available then use = that. Plus any other helpful information such as red flashing text... "WARNING WARNING POLITICAL CALL POLITICAL CALL ANSWER AT YOUR PERIL" That is a service I could pay real money for.=20 If we were to go farther, I'd probably want a request, rather than = automatic sending. [ [RS> ] Why does it not surprise me you would say that. That said = actually SS7 did allow for either model in CNAM. PUSH or PULL. It was = implemented in Canadian Tandem Access platforms but Canadian Carriers like US = carriers choose the dip model into LIDB. In any event it makes no difference. = That is properly an interconnection negotiation between service providers or = some general technical policy that a PBX hosted assertion is not tampered = with during transit. I do believe the current business model is broken, = however we don't need to nor should debate that. I also believe it is = potentially a good business and essential in making things like P2P video = communications more palatable for enterprises and consumers to use.=20 I am very interested in working on improving caller name. [RS> ] So I'm not completely insane? :-) Ok then it seams the conversation is worth having and there is productive work here .. See = you in London. =20 Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > communications system as it moves to an all IP world. Irrespective if = > CNAM it is delivered as part of From: or PAI its not very useful to = the consumer. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the = usual. >=20 > It is not a hard stretch to postulate that called parties might like a = > richer set of data displayed on their UA's and that can be delivered=20 > by the SIP headers in some relatively simple form. Modification of the = > Call-Info header for instance. It is equally not a stretch to think=20 > that National Regulators would be delighted with consumers having a=20 > richer set of information displayed on their handsets in order to make = > more decisions. In addition if we can achieve better all IP to IP=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for = enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > On that list, the current direction seems to be using the display name = > part of the uri to carry a caller name, which is put on the call by=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of = >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> associated > with the >> business entity for whom the call is being made. That could be an = 800 >> number for instance but I won't bore you with the issues with SMS800=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. =20 >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such identities. >> The network can then "validate" such an assertion. >>=20 >> There is something larger here to consider. Though the focus of STIR = >> is validation of a Caller-ID number at some point the RAI area should = >> take > a >> look at the other side of the coin so to speak. =20 >>=20 >> CNAM. That is NOT something STIR can do but I do believe there is an = >> emerging requirement that under some cases the calling party wants to = >> or should provide more substantive information about themselves to=20 >> the called party and frankly 15 character ASCII is not enough.=20 >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> and informed decision on whether to accept the 'call' or not. =20 >> Regulators may want to require telemarketing firms to display NG CNAM = >> or CNAM + like data as a condition of doing business. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> probably 3GPP would need to look at how such data is displayed on the = >> mobile VoLTE handsets. The network operators would have to understand = >> not to modify the contents of such a URI and its source validated but = >> that is a task for another day. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> Getting caught up on some of the STIR discussions, I'd just note that = >> when we talk about "call centers" or "BPOs" we also need to remember=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> could be picked up, etc. >> - calling people scheduled for a flight to let know they are going to = >> be delayed >> - calling members of an organization with an automated survey about=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> appear as if it is coming from their own phone number in the same way = >> that they want an outbound call center to appear as if it is coming=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> authorized entity, each with it's own credentials. Who would have a = >>> problem? We're already agreeing that there are multiple credentials = >>> for a number, because the number gets delegated multiple times. >>> Consider, just as an example, the BPO and the contracting enterprise = >>> that was actually delegated the number can both send calls from that = >>> number. You certainly don't want the enterprise giving out IT'S key = >>> to it's contractors. At best it's a key it authorizes to one or=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> Point taken on PAI, but am still struggling with this BPO model. >>>>>> Apologies >>>>>> upfront if this is obvious and I'm just failing to understand. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> Via headers would be the obvious pick, but they don't survive the = >>>>>> plethora of SBCs that the call is likely to transverse. Or maybe = >>>>>> the certs themselves can carry this type of data (actual caller=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> Don't think that would work without related changes in the = networks. >>>>>>> In >>>>>>> some networks, PAI is used for called id. They would have to=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Could a signed PAI be a potential solution to the BPO use case? >>>>>>>> "From" >>>>>>>> identifies the BPO, "PAI" the c ompany hiring the BPO - based=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal = >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field = >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> If the telemarketer happens to own the inbound call center as = >>>>>>>>>> well, it very likely owns the number as well and this would = >>>>>>>>>> necessarily be a special case >>>>>>>>>> - it would fall under the same characteristics of any call center. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> However can you clarify the following - >>>>>>>>>>> - If a SP "signs" the call, is it attesting to the = "responsible" >>>>>>>>>>> party for the telemarketing call or the party executing the=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> SP A has a credential for the entire 1K block SP A resells = >>>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> numbers were from their own inventory (that is, the company = >>>>>>>>>>> got its numbers from the same SP as the call >>>>>>>>> center). >>>>>>>>>>> Since that won't be the common case, the call center=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> different numbers based on the clients they represent. >>>>>>>>>>>> Wouldn't that create a billing issue though? >>>>>>>>>>>> This is not an area I understand well, but I would suspect=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through = >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the =20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 From richard@shockey.us Thu Oct 31 14:36:39 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDC511E8261 for ; Thu, 31 Oct 2013 14:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.884 X-Spam-Level: X-Spam-Status: No, score=-100.884 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_COMPNY=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNN9wI-n53h7 for ; Thu, 31 Oct 2013 14:36:39 -0700 (PDT) Received: from outbound-ss-2175.bluehost.com (outbound-ss-2175.bluehost.com [74.220.218.8]) by ietfa.amsl.com (Postfix) with SMTP id A880021E8056 for ; Thu, 31 Oct 2013 14:36:15 -0700 (PDT) Received: (qmail 6607 invoked by uid 0); 31 Oct 2013 21:36:06 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy16-pub.mail.unifiedlayer.com with SMTP; 31 Oct 2013 21:36:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=RdgpHb6eieeioawSmr7mcDJEMcgHcFQ5DSlU6vBcKgU=; b=PaHTkI4xISe5/x9wWYZfyzes25M6O++DLtWFGw6c7bvUKzkzss1U8NjJWZH73JQDmfOAzbBazDEYWg9s0ItK/cpsCHEAj6VEAsTdLJAESn7Ms0gEG3y5tIgmCJt6Zf2I; Received: from [173.79.179.104] (port=54366 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbzuP-0004nX-HB; Thu, 31 Oct 2013 15:36:05 -0600 From: "Richard Shockey" To: "'Michael Hammer'" , , References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF4DB6@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEF4DB6@sc9-ex2k10mb1.corp.yaanatech.com> Date: Thu, 31 Oct 2013 17:36:04 -0400 Message-ID: <021401ced681$34ab2640$9e0172c0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8PAdOJjcEBFampjAIH39XjAZ4KSLyXiD+zcA== X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: cnit@ietf.org, dispatch@ietf.org Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 21:36:40 -0000 Could you explain what you mean here? I'm modestly confused. Options indicator for what .. what the other side is capable of? =20 Now you really are in a favorite subject of mine. Before the INVITE = "dip" for capability as well as terminating carrier SBC etc. Welcome to the = new world of numbering databases.=20 -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Thursday, October 31, 2013 2:11 PM To: Henning.Schulzrinne@fcc.gov; br@brianrosen.net; richard@shockey.us Cc: cnit@ietf.org; dispatch@ietf.org Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications It might also be nice to have an options indication, so we can tell the other side that we are not just a limited rotary dial phone. Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Henning Schulzrinne Sent: Thursday, October 31, 2013 1:37 PM To: 'Brian Rosen'; Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Call-info: ;purpose=3Dcard or purpose=3Dinfo would seem to address part of that need. Obviously, there has to be a cryptographic binding to the calling number, but this could be = relatively simple if the vCard/xCard is signed with the same key as the TN. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Brian Rosen Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications I think the issue is whether we think what is usually called "contact" information is reasonable to send on every call. I do think if we were to do anything like that, we would do it with = xCard and Call-Info, so mechanism is something I agree with you on. If we did use display name for caller name, we get the SIP version of = that, which fixes the 15 US-ASCII character problem of the name. If we were to go farther, I'd probably want a request, rather than = automatic sending. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > communications system as it moves to an all IP world. Irrespective if = > CNAM it is delivered as part of From: or PAI its not very useful to = the consumer. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the = usual. >=20 > It is not a hard stretch to postulate that called parties might like a = > richer set of data displayed on their UA's and that can be delivered=20 > by the SIP headers in some relatively simple form. Modification of the = > Call-Info header for instance. It is equally not a stretch to think=20 > that National Regulators would be delighted with consumers having a=20 > richer set of information displayed on their handsets in order to make = > more decisions. In addition if we can achieve better all IP to IP=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for = enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > On that list, the current direction seems to be using the display name = > part of the uri to carry a caller name, which is put on the call by=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of = >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> associated > with the >> business entity for whom the call is being made. That could be an = 800 >> number for instance but I won't bore you with the issues with SMS800=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such identities. >> The network can then "validate" such an assertion. >>=20 >> There is something larger here to consider. Though the focus of STIR = >> is validation of a Caller-ID number at some point the RAI area should = >> take > a >> look at the other side of the coin so to speak. =20 >>=20 >> CNAM. That is NOT something STIR can do but I do believe there is an = >> emerging requirement that under some cases the calling party wants to = >> or should provide more substantive information about themselves to=20 >> the called party and frankly 15 character ASCII is not enough. >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> and informed decision on whether to accept the 'call' or not. >> Regulators may want to require telemarketing firms to display NG CNAM = >> or CNAM + like data as a condition of doing business. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> probably 3GPP would need to look at how such data is displayed on the = >> mobile VoLTE handsets. The network operators would have to understand = >> not to modify the contents of such a URI and its source validated but = >> that is a task for another day. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> Getting caught up on some of the STIR discussions, I'd just note that = >> when we talk about "call centers" or "BPOs" we also need to remember=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> could be picked up, etc. >> - calling people scheduled for a flight to let know they are going to = >> be delayed >> - calling members of an organization with an automated survey about=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> appear as if it is coming from their own phone number in the same way = >> that they want an outbound call center to appear as if it is coming=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> authorized entity, each with it's own credentials. Who would have a = >>> problem? We're already agreeing that there are multiple credentials = >>> for a number, because the number gets delegated multiple times. >>> Consider, just as an example, the BPO and the contracting enterprise = >>> that was actually delegated the number can both send calls from that = >>> number. You certainly don't want the enterprise giving out IT'S key = >>> to it's contractors. At best it's a key it authorizes to one or=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> Point taken on PAI, but am still struggling with this BPO model. >>>>>> Apologies >>>>>> upfront if this is obvious and I'm just failing to understand. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> Via headers would be the obvious pick, but they don't survive the = >>>>>> plethora of SBCs that the call is likely to transverse. Or maybe = >>>>>> the certs themselves can carry this type of data (actual caller=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> Don't think that would work without related changes in the = networks. >>>>>>> In >>>>>>> some networks, PAI is used for called id. They would have to=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Could a signed PAI be a potential solution to the BPO use case? >>>>>>>> "From" >>>>>>>> identifies the BPO, "PAI" the c ompany hiring the BPO - based=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal = >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field = >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> If the telemarketer happens to own the inbound call center as = >>>>>>>>>> well, it very likely owns the number as well and this would = >>>>>>>>>> necessarily be a special case >>>>>>>>>> - it would fall under the same characteristics of any call center. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> However can you clarify the following - >>>>>>>>>>> - If a SP "signs" the call, is it attesting to the = "responsible" >>>>>>>>>>> party for the telemarketing call or the party executing the=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> SP A has a credential for the entire 1K block SP A resells = >>>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> numbers were from their own inventory (that is, the company = >>>>>>>>>>> got its numbers from the same SP as the call >>>>>>>>> center). >>>>>>>>>>> Since that won't be the common case, the call center=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> different numbers based on the clients they represent. >>>>>>>>>>>> Wouldn't that create a billing issue though? >>>>>>>>>>>> This is not an area I understand well, but I would suspect=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through = >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the=20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From michael.hammer@yaanatech.com Thu Oct 31 14:44:50 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E0C21F9DD0; Thu, 31 Oct 2013 14:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=-1.160, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_COMPNY=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDDWKLUUad3k; Thu, 31 Oct 2013 14:44:46 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id A29C411E8243; Thu, 31 Oct 2013 14:44:42 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 31 Oct 2013 14:44:42 -0700 From: Michael Hammer To: "richard@shockey.us" , "Henning.Schulzrinne@fcc.gov" , "br@brianrosen.net" Thread-Topic: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications Thread-Index: AQHO1l/vPBmavPqkd0evJj3dEIAHMJoPHFMwgACurAD//4ySgA== Date: Thu, 31 Oct 2013 21:44:40 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEF5224@sc9-ex2k10mb1.corp.yaanatech.com> References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF4DB6@sc9-ex2k10mb1.corp.yaanatech.com> <021401ced681$34ab2640$9e0172c0$@shockey.us> In-Reply-To: <021401ced681$34ab2640$9e0172c0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.113] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_031A_01CED660.DFA107C0" MIME-Version: 1.0 Cc: "cnit@ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 21:44:50 -0000 ------=_NextPart_000_031A_01CED660.DFA107C0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable What you sign and send may depend on what the receiver is capable of displaying. What triggered the thought was a restriction to 15 characters, when = todays phones can display a whole lot more. I am just saying don't let obsolete technology hobble future technology. Was wondering what might be possible with VoLTE, for example. Mike -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Thursday, October 31, 2013 5:36 PM To: Michael Hammer; Henning.Schulzrinne@fcc.gov; br@brianrosen.net Cc: cnit@ietf.org; dispatch@ietf.org Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Could you explain what you mean here? I'm modestly confused. Options indicator for what .. what the other side is capable of? =20 Now you really are in a favorite subject of mine. Before the INVITE = "dip" for capability as well as terminating carrier SBC etc. Welcome to the = new world of numbering databases.=20 -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, October 31, 2013 2:11 PM To: Henning.Schulzrinne@fcc.gov; br@brianrosen.net; richard@shockey.us Cc: cnit@ietf.org; dispatch@ietf.org Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications It might also be nice to have an options indication, so we can tell the other side that we are not just a limited rotary dial phone. Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Henning Schulzrinne Sent: Thursday, October 31, 2013 1:37 PM To: 'Brian Rosen'; Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Call-info: ;purpose=3Dcard or purpose=3Dinfo would seem to address part of that need. Obviously, there has to be a cryptographic binding to the calling number, but this could be = relatively simple if the vCard/xCard is signed with the same key as the TN. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Brian Rosen Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications I think the issue is whether we think what is usually called "contact" information is reasonable to send on every call. I do think if we were to do anything like that, we would do it with = xCard and Call-Info, so mechanism is something I agree with you on. If we did use display name for caller name, we get the SIP version of = that, which fixes the 15 US-ASCII character problem of the name. If we were to go farther, I'd probably want a request, rather than = automatic sending. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > communications system as it moves to an all IP world. Irrespective if = > CNAM it is delivered as part of From: or PAI its not very useful to=20 > the consumer. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the = usual. >=20 > It is not a hard stretch to postulate that called parties might like a = > richer set of data displayed on their UA's and that can be delivered=20 > by the SIP headers in some relatively simple form. Modification of the = > Call-Info header for instance. It is equally not a stretch to think=20 > that National Regulators would be delighted with consumers having a=20 > richer set of information displayed on their handsets in order to make = > more decisions. In addition if we can achieve better all IP to IP=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for=20 > enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > On that list, the current direction seems to be using the display name = > part of the uri to carry a caller name, which is put on the call by=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of = >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> associated > with the >> business entity for whom the call is being made. That could be an = 800 >> number for instance but I won't bore you with the issues with SMS800=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such identities. >> The network can then "validate" such an assertion. >>=20 >> There is something larger here to consider. Though the focus of STIR = >> is validation of a Caller-ID number at some point the RAI area should = >> take > a >> look at the other side of the coin so to speak. =20 >>=20 >> CNAM. That is NOT something STIR can do but I do believe there is an = >> emerging requirement that under some cases the calling party wants to = >> or should provide more substantive information about themselves to=20 >> the called party and frankly 15 character ASCII is not enough. >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> and informed decision on whether to accept the 'call' or not. >> Regulators may want to require telemarketing firms to display NG CNAM = >> or CNAM + like data as a condition of doing business. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> probably 3GPP would need to look at how such data is displayed on the = >> mobile VoLTE handsets. The network operators would have to understand = >> not to modify the contents of such a URI and its source validated but = >> that is a task for another day. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> Getting caught up on some of the STIR discussions, I'd just note that = >> when we talk about "call centers" or "BPOs" we also need to remember=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> could be picked up, etc. >> - calling people scheduled for a flight to let know they are going to = >> be delayed >> - calling members of an organization with an automated survey about=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> appear as if it is coming from their own phone number in the same way = >> that they want an outbound call center to appear as if it is coming=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> authorized entity, each with it's own credentials. Who would have a = >>> problem? We're already agreeing that there are multiple credentials = >>> for a number, because the number gets delegated multiple times. >>> Consider, just as an example, the BPO and the contracting enterprise = >>> that was actually delegated the number can both send calls from that = >>> number. You certainly don't want the enterprise giving out IT'S key = >>> to it's contractors. At best it's a key it authorizes to one or=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> Point taken on PAI, but am still struggling with this BPO model. >>>>>> Apologies >>>>>> upfront if this is obvious and I'm just failing to understand. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> Via headers would be the obvious pick, but they don't survive the = >>>>>> plethora of SBCs that the call is likely to transverse. Or maybe = >>>>>> the certs themselves can carry this type of data (actual caller=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> Don't think that would work without related changes in the = networks. >>>>>>> In >>>>>>> some networks, PAI is used for called id. They would have to=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Could a signed PAI be a potential solution to the BPO use case? >>>>>>>> "From" >>>>>>>> identifies the BPO, "PAI" the c ompany hiring the BPO - based=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal = >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field = >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> If the telemarketer happens to own the inbound call center as = >>>>>>>>>> well, it very likely owns the number as well and this would = >>>>>>>>>> necessarily be a special case >>>>>>>>>> - it would fall under the same characteristics of any call center. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> However can you clarify the following - >>>>>>>>>>> - If a SP "signs" the call, is it attesting to the = "responsible" >>>>>>>>>>> party for the telemarketing call or the party executing the=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> SP A has a credential for the entire 1K block SP A resells = >>>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> numbers were from their own inventory (that is, the company = >>>>>>>>>>> got its numbers from the same SP as the call >>>>>>>>> center). >>>>>>>>>>> Since that won't be the common case, the call center=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> different numbers based on the clients they represent. >>>>>>>>>>>> Wouldn't that create a billing issue though? >>>>>>>>>>>> This is not an area I understand well, but I would suspect=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through = >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the=20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_031A_01CED660.DFA107C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTAz MTIxNDQzOVowIwYJKoZIhvcNAQkEMRYEFDsGKr9OCPbIwhOh38GGPJjtejwhMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEANSQfmzlXco018noX2ApDq3+ASAARcjma4oquI6o7 yQLt4Ze46Mo2ImA0mIygnH0mDSdYlRiOSjo40eSCsep/2l8OJwe4AQco64syQE74Qxy/RRe67dWo YCBORVZpxc1buLWcCKLGSX0BzEVl2rnAo0AsrffDoc2GpfflbsSmzCz5XzaEDIKwpdabQJwo92jK D9jDUeinCogIMzpRIRA7BjzozIPtrBxLjx6Hpf9QKwsIvNUYEUOTQVc59rfEACHOaHvJuD46WrHP tQY6yWY18qxy+3sHGKKNabbsn4OJgE9Z6EvgdjsHpUfRuo5jCtlWqX6x0hH9qH1tsehsVYk47gAA AAAAAA== ------=_NextPart_000_031A_01CED660.DFA107C0-- From richard@shockey.us Thu Oct 31 15:12:27 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3646911E81BE for ; Thu, 31 Oct 2013 15:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.763 X-Spam-Level: X-Spam-Status: No, score=-100.763 tagged_above=-999 required=5 tests=[AWL=-1.064, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_COMPNY=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwuovgGW+74s for ; Thu, 31 Oct 2013 15:12:27 -0700 (PDT) Received: from outbound-ss-2.hostmonster.com (outbound-ss-2.hostmonster.com [66.147.240.26]) by ietfa.amsl.com (Postfix) with SMTP id 6591D11E81EB for ; Thu, 31 Oct 2013 15:12:22 -0700 (PDT) Received: (qmail 4598 invoked by uid 0); 31 Oct 2013 21:33:43 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.mail.unifiedlayer.com with SMTP; 31 Oct 2013 21:33:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=TndjlG0YKSQV5cuDnoZInODPFsLJfT4RG4CQ6bBynqo=; b=OcvspdOh0vbKzl6lX7XT4x1zPuAYQPZiQ3Kr8UYZ/RE+74CqSkjvni8M7SiYVQPH7/jp5TQWKLS9Os5b/aUweVEh6AYF+kPIcNMAN/K3orMuCsH2ExCfPs89c0K/Rrp9; Received: from [173.79.179.104] (port=54349 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vbzs6-0002oy-S1; Thu, 31 Oct 2013 15:33:43 -0600 From: "Richard Shockey" To: "'Henning Schulzrinne'" , "'Brian Rosen'" References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> In-Reply-To: Date: Thu, 31 Oct 2013 17:33:42 -0400 Message-ID: <021301ced680$dfa0d320$9ee27960$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8PAdOJjcEBFampjAIH39Xjl5Uv3eA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: cnit@ietf.org, 'DISPATCH' Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 22:12:27 -0000 +1 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Thursday, October 31, 2013 1:37 PM To: 'Brian Rosen'; Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Call-info: ;purpose=3Dcard or purpose=3Dinfo would seem to address part of that need. Obviously, there has to be a cryptographic binding to the calling number, but this could be = relatively simple if the vCard/xCard is signed with the same key as the TN. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Brian Rosen Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications I think the issue is whether we think what is usually called "contact" information is reasonable to send on every call. I do think if we were to do anything like that, we would do it with = xCard and Call-Info, so mechanism is something I agree with you on. If we did use display name for caller name, we get the SIP version of = that, which fixes the 15 US-ASCII character problem of the name. If we were to go farther, I'd probably want a request, rather than = automatic sending. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > communications system as it moves to an all IP world. Irrespective if = > CNAM it is delivered as part of From: or PAI its not very useful to = the consumer. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the = usual. >=20 > It is not a hard stretch to postulate that called parties might like a = > richer set of data displayed on their UA's and that can be delivered=20 > by the SIP headers in some relatively simple form. Modification of the = > Call-Info header for instance. It is equally not a stretch to think=20 > that National Regulators would be delighted with consumers having a=20 > richer set of information displayed on their handsets in order to make = > more decisions. In addition if we can achieve better all IP to IP=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for = enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > On that list, the current direction seems to be using the display name = > part of the uri to carry a caller name, which is put on the call by=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of = >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> associated > with the >> business entity for whom the call is being made. That could be an = 800 >> number for instance but I won't bore you with the issues with SMS800=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such identities. >> The network can then "validate" such an assertion. >>=20 >> There is something larger here to consider. Though the focus of STIR = >> is validation of a Caller-ID number at some point the RAI area should = >> take > a >> look at the other side of the coin so to speak. =20 >>=20 >> CNAM. That is NOT something STIR can do but I do believe there is an = >> emerging requirement that under some cases the calling party wants to = >> or should provide more substantive information about themselves to=20 >> the called party and frankly 15 character ASCII is not enough. >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> and informed decision on whether to accept the 'call' or not. >> Regulators may want to require telemarketing firms to display NG CNAM = >> or CNAM + like data as a condition of doing business. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> probably 3GPP would need to look at how such data is displayed on the = >> mobile VoLTE handsets. The network operators would have to understand = >> not to modify the contents of such a URI and its source validated but = >> that is a task for another day. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> Getting caught up on some of the STIR discussions, I'd just note that = >> when we talk about "call centers" or "BPOs" we also need to remember=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> could be picked up, etc. >> - calling people scheduled for a flight to let know they are going to = >> be delayed >> - calling members of an organization with an automated survey about=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> appear as if it is coming from their own phone number in the same way = >> that they want an outbound call center to appear as if it is coming=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> authorized entity, each with it's own credentials. Who would have a = >>> problem? We're already agreeing that there are multiple credentials = >>> for a number, because the number gets delegated multiple times. >>> Consider, just as an example, the BPO and the contracting enterprise = >>> that was actually delegated the number can both send calls from that = >>> number. You certainly don't want the enterprise giving out IT'S key = >>> to it's contractors. At best it's a key it authorizes to one or=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> Point taken on PAI, but am still struggling with this BPO model. >>>>>> Apologies >>>>>> upfront if this is obvious and I'm just failing to understand. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> Via headers would be the obvious pick, but they don't survive the = >>>>>> plethora of SBCs that the call is likely to transverse. Or maybe = >>>>>> the certs themselves can carry this type of data (actual caller=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> Don't think that would work without related changes in the = networks. >>>>>>> In >>>>>>> some networks, PAI is used for called id. They would have to=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Could a signed PAI be a potential solution to the BPO use case? >>>>>>>> "From" >>>>>>>> identifies the BPO, "PAI" the c ompany hiring the BPO - based=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal = >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field = >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> If the telemarketer happens to own the inbound call center as = >>>>>>>>>> well, it very likely owns the number as well and this would = >>>>>>>>>> necessarily be a special case >>>>>>>>>> - it would fall under the same characteristics of any call center. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> However can you clarify the following - >>>>>>>>>>> - If a SP "signs" the call, is it attesting to the = "responsible" >>>>>>>>>>> party for the telemarketing call or the party executing the=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> SP A has a credential for the entire 1K block SP A resells = >>>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> numbers were from their own inventory (that is, the company = >>>>>>>>>>> got its numbers from the same SP as the call >>>>>>>>> center). >>>>>>>>>>> Since that won't be the common case, the call center=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> different numbers based on the clients they represent. >>>>>>>>>>>> Wouldn't that create a billing issue though? >>>>>>>>>>>> This is not an area I understand well, but I would suspect=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through = >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the=20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Thu Oct 31 15:20:28 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01A011E8261 for ; Thu, 31 Oct 2013 15:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.682 X-Spam-Level: X-Spam-Status: No, score=-100.682 tagged_above=-999 required=5 tests=[AWL=-0.983, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_COMPNY=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z51UMMQchBB0 for ; Thu, 31 Oct 2013 15:20:24 -0700 (PDT) Received: from oproxy4-pub.mail.unifiedlayer.com (oproxy4-pub.mail.unifiedlayer.com [74.220.216.66]) by ietfa.amsl.com (Postfix) with SMTP id E2B0021F9F80 for ; Thu, 31 Oct 2013 15:20:23 -0700 (PDT) Received: (qmail 29965 invoked by uid 0); 31 Oct 2013 22:11:52 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy4.mail.unifiedlayer.com with SMTP; 31 Oct 2013 22:11:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=/eSwNJrJnUxo3RqnB7V+3o7MIAMYXB3p0xu6nkaula0=; b=Y/vha9jx9o81GbJroYDeJhqt+KB0siDREeXzOeVYAWaJP/IfhOXr/DVXBy2bcJvbAGC7eFCsn+snvfBrMmmY4Kd1HZGd/0s6WOrosXgWwfAPzqq0TYVAYeiG3SQYLGKQ; Received: from [173.79.179.104] (port=54594 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vc0T2-0000i4-BM; Thu, 31 Oct 2013 16:11:52 -0600 From: "Richard Shockey" To: "'Michael Hammer'" , , References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF4DB6@sc9-ex2k10mb1.corp.yaanatech.com> <021401ced681$34ab2640$9e0172c0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBEF5224@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEF5224@sc9-ex2k10mb1.corp.yaanatech.com> Date: Thu, 31 Oct 2013 18:11:51 -0400 Message-ID: <024001ced686$34437180$9cca5480$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8PAdOJjcEBFampjAIH39XjAZ4KSLwDad9ZjgE+6VwIl2MB81A= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: cnit@ietf.org, dispatch@ietf.org Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 22:20:29 -0000 Excellent question! No need to send or dip for data if the UA can't display it. But then the last hop proxy presumably knows something = about its endpoints. I just don't know.=20 What can IMS do here does anyone know? =20 I would suspect that our friends at Google/Android and Apple etal are = also in favor of anything that could "Enhance the User Experience"=20 Not to mention Cable. You know you have that big 60 inch phone in your living room ... :-) =20 -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Thursday, October 31, 2013 5:45 PM To: richard@shockey.us; Henning.Schulzrinne@fcc.gov; br@brianrosen.net Cc: cnit@ietf.org; dispatch@ietf.org Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications What you sign and send may depend on what the receiver is capable of displaying. What triggered the thought was a restriction to 15 characters, when = todays phones can display a whole lot more. I am just saying don't let obsolete technology hobble future technology. Was wondering what might be possible with VoLTE, for example. Mike -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Thursday, October 31, 2013 5:36 PM To: Michael Hammer; Henning.Schulzrinne@fcc.gov; br@brianrosen.net Cc: cnit@ietf.org; dispatch@ietf.org Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Could you explain what you mean here? I'm modestly confused. Options indicator for what .. what the other side is capable of? =20 Now you really are in a favorite subject of mine. Before the INVITE = "dip" for capability as well as terminating carrier SBC etc. Welcome to the = new world of numbering databases.=20 -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, October 31, 2013 2:11 PM To: Henning.Schulzrinne@fcc.gov; br@brianrosen.net; richard@shockey.us Cc: cnit@ietf.org; dispatch@ietf.org Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications It might also be nice to have an options indication, so we can tell the other side that we are not just a limited rotary dial phone. Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Henning Schulzrinne Sent: Thursday, October 31, 2013 1:37 PM To: 'Brian Rosen'; Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Call-info: ;purpose=3Dcard or purpose=3Dinfo would seem to address part of that need. Obviously, there has to be a cryptographic binding to the calling number, but this could be = relatively simple if the vCard/xCard is signed with the same key as the TN. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Brian Rosen Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications I think the issue is whether we think what is usually called "contact" information is reasonable to send on every call. I do think if we were to do anything like that, we would do it with = xCard and Call-Info, so mechanism is something I agree with you on. If we did use display name for caller name, we get the SIP version of = that, which fixes the 15 US-ASCII character problem of the name. If we were to go farther, I'd probably want a request, rather than = automatic sending. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > communications system as it moves to an all IP world. Irrespective if = > CNAM it is delivered as part of From: or PAI its not very useful to=20 > the consumer. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the = usual. >=20 > It is not a hard stretch to postulate that called parties might like a = > richer set of data displayed on their UA's and that can be delivered=20 > by the SIP headers in some relatively simple form. Modification of the = > Call-Info header for instance. It is equally not a stretch to think=20 > that National Regulators would be delighted with consumers having a=20 > richer set of information displayed on their handsets in order to make = > more decisions. In addition if we can achieve better all IP to IP=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for=20 > enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > On that list, the current direction seems to be using the display name = > part of the uri to carry a caller name, which is put on the call by=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of = >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> associated > with the >> business entity for whom the call is being made. That could be an = 800 >> number for instance but I won't bore you with the issues with SMS800=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such identities. >> The network can then "validate" such an assertion. >>=20 >> There is something larger here to consider. Though the focus of STIR = >> is validation of a Caller-ID number at some point the RAI area should = >> take > a >> look at the other side of the coin so to speak. =20 >>=20 >> CNAM. That is NOT something STIR can do but I do believe there is an = >> emerging requirement that under some cases the calling party wants to = >> or should provide more substantive information about themselves to=20 >> the called party and frankly 15 character ASCII is not enough. >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> and informed decision on whether to accept the 'call' or not. >> Regulators may want to require telemarketing firms to display NG CNAM = >> or CNAM + like data as a condition of doing business. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> probably 3GPP would need to look at how such data is displayed on the = >> mobile VoLTE handsets. The network operators would have to understand = >> not to modify the contents of such a URI and its source validated but = >> that is a task for another day. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> Getting caught up on some of the STIR discussions, I'd just note that = >> when we talk about "call centers" or "BPOs" we also need to remember=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> could be picked up, etc. >> - calling people scheduled for a flight to let know they are going to = >> be delayed >> - calling members of an organization with an automated survey about=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> appear as if it is coming from their own phone number in the same way = >> that they want an outbound call center to appear as if it is coming=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> authorized entity, each with it's own credentials. Who would have a = >>> problem? We're already agreeing that there are multiple credentials = >>> for a number, because the number gets delegated multiple times. >>> Consider, just as an example, the BPO and the contracting enterprise = >>> that was actually delegated the number can both send calls from that = >>> number. You certainly don't want the enterprise giving out IT'S key = >>> to it's contractors. At best it's a key it authorizes to one or=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> Point taken on PAI, but am still struggling with this BPO model. >>>>>> Apologies >>>>>> upfront if this is obvious and I'm just failing to understand. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> Via headers would be the obvious pick, but they don't survive the = >>>>>> plethora of SBCs that the call is likely to transverse. Or maybe = >>>>>> the certs themselves can carry this type of data (actual caller=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> Don't think that would work without related changes in the = networks. >>>>>>> In >>>>>>> some networks, PAI is used for called id. They would have to=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Could a signed PAI be a potential solution to the BPO use case? >>>>>>>> "From" >>>>>>>> identifies the BPO, "PAI" the c ompany hiring the BPO - based=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal = >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field = >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> If the telemarketer happens to own the inbound call center as = >>>>>>>>>> well, it very likely owns the number as well and this would = >>>>>>>>>> necessarily be a special case >>>>>>>>>> - it would fall under the same characteristics of any call center. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> However can you clarify the following - >>>>>>>>>>> - If a SP "signs" the call, is it attesting to the = "responsible" >>>>>>>>>>> party for the telemarketing call or the party executing the=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> SP A has a credential for the entire 1K block SP A resells = >>>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> numbers were from their own inventory (that is, the company = >>>>>>>>>>> got its numbers from the same SP as the call >>>>>>>>> center). >>>>>>>>>>> Since that won't be the common case, the call center=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> different numbers based on the clients they represent. >>>>>>>>>>>> Wouldn't that create a billing issue though? >>>>>>>>>>>> This is not an area I understand well, but I would suspect=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through = >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the=20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch