From Internet-Drafts@ietf.org Tue Mar 1 22:15:04 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F41B23A6A49; Tue, 1 Mar 2011 22:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aCIi6n+LUIQ; Tue, 1 Mar 2011 22:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5553A67D2; Tue, 1 Mar 2011 22:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110302061502.27555.13389.idtracker@localhost> Date: Tue, 01 Mar 2011 22:15:02 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 06:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control Author(s) : A. Niemi, et al. Filename : draft-ietf-sipcore-event-rate-control-06.txt Pages : 25 Date : 2011-03-01 This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-event-rate-control-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-01220130.I-D@ietf.org> --NextPart-- From pkyzivat@cisco.com Wed Mar 2 07:41:00 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B813A67E1 for ; Wed, 2 Mar 2011 07:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.554 X-Spam-Level: X-Spam-Status: No, score=-110.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2Lk0wDlz4MT for ; Wed, 2 Mar 2011 07:40:55 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6846A3A6811 for ; Wed, 2 Mar 2011 07:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1083; q=dns/txt; s=iport; t=1299080521; x=1300290121; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=eqCAqqQx03xp3Cy4E6Nhi5WEZoGWGBcYU33u+atQy3w=; b=JrmpbHoqQOirxaHENzJqmG2uM2+kK9MOgYjBT0ttx1yn66yXo9VpjxKt 9ShBhaKL8e3YnqByHvF9T55yjRD6CKJ6V0Sfh7MmkA+tnbLMLbRRd2tB/ 6bzgxnucZ1PhvDib527u1mOwutOvCRg+lPe+HmBH3fsWnaIYomn+NfyOJ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJ7zbU1AZnwM/2dsb2JhbACEKKIwdKFyiwqQZIEng0R2BIUXhw+DQA X-IronPort-AV: E=Sophos;i="4.62,253,1297036800"; d="scan'208";a="221874904" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 02 Mar 2011 15:42:01 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p22Fg1rx014816 for ; Wed, 2 Mar 2011 15:42:01 GMT Message-ID: <4D6E6549.8010302@cisco.com> Date: Wed, 02 Mar 2011 10:42:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: SIPCORE References: <20110302061502.27555.21575.idtracker@localhost> In-Reply-To: <20110302061502.27555.21575.idtracker@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] PLEASE NOTE: draft-ietf-sipcore-event-rate-control-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 15:41:00 -0000 sipcore participants: Please note the new version of this draft. It has been edited based on iesg comments. The major change was to address confusing mixed use of "rate" and "interval", to a consistent use of "rate". As a consequence, there are operational differences, not just descriptive differences: the names of parameters have changed. Anyone who might be concerned about the impact of this change should speak up now. Thanks, Paul BTW, it seems there there were a few places overlooked in this fix, so there will presumably be yet another version that fixes those. But that change should be strictly editorial. On 3/2/2011 1:15 AM, Internet-Draft@ietf.org wrote: > New version (-06) has been submitted for draft-ietf-sipcore-event-rate-control-06.txt. > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-06.txt > Sub state has been changed to AD Follow up from New Id Needed > > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipcore-event-rate-control-06 > > IETF Secretariat. > From marianne.mohali@orange-ftgroup.com Thu Mar 3 08:50:14 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2993A67F1 for ; Thu, 3 Mar 2011 08:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLDVtckWrgUv for ; Thu, 3 Mar 2011 08:50:13 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 86FED3A6980 for ; Thu, 3 Mar 2011 08:50:10 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D2B608B800B; Thu, 3 Mar 2011 17:51:44 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id C55808B8001; Thu, 3 Mar 2011 17:51:44 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 17:51:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Mar 2011 17:51:15 +0100 Message-ID: In-Reply-To: <4D6C2CB6.4040800@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvXnY/hJfnSlcO5SHKXq20A5PnHwwBIYSkQ References: <4D6C2CB6.4040800@cisco.com> From: To: , X-OriginalArrivalTime: 03 Mar 2011 16:51:17.0935 (UTC) FILETIME=[37459BF0:01CBD9C3] Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 16:50:14 -0000 Hi Paul, The purpose is to allow applications/services to be explicitely = identified in the signaling path, so that others = services/applications/telephony-AS can act accordingly. Either to apply = a process taking into account the service interaction or on the = contrary, do not execute a feature already covered by the application. = For instance, a caller with a prepaid service calls a directory = enquiries Server to ask for a restaurant phone number. The operator = would suggest to connect the caller to the researched phone number = EXCEPT if the caller has a prepaid service because it is not sure he has = enough credit to pay for the communication. To allow this customized = feature, the directory enquiries Application needs to know that the = prepaid Application has been invocated.=20 About your comment in case of several applications involved = *simultaneously* in the call establishment, it is possible to add 1 more = hi-entry for the second application Cause you want to be identified in = the signaling path.=20 Regards, Marianne =20 > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de Paul Kyzivat > Envoy=E9 : mardi 1 mars 2011 00:16 > =C0 : sipcore@ietf.org > Objet : Re: [sipcore] I-DAction:=20 > draft-mohali-sipcore-reason-extension-application-01 >=20 > (As individual) >=20 > Marianne, >=20 > I'm still struggling to make sense of this in the form proposed. >=20 > I look at the various cause values, and all the descriptions=20 > are of the form. E.g.: >=20 > Cause value: 2 > Reason text: Freephone > Description: A Freephone application has influenced=20 > processing of > the call (e.g. by translating a dialed Free Phone number to a > routable directory number). >=20 > I can't figure out how to make any actionable decision based on this. > Rather, it seems I need to make a number of leaps of faith=20 > before I can decide what to do. >=20 > For instance, if I get an error, it *might* be because I=20 > dialed a freephone number, and it isn't supported from my=20 > calling location. (E.g.=20 > maybe I'm dialing +1-800-555-1234, but I'm doing so from=20 > France, and calling that number is only supported in the USA. >=20 > But getting a application reason code with cause 2 doesn't=20 > really tell me that is what happened. It could be that the=20 > call indeed was routed through a freephone application, and=20 > it properly routed the call, and the call failed for some=20 > other reason. But the cause is there because the application=20 > *did* influence the call routing. >=20 > Also, these "applications" are not, AFAIK, mutually=20 > exclusive. E.g. I could be using a prepaid service to make a=20 > directory assistance call that costs extra $$$ that I don't=20 > have credits to cover. But you can't include two cause values=20 > for the same protocol. (But it is true that you > *can* have a number of servers each put one cause into=20 > *their* H-I entry.) >=20 > So *maybe* I would see that my call failed, and that there is=20 > both a reason indicating a prepaid application on one H-I=20 > entry, and another indicating a another H-I indicating a=20 > directory service application. But what can I conclude from that? >=20 > Bottom line, I just can't make sense how this could be used=20 > in a well defined and interoperable way. >=20 > Thanks, > Paul >=20 > On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: > > Hello, > > > > Here is the new version of the draft. > > Main changes are following: > > - More details about the registration procedure for new values > > - Clearer text in section 3.2 > > - Add of Public and Private status for registered values. > > - Add of a range for cause values registration > > > > Best Regards, > > Marianne Mohali > > > > -----Message d'origine----- > > Objet : New Version Notification for > > draft-mohali-sipcore-reason-extension-application-01 > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > > > Title : Extending the Session Initiation Protocol > > (SIP) Reason Header for Applications > > Author(s) : M. Mohali, B. Chatras > > Filename : > > draft-mohali-sipcore-reason-extension-application-01.txt > > Pages : 10 > > Date : 2011-02-24 > > > > This document defines a new protocol value "Application" for the=20 > > Reason Header field and a new IANA Registry for registering=20 > > application types. This new value enables signaling that a=20 > request or=20 > > response has been issued as a result of a decision made by a=20 > > particular type of application or that an initial request has been=20 > > retargeted as a result of an application decision. > > > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-extens > > io > > n-application-01.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > > > >=20 > > io > > n-application-01.txt> > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Thu Mar 3 09:29:30 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441943A6860 for ; Thu, 3 Mar 2011 09:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.408 X-Spam-Level: X-Spam-Status: No, score=-109.408 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWRMGDjYdv2U for ; Thu, 3 Mar 2011 09:29:27 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6E8723A6859 for ; Thu, 3 Mar 2011 09:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6828; q=dns/txt; s=iport; t=1299173435; x=1300383035; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jrVv9M70LX6ykX4Q4aEPSE9TGnewxVBcwmSAlaqW/zs=; b=SFm4qBP3Mng8ebkHkhPQJqD40lq+O4JwNxVFIRiBnvTIe3tNr2Vq2kAT e/I+Hxf0CTCEbJuRwe3eCf54/M3Jt7Ym2JdbNPugKNCWKvJ46CzV1RZ4+ zzqO/cp44TjMup806Ss7Qt8uHjEULwq96GazArTfUL42qTKMax+09aen3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKpeb01AZnwM/2dsb2JhbACmZXSiUpwfgxEHgkkEhRqHEoNC X-IronPort-AV: E=Sophos;i="4.62,259,1297036800"; d="scan'208";a="222299388" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 03 Mar 2011 17:30:35 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p23HUYMR013225; Thu, 3 Mar 2011 17:30:34 GMT Message-ID: <4D6FD03A.8040507@cisco.com> Date: Thu, 03 Mar 2011 12:30:34 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: marianne.mohali@orange-ftgroup.com References: <4D6C2CB6.4040800@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org, "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:29:30 -0000 Marianne, On 3/3/2011 11:51 AM, marianne.mohali@orange-ftgroup.com wrote: > Hi Paul, > > The purpose is to allow applications/services to be explicitely identified in the signaling path, so that others services/applications/telephony-AS can act accordingly. Either to apply a process taking into account the service interaction or on the contrary, do not execute a feature already covered by the application. > For instance, a caller with a prepaid service calls a directory enquiries Server to ask for a restaurant phone number. The operator would suggest to connect the caller to the researched phone number EXCEPT if the caller has a prepaid service because it is not sure he has enough credit to pay for the communication. To allow this customized feature, the directory enquiries Application needs to know that the prepaid Application has been invocated. So once again, we are back to your wanting to use Reason not to express a "reason" for anything, but rather as just a hook to hang something on H-I. (With the causes you have defined, I can't imagine it making *any* sense to actually use one in a Reason header in a message, because they aren't specific enough to be actionable.) I am now thinking there is a large overlap between what you are trying to accomplish this way, and what Christer is trying to accomplish with draft-holmberg-sipcore-proxy-feature. Is that true? (Christer: What do you think?) > About your comment in case of several applications involved *simultaneously* in the call establishment, it is possible to add 1 more hi-entry for the second application Cause you want to be identified in the signaling path. Sure, you can indicate that they are "involved". But you can't infer anything about which one "caused" something. They might have, but you can't tell it from the presence of these headers. Thanks, Paul > Regards, > Marianne > > >> -----Message d'origine----- >> De : sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] De la part de Paul Kyzivat >> Envoyé : mardi 1 mars 2011 00:16 >> À : sipcore@ietf.org >> Objet : Re: [sipcore] I-DAction: >> draft-mohali-sipcore-reason-extension-application-01 >> >> (As individual) >> >> Marianne, >> >> I'm still struggling to make sense of this in the form proposed. >> >> I look at the various cause values, and all the descriptions >> are of the form. E.g.: >> >> Cause value: 2 >> Reason text: Freephone >> Description: A Freephone application has influenced >> processing of >> the call (e.g. by translating a dialed Free Phone number to a >> routable directory number). >> >> I can't figure out how to make any actionable decision based on this. >> Rather, it seems I need to make a number of leaps of faith >> before I can decide what to do. >> >> For instance, if I get an error, it *might* be because I >> dialed a freephone number, and it isn't supported from my >> calling location. (E.g. >> maybe I'm dialing +1-800-555-1234, but I'm doing so from >> France, and calling that number is only supported in the USA. >> >> But getting a application reason code with cause 2 doesn't >> really tell me that is what happened. It could be that the >> call indeed was routed through a freephone application, and >> it properly routed the call, and the call failed for some >> other reason. But the cause is there because the application >> *did* influence the call routing. >> >> Also, these "applications" are not, AFAIK, mutually >> exclusive. E.g. I could be using a prepaid service to make a >> directory assistance call that costs extra $$$ that I don't >> have credits to cover. But you can't include two cause values >> for the same protocol. (But it is true that you >> *can* have a number of servers each put one cause into >> *their* H-I entry.) >> >> So *maybe* I would see that my call failed, and that there is >> both a reason indicating a prepaid application on one H-I >> entry, and another indicating a another H-I indicating a >> directory service application. But what can I conclude from that? >> >> Bottom line, I just can't make sense how this could be used >> in a well defined and interoperable way. >> >> Thanks, >> Paul >> >> On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: >>> Hello, >>> >>> Here is the new version of the draft. >>> Main changes are following: >>> - More details about the registration procedure for new values >>> - Clearer text in section 3.2 >>> - Add of Public and Private status for registered values. >>> - Add of a range for cause values registration >>> >>> Best Regards, >>> Marianne Mohali >>> >>> -----Message d'origine----- >>> Objet : New Version Notification for >>> draft-mohali-sipcore-reason-extension-application-01 >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Extending the Session Initiation Protocol >>> (SIP) Reason Header for Applications >>> Author(s) : M. Mohali, B. Chatras >>> Filename : >>> draft-mohali-sipcore-reason-extension-application-01.txt >>> Pages : 10 >>> Date : 2011-02-24 >>> >>> This document defines a new protocol value "Application" for the >>> Reason Header field and a new IANA Registry for registering >>> application types. This new value enables signaling that a >> request or >>> response has been issued as a result of a decision made by a >>> particular type of application or that an initial request has been >>> retargeted as a result of an application decision. >>> >>> A URL for this Internet-Draft is: >>> >> http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-extens >>> io >>> n-application-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >> >> io >>> n-application-01.txt> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From john.elwell@siemens-enterprise.com Thu Mar 3 09:32:54 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A222C3A6860 for ; Thu, 3 Mar 2011 09:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.618 X-Spam-Level: X-Spam-Status: No, score=-102.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70ErT7O2yctJ for ; Thu, 3 Mar 2011 09:32:53 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E83BC3A6810 for ; Thu, 3 Mar 2011 09:32:52 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3614726; Thu, 3 Mar 2011 18:33:40 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 5A1621EB82AB; Thu, 3 Mar 2011 18:33:40 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 3 Mar 2011 18:33:40 +0100 From: "Elwell, John" To: "marianne.mohali@orange-ftgroup.com" , "pkyzivat@cisco.com" , "sipcore@ietf.org" Date: Thu, 3 Mar 2011 18:33:38 +0100 Thread-Topic: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvXnY/hJfnSlcO5SHKXq20A5PnHwwBIYSkQAEINgLA= Message-ID: References: <4D6C2CB6.4040800@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:32:54 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > marianne.mohali@orange-ftgroup.com > Sent: 03 March 2011 16:51 > To: pkyzivat@cisco.com; sipcore@ietf.org > Subject: Re: [sipcore] I-DAction:=20 > draft-mohali-sipcore-reason-extension-application-01 >=20 > Hi Paul, >=20 > The purpose is to allow applications/services to be=20 > explicitely identified in the signaling path, so that others=20 > services/applications/telephony-AS can act accordingly.=20 > Either to apply a process taking into account the service=20 > interaction or on the contrary, do not execute a feature=20 > already covered by the application. =20 > For instance, a caller with a prepaid service calls a=20 > directory enquiries Server to ask for a restaurant phone=20 > number. The operator would suggest to connect the caller to=20 > the researched phone number EXCEPT if the caller has a=20 > prepaid service because it is not sure he has enough credit=20 > to pay for the communication. To allow this customized=20 > feature, the directory enquiries Application needs to know=20 > that the prepaid Application has been invocated.=20 [JRE] This introduces completely new considerations for the security proper= ties of History-Info. Hi-entries are expected to be informational - the app= lication can make use of them on trust. For many purposes (e.g., displaying= to Bob the fact that the call was originally targeted at Alice and forward= ed) the security properties are sufficient. For making accounting decisions= I rather doubt they are sufficient. For a start, the SIP entity doing the = prepaid service might not support History-Info and/or the proposed Reason h= eader field extension, and therefore a downstream entity will not know that= a prepaid service has been used. Or an intermediate entity could remove th= e hi-entry or the Reason header field, for privacy or malicious reasons. In= fact it sounds like the proposal is in violation of RFC5897, unless used w= ithin closed environments. If the authors wish to use History-Info in this sort of way, I would sugges= t they review RFC5897 and the RFC4244bis security considerations very caref= ully. John >=20 > About your comment in case of several applications involved=20 > *simultaneously* in the call establishment, it is possible to=20 > add 1 more hi-entry for the second application Cause you want=20 > to be identified in the signaling path.=20 >=20 > Regards, > Marianne > =20 >=20 > > -----Message d'origine----- > > De : sipcore-bounces@ietf.org=20 > > [mailto:sipcore-bounces@ietf.org] De la part de Paul Kyzivat > > Envoy=E9 : mardi 1 mars 2011 00:16 > > =C0 : sipcore@ietf.org > > Objet : Re: [sipcore] I-DAction:=20 > > draft-mohali-sipcore-reason-extension-application-01 > >=20 > > (As individual) > >=20 > > Marianne, > >=20 > > I'm still struggling to make sense of this in the form proposed. > >=20 > > I look at the various cause values, and all the descriptions=20 > > are of the form. E.g.: > >=20 > > Cause value: 2 > > Reason text: Freephone > > Description: A Freephone application has influenced=20 > > processing of > > the call (e.g. by translating a dialed Free Phone number to a > > routable directory number). > >=20 > > I can't figure out how to make any actionable decision=20 > based on this. > > Rather, it seems I need to make a number of leaps of faith=20 > > before I can decide what to do. > >=20 > > For instance, if I get an error, it *might* be because I=20 > > dialed a freephone number, and it isn't supported from my=20 > > calling location. (E.g.=20 > > maybe I'm dialing +1-800-555-1234, but I'm doing so from=20 > > France, and calling that number is only supported in the USA. > >=20 > > But getting a application reason code with cause 2 doesn't=20 > > really tell me that is what happened. It could be that the=20 > > call indeed was routed through a freephone application, and=20 > > it properly routed the call, and the call failed for some=20 > > other reason. But the cause is there because the application=20 > > *did* influence the call routing. > >=20 > > Also, these "applications" are not, AFAIK, mutually=20 > > exclusive. E.g. I could be using a prepaid service to make a=20 > > directory assistance call that costs extra $$$ that I don't=20 > > have credits to cover. But you can't include two cause values=20 > > for the same protocol. (But it is true that you > > *can* have a number of servers each put one cause into=20 > > *their* H-I entry.) > >=20 > > So *maybe* I would see that my call failed, and that there is=20 > > both a reason indicating a prepaid application on one H-I=20 > > entry, and another indicating a another H-I indicating a=20 > > directory service application. But what can I conclude from that? > >=20 > > Bottom line, I just can't make sense how this could be used=20 > > in a well defined and interoperable way. > >=20 > > Thanks, > > Paul > >=20 > > On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: > > > Hello, > > > > > > Here is the new version of the draft. > > > Main changes are following: > > > - More details about the registration procedure for new values > > > - Clearer text in section 3.2 > > > - Add of Public and Private status for registered values. > > > - Add of a range for cause values registration > > > > > > Best Regards, > > > Marianne Mohali > > > > > > -----Message d'origine----- > > > Objet : New Version Notification for > > > draft-mohali-sipcore-reason-extension-application-01 > > > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > > directories. > > > > > > Title : Extending the Session Initiation Protocol > > > (SIP) Reason Header for Applications > > > Author(s) : M. Mohali, B. Chatras > > > Filename : > > > draft-mohali-sipcore-reason-extension-application-01.txt > > > Pages : 10 > > > Date : 2011-02-24 > > > > > > This document defines a new protocol value "Application" for the=20 > > > Reason Header field and a new IANA Registry for registering=20 > > > application types. This new value enables signaling that a=20 > > request or=20 > > > response has been issued as a result of a decision made by a=20 > > > particular type of application or that an initial request=20 > has been=20 > > > retargeted as a result of an application decision. > > > > > > A URL for this Internet-Draft is: > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-extens > > > io > > > n-application-01.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader=20 > > > implementation to automatically retrieve the ASCII version of the=20 > > > Internet-Draft. > > > > > >=20 > >=20 > > > io > > > n-application-01.txt> > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From wwwrun@rfc-editor.org Thu Mar 3 10:04:01 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D6128C0F9; Thu, 3 Mar 2011 10:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.105 X-Spam-Level: X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1QZRGAwYQWn; Thu, 3 Mar 2011 10:04:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 2639528C0E2; Thu, 3 Mar 2011 10:03:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 60ACDE0747; Thu, 3 Mar 2011 10:05:06 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110303180506.60ACDE0747@rfc-editor.org> Date: Thu, 3 Mar 2011 10:05:06 -0800 (PST) Cc: sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 6141 on Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 18:04:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6141 Title: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) Author: G. Camarillo, Ed., C. Holmberg, Y. Gao Status: Standards Track Stream: IETF Date: March 2011 Mailbox: Gonzalo.Camarillo@ericsson.com, Christer.Holmberg@ericsson.com, gao.yang2@zte.com.cn Pages: 26 Characters: 57517 Updates: RFC3261 I-D Tag: draft-ietf-sipcore-reinvite-08.txt URL: http://www.rfc-editor.org/rfc/rfc6141.txt The procedures for handling SIP re-INVITEs are described in RFC 3261. Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues. In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, this document defines further details of procedures related to target-refresh requests. [STANDARDS-TRACK] This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Internet-Drafts@ietf.org Thu Mar 3 12:30:08 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586F13A6843; Thu, 3 Mar 2011 12:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjTTpMU0TAHZ; Thu, 3 Mar 2011 12:30:07 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4B63A6800; Thu, 3 Mar 2011 12:30:07 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110303203002.10223.51027.idtracker@localhost> Date: Thu, 03 Mar 2011 12:30:02 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-199-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 20:30:08 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sipcore-199-06.txt Pages : 17 Date : 2011-03-03 This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate towards upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-199-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-199-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-03121727.I-D@ietf.org> --NextPart-- From mary.ietf.barnes@gmail.com Thu Mar 3 12:44:59 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124AF3A6973 for ; Thu, 3 Mar 2011 12:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.44 X-Spam-Level: X-Spam-Status: No, score=-103.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WJebPvl+uDh for ; Thu, 3 Mar 2011 12:44:56 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 99CC73A688F for ; Thu, 3 Mar 2011 12:44:56 -0800 (PST) Received: by vws6 with SMTP id 6so1552381vws.31 for ; Thu, 03 Mar 2011 12:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Gabf9fXU3U+CsV2WkTLdZAbiBoV3eK11Sp45/plMyjE=; b=W4QkTfizO9KHAcACQjxQMz9gFQtjCXoSXKWFTCvge6bnArfVILiBVm2RI+LmQO5p2c i5mbQbVkHP4t23IbtzKQYTjGveRrrH97D1OHo9+3hzPN3h1hkqwbZCxiRwxXax1VXLP6 CH0swfCrT4waVRjFauapdCvpUExW2/x2lN24Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UknZlS3a0LMVoEsMEbfiFdDp/RPgk9ExKwTMV8uGBShm31eONoZPv2FkL+qqfo9eiH dekgsk0vhJnfyo1oibuhpi85WM06tRJe5oD9NA10Qh3FcqihArZKnSjU7gsJZseSS3d7 4kJNTqFE3n7la75oU0N4WbyY/hPO5UDxM6PWo= MIME-Version: 1.0 Received: by 10.52.68.65 with SMTP id u1mr2500863vdt.176.1299185162959; Thu, 03 Mar 2011 12:46:02 -0800 (PST) Received: by 10.52.162.202 with HTTP; Thu, 3 Mar 2011 12:46:02 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Mar 2011 14:46:02 -0600 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=20cf307cff8e22be1e049d9a1ebd Cc: "Barnes, Mary" , SIPCORE Subject: Re: [sipcore] Proposed rewrite of parts of rfc4424bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 20:44:59 -0000 --20cf307cff8e22be1e049d9a1ebd Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I've seen no responses to John's suggestion. If folks could please read and provide feedback as to whether they support this change, we should be able to get final updates done for 4244bis and get it ready for another WGLC. Thanks, Mary. On Wed, Feb 23, 2011 at 2:30 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Based on responses from Mary to my recent questions, I am convinced that > procedures could be documented in a much simpler way. Basically I think we > can have common procedures for the different entities (UAC, UAS, Proxy, > Redirect) - how you behave on receipt of a request, forwarding a request, > receipt of a response or forwarding a response is pretty much independent of > the type of entity. In recent emails I developed a model of what I believe > we want to happen. I have tried to capture this model in text in a new > section X, which should occur between sections 8 and 9. Sections 6, 7 and 8 > essentially just reference section X. I would like WG opinion as to whether > this is easier to understand, as well as opinions as to whether it > accurately reflects the intent of the current I-D. > > > 6. User Agent Handling of the History-Info Header Field > A B2BUA MAY adopt the behavior of a proxy (section 7) as an alternative to > adopting the behaviour of a UAS (section 6.2) and the behaviour of a UAC > (section 6.1). In behaving as a proxy, a B2BUA will carry forward hi-entries > received in requests at the UAS to requests forwarded by the UAC and will > carry forward hi-entries received in responses at the UAC to responses > forwarded by the UAS, subject to privacy considerations. > > 6.1 User Agent Client (UAC) Behavior > When issuing a request, a UAC MUST behave in accordance with X.2 for > sending a request. Note that the cache of previous requests will be empty > and the index of the hi-entry added to the sent request will be 1, except > where the UAC issues a retargeted request as a result of a received > response. When receiving a response, a UAC MUST behave in accordance with > X.3. In addition, if a UAC would like to receive the History-Info header > field in responses, it MUST include in the sent request a Supported header > field containing option tag histinfo. > > 6.2 User Agent Server (UAS) Behaviour. > When receiving a request, a UAS MUST behave in accordance with X.1. When > sending a response other than a 3xx response, a UAS MUST behave in > accordance with X.4. When sending a 3xx response, the UAS MUST behave as a > redirect server in accordance with section 8. An application at the UAS can > make use of the cached hi-entries, taking into account the considerations of > section 10. > > 7. Proxy /Intermediary Handling of the History-Info Header Field > The following behaviour is applicable to a proxy or a B2BUA that behaves as > a proxy (see section 6). > A proxy / intermediary MUST behave: > - in accordance with X.1 when receiving a request; > - in accordance with X.2 when sending (forwarding) a request; > - in accordance with X.3 when receiving a response; > - in accordance with X.4 when sending a response. > Sometimes the internal design of a proxy or B2BUA will result in a request > being retargeted twice before the request is forwarded, i.e., it is "sent" > to an internal target, which is resolved by that same entity internally by > retargeting to an external target. A proxy or B2BUA in this case MAY behave > as if the request had actually been sent to the internal target before > sending to the external target, thereby generating an hi-entry for that > internal target, in addition to the hi-entry for the external target. Both > hi-entries would then be seen "on the wire" in the resulting request sent > downstream and any response sent upstream, subject to privacy > considerations. > > 8. Redirect Server Handling of the History-Info Header Field > When receiving a request, a Redirect Server MUST behave in accordance with > X.1. When sending a response, a Redirect Server MUST behave in accordance > with X.4 and MUST add an "rc" or "mp" header field parameter to the Contact > header field if either of these parameters is applicable according to 9.4. > > X. Common Handling of the History-Info Header Field > X.1 Receiving a Request > When receiving a request, an entity MUST create a cache of hi-entries > associated with that request and include in that cache any hi-entries in the > received request. > > If the Request-URI of the received request does not match the URI in the > last hi-entry in the cache, the entity MUST add to the end of the cache an > hi-entry containing that URI as the hi-targeted-to-uri. For the added > hi-entry, the entity MUST behave in accordance with 9.1 if privacy is > required, MUST populate the hi-index in accordance with 9.3, and MUST NOT > include an "rc" or "mp" header field parameter. > > X.2 Sending a Request > When sending a request, and entity MUST include all cached hi-entries in > the request. In addition, the entity MUST include in the request an > additional hi-entry containing the Request-URI as the hi-targeted-to-uri but > MUST NOT cache this hi-entry. For the new hi-entry, the entity MUST behave > in accordance with 9.1 if privacy is required, MUST populate the hi-index in > accordance with 9.3, and, if applicable, MUST include in the new hi-entry an > "rc" or "mp" parameter in accordance with 9.4. If the sent request is a > direct result of retargeting to a contact URI received in a 3xx response and > the Contact header field in that response contained an "rc" or "mp" header > field parameter, the entity MUST include the corresponding parameter in the > new hi-entry in accordance with 9.4. > > X.3 Receiving a response > When receiving a response other than 100, an entity MUST add to the cache > the new hi-entry that was added to the sent request that led to that > response (if not already in the cache) and include in that cached hi-entry > (whether or not it was already cached) a Reason header field in accordance > with 9.2 denoting the SIP response code in the response. The entity MUST > also add to the cache any hi-entries in the response that are not already in > the cache (i.e., any hi-entries added by downstream entities). When adding > hi-entries to the cache, the entity MUST maintain hi-entries in ascending > order of index (e.g., 1.2.1 comes after 1.2 but before 1.3). Note that the > cache will not contain hi-entries for requests that have not attracted a > non-100 response, so there can be gaps in the indices (e.g., 1.2 and 1.4 > could be present but 1.3 absent). > > X.4 Procedures for sending a response > When sending a response other than 100, an entity MUST include in the > response all cached hi-entries, with the exception that when the received > request contained no hi-entries and no histinfo option tag in the Supported > header field, the entity MUST NOT include any hi-entries in the response. > > > I think I have covered most of what was in sections 6, 7 and 8, but I have > left out some explanatory material giving reasons (the simplified > procedures, in my opinion, don't require so much explanation, or if really > needed it can be done in section 5). > > The original word count of 1719 is reduced to 956, a significant reduction > arising mainly from avoidance of any duplication and also the loss of some > explanation. However, in my opinion behaviour is specified in a more logical > way, and in a way that makes it a lot more likely that people will implement > this. The question is whether the WG feels this is a worthwhile change at > this late stage. > > I have not checked section 9 in detail to see whether any slight changes > are required to align with this new text. > > John > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --20cf307cff8e22be1e049d9a1ebd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

I've seen no responses to John's sugge= stion. If folks could please read and provide feedback as to whether they s= upport this change, we should be able to get final updates done for 4244bis= and get it ready for another WGLC. =A0

Thanks,
Mary.=A0

On Wed, Feb 23, 2011 at 2:30 PM, Elwell, John <<= a href=3D"mailto:john.elwell@siemens-enterprise.com">john.elwell@siemens-en= terprise.com> wrote:
Based on responses from Mary to my recent q= uestions, I am convinced that procedures could be documented in a much simp= ler way. Basically I think we can have common procedures for the different = entities (UAC, UAS, Proxy, Redirect) - how you behave on receipt of a reque= st, forwarding a request, receipt of a response or forwarding a response is= pretty much independent of the type of entity. In recent emails I develope= d a model of what I believe we want to happen. I have tried to capture this= model in text in a new section X, which should occur between sections 8 an= d 9. Sections 6, 7 and 8 essentially just reference section X. I would like= WG opinion as to whether this is easier to understand, as well as opinions= as to whether it accurately reflects the intent of the current I-D.

<text>
6. User Agent Handling of the History-Info Header Field
A B2BUA MAY adopt the behavior of a proxy (section 7) as an alternative to = adopting the behaviour of a UAS (section 6.2) and the behaviour of a UAC (s= ection 6.1). In behaving as a proxy, a B2BUA will carry forward hi-entries = received in requests at the UAS to requests forwarded by the UAC and will c= arry forward hi-entries received in responses at the UAC to responses forwa= rded by the UAS, subject to privacy considerations.

6.1 User Agent Client (UAC) Behavior
When issuing a request, a UAC MUST behave in accordance with X.2 for sendin= g a request. Note that the cache of previous requests will be empty and the= index of the hi-entry added to the sent request will be 1, except where th= e UAC issues a retargeted request as a result of a received response. When = receiving a response, a UAC MUST behave in accordance with X.3. In addition= , if a UAC would like to receive the History-Info header field in responses= , it MUST include in the sent request a Supported header field containing o= ption tag histinfo.

6.2 User Agent Server (UAS) Behaviour.
When receiving a request, a UAS MUST behave in accordance with X.1. When se= nding a response other than a 3xx response, a UAS MUST behave in accordance= with X.4. When sending a 3xx response, the UAS MUST behave as a redirect s= erver in accordance with section 8. An application at the UAS can make use = of the cached hi-entries, taking into account the considerations of section= 10.

7. Proxy /Intermediary Handling of the History-Info Header Field
The following behaviour is applicable to a proxy or a B2BUA that behaves as= a proxy (see section 6).
A proxy / intermediary MUST behave:
- in accordance with X.1 when receiving a request;
- in accordance with X.2 when sending (forwarding) a request;
- in accordance with X.3 when receiving a response;
- in accordance with X.4 when sending a response.
Sometimes the internal design of a proxy or B2BUA will result in a request = being retargeted twice before the request is forwarded, i.e., it is "s= ent" to an internal target, which is resolved by that same entity inte= rnally by retargeting to an external target. A proxy or B2BUA in this case = MAY behave as if the request had actually been sent to the internal target = before sending to the external target, thereby generating an hi-entry for t= hat internal target, in addition to the hi-entry for the external target. B= oth hi-entries would then be seen "on the wire" in the resulting = request sent downstream and any response sent upstream, subject to privacy = considerations.

8. Redirect Server Handling of the History-Info Header Field
When receiving a request, a Redirect Server MUST behave in accordance with = X.1. When sending a response, a Redirect Server MUST behave in accordance w= ith X.4 and MUST add an "rc" or "mp" header field param= eter to the Contact header field if either of these parameters is applicabl= e according to 9.4.

X. Common Handling of the History-Info Header Field
X.1 Receiving a Request
When receiving a request, an entity MUST create a cache of hi-entries assoc= iated with that request and include in that cache any hi-entries in the rec= eived request.

If the Request-URI of the received request does not match the URI in the la= st hi-entry in the cache, the entity MUST add to the end of the cache an hi= -entry containing that URI as the hi-targeted-to-uri. For the added hi-entr= y, the entity MUST behave in accordance with 9.1 if privacy is required, MU= ST populate the hi-index in accordance with 9.3, and MUST NOT include an &q= uot;rc" or "mp" header field parameter.

X.2 Sending a Request
When sending a request, and entity MUST include all cached hi-entries in th= e request. In addition, the entity MUST include in the request an additiona= l hi-entry containing the Request-URI as the hi-targeted-to-uri but MUST NO= T cache this hi-entry. For the new hi-entry, the entity MUST behave in acco= rdance with 9.1 if privacy is required, MUST populate the hi-index in accor= dance with 9.3, and, if applicable, MUST include in the new hi-entry an &qu= ot;rc" or "mp" parameter in accordance with 9.4. If the sent= request is a direct result of retargeting to a contact URI received in a 3= xx response and the Contact header field in that response contained an &quo= t;rc" or "mp" header field parameter, the entity MUST includ= e the corresponding parameter in the new hi-entry in accordance with 9.4.
X.3 Receiving a response
When receiving a response other than 100, an entity MUST add to the cache t= he new hi-entry that was added to the sent request that led to that respons= e (if not already in the cache) and include in that cached hi-entry (whethe= r or not it was already cached) a Reason header field in accordance with 9.= 2 denoting the SIP response code in the response. The entity MUST also add = to the cache any hi-entries in the response that are not already in the cac= he (i.e., any hi-entries added by downstream entities). When adding hi-entr= ies to the cache, the entity MUST maintain hi-entries in ascending order of= index (e.g., 1.2.1 comes after 1.2 but before 1.3). Note that the cache wi= ll not contain hi-entries for requests that have not attracted a non-100 re= sponse, so there can be gaps in the indices (e.g., 1.2 and 1.4 could be pre= sent but 1.3 absent).

X.4 Procedures for sending a response
When sending a response other than 100, an entity MUST include in the respo= nse all cached hi-entries, with the exception that when the received reques= t contained no hi-entries and no histinfo option tag in the Supported heade= r field, the entity MUST NOT include any hi-entries in the response.
</text>

I think I have covered most of what was in sections 6, 7 and 8, but I have = left out some explanatory material giving reasons (the simplified procedure= s, in my opinion, don't require so much explanation, or if really neede= d it can be done in section 5).

The original word count of 1719 is reduced to 956, a significant reduction = arising mainly from avoidance of any duplication and also the loss of some = explanation. However, in my opinion behaviour is specified in a more logica= l way, and in a way that makes it a lot more likely that people will implem= ent this. The question is whether the WG feels this is a worthwhile change = at this late stage.

I have not checked section 9 in detail to see whether any slight changes ar= e required to align with this new text.

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

--20cf307cff8e22be1e049d9a1ebd-- From marianne.mohali@orange-ftgroup.com Fri Mar 4 08:58:49 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C31B3A683B for ; Fri, 4 Mar 2011 08:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GkULqO2pWhM for ; Fri, 4 Mar 2011 08:58:47 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 61D743A687E for ; Fri, 4 Mar 2011 08:58:46 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4EDAFFC4013; Fri, 4 Mar 2011 18:00:00 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 41B4FFC4001; Fri, 4 Mar 2011 18:00:00 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 17:59:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 17:59:50 +0100 Message-ID: In-Reply-To: <4D6FD03A.8040507@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvZyMeCfl6FKhNYSCqZg5YhzzfZxgAwppvQ References: <4D6C2CB6.4040800@cisco.com> <4D6FD03A.8040507@cisco.com> From: To: X-OriginalArrivalTime: 04 Mar 2011 16:59:54.0129 (UTC) FILETIME=[955C5010:01CBDA8D] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:58:49 -0000 Hi Paul, My answer below [MM]=20 Marianne > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Envoy=E9 : jeudi 3 mars 2011 18:31 > =C0 : MOHALI Marianne RD-CORE-ISS > Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com > Objet : Re: [sipcore] I-DAction:=20 > draft-mohali-sipcore-reason-extension-application-01 >=20 > Marianne, >=20 > On 3/3/2011 11:51 AM, marianne.mohali@orange-ftgroup.com wrote: > > Hi Paul, > > > > The purpose is to allow applications/services to be=20 > explicitely identified in the signaling path, so that others=20 > services/applications/telephony-AS can act accordingly.=20 > Either to apply a process taking into account the service=20 > interaction or on the contrary, do not execute a feature=20 > already covered by the application. > > For instance, a caller with a prepaid service calls a=20 > directory enquiries Server to ask for a restaurant phone=20 > number. The operator would suggest to connect the caller to=20 > the researched phone number EXCEPT if the caller has a=20 > prepaid service because it is not sure he has enough credit=20 > to pay for the communication. To allow this customized=20 > feature, the directory enquiries Application needs to know=20 > that the prepaid Application has been invocated. >=20 > So once again, we are back to your wanting to use Reason not=20 > to express a "reason" for anything, but rather as just a hook=20 > to hang something on H-I. [MM] The *reason* why the call has been retargeted/rejected/modified is = the invocation of a specific application. If you call a Service number = and then the URI is changed for routing to the real destination, the = *reason* of the URI modification (listed in H-I) is the application. >=20 > (With the causes you have defined, I can't imagine it making=20 > *any* sense to actually use one in a Reason header in a=20 > message, because they aren't specific enough to be actionable.) >=20 > I am now thinking there is a large overlap between what you=20 > are trying to accomplish this way, and what Christer is=20 > trying to accomplish with draft-holmberg-sipcore-proxy-feature. >=20 > Is that true? >=20 > (Christer: What do you think?) [MM] I don't see the overlap with Christer's draft because it is not = about capabilities, it is about what's happened. >=20 > > About your comment in case of several applications involved=20 > *simultaneously* in the call establishment, it is possible to=20 > add 1 more hi-entry for the second application Cause you want=20 > to be identified in the signaling path. >=20 > Sure, you can indicate that they are "involved". But you=20 > can't infer anything about which one "caused" something. They=20 > might have, but you can't tell it from the presence of these headers. >=20 > Thanks, > Paul >=20 > > Regards, > > Marianne > > > > > >> -----Message d'origine----- > >> De : sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] De la part de Paul=20 > Kyzivat Envoy=E9 :=20 > >> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org Objet : Re: = [sipcore]=20 > >> I-DAction: > >> draft-mohali-sipcore-reason-extension-application-01 > >> > >> (As individual) > >> > >> Marianne, > >> > >> I'm still struggling to make sense of this in the form proposed. > >> > >> I look at the various cause values, and all the=20 > descriptions are of=20 > >> the form. E.g.: > >> > >> Cause value: 2 > >> Reason text: Freephone > >> Description: A Freephone application has influenced=20 > >> processing of > >> the call (e.g. by translating a dialed Free Phone=20 > number to a > >> routable directory number). > >> > >> I can't figure out how to make any actionable decision=20 > based on this. > >> Rather, it seems I need to make a number of leaps of faith=20 > before I=20 > >> can decide what to do. > >> > >> For instance, if I get an error, it *might* be because I dialed a=20 > >> freephone number, and it isn't supported from my calling location.=20 > >> (E.g. > >> maybe I'm dialing +1-800-555-1234, but I'm doing so from=20 > France, and=20 > >> calling that number is only supported in the USA. > >> > >> But getting a application reason code with cause 2 doesn't really=20 > >> tell me that is what happened. It could be that the call=20 > indeed was=20 > >> routed through a freephone application, and it properly routed the=20 > >> call, and the call failed for some other reason. But the cause is=20 > >> there because the application > >> *did* influence the call routing. > >> > >> Also, these "applications" are not, AFAIK, mutually=20 > exclusive. E.g. I=20 > >> could be using a prepaid service to make a directory=20 > assistance call=20 > >> that costs extra $$$ that I don't have credits to cover. But you=20 > >> can't include two cause values for the same protocol. (But=20 > it is true=20 > >> that you > >> *can* have a number of servers each put one cause into > >> *their* H-I entry.) > >> > >> So *maybe* I would see that my call failed, and that there=20 > is both a=20 > >> reason indicating a prepaid application on one H-I entry,=20 > and another=20 > >> indicating a another H-I indicating a directory service=20 > application.=20 > >> But what can I conclude from that? > >> > >> Bottom line, I just can't make sense how this could be=20 > used in a well=20 > >> defined and interoperable way. > >> > >> Thanks, > >> Paul > >> > >> On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: > >>> Hello, > >>> > >>> Here is the new version of the draft. > >>> Main changes are following: > >>> - More details about the registration procedure for new values > >>> - Clearer text in section 3.2 > >>> - Add of Public and Private status for registered values. > >>> - Add of a range for cause values registration > >>> > >>> Best Regards, > >>> Marianne Mohali > >>> > >>> -----Message d'origine----- > >>> Objet : New Version Notification for > >>> draft-mohali-sipcore-reason-extension-application-01 > >>> > >>> A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > >>> directories. > >>> > >>> Title : Extending the Session Initiation Protocol > >>> (SIP) Reason Header for Applications > >>> Author(s) : M. Mohali, B. Chatras > >>> Filename : > >>> draft-mohali-sipcore-reason-extension-application-01.txt > >>> Pages : 10 > >>> Date : 2011-02-24 > >>> > >>> This document defines a new protocol value "Application" for the=20 > >>> Reason Header field and a new IANA Registry for registering=20 > >>> application types. This new value enables signaling that a > >> request or > >>> response has been issued as a result of a decision made by a=20 > >>> particular type of application or that an initial request=20 > has been=20 > >>> retargeted as a result of an application decision. > >>> > >>> A URL for this Internet-Draft is: > >>> > >>=20 > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten > >> s > >>> io > >>> n-application-01.txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> Below is the data which will enable a MIME compliant mail reader=20 > >>> implementation to automatically retrieve the ASCII version of the=20 > >>> Internet-Draft. > >>> > >>> > >>=20 > >> s > >>> io > >>> n-application-01.txt> > >>> > >>> _______________________________________________ > >>> I-D-Announce mailing list > >>> I-D-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > >=20 From marianne.mohali@orange-ftgroup.com Fri Mar 4 09:32:28 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5988C3A68AB for ; Fri, 4 Mar 2011 09:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GL-xVCfNxnEf for ; Fri, 4 Mar 2011 09:32:26 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 4BF843A67F1 for ; Fri, 4 Mar 2011 09:32:26 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B7AFA8B800B; Fri, 4 Mar 2011 18:34:01 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id AD6758B8001; Fri, 4 Mar 2011 18:34:01 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 18:33:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 18:33:33 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvXnY/hJfnSlcO5SHKXq20A5PnHwwBIYSkQAEINgLAAMQcpIA== References: <4D6C2CB6.4040800@cisco.com> From: To: , , X-OriginalArrivalTime: 04 Mar 2011 17:33:34.0383 (UTC) FILETIME=[49869BF0:01CBDA92] Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 17:32:28 -0000 Hi John,=20 My answer inline [MM]=20 Regards, Marianne > -----Message d'origine----- > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Envoy=E9 : jeudi 3 mars 2011 18:34 > =C0 : MOHALI Marianne RD-CORE-ISS; pkyzivat@cisco.com; = sipcore@ietf.org > Objet : RE: [sipcore]=20 > I-DAction:draft-mohali-sipcore-reason-extension-application-01 >=20 > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > > marianne.mohali@orange-ftgroup.com > > Sent: 03 March 2011 16:51 > > To: pkyzivat@cisco.com; sipcore@ietf.org > > Subject: Re: [sipcore] I-DAction:=20 > > draft-mohali-sipcore-reason-extension-application-01 > >=20 > > Hi Paul, > >=20 > > The purpose is to allow applications/services to be explicitely=20 > > identified in the signaling path, so that others=20 > > services/applications/telephony-AS can act accordingly. > > Either to apply a process taking into account the service=20 > interaction=20 > > or on the contrary, do not execute a feature > > already covered by the application. =20 > > For instance, a caller with a prepaid service calls a directory=20 > > enquiries Server to ask for a restaurant phone number. The operator=20 > > would suggest to connect the caller to the researched phone number=20 > > EXCEPT if the caller has a prepaid service because it is=20 > not sure he=20 > > has enough credit to pay for the communication. To allow this=20 > > customized feature, the directory enquiries Application=20 > needs to know=20 > > that the prepaid Application has been invocated. > [JRE] This introduces completely new considerations for the=20 > security properties of History-Info. Hi-entries are expected=20 > to be informational - the application can make use of them on=20 > trust. For many purposes (e.g., displaying to Bob the fact=20 > that the call was originally targeted at Alice and forwarded)=20 > the security properties are sufficient. For making accounting=20 > decisions I rather doubt they are sufficient. For a start,=20 > the SIP entity doing the prepaid service might not support=20 > History-Info and/or the proposed Reason header field=20 > extension, and therefore a downstream entity will not know=20 > that a prepaid service has been used. Or an intermediate=20 > entity could remove the hi-entry or the Reason header field,=20 > for privacy or malicious reasons. In fact it sounds like the=20 > proposal is in violation of RFC5897, unless used within=20 > closed environments. >=20 > If the authors wish to use History-Info in this sort of way,=20 > I would suggest they review RFC5897 and the RFC4244bis=20 > security considerations very carefully. >=20 [MM] I agree that hi-entries are informational. The draft state that if = you want to mark up an application in the signalling path, you can do it = using the Reason header with a specific cause value. Obviously, it is up = to the service interaction managment to ensure what are the trusted = applications, networks, or operators with an interaction policy or to do = it only in closed environments. That's why Public and Private values are = proposed. For 3GPP 24.604 CDIV service, the downstream entities rely on = History-Info header to find the original called number for ISUP = interworking. Even if hi-entries are informational.=20 In your example, if the prepaid service is not identified, the 2nd = application will act as usual or consider the caller untrusted and not = propose the connection.=20 > John >=20 > >=20 > > About your comment in case of several applications involved > > *simultaneously* in the call establishment, it is possible to add 1=20 > > more hi-entry for the second application Cause you want to be=20 > > identified in the signaling path. > >=20 > > Regards, > > Marianne > > =20 > >=20 > > > -----Message d'origine----- > > > De : sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] De la part de Paul=20 > Kyzivat Envoy=E9=20 > > > : mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org Objet :=20 > Re: [sipcore]=20 > > > I-DAction: > > > draft-mohali-sipcore-reason-extension-application-01 > > >=20 > > > (As individual) > > >=20 > > > Marianne, > > >=20 > > > I'm still struggling to make sense of this in the form proposed. > > >=20 > > > I look at the various cause values, and all the=20 > descriptions are of=20 > > > the form. E.g.: > > >=20 > > > Cause value: 2 > > > Reason text: Freephone > > > Description: A Freephone application has influenced=20 > > > processing of > > > the call (e.g. by translating a dialed Free Phone=20 > number to a > > > routable directory number). > > >=20 > > > I can't figure out how to make any actionable decision > > based on this. > > > Rather, it seems I need to make a number of leaps of=20 > faith before I=20 > > > can decide what to do. > > >=20 > > > For instance, if I get an error, it *might* be because I dialed a=20 > > > freephone number, and it isn't supported from my calling=20 > location.=20 > > > (E.g. > > > maybe I'm dialing +1-800-555-1234, but I'm doing so from=20 > France, and=20 > > > calling that number is only supported in the USA. > > >=20 > > > But getting a application reason code with cause 2 doesn't really=20 > > > tell me that is what happened. It could be that the call=20 > indeed was=20 > > > routed through a freephone application, and it properly=20 > routed the=20 > > > call, and the call failed for some other reason. But the cause is=20 > > > there because the application > > > *did* influence the call routing. > > >=20 > > > Also, these "applications" are not, AFAIK, mutually=20 > exclusive. E.g.=20 > > > I could be using a prepaid service to make a directory assistance=20 > > > call that costs extra $$$ that I don't have credits to cover. But=20 > > > you can't include two cause values for the same protocol.=20 > (But it is=20 > > > true that you > > > *can* have a number of servers each put one cause into > > > *their* H-I entry.) > > >=20 > > > So *maybe* I would see that my call failed, and that=20 > there is both a=20 > > > reason indicating a prepaid application on one H-I entry, and=20 > > > another indicating a another H-I indicating a directory service=20 > > > application. But what can I conclude from that? > > >=20 > > > Bottom line, I just can't make sense how this could be used in a=20 > > > well defined and interoperable way. > > >=20 > > > Thanks, > > > Paul > > >=20 > > > On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: > > > > Hello, > > > > > > > > Here is the new version of the draft. > > > > Main changes are following: > > > > - More details about the registration procedure for new values > > > > - Clearer text in section 3.2 > > > > - Add of Public and Private status for registered values. > > > > - Add of a range for cause values registration > > > > > > > > Best Regards, > > > > Marianne Mohali > > > > > > > > -----Message d'origine----- > > > > Objet : New Version Notification for > > > > draft-mohali-sipcore-reason-extension-application-01 > > > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > directories. > > > > > > > > Title : Extending the Session=20 > Initiation Protocol > > > > (SIP) Reason Header for Applications > > > > Author(s) : M. Mohali, B. Chatras > > > > Filename : > > > > draft-mohali-sipcore-reason-extension-application-01.txt > > > > Pages : 10 > > > > Date : 2011-02-24 > > > > > > > > This document defines a new protocol value=20 > "Application" for the=20 > > > > Reason Header field and a new IANA Registry for registering=20 > > > > application types. This new value enables signaling that a > > > request or > > > > response has been issued as a result of a decision made by a=20 > > > > particular type of application or that an initial request > > has been > > > > retargeted as a result of an application decision. > > > > > > > > A URL for this Internet-Draft is: > > > >=20 > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-extens > > > > io > > > > n-application-01.txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > Below is the data which will enable a MIME compliant=20 > mail reader=20 > > > > implementation to automatically retrieve the ASCII=20 > version of the=20 > > > > Internet-Draft. > > > > > > > >=20 > > >=20 > >=20 > > > > io > > > > n-application-01.txt> > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 From pkyzivat@cisco.com Sun Mar 6 16:41:09 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E96A3A68AE for ; Sun, 6 Mar 2011 16:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzbjFIul6Y2i for ; Sun, 6 Mar 2011 16:41:07 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 102503A68AF for ; Sun, 6 Mar 2011 16:41:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=9198; q=dns/txt; s=iport; t=1299458540; x=1300668140; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WUMaHRTGVvP6MILTtjKhWw6WdUnDTFlAPYM5R4oDTyA=; b=CVusYPZVDN5k0yjTt5+6GvPK0jm0Kr1CY+cHVVBBHnfwqcjIB+0lTjff sLuWQx5OL2e1ErH6dCdqwnQuHlrkS2op5RjkYtXQBS9Dh2QovXjALis+H G+L+nHG/NvMPH0fqOBpWciIhhan2VGohdjEroNrQPnJybQefE0Kn/u7Lv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPO3c01AZnwN/2dsb2JhbACmT3SkAJp5gxEHgkoEhRyHFIND X-IronPort-AV: E=Sophos;i="4.62,273,1297036800"; d="scan'208";a="222734027" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Mar 2011 00:42:18 +0000 Received: from [10.86.241.53] (che-vpn-cluster-1-308.cisco.com [10.86.241.53]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p270gHOt019305; Mon, 7 Mar 2011 00:42:18 GMT Message-ID: <4D7429E9.5070607@cisco.com> Date: Sun, 06 Mar 2011 19:42:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: marianne.mohali@orange-ftgroup.com References: <4D6C2CB6.4040800@cisco.com> <4D6FD03A.8040507@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 00:41:09 -0000 Marianne On 3/4/2011 11:59 AM, marianne.mohali@orange-ftgroup.com wrote: > Hi Paul, > > My answer below [MM] > > Marianne >> -----Message d'origine----- >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Envoyé : jeudi 3 mars 2011 18:31 >> À : MOHALI Marianne RD-CORE-ISS >> Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com >> Objet : Re: [sipcore] I-DAction: >> draft-mohali-sipcore-reason-extension-application-01 >> >> Marianne, >> >> On 3/3/2011 11:51 AM, marianne.mohali@orange-ftgroup.com wrote: >>> Hi Paul, >>> >>> The purpose is to allow applications/services to be >> explicitely identified in the signaling path, so that others >> services/applications/telephony-AS can act accordingly. >> Either to apply a process taking into account the service >> interaction or on the contrary, do not execute a feature >> already covered by the application. >>> For instance, a caller with a prepaid service calls a >> directory enquiries Server to ask for a restaurant phone >> number. The operator would suggest to connect the caller to >> the researched phone number EXCEPT if the caller has a >> prepaid service because it is not sure he has enough credit >> to pay for the communication. To allow this customized >> feature, the directory enquiries Application needs to know >> that the prepaid Application has been invocated. >> >> So once again, we are back to your wanting to use Reason not >> to express a "reason" for anything, but rather as just a hook >> to hang something on H-I. > [MM] The *reason* why the call has been retargeted/rejected/modified is the invocation of a specific application. > If you call a Service number and then the URI is changed for routing to the real destination, the *reason* of the URI modification (listed in H-I) is the application. Based on your other replies, this is not necessarily so. In fact the example above is a counter-example. The prepaid service is not responsible for any redirection, and the operator service is looking for it for a reason other than that it has been the cause of anything. Its looking for it because it might be the cause of something in the future. >> (With the causes you have defined, I can't imagine it making >> *any* sense to actually use one in a Reason header in a >> message, because they aren't specific enough to be actionable.) >> >> I am now thinking there is a large overlap between what you >> are trying to accomplish this way, and what Christer is >> trying to accomplish with draft-holmberg-sipcore-proxy-feature. >> >> Is that true? >> >> (Christer: What do you think?) > [MM] I don't see the overlap with Christer's draft because it is not about capabilities, it is about what's happened. In your example above, it seems that the operator service is looking for the prepaid service because the prepaid service has the capability to influence billing, or something like that. This seems at least somewhat in line with what Christer is advocating. Looking in the Route header, or Record-Route header would make at least as much sense for this case as looking in H-I. H-I makes sense if you are indeed looking for something that has already happened, perhaps on a path other that the current one. I think it would be helpful for the two of you to come to some reconciliation of what you are trying to accomplish. Thanks, Paul >>> About your comment in case of several applications involved >> *simultaneously* in the call establishment, it is possible to >> add 1 more hi-entry for the second application Cause you want >> to be identified in the signaling path. >> >> Sure, you can indicate that they are "involved". But you >> can't infer anything about which one "caused" something. They >> might have, but you can't tell it from the presence of these headers. >> >> Thanks, >> Paul >> >>> Regards, >>> Marianne >>> >>> >>>> -----Message d'origine----- >>>> De : sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul >> Kyzivat Envoyé : >>>> mardi 1 mars 2011 00:16 À : sipcore@ietf.org Objet : Re: [sipcore] >>>> I-DAction: >>>> draft-mohali-sipcore-reason-extension-application-01 >>>> >>>> (As individual) >>>> >>>> Marianne, >>>> >>>> I'm still struggling to make sense of this in the form proposed. >>>> >>>> I look at the various cause values, and all the >> descriptions are of >>>> the form. E.g.: >>>> >>>> Cause value: 2 >>>> Reason text: Freephone >>>> Description: A Freephone application has influenced >>>> processing of >>>> the call (e.g. by translating a dialed Free Phone >> number to a >>>> routable directory number). >>>> >>>> I can't figure out how to make any actionable decision >> based on this. >>>> Rather, it seems I need to make a number of leaps of faith >> before I >>>> can decide what to do. >>>> >>>> For instance, if I get an error, it *might* be because I dialed a >>>> freephone number, and it isn't supported from my calling location. >>>> (E.g. >>>> maybe I'm dialing +1-800-555-1234, but I'm doing so from >> France, and >>>> calling that number is only supported in the USA. >>>> >>>> But getting a application reason code with cause 2 doesn't really >>>> tell me that is what happened. It could be that the call >> indeed was >>>> routed through a freephone application, and it properly routed the >>>> call, and the call failed for some other reason. But the cause is >>>> there because the application >>>> *did* influence the call routing. >>>> >>>> Also, these "applications" are not, AFAIK, mutually >> exclusive. E.g. I >>>> could be using a prepaid service to make a directory >> assistance call >>>> that costs extra $$$ that I don't have credits to cover. But you >>>> can't include two cause values for the same protocol. (But >> it is true >>>> that you >>>> *can* have a number of servers each put one cause into >>>> *their* H-I entry.) >>>> >>>> So *maybe* I would see that my call failed, and that there >> is both a >>>> reason indicating a prepaid application on one H-I entry, >> and another >>>> indicating a another H-I indicating a directory service >> application. >>>> But what can I conclude from that? >>>> >>>> Bottom line, I just can't make sense how this could be >> used in a well >>>> defined and interoperable way. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: >>>>> Hello, >>>>> >>>>> Here is the new version of the draft. >>>>> Main changes are following: >>>>> - More details about the registration procedure for new values >>>>> - Clearer text in section 3.2 >>>>> - Add of Public and Private status for registered values. >>>>> - Add of a range for cause values registration >>>>> >>>>> Best Regards, >>>>> Marianne Mohali >>>>> >>>>> -----Message d'origine----- >>>>> Objet : New Version Notification for >>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>> >>>>> A New Internet-Draft is available from the on-line >> Internet-Drafts >>>>> directories. >>>>> >>>>> Title : Extending the Session Initiation Protocol >>>>> (SIP) Reason Header for Applications >>>>> Author(s) : M. Mohali, B. Chatras >>>>> Filename : >>>>> draft-mohali-sipcore-reason-extension-application-01.txt >>>>> Pages : 10 >>>>> Date : 2011-02-24 >>>>> >>>>> This document defines a new protocol value "Application" for the >>>>> Reason Header field and a new IANA Registry for registering >>>>> application types. This new value enables signaling that a >>>> request or >>>>> response has been issued as a result of a decision made by a >>>>> particular type of application or that an initial request >> has been >>>>> retargeted as a result of an application decision. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> >>>> >> http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten >>>> s >>>>> io >>>>> n-application-01.txt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader >>>>> implementation to automatically retrieve the ASCII version of the >>>>> Internet-Draft. >>>>> >>>>> >>>> >> >>> s >>>>> io >>>>> n-application-01.txt> >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >> > From shida@ntt-at.com Mon Mar 7 00:19:16 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E043A6936 for ; Mon, 7 Mar 2011 00:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK9voq+yoGd8 for ; Mon, 7 Mar 2011 00:19:14 -0800 (PST) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.184.28]) by core3.amsl.com (Postfix) with SMTP id 1A26D3A6827 for ; Mon, 7 Mar 2011 00:19:14 -0800 (PST) Received: (qmail 17224 invoked from network); 7 Mar 2011 08:19:36 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway08.websitewelcome.com with SMTP; 7 Mar 2011 08:19:36 -0000 Received: from [125.193.35.111] (port=50080 helo=[192.168.11.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PwVg1-0003SV-Fa; Mon, 07 Mar 2011 02:20:26 -0600 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-8--943724671 From: Shida Schubert In-Reply-To: Date: Mon, 7 Mar 2011 17:20:22 +0900 Message-Id: References: To: Mary Barnes X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: SIPCORE , "Barnes, Mary" Subject: Re: [sipcore] Proposed rewrite of parts of rfc4424bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 08:19:16 -0000 --Apple-Mail-8--943724671 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks John.=20 I like the simplified text and support the suggested changes.=20 Although the repetitive reference to common section can be=20 confusing, the overall reduction in redundant text allows for=20 overall reduction of information necessary to understand the=20 spec, making the change a sensible move.=20 I will need to read it several times and compare it to original=20 contents to make sure that it covers everything but I like the=20 new structure never the less.=20 =20 Regards Shida On Mar 4, 2011, at 5:46 AM, Mary Barnes wrote: > Hi folks, >=20 > I've seen no responses to John's suggestion. If folks could please = read and provide feedback as to whether they support this change, we = should be able to get final updates done for 4244bis and get it ready = for another WGLC. =20 >=20 > Thanks, > Mary.=20 >=20 > On Wed, Feb 23, 2011 at 2:30 PM, Elwell, John = wrote: > Based on responses from Mary to my recent questions, I am convinced = that procedures could be documented in a much simpler way. Basically I = think we can have common procedures for the different entities (UAC, = UAS, Proxy, Redirect) - how you behave on receipt of a request, = forwarding a request, receipt of a response or forwarding a response is = pretty much independent of the type of entity. In recent emails I = developed a model of what I believe we want to happen. I have tried to = capture this model in text in a new section X, which should occur = between sections 8 and 9. Sections 6, 7 and 8 essentially just reference = section X. I would like WG opinion as to whether this is easier to = understand, as well as opinions as to whether it accurately reflects the = intent of the current I-D. >=20 > > 6. User Agent Handling of the History-Info Header Field > A B2BUA MAY adopt the behavior of a proxy (section 7) as an = alternative to adopting the behaviour of a UAS (section 6.2) and the = behaviour of a UAC (section 6.1). In behaving as a proxy, a B2BUA will = carry forward hi-entries received in requests at the UAS to requests = forwarded by the UAC and will carry forward hi-entries received in = responses at the UAC to responses forwarded by the UAS, subject to = privacy considerations. >=20 > 6.1 User Agent Client (UAC) Behavior > When issuing a request, a UAC MUST behave in accordance with X.2 for = sending a request. Note that the cache of previous requests will be = empty and the index of the hi-entry added to the sent request will be 1, = except where the UAC issues a retargeted request as a result of a = received response. When receiving a response, a UAC MUST behave in = accordance with X.3. In addition, if a UAC would like to receive the = History-Info header field in responses, it MUST include in the sent = request a Supported header field containing option tag histinfo. >=20 > 6.2 User Agent Server (UAS) Behaviour. > When receiving a request, a UAS MUST behave in accordance with X.1. = When sending a response other than a 3xx response, a UAS MUST behave in = accordance with X.4. When sending a 3xx response, the UAS MUST behave as = a redirect server in accordance with section 8. An application at the = UAS can make use of the cached hi-entries, taking into account the = considerations of section 10. >=20 > 7. Proxy /Intermediary Handling of the History-Info Header Field > The following behaviour is applicable to a proxy or a B2BUA that = behaves as a proxy (see section 6). > A proxy / intermediary MUST behave: > - in accordance with X.1 when receiving a request; > - in accordance with X.2 when sending (forwarding) a request; > - in accordance with X.3 when receiving a response; > - in accordance with X.4 when sending a response. > Sometimes the internal design of a proxy or B2BUA will result in a = request being retargeted twice before the request is forwarded, i.e., it = is "sent" to an internal target, which is resolved by that same entity = internally by retargeting to an external target. A proxy or B2BUA in = this case MAY behave as if the request had actually been sent to the = internal target before sending to the external target, thereby = generating an hi-entry for that internal target, in addition to the = hi-entry for the external target. Both hi-entries would then be seen "on = the wire" in the resulting request sent downstream and any response sent = upstream, subject to privacy considerations. >=20 > 8. Redirect Server Handling of the History-Info Header Field > When receiving a request, a Redirect Server MUST behave in accordance = with X.1. When sending a response, a Redirect Server MUST behave in = accordance with X.4 and MUST add an "rc" or "mp" header field parameter = to the Contact header field if either of these parameters is applicable = according to 9.4. >=20 > X. Common Handling of the History-Info Header Field > X.1 Receiving a Request > When receiving a request, an entity MUST create a cache of hi-entries = associated with that request and include in that cache any hi-entries in = the received request. >=20 > If the Request-URI of the received request does not match the URI in = the last hi-entry in the cache, the entity MUST add to the end of the = cache an hi-entry containing that URI as the hi-targeted-to-uri. For the = added hi-entry, the entity MUST behave in accordance with 9.1 if privacy = is required, MUST populate the hi-index in accordance with 9.3, and MUST = NOT include an "rc" or "mp" header field parameter. >=20 > X.2 Sending a Request > When sending a request, and entity MUST include all cached hi-entries = in the request. In addition, the entity MUST include in the request an = additional hi-entry containing the Request-URI as the hi-targeted-to-uri = but MUST NOT cache this hi-entry. For the new hi-entry, the entity MUST = behave in accordance with 9.1 if privacy is required, MUST populate the = hi-index in accordance with 9.3, and, if applicable, MUST include in the = new hi-entry an "rc" or "mp" parameter in accordance with 9.4. If the = sent request is a direct result of retargeting to a contact URI received = in a 3xx response and the Contact header field in that response = contained an "rc" or "mp" header field parameter, the entity MUST = include the corresponding parameter in the new hi-entry in accordance = with 9.4. >=20 > X.3 Receiving a response > When receiving a response other than 100, an entity MUST add to the = cache the new hi-entry that was added to the sent request that led to = that response (if not already in the cache) and include in that cached = hi-entry (whether or not it was already cached) a Reason header field in = accordance with 9.2 denoting the SIP response code in the response. The = entity MUST also add to the cache any hi-entries in the response that = are not already in the cache (i.e., any hi-entries added by downstream = entities). When adding hi-entries to the cache, the entity MUST maintain = hi-entries in ascending order of index (e.g., 1.2.1 comes after 1.2 but = before 1.3). Note that the cache will not contain hi-entries for = requests that have not attracted a non-100 response, so there can be = gaps in the indices (e.g., 1.2 and 1.4 could be present but 1.3 absent). >=20 > X.4 Procedures for sending a response > When sending a response other than 100, an entity MUST include in the = response all cached hi-entries, with the exception that when the = received request contained no hi-entries and no histinfo option tag in = the Supported header field, the entity MUST NOT include any hi-entries = in the response. > >=20 > I think I have covered most of what was in sections 6, 7 and 8, but I = have left out some explanatory material giving reasons (the simplified = procedures, in my opinion, don't require so much explanation, or if = really needed it can be done in section 5). >=20 > The original word count of 1719 is reduced to 956, a significant = reduction arising mainly from avoidance of any duplication and also the = loss of some explanation. However, in my opinion behaviour is specified = in a more logical way, and in a way that makes it a lot more likely that = people will implement this. The question is whether the WG feels this is = a worthwhile change at this late stage. >=20 > I have not checked section 9 in detail to see whether any slight = changes are required to align with this new text. >=20 > John > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-8--943724671 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi = folks,

I've seen no responses to John's suggestion. = If folks could please read and provide feedback as to whether they = support this change, we should be able to get final updates done for = 4244bis and get it ready for another WGLC.  

Thanks,
Mary. 

On Wed, Feb 23, 2011 at 2:30 PM, Elwell, John = <john.elwell@siemens-ent= erprise.com> wrote:
Based on responses = from Mary to my recent questions, I am convinced that procedures could = be documented in a much simpler way. Basically I think we can have = common procedures for the different entities (UAC, UAS, Proxy, Redirect) = - how you behave on receipt of a request, forwarding a request, receipt = of a response or forwarding a response is pretty much independent of the = type of entity. In recent emails I developed a model of what I believe = we want to happen. I have tried to capture this model in text in a new = section X, which should occur between sections 8 and 9. Sections 6, 7 = and 8 essentially just reference section X. I would like WG opinion as = to whether this is easier to understand, as well as opinions as to = whether it accurately reflects the intent of the current I-D.

<text>
6. User Agent Handling of the History-Info Header Field
A B2BUA MAY adopt the behavior of a proxy (section 7) as an alternative = to adopting the behaviour of a UAS (section 6.2) and the behaviour of a = UAC (section 6.1). In behaving as a proxy, a B2BUA will carry forward = hi-entries received in requests at the UAS to requests forwarded by the = UAC and will carry forward hi-entries received in responses at the UAC = to responses forwarded by the UAS, subject to privacy = considerations.

6.1 User Agent Client (UAC) Behavior
When issuing a request, a UAC MUST behave in accordance with X.2 for = sending a request. Note that the cache of previous requests will be = empty and the index of the hi-entry added to the sent request will be 1, = except where the UAC issues a retargeted request as a result of a = received response. When receiving a response, a UAC MUST behave in = accordance with X.3. In addition, if a UAC would like to receive the = History-Info header field in responses, it MUST include in the sent = request a Supported header field containing option tag histinfo.

6.2 User Agent Server (UAS) Behaviour.
When receiving a request, a UAS MUST behave in accordance with X.1. When = sending a response other than a 3xx response, a UAS MUST behave in = accordance with X.4. When sending a 3xx response, the UAS MUST behave as = a redirect server in accordance with section 8. An application at the = UAS can make use of the cached hi-entries, taking into account the = considerations of section 10.

7. Proxy /Intermediary Handling of the History-Info Header Field
The following behaviour is applicable to a proxy or a B2BUA that behaves = as a proxy (see section 6).
A proxy / intermediary MUST behave:
- in accordance with X.1 when receiving a request;
- in accordance with X.2 when sending (forwarding) a request;
- in accordance with X.3 when receiving a response;
- in accordance with X.4 when sending a response.
Sometimes the internal design of a proxy or B2BUA will result in a = request being retargeted twice before the request is forwarded, i.e., it = is "sent" to an internal target, which is resolved by that same entity = internally by retargeting to an external target. A proxy or B2BUA in = this case MAY behave as if the request had actually been sent to the = internal target before sending to the external target, thereby = generating an hi-entry for that internal target, in addition to the = hi-entry for the external target. Both hi-entries would then be seen "on = the wire" in the resulting request sent downstream and any response sent = upstream, subject to privacy considerations.

8. Redirect Server Handling of the History-Info Header Field
When receiving a request, a Redirect Server MUST behave in accordance = with X.1. When sending a response, a Redirect Server MUST behave in = accordance with X.4 and MUST add an "rc" or "mp" header field parameter = to the Contact header field if either of these parameters is applicable = according to 9.4.

X. Common Handling of the History-Info Header Field
X.1 Receiving a Request
When receiving a request, an entity MUST create a cache of hi-entries = associated with that request and include in that cache any hi-entries in = the received request.

If the Request-URI of the received request does not match the URI in the = last hi-entry in the cache, the entity MUST add to the end of the cache = an hi-entry containing that URI as the hi-targeted-to-uri. For the added = hi-entry, the entity MUST behave in accordance with 9.1 if privacy is = required, MUST populate the hi-index in accordance with 9.3, and MUST = NOT include an "rc" or "mp" header field parameter.

X.2 Sending a Request
When sending a request, and entity MUST include all cached hi-entries in = the request. In addition, the entity MUST include in the request an = additional hi-entry containing the Request-URI as the hi-targeted-to-uri = but MUST NOT cache this hi-entry. For the new hi-entry, the entity MUST = behave in accordance with 9.1 if privacy is required, MUST populate the = hi-index in accordance with 9.3, and, if applicable, MUST include in the = new hi-entry an "rc" or "mp" parameter in accordance with 9.4. If the = sent request is a direct result of retargeting to a contact URI received = in a 3xx response and the Contact header field in that response = contained an "rc" or "mp" header field parameter, the entity MUST = include the corresponding parameter in the new hi-entry in accordance = with 9.4.

X.3 Receiving a response
When receiving a response other than 100, an entity MUST add to the = cache the new hi-entry that was added to the sent request that led to = that response (if not already in the cache) and include in that cached = hi-entry (whether or not it was already cached) a Reason header field in = accordance with 9.2 denoting the SIP response code in the response. The = entity MUST also add to the cache any hi-entries in the response that = are not already in the cache (i.e., any hi-entries added by downstream = entities). When adding hi-entries to the cache, the entity MUST maintain = hi-entries in ascending order of index (e.g., 1.2.1 comes after 1.2 but = before 1.3). Note that the cache will not contain hi-entries for = requests that have not attracted a non-100 response, so there can be = gaps in the indices (e.g., 1.2 and 1.4 could be present but 1.3 = absent).

X.4 Procedures for sending a response
When sending a response other than 100, an entity MUST include in the = response all cached hi-entries, with the exception that when the = received request contained no hi-entries and no histinfo option tag in = the Supported header field, the entity MUST NOT include any hi-entries = in the response.
</text>

I think I have covered most of what was in sections 6, 7 and 8, but I = have left out some explanatory material giving reasons (the simplified = procedures, in my opinion, don't require so much explanation, or if = really needed it can be done in section 5).

The original word count of 1719 is reduced to 956, a significant = reduction arising mainly from avoidance of any duplication and also the = loss of some explanation. However, in my opinion behaviour is specified = in a more logical way, and in a way that makes it a lot more likely that = people will implement this. The question is whether the WG feels this is = a worthwhile change at this late stage.

I have not checked section 9 in detail to see whether any slight changes = are required to align with this new text.

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

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

= --Apple-Mail-8--943724671-- From john.elwell@siemens-enterprise.com Mon Mar 7 06:01:55 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3510D3A6955 for ; Mon, 7 Mar 2011 06:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rExlZNpBmdi3 for ; Mon, 7 Mar 2011 06:01:54 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 079843A6998 for ; Mon, 7 Mar 2011 06:01:53 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3652961 for sipcore@ietf.org; Mon, 7 Mar 2011 15:03:00 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id D126123F028E for ; Mon, 7 Mar 2011 15:03:00 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 7 Mar 2011 15:03:00 +0100 From: "Elwell, John" To: "sipcore@ietf.org" Date: Mon, 7 Mar 2011 15:02:59 +0100 Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance Thread-Index: AcvXoLtQJpEyszcyT0OGcZwSyIMowABJyFEwAQH5nXA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 14:01:55 -0000 The following was pointed out to me: Section 5.1: "Supported: geolocation" We should either delete this line or change it to contain one or both of th= e new option tags. Similarly in 5.2. John = From thomas.stach@siemens-enterprise.com Mon Mar 7 08:14:15 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9766E3A6906 for ; Mon, 7 Mar 2011 08:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51sk6eNXZD6a for ; Mon, 7 Mar 2011 08:14:14 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 31E3D3A6919 for ; Mon, 7 Mar 2011 08:14:13 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3655113 for sipcore@ietf.org; Mon, 7 Mar 2011 17:15:22 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 13F7323F028E for ; Mon, 7 Mar 2011 17:15:18 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 7 Mar 2011 17:15:18 +0100 From: "Stach, Thomas" To: "SIPCORE (Session Initiation Protocol Core) WG" Date: Mon, 7 Mar 2011 17:15:16 +0100 Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance Thread-Index: AcvXoLtQJpEyszcyT0OGcZwSyIMowAFQWe2A Message-ID: References: <4D6C31DC.80005@nostrum.com> In-Reply-To: <4D6C31DC.80005@nostrum.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 16:14:15 -0000 Hi James, Brian, Jon,=20 I did some review with focus on section 4. Please find below some comments: General/Editorial: The document uses the term "header" and "header field" interchangeably.=20 I propose to consistently use "header field". See e.g. captions of section 4.1, 4.2, 4.4, 8.1, 8.2. 8.5 and several occur= rences in the text. Section2,=20 1st para "... of a Target (Target) to a Location Recipient (LR)." (Target) does not seem to abbreviate something. 2nd para "In order to convey location information, this document specifies a new SIP= header, the Geolocation header, which ..."=20 Since the document defines 3 header fields, what about: "In order to convey location information, this document specifies three new SIP header fields, Geolocation, Geolocation-Routing and Geolocation-Err= or, which carry a reference to a Location Object, grant permission to route a SIP request based on the loa= tion-value and provide error=20 notifications specific to location errors. " Note, this text proposal still does not mention the new 424 Response code, = which could be mentioned too. ABNF issues in section 4 section 4.1 message-header /=3D Geolocation-header ; (message-header from 3261) Geolocation-header =3D ... Related to my comment above I propose to rename Geolocation-header to Geolo= cation. =20 This would also be more inline with the 3261 practice of header field defin= itions. locationURI =3D sip-URI / sips-URI / pres-URI / http-URI / HTTPS-URI What about changing HTTPS-URI to https-URI in order to make consistent use = of capitalization or is this too much nitpicking? " HTTP-URI and HTTPS-URI are defined according to [RFC2616] and [RFC2818], respectively." a. There is inconsistent capitalization of "HTTP-URI" when compared to the = ABNF (another nit). =20 b. While 2616 provides ABNF for http-URI, 2818 does not provide ABNF for ht= tps-URI. Would it makes sense to provide a corresponding ABNF production in this = doc? e.g. https_URI =3D "https:" "//" host [ ":" port ] [ abs_path [ "?" que= ry ]] "If a Geolocation header field is received that contains generic-params, each SHOULD be ignored, and SHOULD NOT be removed when forwarding ^^^^ the locationValue." Does "each" refer to the header field or parameter?=20 Though rather obvious that the parameter is meant changing=20 "... each SHOULD be ignored..." to=20 "... each parameter SHOULD be ignored..." would make that clearer. section 4.2 message-header /=3D Georouting-header ; (message-header from 3261) Georouting =3D "Geolocation-Routing" HCOLON ( "yes" / "no" / generic-value ) a) Propose to rename Georouting-header to Georouting (or Geolocation-Routin= g), as per above. b) I could not find a definition/production/reference for generic-value. Do you mean gen-value from 3261? I.e gen-value =3D token / host / quoted-st= ring? If yes, do you really need this flexibility or would e.g. quoted-string alo= ne be sufficient? The para after the ABNF definition end with: " ... Values other than "yes" or "no" are permitted as a mechanism for future extensions, and should be treated the same as "no". " =20 Please add "if not understood" after "no". Section 4.4 message-header /=3D Geolocation-Error-header ; (message-header from 3261) Geolocation-Error =3D "Geolocation-Error" HCOLON locationErrorValue locationErrorValue =3D location-error-code *(SEMI location-error-params) location-error-code =3D 1*3DIGIT location-error-params =3D location-error-code-text / generic-param ; from RFC3261 location-error-code-text =3D "code" EQUAL quoted-string ; from RFC3261 Geolocation-Error-header is not further expanded. You probably mean Geoloca= tion-Error. The examples do not conform to this ABNF, e.g.=20 Geolocation-Error: 100 "Cannot Process Location"=20 does not show the semicolon, the string "code" and the "=3D" According to the ABNF is would have to read=20 Geolocation-Error: 100 ; code=3D"Cannot Process Location"=20 ^^^^^^^^ - A further question on=20 locationErrorValue =3D location-error-code *(SEMI location-error-para= ms)=20 Does the locationErrorValue really need one or more parameters or would a s= imple reason phrase be sufficient?=20 The current example suggest the latter, whereas the ABNF suggests the forme= r.=20 If it is just a reason phrase one could simplify to: locationErrorValue =3D location-error-code [SP location-error-code-te= xt] location-error-code-text =3D quoted-string=20 However I don't have a strong preference here, other than that the examples= should match the ABNF. - The grammar of RFC 3261 specified explicit ABNF for the response codes.=20 Do you want to do the same for location-error-code, which currently only sp= ecifies 1*3DIGIT? The effort of doing so does not seem to be too big for the five already def= ined codes 100, 200, 300, 201, 202. - From these specified error codes and their explaining text on page 15/16 = it does not become clear=20 if the text phrase is a only default string or a fixed value.=20 Similar to RFC 3261 I assume the former is meant and not the latter.=20 However, if it was the latter this should be nailed down in the ABNF. Kind Regards Thomas > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Adam Roach -=20 > SIPCORE Chair > Gesendet: Dienstag, 01. M=E4rz 2011 00:38 > An: SIPCORE (Session Initiation Protocol Core) WG > Cc: draft-ietf-sipcore-location-conveyance@tools.ietf.org;=20 > Robert Sparks; SIPCORE Chairs > Betreff: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance >=20 > [as chair] >=20 > The current editor of draft-ietf-sipcore-location-conveyance believes=20 > that the document has no remaining technical issues[1], and=20 > is ready for=20 > evaluation. Today, we are starting a two-week working group last call=20 > period. This last call period ends on Tuesday, March 15th. >=20 > The latest version of the document can be retrieved here: >=20 > http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance >=20 > Any comments on the document should be sent to the SIPCORE=20 > mailing list. >=20 > /a >=20 > [1] John Elwell's editorial comments of February 25th have=20 > been noted by=20 > the authors, and will be treated as WGLC comments. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From dworley@avaya.com Mon Mar 7 10:17:16 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60EE3A6810 for ; Mon, 7 Mar 2011 10:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP2KXI6h3+tT for ; Mon, 7 Mar 2011 10:17:16 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 8EA7F3A680D for ; Mon, 7 Mar 2011 10:17:15 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGKwdE3GmAcF/2dsb2JhbACmTnSlBwKZMoMRglEEhRyKcQ X-IronPort-AV: E=Sophos;i="4.62,278,1297054800"; d="scan'208";a="62259555" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 07 Mar 2011 13:18:20 -0500 X-IronPort-AV: E=Sophos;i="4.62,278,1297054800"; d="scan'208";a="591818741" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Mar 2011 13:18:19 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.187]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 7 Mar 2011 13:18:19 -0500 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , "marianne.mohali@orange-ftgroup.com" Date: Mon, 7 Mar 2011 13:18:00 -0500 Thread-Topic: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvZyONLW9FOvLuUTUqkYcckL0it7wDKxr0y Message-ID: References: <4D6C2CB6.4040800@cisco.com> , <4D6FD03A.8040507@cisco.com> In-Reply-To: <4D6FD03A.8040507@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 18:17:16 -0000 On 3/3/2011 11:51 AM, marianne.mohali@orange-ftgroup.com wrote: > The purpose is to allow applications/services to be explicitely > identified in the signaling path, so that others > services/applications/telephony-AS can act accordingly. Either to > apply a process taking into account the service interaction or on > the contrary, do not execute a feature already covered by the > application. >=20 > For instance, a caller with a prepaid service calls a directory > enquiries Server to ask for a restaurant phone number. The operator > would suggest to connect the caller to the researched phone number > EXCEPT if the caller has a prepaid service because it is not sure he > has enough credit to pay for the communication. To allow this > customized feature, the directory enquiries Application needs to > know that the prepaid Application has been invocated. Could we see an example of how this is expected to be done? (Or have I overlooked the example?) There are various subtlties in a protocol feature whose *absence* in the signaling tells another application that a certain action may be taken. Dale From marianne.mohali@orange-ftgroup.com Mon Mar 7 10:29:05 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603BD3A680C for ; Mon, 7 Mar 2011 10:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrernyhIpdzl for ; Mon, 7 Mar 2011 10:29:04 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 9D3F23A6809 for ; Mon, 7 Mar 2011 10:29:02 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 83E8E6C8007; Mon, 7 Mar 2011 19:30:17 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 74AFF6C0004; Mon, 7 Mar 2011 19:30:17 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 19:29:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Mar 2011 19:29:40 +0100 Message-ID: In-Reply-To: <4D7429E9.5070607@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvcYISb0u1jdMeySTaPExDFDWj03gAgAOHg References: <4D6C2CB6.4040800@cisco.com> <4D6FD03A.8040507@cisco.com> <4D7429E9.5070607@cisco.com> From: To: X-OriginalArrivalTime: 07 Mar 2011 18:29:45.0415 (UTC) FILETIME=[A20E8570:01CBDCF5] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 18:29:05 -0000 Paul, I think that Christer's draft (proxy-feature) is about capabilities = while this one (reason-extension-application) is about what really = happened (like reason in general). It is provided only when the event = happens and the purpose is to give an accuate information for = applicative events.=20 Let me give you an other example: A reception AS called with several premium rate numbers (1 per hosted = application/service). The AS dispatches calls to several call centers = (eg. Depending on charge, hour of the day/night...). The final = destination needs to know the called service. The premuim rate number = should be listed in the H-I header. Which entry? For which = application/service invocated?=20 As you can have a call forwarding reason associated to a 3xx or 486 = Reason-cause, you could have an applicative reason to easily identify = the premium rate dialed number. Regards, Marianne > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Envoy=E9 : lundi 7 mars 2011 01:42 > =C0 : MOHALI Marianne RD-CORE-ISS > Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com > Objet : Re: [sipcore] I-DAction:=20 > draft-mohali-sipcore-reason-extension-application-01 >=20 > Marianne=20 >=20 > On 3/4/2011 11:59 AM, marianne.mohali@orange-ftgroup.com wrote: > > Hi Paul, > > > > My answer below [MM] > > > > Marianne > >> -----Message d'origine----- > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 :=20 > jeudi 3 mars=20 > >> 2011 18:31 =C0 : MOHALI Marianne RD-CORE-ISS Cc : sipcore@ietf.org; = > >> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] I-DAction: > >> draft-mohali-sipcore-reason-extension-application-01 > >> > >> Marianne, > >> > >> On 3/3/2011 11:51 AM, marianne.mohali@orange-ftgroup.com wrote: > >>> Hi Paul, > >>> > >>> The purpose is to allow applications/services to be > >> explicitely identified in the signaling path, so that others=20 > >> services/applications/telephony-AS can act accordingly. > >> Either to apply a process taking into account the service=20 > interaction=20 > >> or on the contrary, do not execute a feature already=20 > covered by the=20 > >> application. > >>> For instance, a caller with a prepaid service calls a > >> directory enquiries Server to ask for a restaurant phone=20 > number. The=20 > >> operator would suggest to connect the caller to the=20 > researched phone=20 > >> number EXCEPT if the caller has a prepaid service because=20 > it is not=20 > >> sure he has enough credit to pay for the communication. To=20 > allow this=20 > >> customized feature, the directory enquiries Application=20 > needs to know=20 > >> that the prepaid Application has been invocated. > >> > >> So once again, we are back to your wanting to use Reason not to=20 > >> express a "reason" for anything, but rather as just a hook to hang=20 > >> something on H-I. > > [MM] The *reason* why the call has been=20 > retargeted/rejected/modified is the invocation of a specific=20 > application. > > If you call a Service number and then the URI is changed=20 > for routing to the real destination, the *reason* of the URI=20 > modification (listed in H-I) is the application. >=20 > Based on your other replies, this is not necessarily so. >=20 > In fact the example above is a counter-example. > The prepaid service is not responsible for any redirection,=20 > and the operator service is looking for it for a reason other=20 > than that it has been the cause of anything. Its looking for=20 > it because it might be the cause of something in the future. >=20 > >> (With the causes you have defined, I can't imagine it making > >> *any* sense to actually use one in a Reason header in a message,=20 > >> because they aren't specific enough to be actionable.) > >> > >> I am now thinking there is a large overlap between what you are=20 > >> trying to accomplish this way, and what Christer is trying to=20 > >> accomplish with draft-holmberg-sipcore-proxy-feature. > >> > >> Is that true? > >> > >> (Christer: What do you think?) > > [MM] I don't see the overlap with Christer's draft because=20 > it is not about capabilities, it is about what's happened. >=20 > In your example above, it seems that the operator service is=20 > looking for the prepaid service because the prepaid service=20 > has the capability to influence billing, or something like=20 > that. This seems at least somewhat in line with what Christer=20 > is advocating. Looking in the Route header, or Record-Route=20 > header would make at least as much sense for this case as=20 > looking in H-I. H-I makes sense if you are indeed looking for=20 > something that has already happened, perhaps on a path other=20 > that the current one. >=20 > I think it would be helpful for the two of you to come to=20 > some reconciliation of what you are trying to accomplish. >=20 > Thanks, > Paul >=20 > >>> About your comment in case of several applications involved > >> *simultaneously* in the call establishment, it is possible=20 > to add 1=20 > >> more hi-entry for the second application Cause you want to be=20 > >> identified in the signaling path. > >> > >> Sure, you can indicate that they are "involved". But you=20 > can't infer=20 > >> anything about which one "caused" something. They might=20 > have, but you=20 > >> can't tell it from the presence of these headers. > >> > >> Thanks, > >> Paul > >> > >>> Regards, > >>> Marianne > >>> > >>> > >>>> -----Message d'origine----- > >>>> De : sipcore-bounces@ietf.org > >>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul > >> Kyzivat Envoy=E9 : > >>>> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org Objet : Re:=20 > [sipcore] > >>>> I-DAction: > >>>> draft-mohali-sipcore-reason-extension-application-01 > >>>> > >>>> (As individual) > >>>> > >>>> Marianne, > >>>> > >>>> I'm still struggling to make sense of this in the form proposed. > >>>> > >>>> I look at the various cause values, and all the > >> descriptions are of > >>>> the form. E.g.: > >>>> > >>>> Cause value: 2 > >>>> Reason text: Freephone > >>>> Description: A Freephone application has influenced=20 > >>>> processing of > >>>> the call (e.g. by translating a dialed Free Phone > >> number to a > >>>> routable directory number). > >>>> > >>>> I can't figure out how to make any actionable decision > >> based on this. > >>>> Rather, it seems I need to make a number of leaps of faith > >> before I > >>>> can decide what to do. > >>>> > >>>> For instance, if I get an error, it *might* be because I=20 > dialed a=20 > >>>> freephone number, and it isn't supported from my calling=20 > location. > >>>> (E.g. > >>>> maybe I'm dialing +1-800-555-1234, but I'm doing so from > >> France, and > >>>> calling that number is only supported in the USA. > >>>> > >>>> But getting a application reason code with cause 2=20 > doesn't really=20 > >>>> tell me that is what happened. It could be that the call > >> indeed was > >>>> routed through a freephone application, and it properly=20 > routed the=20 > >>>> call, and the call failed for some other reason. But the=20 > cause is=20 > >>>> there because the application > >>>> *did* influence the call routing. > >>>> > >>>> Also, these "applications" are not, AFAIK, mutually > >> exclusive. E.g. I > >>>> could be using a prepaid service to make a directory > >> assistance call > >>>> that costs extra $$$ that I don't have credits to cover. But you=20 > >>>> can't include two cause values for the same protocol. (But > >> it is true > >>>> that you > >>>> *can* have a number of servers each put one cause into > >>>> *their* H-I entry.) > >>>> > >>>> So *maybe* I would see that my call failed, and that there > >> is both a > >>>> reason indicating a prepaid application on one H-I entry, > >> and another > >>>> indicating a another H-I indicating a directory service > >> application. > >>>> But what can I conclude from that? > >>>> > >>>> Bottom line, I just can't make sense how this could be > >> used in a well > >>>> defined and interoperable way. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: > >>>>> Hello, > >>>>> > >>>>> Here is the new version of the draft. > >>>>> Main changes are following: > >>>>> - More details about the registration procedure for new values > >>>>> - Clearer text in section 3.2 > >>>>> - Add of Public and Private status for registered values. > >>>>> - Add of a range for cause values registration > >>>>> > >>>>> Best Regards, > >>>>> Marianne Mohali > >>>>> > >>>>> -----Message d'origine----- > >>>>> Objet : New Version Notification for > >>>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>> > >>>>> A New Internet-Draft is available from the on-line > >> Internet-Drafts > >>>>> directories. > >>>>> > >>>>> Title : Extending the Session=20 > Initiation Protocol > >>>>> (SIP) Reason Header for Applications > >>>>> Author(s) : M. Mohali, B. Chatras > >>>>> Filename : > >>>>> draft-mohali-sipcore-reason-extension-application-01.txt > >>>>> Pages : 10 > >>>>> Date : 2011-02-24 > >>>>> > >>>>> This document defines a new protocol value=20 > "Application" for the=20 > >>>>> Reason Header field and a new IANA Registry for registering=20 > >>>>> application types. This new value enables signaling that a > >>>> request or > >>>>> response has been issued as a result of a decision made by a=20 > >>>>> particular type of application or that an initial request > >> has been > >>>>> retargeted as a result of an application decision. > >>>>> > >>>>> A URL for this Internet-Draft is: > >>>>> > >>>> > >>=20 > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten > >>>> s > >>>>> io > >>>>> n-application-01.txt > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> Below is the data which will enable a MIME compliant=20 > mail reader=20 > >>>>> implementation to automatically retrieve the ASCII=20 > version of the=20 > >>>>> Internet-Draft. > >>>>> > >>>>> > >>>> > >>=20 > >>>> s > >>>>> io > >>>>> n-application-01.txt> > >>>>> > >>>>> _______________________________________________ > >>>>> I-D-Announce mailing list > >>>>> I-D-Announce@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>> > >>> > >> > > >=20 From christer.holmberg@ericsson.com Mon Mar 7 11:17:29 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70BEA3A67F4 for ; Mon, 7 Mar 2011 11:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc0FzU8tnp6Y for ; Mon, 7 Mar 2011 11:17:28 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id AD77E3A67E2 for ; Mon, 7 Mar 2011 11:17:26 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-21-4d752f8f4304 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 73.F7.09202.F8F257D4; Mon, 7 Mar 2011 20:18:40 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 7 Mar 2011 20:18:39 +0100 From: Christer Holmberg To: "'marianne.mohali@orange-ftgroup.com'" , "pkyzivat@cisco.com" Date: Mon, 7 Mar 2011 20:18:38 +0100 Thread-Topic: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvZyMeCfl6FKhNYSCqZg5YhzzfZxgAwppvQAJv9BmA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851948F0B2FF@ESESSCMS0356.eemea.ericsson.se> References: <4D6C2CB6.4040800@cisco.com> <4D6FD03A.8040507@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 19:17:29 -0000 Hi, >>>The purpose is to allow applications/services to be >>>explicitely identified in the signaling path, so that others=20 >>>services/applications/telephony-AS can act accordingly. >>>Either to apply a process taking into account the service interaction=20 >>>or on the contrary, do not execute a feature already covered by the=20 >>>application. >>>For instance, a caller with a prepaid service calls a >>>directory enquiries Server to ask for a restaurant phone number. The=20 >>>operator would suggest to connect the caller to the researched phone=20 >>>number EXCEPT if the caller has a prepaid service because it is not=20 >>>sure he has enough credit to pay for the communication. To allow this=20 >>>customized feature, the directory enquiries Application needs to know=20 >>>that the prepaid Application has been invocated. >>=20 >>So once again, we are back to your wanting to use Reason not to=20 >>express a "reason" for anything, but rather as just a hook to hang=20 >>something on H-I. >[MM] The *reason* why the call has been retargeted/rejected/modified is th= e=20 >invocation of a specific application. If you call a Service number and the= n the=20 >URI is changed for routing to the real destination, the *reason* of the UR= I=20 >modification (listed in H-I) is the application. >=20 >>(With the causes you have defined, I can't imagine it making >>*any* sense to actually use one in a Reason header in a message,=20 >>because they aren't specific enough to be actionable.) >>=20 >>I am now thinking there is a large overlap between what you are trying=20 >>to accomplish this way, and what Christer is trying to accomplish with=20 >>draft-holmberg-sipcore-proxy-feature. > > >>Is that true? >>=20 >(Christer: What do you think?) >[MM] I don't see the overlap with Christer's draft because it is not about= capabilities, it is about what's happened. Marianne is correct: proxy-feature is about entity capabilities - what they= CAN do. Regards, Christer =20 > > About your comment in case of several applications involved > *simultaneously* in the call establishment, it is possible to add 1=20 > more hi-entry for the second application Cause you want to be=20 > identified in the signaling path. >=20 > Sure, you can indicate that they are "involved". But you can't infer=20 > anything about which one "caused" something. They might have, but you=20 > can't tell it from the presence of these headers. >=20 > Thanks, > Paul >=20 > > Regards, > > Marianne > > > > > >> -----Message d'origine----- > >> De : sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] De la part de Paul > Kyzivat Envoy=E9 :=20 > >> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org Objet : Re: [sipcore] > >> I-DAction: > >> draft-mohali-sipcore-reason-extension-application-01 > >> > >> (As individual) > >> > >> Marianne, > >> > >> I'm still struggling to make sense of this in the form proposed. > >> > >> I look at the various cause values, and all the > descriptions are of > >> the form. E.g.: > >> > >> Cause value: 2 > >> Reason text: Freephone > >> Description: A Freephone application has influenced=20 > >> processing of > >> the call (e.g. by translating a dialed Free Phone > number to a > >> routable directory number). > >> > >> I can't figure out how to make any actionable decision > based on this. > >> Rather, it seems I need to make a number of leaps of faith > before I > >> can decide what to do. > >> > >> For instance, if I get an error, it *might* be because I dialed a=20 > >> freephone number, and it isn't supported from my calling location. > >> (E.g. > >> maybe I'm dialing +1-800-555-1234, but I'm doing so from > France, and > >> calling that number is only supported in the USA. > >> > >> But getting a application reason code with cause 2 doesn't really=20 > >> tell me that is what happened. It could be that the call > indeed was > >> routed through a freephone application, and it properly routed the=20 > >> call, and the call failed for some other reason. But the cause is=20 > >> there because the application > >> *did* influence the call routing. > >> > >> Also, these "applications" are not, AFAIK, mutually > exclusive. E.g. I > >> could be using a prepaid service to make a directory > assistance call > >> that costs extra $$$ that I don't have credits to cover. But you=20 > >> can't include two cause values for the same protocol. (But > it is true > >> that you > >> *can* have a number of servers each put one cause into > >> *their* H-I entry.) > >> > >> So *maybe* I would see that my call failed, and that there > is both a > >> reason indicating a prepaid application on one H-I entry, > and another > >> indicating a another H-I indicating a directory service > application.=20 > >> But what can I conclude from that? > >> > >> Bottom line, I just can't make sense how this could be > used in a well > >> defined and interoperable way. > >> > >> Thanks, > >> Paul > >> > >> On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: > >>> Hello, > >>> > >>> Here is the new version of the draft. > >>> Main changes are following: > >>> - More details about the registration procedure for new values > >>> - Clearer text in section 3.2 > >>> - Add of Public and Private status for registered values. > >>> - Add of a range for cause values registration > >>> > >>> Best Regards, > >>> Marianne Mohali > >>> > >>> -----Message d'origine----- > >>> Objet : New Version Notification for > >>> draft-mohali-sipcore-reason-extension-application-01 > >>> > >>> A New Internet-Draft is available from the on-line > Internet-Drafts > >>> directories. > >>> > >>> Title : Extending the Session Initiation Protocol > >>> (SIP) Reason Header for Applications > >>> Author(s) : M. Mohali, B. Chatras > >>> Filename : > >>> draft-mohali-sipcore-reason-extension-application-01.txt > >>> Pages : 10 > >>> Date : 2011-02-24 > >>> > >>> This document defines a new protocol value "Application" for the=20 > >>> Reason Header field and a new IANA Registry for registering=20 > >>> application types. This new value enables signaling that a > >> request or > >>> response has been issued as a result of a decision made by a=20 > >>> particular type of application or that an initial request > has been > >>> retargeted as a result of an application decision. > >>> > >>> A URL for this Internet-Draft is: > >>> > >>=20 > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten > >> s > >>> io > >>> n-application-01.txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> Below is the data which will enable a MIME compliant mail reader=20 > >>> implementation to automatically retrieve the ASCII version of the=20 > >>> Internet-Draft. > >>> > >>> > >>=20 > >> s > >>> io > >>> n-application-01.txt> > >>> > >>> _______________________________________________ > >>> I-D-Announce mailing list > >>> I-D-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > >=20 From christer.holmberg@ericsson.com Mon Mar 7 11:23:28 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9E73A67F4 for ; Mon, 7 Mar 2011 11:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dazP4pU6Rto6 for ; Mon, 7 Mar 2011 11:23:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D3D993A67E2 for ; Mon, 7 Mar 2011 11:23:26 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-31-4d7530f7a57a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 05.38.09202.7F0357D4; Mon, 7 Mar 2011 20:24:40 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 7 Mar 2011 20:24:39 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , "marianne.mohali@orange-ftgroup.com" Date: Mon, 7 Mar 2011 20:24:39 +0100 Thread-Topic: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvcYISVl+mM27GVQW20lhKurWBuZQAm/njQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851948F0B300@ESESSCMS0356.eemea.ericsson.se> References: <4D6C2CB6.4040800@cisco.com> <4D6FD03A.8040507@cisco.com> <4D7429E9.5070607@cisco.com> In-Reply-To: <4D7429E9.5070607@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 19:23:29 -0000 Hi,=20 >>[MM] I don't see the overlap with Christer's draft because it is not abou= t capabilities, it is about what's happened. > >In your example above, it seems that the operator service is looking for t= he prepaid service because=20 >the prepaid service has the capability to influence billing, or something = like that. This seems at=20 >least somewhat in line with what Christer is advocating. Looking in the Ro= ute header, or Record-Route=20 >header would make at least as much sense for this case as looking in H-I. = H-I makes sense if you are=20 >indeed looking for something that has already happened, perhaps on a path = other that the current one. I haven't studies this specific use-case, but if it's about finding a servi= ce or capability in the network then I agree that proxy-feature is appropri= ate. Without looking at it from a can-do/have-done perspective, another importan= t thing with proxy-feature is that the entity that inserts a feature tag MU= ST NOT assume that other entities will understand and act upon it. I am not claiming that Marianne's use-case is any different in that perspec= tive, but just to keep in mind. >I think it would be helpful for the two of you to come to some reconciliat= ion of what you are trying to accomplish. I am trying to indicate support of capabilities :) Regards, Christer >>> About your comment in case of several applications involved >> *simultaneously* in the call establishment, it is possible to add 1=20 >> more hi-entry for the second application Cause you want to be=20 >> identified in the signaling path. >> >> Sure, you can indicate that they are "involved". But you can't infer=20 >> anything about which one "caused" something. They might have, but you=20 >> can't tell it from the presence of these headers. >> >> Thanks, >> Paul >> >>> Regards, >>> Marianne >>> >>> >>>> -----Message d'origine----- >>>> De : sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul >> Kyzivat Envoy=E9 : >>>> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org Objet : Re: [sipcore] >>>> I-DAction: >>>> draft-mohali-sipcore-reason-extension-application-01 >>>> >>>> (As individual) >>>> >>>> Marianne, >>>> >>>> I'm still struggling to make sense of this in the form proposed. >>>> >>>> I look at the various cause values, and all the >> descriptions are of >>>> the form. E.g.: >>>> >>>> Cause value: 2 >>>> Reason text: Freephone >>>> Description: A Freephone application has influenced=20 >>>> processing of >>>> the call (e.g. by translating a dialed Free Phone >> number to a >>>> routable directory number). >>>> >>>> I can't figure out how to make any actionable decision >> based on this. >>>> Rather, it seems I need to make a number of leaps of faith >> before I >>>> can decide what to do. >>>> >>>> For instance, if I get an error, it *might* be because I dialed a=20 >>>> freephone number, and it isn't supported from my calling location. >>>> (E.g. >>>> maybe I'm dialing +1-800-555-1234, but I'm doing so from >> France, and >>>> calling that number is only supported in the USA. >>>> >>>> But getting a application reason code with cause 2 doesn't really=20 >>>> tell me that is what happened. It could be that the call >> indeed was >>>> routed through a freephone application, and it properly routed the=20 >>>> call, and the call failed for some other reason. But the cause is=20 >>>> there because the application >>>> *did* influence the call routing. >>>> >>>> Also, these "applications" are not, AFAIK, mutually >> exclusive. E.g. I >>>> could be using a prepaid service to make a directory >> assistance call >>>> that costs extra $$$ that I don't have credits to cover. But you=20 >>>> can't include two cause values for the same protocol. (But >> it is true >>>> that you >>>> *can* have a number of servers each put one cause into >>>> *their* H-I entry.) >>>> >>>> So *maybe* I would see that my call failed, and that there >> is both a >>>> reason indicating a prepaid application on one H-I entry, >> and another >>>> indicating a another H-I indicating a directory service >> application. >>>> But what can I conclude from that? >>>> >>>> Bottom line, I just can't make sense how this could be >> used in a well >>>> defined and interoperable way. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: >>>>> Hello, >>>>> >>>>> Here is the new version of the draft. >>>>> Main changes are following: >>>>> - More details about the registration procedure for new values >>>>> - Clearer text in section 3.2 >>>>> - Add of Public and Private status for registered values. >>>>> - Add of a range for cause values registration >>>>> >>>>> Best Regards, >>>>> Marianne Mohali >>>>> >>>>> -----Message d'origine----- >>>>> Objet : New Version Notification for >>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>> >>>>> A New Internet-Draft is available from the on-line >> Internet-Drafts >>>>> directories. >>>>> >>>>> Title : Extending the Session Initiation Protocol >>>>> (SIP) Reason Header for Applications >>>>> Author(s) : M. Mohali, B. Chatras >>>>> Filename : >>>>> draft-mohali-sipcore-reason-extension-application-01.txt >>>>> Pages : 10 >>>>> Date : 2011-02-24 >>>>> >>>>> This document defines a new protocol value "Application" for the=20 >>>>> Reason Header field and a new IANA Registry for registering=20 >>>>> application types. This new value enables signaling that a >>>> request or >>>>> response has been issued as a result of a decision made by a=20 >>>>> particular type of application or that an initial request >> has been >>>>> retargeted as a result of an application decision. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> >>>> >> http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten >>>> s >>>>> io >>>>> n-application-01.txt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader=20 >>>>> implementation to automatically retrieve the ASCII version of the=20 >>>>> Internet-Draft. >>>>> >>>>> >>>> >> >>> s >>>>> io >>>>> n-application-01.txt> >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >> > From pkyzivat@cisco.com Mon Mar 7 11:58:29 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966113A63D3 for ; Mon, 7 Mar 2011 11:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVD4tYbpq6DS for ; Mon, 7 Mar 2011 11:58:27 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2D2E23A6407 for ; Mon, 7 Mar 2011 11:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=13394; q=dns/txt; s=iport; t=1299527981; x=1300737581; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=o6xAWkxaJzFCueQmtyuaVco9cCR5Jv1PXT2HWAWlvGQ=; b=aqX3vBrF/ymnBrDZAlBAxzFoaCZcQA6KM+upX41ESyjKnIIp0EQUSMsC rhmKL3kAO/lCF7aUUePNE3rrY7koyAdf9OIjpFdwS+/hA5WmoULS+QDpr Dsxnumf/HYjYgF9Yj22Fwoaa0ejKs5viCCy1M/jRs64fskg130W2hB5T0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANPHdE1AZnwN/2dsb2JhbACmUnSiLpt2gn4TB4JKBIUchxSDQw X-IronPort-AV: E=Sophos;i="4.62,278,1297036800"; d="scan'208";a="222991782" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Mar 2011 19:59:40 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p27Jxe0o017295; Mon, 7 Mar 2011 19:59:40 GMT Message-ID: <4D75392C.6050405@cisco.com> Date: Mon, 07 Mar 2011 14:59:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: marianne.mohali@orange-ftgroup.com References: <4D6C2CB6.4040800@cisco.com> <4D6FD03A.8040507@cisco.com> <4D7429E9.5070607@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 19:58:29 -0000 On 3/7/2011 1:29 PM, marianne.mohali@orange-ftgroup.com wrote: > Paul, > > I think that Christer's draft (proxy-feature) is about capabilities while this one (reason-extension-application) is about what really happened (like reason in general). It is provided only when the event happens and the purpose is to give an accuate information for applicative events. > > Let me give you an other example: > A reception AS called with several premium rate numbers (1 per hosted application/service). I'm sorry, but I'm not familiar with such services, so I don't fully understand this, though I can guess. Here is what I think you are saying: There are some special URLs (premium rate numbers) that I can call. A property of these is that when I call them my call is charged extra. (I guess perhaps these are what we call "900" numbers in the US.) Such calls are routed to a special server which handles this premium rate charging. When it receives an INVITE to a premium rate URL that it supports, it regargets the URL to a different one denoting the actual server, and then forwards the INVITE. The ultimate server wants a way to determine whether a premium rate URL was used in reaching this server, and if so, which one. And I suppose there may have been multiple translations, and so the goal is to identify one that was done by a premium rate server. > The AS dispatches calls to several call centers (eg. Depending on charge, hour of the day/night...). The final destination needs to know the called service. > The premuim rate number should be listed in the H-I header. Which entry? For which application/service invocated? > As you can have a call forwarding reason associated to a 3xx or 486 Reason-cause, you could have an applicative reason to easily identify the premium rate dialed number. So you want to have an indication that the cause of the retargeting was "premium rate", or "premium rate server" or "premium rate service". But frankly it doesn't sound like that is the reason for the retargeting. The reason for retargeting is that the address given terminated on something that delegates the actual work. It could as well have been a registrar, to which the actual services register. ISTM that the URL has the property that calling it costs extra, or else its the behavior of the AS that it first landed on that charges a premium rate. Isn't it equally possible that the AS could have provided the service directly rather than retargeting. If the AS actually does the billing, and needs to be in the route to do so, then Christer's proposal might make sense. If its the ultimate recipient that does the billing, and does so based on the particular URL used to reach it, then its perhaps just the presence of that URL along the path that matters, and maybe even if the call was redirected. If the URL called determines the service delivered and the price, why does it matter whether the retargetting was via a premium rate service or not? Wouldn't the server just look through the H-I at all the retargetings until it got to one that identifies a service it supports? If so, it wouldn't need a cause code at all. Thanks, Paul > Regards, > Marianne > > >> -----Message d'origine----- >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Envoyé : lundi 7 mars 2011 01:42 >> À : MOHALI Marianne RD-CORE-ISS >> Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com >> Objet : Re: [sipcore] I-DAction: >> draft-mohali-sipcore-reason-extension-application-01 >> >> Marianne >> >> On 3/4/2011 11:59 AM, marianne.mohali@orange-ftgroup.com wrote: >>> Hi Paul, >>> >>> My answer below [MM] >>> >>> Marianne >>>> -----Message d'origine----- >>>> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoyé : >> jeudi 3 mars >>>> 2011 18:31 À : MOHALI Marianne RD-CORE-ISS Cc : sipcore@ietf.org; >>>> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] I-DAction: >>>> draft-mohali-sipcore-reason-extension-application-01 >>>> >>>> Marianne, >>>> >>>> On 3/3/2011 11:51 AM, marianne.mohali@orange-ftgroup.com wrote: >>>>> Hi Paul, >>>>> >>>>> The purpose is to allow applications/services to be >>>> explicitely identified in the signaling path, so that others >>>> services/applications/telephony-AS can act accordingly. >>>> Either to apply a process taking into account the service >> interaction >>>> or on the contrary, do not execute a feature already >> covered by the >>>> application. >>>>> For instance, a caller with a prepaid service calls a >>>> directory enquiries Server to ask for a restaurant phone >> number. The >>>> operator would suggest to connect the caller to the >> researched phone >>>> number EXCEPT if the caller has a prepaid service because >> it is not >>>> sure he has enough credit to pay for the communication. To >> allow this >>>> customized feature, the directory enquiries Application >> needs to know >>>> that the prepaid Application has been invocated. >>>> >>>> So once again, we are back to your wanting to use Reason not to >>>> express a "reason" for anything, but rather as just a hook to hang >>>> something on H-I. >>> [MM] The *reason* why the call has been >> retargeted/rejected/modified is the invocation of a specific >> application. >>> If you call a Service number and then the URI is changed >> for routing to the real destination, the *reason* of the URI >> modification (listed in H-I) is the application. >> >> Based on your other replies, this is not necessarily so. >> >> In fact the example above is a counter-example. >> The prepaid service is not responsible for any redirection, >> and the operator service is looking for it for a reason other >> than that it has been the cause of anything. Its looking for >> it because it might be the cause of something in the future. >> >>>> (With the causes you have defined, I can't imagine it making >>>> *any* sense to actually use one in a Reason header in a message, >>>> because they aren't specific enough to be actionable.) >>>> >>>> I am now thinking there is a large overlap between what you are >>>> trying to accomplish this way, and what Christer is trying to >>>> accomplish with draft-holmberg-sipcore-proxy-feature. >>>> >>>> Is that true? >>>> >>>> (Christer: What do you think?) >>> [MM] I don't see the overlap with Christer's draft because >> it is not about capabilities, it is about what's happened. >> >> In your example above, it seems that the operator service is >> looking for the prepaid service because the prepaid service >> has the capability to influence billing, or something like >> that. This seems at least somewhat in line with what Christer >> is advocating. Looking in the Route header, or Record-Route >> header would make at least as much sense for this case as >> looking in H-I. H-I makes sense if you are indeed looking for >> something that has already happened, perhaps on a path other >> that the current one. >> >> I think it would be helpful for the two of you to come to >> some reconciliation of what you are trying to accomplish. >> >> Thanks, >> Paul >> >>>>> About your comment in case of several applications involved >>>> *simultaneously* in the call establishment, it is possible >> to add 1 >>>> more hi-entry for the second application Cause you want to be >>>> identified in the signaling path. >>>> >>>> Sure, you can indicate that they are "involved". But you >> can't infer >>>> anything about which one "caused" something. They might >> have, but you >>>> can't tell it from the presence of these headers. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, >>>>> Marianne >>>>> >>>>> >>>>>> -----Message d'origine----- >>>>>> De : sipcore-bounces@ietf.org >>>>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul >>>> Kyzivat Envoyé : >>>>>> mardi 1 mars 2011 00:16 À : sipcore@ietf.org Objet : Re: >> [sipcore] >>>>>> I-DAction: >>>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>>> >>>>>> (As individual) >>>>>> >>>>>> Marianne, >>>>>> >>>>>> I'm still struggling to make sense of this in the form proposed. >>>>>> >>>>>> I look at the various cause values, and all the >>>> descriptions are of >>>>>> the form. E.g.: >>>>>> >>>>>> Cause value: 2 >>>>>> Reason text: Freephone >>>>>> Description: A Freephone application has influenced >>>>>> processing of >>>>>> the call (e.g. by translating a dialed Free Phone >>>> number to a >>>>>> routable directory number). >>>>>> >>>>>> I can't figure out how to make any actionable decision >>>> based on this. >>>>>> Rather, it seems I need to make a number of leaps of faith >>>> before I >>>>>> can decide what to do. >>>>>> >>>>>> For instance, if I get an error, it *might* be because I >> dialed a >>>>>> freephone number, and it isn't supported from my calling >> location. >>>>>> (E.g. >>>>>> maybe I'm dialing +1-800-555-1234, but I'm doing so from >>>> France, and >>>>>> calling that number is only supported in the USA. >>>>>> >>>>>> But getting a application reason code with cause 2 >> doesn't really >>>>>> tell me that is what happened. It could be that the call >>>> indeed was >>>>>> routed through a freephone application, and it properly >> routed the >>>>>> call, and the call failed for some other reason. But the >> cause is >>>>>> there because the application >>>>>> *did* influence the call routing. >>>>>> >>>>>> Also, these "applications" are not, AFAIK, mutually >>>> exclusive. E.g. I >>>>>> could be using a prepaid service to make a directory >>>> assistance call >>>>>> that costs extra $$$ that I don't have credits to cover. But you >>>>>> can't include two cause values for the same protocol. (But >>>> it is true >>>>>> that you >>>>>> *can* have a number of servers each put one cause into >>>>>> *their* H-I entry.) >>>>>> >>>>>> So *maybe* I would see that my call failed, and that there >>>> is both a >>>>>> reason indicating a prepaid application on one H-I entry, >>>> and another >>>>>> indicating a another H-I indicating a directory service >>>> application. >>>>>> But what can I conclude from that? >>>>>> >>>>>> Bottom line, I just can't make sense how this could be >>>> used in a well >>>>>> defined and interoperable way. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Here is the new version of the draft. >>>>>>> Main changes are following: >>>>>>> - More details about the registration procedure for new values >>>>>>> - Clearer text in section 3.2 >>>>>>> - Add of Public and Private status for registered values. >>>>>>> - Add of a range for cause values registration >>>>>>> >>>>>>> Best Regards, >>>>>>> Marianne Mohali >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> Objet : New Version Notification for >>>>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts >>>>>>> directories. >>>>>>> >>>>>>> Title : Extending the Session >> Initiation Protocol >>>>>>> (SIP) Reason Header for Applications >>>>>>> Author(s) : M. Mohali, B. Chatras >>>>>>> Filename : >>>>>>> draft-mohali-sipcore-reason-extension-application-01.txt >>>>>>> Pages : 10 >>>>>>> Date : 2011-02-24 >>>>>>> >>>>>>> This document defines a new protocol value >> "Application" for the >>>>>>> Reason Header field and a new IANA Registry for registering >>>>>>> application types. This new value enables signaling that a >>>>>> request or >>>>>>> response has been issued as a result of a decision made by a >>>>>>> particular type of application or that an initial request >>>> has been >>>>>>> retargeted as a result of an application decision. >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> >>>>>> >>>> >> http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten >>>>>> s >>>>>>> io >>>>>>> n-application-01.txt >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> Below is the data which will enable a MIME compliant >> mail reader >>>>>>> implementation to automatically retrieve the ASCII >> version of the >>>>>>> Internet-Draft. >>>>>>> >>>>>>> >>>>>> >>>> >> >>>>> s >>>>>>> io >>>>>>> n-application-01.txt> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> I-D-Announce mailing list >>>>>>> I-D-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>>> >>>> >>> >> > From jmpolk@cisco.com Mon Mar 7 12:39:20 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25223A659C for ; Mon, 7 Mar 2011 12:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9IVcqnnD9XD for ; Mon, 7 Mar 2011 12:39:19 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DE1133A657C for ; Mon, 7 Mar 2011 12:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=525; q=dns/txt; s=iport; t=1299530434; x=1300740034; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=fBGjHIsUiJZRFmRdJDHNGFmxtFTnukpeB3uLr0PnbMM=; b=Zw7JgmvteZYUYClRkrcYPu8FN3VXZavIR3sHVPpkssMs9iTnk2vD0KH4 eG7JKK9B5/OEA5765hITuXNSTVi6Nsj9dTyLsxkDH1Oox5dZCfr+WUuyr We8JDBYQBRQk/BXcMg0/lYRAoFubPOIwE2vpeINl0jAK7mDX/7y4IZbks Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKrRdE2rRN+J/2dsb2JhbACmV3SiPpt9hWIEhRw X-IronPort-AV: E=Sophos;i="4.62,278,1297036800"; d="scan'208";a="341821244" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2011 20:40:33 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p27KeXgB018993; Mon, 7 Mar 2011 20:40:33 GMT Message-Id: <201103072040.p27KeXgB018993@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 07 Mar 2011 14:40:32 -0600 To: "Elwell, John" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 20:39:21 -0000 At 08:02 AM 3/7/2011, Elwell, John wrote: >The following was pointed out to me: >Section 5.1: "Supported: geolocation" oops, missed that one fortunately these are examples and there's no text supporting the inclusion of it... ;-) Thanks >We should either delete this line or change it to contain one or >both of the new option tags. > >Similarly in 5.2. > >John >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From iesg-secretary@ietf.org Mon Mar 7 13:17:15 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E083A6836; Mon, 7 Mar 2011 13:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUMvvjw9MoI1; Mon, 7 Mar 2011 13:17:14 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11D53A683F; Mon, 7 Mar 2011 13:17:13 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110307211713.2175.59043.idtracker@localhost> Date: Mon, 07 Mar 2011 13:17:13 -0800 Cc: sipcore chair , Internet Architecture Board , sipcore mailing list , RFC Editor Subject: [sipcore] Protocol Action: 'Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog' to Proposed Standard (draft-ietf-sipcore-199-06.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:17:15 -0000 The IESG has approved the following document: - 'Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog' (draft-ietf-sipcore-199-06.txt) as a Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-199/ Technical Summary This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP forking proxy and a UAS can use to indicate upstream towards the UAC that an early dialog has been terminated, before a final response is sent towards the UAC Working Group Summary There is consensus in the SIPCORE working group to publish this document despite early concerns about the utility of the mechanism. There was significant discussion of the document on the working group mailing list, including many detail adjustments after publication request. While resolving review comments, an issue with the interaction of the 199 response and the 100rel extension was identified and addressed by the SIPCORE working group. Document Quality This document is a product of the SIPCORE working group. Personnel The document shepherd is Gonzalo Camarillo The responsible area director is Robert Sparks From RjS@nostrum.com Wed Mar 9 08:22:59 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28C73A6859 for ; Wed, 9 Mar 2011 08:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sv10kH0qpBx1 for ; Wed, 9 Mar 2011 08:22:58 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 355B73A683E for ; Wed, 9 Mar 2011 08:22:57 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p29GOCbv008784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Mar 2011 10:24:12 -0600 (CST) (envelope-from RjS@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <4D6C31DC.80005@nostrum.com> Date: Wed, 9 Mar 2011 10:24:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D6C31DC.80005@nostrum.com> To: SIPCORE Chairs X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Wed, 09 Mar 2011 08:40:05 -0800 Cc: "draft-ietf-sipcore-location-conveyance@tools.ietf.org" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:22:59 -0000 James - There are some nits that idnits points out - please address those with = the other WGLC comments. RjS On Feb 28, 2011, at 5:38 PM, Adam Roach - SIPCORE Chair wrote: > [as chair] >=20 > The current editor of draft-ietf-sipcore-location-conveyance believes = that the document has no remaining technical issues[1], and is ready for = evaluation. Today, we are starting a two-week working group last call = period. This last call period ends on Tuesday, March 15th. >=20 > The latest version of the document can be retrieved here: >=20 > http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance >=20 > Any comments on the document should be sent to the SIPCORE mailing = list. >=20 > /a >=20 > [1] John Elwell's editorial comments of February 25th have been noted = by the authors, and will be treated as WGLC comments. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From marianne.mohali@orange-ftgroup.com Wed Mar 9 09:31:05 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CEC53A6856 for ; Wed, 9 Mar 2011 09:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbIn-WoZN6bX for ; Wed, 9 Mar 2011 09:31:02 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id F23F13A68C5 for ; Wed, 9 Mar 2011 09:31:01 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7F48B858005; Wed, 9 Mar 2011 18:37:56 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 76202858001; Wed, 9 Mar 2011 18:37:56 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Mar 2011 18:32:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2011 18:32:15 +0100 Message-ID: In-Reply-To: <4D75392C.6050405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvdAkVHQaFFiLE+Q6ujN+unXfv8xgBRGWpg References: <4D6C2CB6.4040800@cisco.com> <4D6FD03A.8040507@cisco.com> <4D7429E9.5070607@cisco.com> <4D75392C.6050405@cisco.com> From: To: X-OriginalArrivalTime: 09 Mar 2011 17:32:17.0474 (UTC) FILETIME=[EFBFFA20:01CBDE7F] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 17:31:05 -0000 > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Envoy=E9 : lundi 7 mars 2011 21:00 > =C0 : MOHALI Marianne RD-CORE-ISS > Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com > Objet : Re: [sipcore] I-DAction:=20 > draft-mohali-sipcore-reason-extension-application-01 >=20 >=20 >=20 > On 3/7/2011 1:29 PM, marianne.mohali@orange-ftgroup.com wrote: > > Paul, > > > > I think that Christer's draft (proxy-feature) is about=20 > capabilities while this one (reason-extension-application) is=20 > about what really happened (like reason in general). It is=20 > provided only when the event happens and the purpose is to=20 > give an accuate information for applicative events. > > > > Let me give you an other example: > > A reception AS called with several premium rate numbers (1=20 > per hosted application/service). >=20 > I'm sorry, but I'm not familiar with such services, so I=20 > don't fully understand this, though I can guess. Here is what=20 > I think you are saying: >=20 > There are some special URLs (premium rate numbers) that I can call. > A property of these is that when I call them my call is charged extra. > (I guess perhaps these are what we call "900" numbers in the US.) [MM] Not only this type of numbers but also "800" or other *welcome* = numbers. The routing, the provided service are not linked to the = charging. They can be extra charged, normally charged or free of charge. = Changing is not the subject. >=20 > Such calls are routed to a special server which handles this=20 > premium rate charging. When it receives an INVITE to a=20 > premium rate URL that it supports, it regargets the URL to a=20 > different one denoting the actual server, and then forwards=20 > the INVITE. >=20 > The ultimate server wants a way to determine whether a=20 > premium rate URL was used in reaching this server, and if so,=20 > which one. >=20 > And I suppose there may have been multiple translations, and=20 > so the goal is to identify one that was done by a premium rate server. [MM] Exact! The goal is to identify the provided service. >=20 > > The AS dispatches calls to several call centers (eg.=20 > Depending on charge, hour of the day/night...). The final=20 > destination needs to know the called service. >=20 > > The premuim rate number should be listed in the H-I header.=20 > Which entry? For which application/service invocated? > > As you can have a call forwarding reason associated to a=20 > 3xx or 486 Reason-cause, you could have an applicative reason=20 > to easily identify the premium rate dialed number. >=20 > So you want to have an indication that the cause of the=20 > retargeting was "premium rate", or "premium rate server" or=20 > "premium rate service". >=20 > But frankly it doesn't sound like that is the reason for the=20 > retargeting. The reason for retargeting is that the address=20 > given terminated on something that delegates the actual work.=20 > It could as well have been a registrar, to which the actual=20 > services register. >=20 > ISTM that the URL has the property that calling it costs=20 > extra, or else its the behavior of the AS that it first=20 > landed on that charges a premium rate. Isn't it equally=20 > possible that the AS could have provided the service directly=20 > rather than retargeting. >=20 [MM] It is the reason why the call has been routed to this URL and what = is happened. Let me give you an other example:=20 A call center provides hot line / help desk services on behalf of = several enterprises (utility companies, mail order catalogue retailers, = customer support for various products...). Call center agents can reply = to calls destined to several enterprises. Customers of these enterprises = call an 800 number that is specific to the enterprise. The 800 number is = re-targeted by a SIP Application Server to the workstation of a call = center agent whose location may depend on criteria such as the caller's = location, the time of day... The call center agent needs to know the = original number dialed by the customer so as to provide enterprise = specific welcome messages and answers. > If the AS actually does the billing, and needs to be in the=20 > route to do so, then Christer's proposal might make sense. >=20 > If its the ultimate recipient that does the billing, and does=20 > so based on the particular URL used to reach it, then its=20 > perhaps just the presence of that URL along the path that=20 > matters, and maybe even if the call was redirected. >=20 > If the URL called determines the service delivered and the=20 > price, why does it matter whether the retargetting was via a=20 > premium rate service or not? Wouldn't the server just look=20 > through the H-I at all the retargetings until it got to one=20 > that identifies a service it supports?=20 > If so, it wouldn't need a cause code at all. >=20 > Thanks, > Paul >=20 > > Regards, > > Marianne > > > > > >> -----Message d'origine----- > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 :=20 > lundi 7 mars=20 > >> 2011 01:42 =C0 : MOHALI Marianne RD-CORE-ISS Cc : sipcore@ietf.org; = > >> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] I-DAction: > >> draft-mohali-sipcore-reason-extension-application-01 > >> > >> Marianne > >> > >> On 3/4/2011 11:59 AM, marianne.mohali@orange-ftgroup.com wrote: > >>> Hi Paul, > >>> > >>> My answer below [MM] > >>> > >>> Marianne > >>>> -----Message d'origine----- > >>>> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : > >> jeudi 3 mars > >>>> 2011 18:31 =C0 : MOHALI Marianne RD-CORE-ISS Cc :=20 > sipcore@ietf.org;=20 > >>>> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] I-DAction: > >>>> draft-mohali-sipcore-reason-extension-application-01 > >>>> > >>>> Marianne, > >>>> > >>>> On 3/3/2011 11:51 AM, marianne.mohali@orange-ftgroup.com wrote: > >>>>> Hi Paul, > >>>>> > >>>>> The purpose is to allow applications/services to be > >>>> explicitely identified in the signaling path, so that others=20 > >>>> services/applications/telephony-AS can act accordingly. > >>>> Either to apply a process taking into account the service > >> interaction > >>>> or on the contrary, do not execute a feature already > >> covered by the > >>>> application. > >>>>> For instance, a caller with a prepaid service calls a > >>>> directory enquiries Server to ask for a restaurant phone > >> number. The > >>>> operator would suggest to connect the caller to the > >> researched phone > >>>> number EXCEPT if the caller has a prepaid service because > >> it is not > >>>> sure he has enough credit to pay for the communication. To > >> allow this > >>>> customized feature, the directory enquiries Application > >> needs to know > >>>> that the prepaid Application has been invocated. > >>>> > >>>> So once again, we are back to your wanting to use Reason not to=20 > >>>> express a "reason" for anything, but rather as just a=20 > hook to hang=20 > >>>> something on H-I. > >>> [MM] The *reason* why the call has been > >> retargeted/rejected/modified is the invocation of a specific=20 > >> application. > >>> If you call a Service number and then the URI is changed > >> for routing to the real destination, the *reason* of the URI=20 > >> modification (listed in H-I) is the application. > >> > >> Based on your other replies, this is not necessarily so. > >> > >> In fact the example above is a counter-example. > >> The prepaid service is not responsible for any=20 > redirection, and the=20 > >> operator service is looking for it for a reason other than that it=20 > >> has been the cause of anything. Its looking for it because=20 > it might=20 > >> be the cause of something in the future. > >> > >>>> (With the causes you have defined, I can't imagine it making > >>>> *any* sense to actually use one in a Reason header in a message,=20 > >>>> because they aren't specific enough to be actionable.) > >>>> > >>>> I am now thinking there is a large overlap between what you are=20 > >>>> trying to accomplish this way, and what Christer is trying to=20 > >>>> accomplish with draft-holmberg-sipcore-proxy-feature. > >>>> > >>>> Is that true? > >>>> > >>>> (Christer: What do you think?) > >>> [MM] I don't see the overlap with Christer's draft because > >> it is not about capabilities, it is about what's happened. > >> > >> In your example above, it seems that the operator service=20 > is looking=20 > >> for the prepaid service because the prepaid service has the=20 > >> capability to influence billing, or something like that.=20 > This seems=20 > >> at least somewhat in line with what Christer is=20 > advocating. Looking=20 > >> in the Route header, or Record-Route header would make at least as=20 > >> much sense for this case as looking in H-I. H-I makes sense if you=20 > >> are indeed looking for something that has already=20 > happened, perhaps=20 > >> on a path other that the current one. > >> > >> I think it would be helpful for the two of you to come to some=20 > >> reconciliation of what you are trying to accomplish. > >> > >> Thanks, > >> Paul > >> > >>>>> About your comment in case of several applications involved > >>>> *simultaneously* in the call establishment, it is possible > >> to add 1 > >>>> more hi-entry for the second application Cause you want to be=20 > >>>> identified in the signaling path. > >>>> > >>>> Sure, you can indicate that they are "involved". But you > >> can't infer > >>>> anything about which one "caused" something. They might > >> have, but you > >>>> can't tell it from the presence of these headers. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Regards, > >>>>> Marianne > >>>>> > >>>>> > >>>>>> -----Message d'origine----- > >>>>>> De : sipcore-bounces@ietf.org > >>>>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul > >>>> Kyzivat Envoy=E9 : > >>>>>> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org Objet : Re: > >> [sipcore] > >>>>>> I-DAction: > >>>>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>>> > >>>>>> (As individual) > >>>>>> > >>>>>> Marianne, > >>>>>> > >>>>>> I'm still struggling to make sense of this in the form=20 > proposed. > >>>>>> > >>>>>> I look at the various cause values, and all the > >>>> descriptions are of > >>>>>> the form. E.g.: > >>>>>> > >>>>>> Cause value: 2 > >>>>>> Reason text: Freephone > >>>>>> Description: A Freephone application has influenced=20 > >>>>>> processing of > >>>>>> the call (e.g. by translating a dialed Free Phone > >>>> number to a > >>>>>> routable directory number). > >>>>>> > >>>>>> I can't figure out how to make any actionable decision > >>>> based on this. > >>>>>> Rather, it seems I need to make a number of leaps of faith > >>>> before I > >>>>>> can decide what to do. > >>>>>> > >>>>>> For instance, if I get an error, it *might* be because I > >> dialed a > >>>>>> freephone number, and it isn't supported from my calling > >> location. > >>>>>> (E.g. > >>>>>> maybe I'm dialing +1-800-555-1234, but I'm doing so from > >>>> France, and > >>>>>> calling that number is only supported in the USA. > >>>>>> > >>>>>> But getting a application reason code with cause 2 > >> doesn't really > >>>>>> tell me that is what happened. It could be that the call > >>>> indeed was > >>>>>> routed through a freephone application, and it properly > >> routed the > >>>>>> call, and the call failed for some other reason. But the > >> cause is > >>>>>> there because the application > >>>>>> *did* influence the call routing. > >>>>>> > >>>>>> Also, these "applications" are not, AFAIK, mutually > >>>> exclusive. E.g. I > >>>>>> could be using a prepaid service to make a directory > >>>> assistance call > >>>>>> that costs extra $$$ that I don't have credits to=20 > cover. But you=20 > >>>>>> can't include two cause values for the same protocol. (But > >>>> it is true > >>>>>> that you > >>>>>> *can* have a number of servers each put one cause into > >>>>>> *their* H-I entry.) > >>>>>> > >>>>>> So *maybe* I would see that my call failed, and that there > >>>> is both a > >>>>>> reason indicating a prepaid application on one H-I entry, > >>>> and another > >>>>>> indicating a another H-I indicating a directory service > >>>> application. > >>>>>> But what can I conclude from that? > >>>>>> > >>>>>> Bottom line, I just can't make sense how this could be > >>>> used in a well > >>>>>> defined and interoperable way. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> > >>>>>> On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> Here is the new version of the draft. > >>>>>>> Main changes are following: > >>>>>>> - More details about the registration procedure for new values > >>>>>>> - Clearer text in section 3.2 > >>>>>>> - Add of Public and Private status for registered values. > >>>>>>> - Add of a range for cause values registration > >>>>>>> > >>>>>>> Best Regards, > >>>>>>> Marianne Mohali > >>>>>>> > >>>>>>> -----Message d'origine----- > >>>>>>> Objet : New Version Notification for > >>>>>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>>>> > >>>>>>> A New Internet-Draft is available from the on-line > >>>> Internet-Drafts > >>>>>>> directories. > >>>>>>> > >>>>>>> Title : Extending the Session > >> Initiation Protocol > >>>>>>> (SIP) Reason Header for Applications > >>>>>>> Author(s) : M. Mohali, B. Chatras > >>>>>>> Filename : > >>>>>>> draft-mohali-sipcore-reason-extension-application-01.txt > >>>>>>> Pages : 10 > >>>>>>> Date : 2011-02-24 > >>>>>>> > >>>>>>> This document defines a new protocol value > >> "Application" for the > >>>>>>> Reason Header field and a new IANA Registry for registering=20 > >>>>>>> application types. This new value enables signaling that a > >>>>>> request or > >>>>>>> response has been issued as a result of a decision made by a=20 > >>>>>>> particular type of application or that an initial request > >>>> has been > >>>>>>> retargeted as a result of an application decision. > >>>>>>> > >>>>>>> A URL for this Internet-Draft is: > >>>>>>> > >>>>>> > >>>> > >>=20 > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten > >>>>>> s > >>>>>>> io > >>>>>>> n-application-01.txt > >>>>>>> > >>>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>>> > >>>>>>> Below is the data which will enable a MIME compliant > >> mail reader > >>>>>>> implementation to automatically retrieve the ASCII > >> version of the > >>>>>>> Internet-Draft. > >>>>>>> > >>>>>>> > >>>>>> > >>>> > >>=20 > >>>>>> s > >>>>>>> io > >>>>>>> n-application-01.txt> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> I-D-Announce mailing list > >>>>>>> I-D-Announce@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>>>>> Internet-Draft directories:=20 > http://www.ietf.org/shadow.html or=20 > >>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>>>> _______________________________________________ > >>>>>>> sipcore mailing list > >>>>>>> sipcore@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> sipcore mailing list > >>>>>> sipcore@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>> > >>>>> > >>>> > >>> > >> > > >=20 From marianne.mohali@orange-ftgroup.com Wed Mar 9 09:39:05 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7C903A68F1 for ; Wed, 9 Mar 2011 09:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H30ys--YPxqn for ; Wed, 9 Mar 2011 09:39:04 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 19D923A6814 for ; Wed, 9 Mar 2011 09:39:04 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 26AF68B800C; Wed, 9 Mar 2011 18:40:48 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 1D9FA8B8004; Wed, 9 Mar 2011 18:40:48 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Mar 2011 18:40:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2011 18:40:18 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvZyONLW9FOvLuUTUqkYcckL0it7wDKxr0yAFSpeNA= References: <4D6C2CB6.4040800@cisco.com>, <4D6FD03A.8040507@cisco.com> From: To: , X-OriginalArrivalTime: 09 Mar 2011 17:40:19.0912 (UTC) FILETIME=[0F4E2C80:01CBDE81] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 17:39:05 -0000 Hi Dale, My answer below [MM] Marianne=20 > -----Message d'origine----- > De : Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20 > Envoy=E9 : lundi 7 mars 2011 19:18 > =C0 : Paul Kyzivat; MOHALI Marianne RD-CORE-ISS > Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com > Objet : RE: [sipcore]=20 > I-DAction:draft-mohali-sipcore-reason-extension-application-01 >=20 > On 3/3/2011 11:51 AM, marianne.mohali@orange-ftgroup.com wrote: > > The purpose is to allow applications/services to be explicitely=20 > > identified in the signaling path, so that others=20 > > services/applications/telephony-AS can act accordingly. Either to=20 > > apply a process taking into account the service interaction=20 > or on the=20 > > contrary, do not execute a feature already covered by the=20 > application. > >=20 > > For instance, a caller with a prepaid service calls a directory=20 > > enquiries Server to ask for a restaurant phone number. The operator=20 > > would suggest to connect the caller to the researched phone number=20 > > EXCEPT if the caller has a prepaid service because it is=20 > not sure he=20 > > has enough credit to pay for the communication. To allow this=20 > > customized feature, the directory enquiries Application=20 > needs to know=20 > > that the prepaid Application has been invocated. >=20 > Could we see an example of how this is expected to be done? =20 > (Or have I overlooked the example?) There are various=20 > subtlties in a protocol feature whose *absence* in the=20 > signaling tells another application that a certain action may=20 > be taken. [MM] In my network, I have an agreement with the Prepaid application = that is to identify itself in the signaling (in the H-I header) when = applied. So that, I can offer to all of my clients a customized service with a = connection to the reseached phone number except for prepaid callers. Callers from other networks will not be able to enjoy the customized = service (with the connection) as they are considered as untrusted.=20 >=20 > Dale >=20 From dworley@avaya.com Wed Mar 9 10:31:13 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1AF3A6944 for ; Wed, 9 Mar 2011 10:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AolsZrp9kgj for ; Wed, 9 Mar 2011 10:31:12 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 831723A6933 for ; Wed, 9 Mar 2011 10:31:12 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMtcU2HCzI1/2dsb2JhbACmZXSkeQKZFoJ+gmMEhRyKcA X-IronPort-AV: E=Sophos;i="4.62,291,1297054800"; d="scan'208";a="268608090" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Mar 2011 13:32:28 -0500 X-IronPort-AV: E=Sophos;i="4.62,291,1297054800"; d="scan'208";a="614077725" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Mar 2011 13:32:28 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.187]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 9 Mar 2011 13:32:27 -0500 From: "Worley, Dale R (Dale)" To: "marianne.mohali@orange-ftgroup.com" , "pkyzivat@cisco.com" Date: Wed, 9 Mar 2011 13:31:42 -0500 Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvZyONLW9FOvLuUTUqkYcckL0it7wDKxr0yAFSpeNAAEGYxoA== Message-ID: References: <4D6C2CB6.4040800@cisco.com>, <4D6FD03A.8040507@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 18:31:13 -0000 ________________________________________ From: marianne.mohali@orange-ftgroup.com [marianne.mohali@orange-ftgroup.co= m] > -----Message d'origine----- > De : Worley, Dale R (Dale) [mailto:dworley@avaya.com] > > Could we see an example of how this is expected to be done? > (Or have I overlooked the example?) There are various > subtlties in a protocol feature whose *absence* in the > signaling tells another application that a certain action may > be taken. [MM] In my network, I have an agreement with the Prepaid application that i= s to identify itself in the signaling (in the H-I header) when applied. So that, I can offer to all of my clients a customized service with a conne= ction to the reseached phone number except for prepaid callers. Callers from other networks will not be able to enjoy the customized servic= e (with the connection) as they are considered as untrusted. _______________________________________ I was thinking of a call flow, showing the critical header fields, the vari= ous proxies involved, etc. Dale From rjsparks@nostrum.com Wed Mar 9 12:44:18 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B893A6ABA for ; Wed, 9 Mar 2011 12:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 160Bm2-y6SDK for ; Wed, 9 Mar 2011 12:44:17 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id CF2EF3A6ABC for ; Wed, 9 Mar 2011 12:44:16 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p29KjSFS033867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Mar 2011 14:45:32 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <4D6C31DC.80005@nostrum.com> Date: Wed, 9 Mar 2011 14:45:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D6C31DC.80005@nostrum.com> To: SIPCORE Chairs X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-location-conveyance@tools.ietf.org, "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:44:18 -0000 There are a couple of larger and several small things to also address in = this document before requesting publication. The larger things: 1) In section 4.4, the document talks about providing a text string = "RECOMMENDED for human readability". The document needs to be clear who this is intended for. Do you expect this to be = rendered to a user or only read by an operator? (Fortunately quoted-string allows non-ascii UTF-8 already, so we won't = have to argue about whether this needs to be internationalized.) 2) The Geolocation-Error ABNF and the IANA registration section use a = parameter name =3D value form (with a name of "code"). Following those sections of the document, the examples should all look = like Geolocation-Error: 100;code=3D"Cannot Process Location" But all the examples currently look like Geolocation-Error: 100 "Cannot Process Location" It's worth pointing out that 3261 (see the top of page 32) doesn't allow = the same parameter name to appear in a header field value more than once, so the following is not allowed: Geolocation-Error: 100;code=3D"Cannot Process Location";code=3D"Impossible= de processus de localisation" Are the values you are registering for code=3D suggested defaults (like = for SIP response start lines) or are they what MUST appear? Is this OK? Geolocation-Error: 100;code=3D"Have a nice day" If not, what in the document says so? 3) I can't figure out what the paragraph in section 4.4 that starts = "Additionally, if a sip entity cannot..." and goes onto talk about 503's is trying to say. I think some surrounding context = must have been lost or not captured. Why would we be recommending sending a 503 here? 4) Section 4.4 defines classes of error codes, and even default values = of error codes, but does not go on to say that if an element receives an error code it doesn't understand, it = treats it like the default code in that class. Surely that was the intent (otherwise, having the classes isn't = particularly useful). If it was, the document should say so. --------------------------------------------------------- Here are the smaller things. I've listed these in as close to document order as I could 1) In 4.1, please call out what document's definition of HCOLON, COMMA, = LAQUOT, RAQUOT and SEMI that you are using. Either call out that these are used in other places in the doc (4.2 = and 4.4) or similarly call out the terminals used in those sections (be sure to catch DIGIT and EQUAL in 4.4). 2) In section 4.1, I suggest replacing OLD: A Geolocation header field MUST have at least one header-value. with NEW: A Geolocation header field MUST have at least on 3) In 4.2, I suggest replacing OLD: Values other than "yes" or "no" are permitted as a mechanism for = future extensions, and should be treated the same as "no". with NEW: The syntax allows values other than "yes" or "no" to appear to = allow for future extensions. Implementations not aware of an extension = SHOULD treat any other received value the same as "no". I also propose that this be MUST instead of SHOULD. 4) 4.2.1, first paragraph, s/contained in a one or/contained in one or/ = (delete the spurious "a") 5) I suggest the following replacement for the paragraph in section 4.3 = that starts "It is only appropriate" It is only appropriate to generate a 424 response when the responding = entity needs a locationValue and there are no values in the request that are usable by the responder, = or when the responder has additional location information to provide. The latter case is shown in = Figure 4 of section 3.4. There, a SIP intermediary is informing the upstream UA which location to = include in the next SIP request. 6) In 4.4 was "any SIP non-100 response" intended to mean a) any SIP response, including provisional responses other than 100 = Trying or b) only SIP Final responses ?=20 7) Section 8.1 claims two actions for IANA, but provides only one. 8) In section 8.5 step 2, please just say "Yes" under predefined values = instead of "yes*", and delete the footnote. Section 8.6 is the next section and is easy to = find, and it will save IANA having to ask if you are trying to put a * in the table in the = registry. 9) A.2 UAS-1 will cause confusion. We are allowing locations to appear = in responses, just not the location of the responder. Please adjust it to avoid that = potential confusion. =20 As an individual contributor, I don't think these appendices add = enough value to the document=20 to warrant the confusion they may cause and would be happier if they = were deleted. On Feb 28, 2011, at 5:38 PM, Adam Roach - SIPCORE Chair wrote: > [as chair] >=20 > The current editor of draft-ietf-sipcore-location-conveyance believes = that the document has no remaining technical issues[1], and is ready for = evaluation. Today, we are starting a two-week working group last call = period. This last call period ends on Tuesday, March 15th. >=20 > The latest version of the document can be retrieved here: >=20 > http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance >=20 > Any comments on the document should be sent to the SIPCORE mailing = list. >=20 > /a >=20 > [1] John Elwell's editorial comments of February 25th have been noted = by the authors, and will be treated as WGLC comments. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From rjsparks@nostrum.com Wed Mar 9 13:45:42 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65FC23A6AE0 for ; Wed, 9 Mar 2011 13:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nl8XuiWnDVGo for ; Wed, 9 Mar 2011 13:45:41 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 05B823A6AE3 for ; Wed, 9 Mar 2011 13:45:38 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p29LksQ5039235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Mar 2011 15:46:54 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <4D6C31DC.80005@nostrum.com> Date: Wed, 9 Mar 2011 15:46:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8E762DE9-87F6-4765-9E44-21EF5548662D@nostrum.com> References: <4D6C31DC.80005@nostrum.com> To: SIPCORE Chairs X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "draft-ietf-sipcore-location-conveyance@tools.ietf.org" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: [sipcore] Additional editorial suggestions (was Re: WGLC: draft-ietf-sipcore-location-conveyance) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:45:42 -0000 Hi document editors - Here are a few additional suggestions that are purely editorial that I = think would=20 make the document stronger - please consider them, but its up to you = whether to=20 do anything with them. a) I suggest "your favorite local pizza delivery service" instead of = "Pizza Hut" b) Replace 'The only conceivable way forward, when a second location is = placed into the same SIP request by a SIP intermediary is to take a "you break it, = you bought it" philosophy with respect to the inserting SIP intermediary' with 'This document = takes a "you break it, you bought it" approach to dealing with second locations placed into a SIP request by = an intermediary entity.' c) Delete the parenthetical '(we are not going to discuss any other = reasons in this document, and there are many)'. That's obvious and distracts from the point. d) Replace 'SIP intermediaries are NOT RECOMMENDED to modify existing = locationValue(s), and further not to delete any either' with 'SIP intermediaries SHOULD = NOT modify or remove any existing locationValue(s).' e) Replace the first sentence of the paragraph at the end of page 10 = with 'A Geolocation-Routing header-value that is set to "no" has no special = security properties. It is at most a request for behavior within SIP intermediaries.' f) Replace 'SIP intermediaries MUST NOT add, modify or delete the = location in a 424 response.' with 'SIP intermediaries that are forwarding (as opposed to generating) = a 424 response MUST NOT add, modify, or delete any location appearing in that response.' g) Delete the '- etc...' bullet in the non-exclusive list of reasons for = 1XX in section 4.4 =20 h) Delete 'At this time,' in the paragraph after that list. This = document won''t alter things at any other time either.=20 i) Replace "This was first brought up in section 3.2." with "The end of = section 3.2 discusses how transaction timing considerations lead to this requirement." RjS On Feb 28, 2011, at 5:38 PM, Adam Roach - SIPCORE Chair wrote: > [as chair] >=20 > The current editor of draft-ietf-sipcore-location-conveyance believes = that the document has no remaining technical issues[1], and is ready for = evaluation. Today, we are starting a two-week working group last call = period. This last call period ends on Tuesday, March 15th. >=20 > The latest version of the document can be retrieved here: >=20 > http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance >=20 > Any comments on the document should be sent to the SIPCORE mailing = list. >=20 > /a >=20 > [1] John Elwell's editorial comments of February 25th have been noted = by the authors, and will be treated as WGLC comments. From jmpolk@cisco.com Wed Mar 9 15:52:51 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314FB3A6AF6 for ; Wed, 9 Mar 2011 15:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.584 X-Spam-Level: X-Spam-Status: No, score=-110.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RvQ90s-Bsst for ; Wed, 9 Mar 2011 15:52:50 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 348633A67D9 for ; Wed, 9 Mar 2011 15:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1241; q=dns/txt; s=iport; t=1299714847; x=1300924447; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=tIsoe7l+QEn4RVRcI3NO/mCn49n8lMaqk9LgKamjOvg=; b=FIzGAYEa0f3XDwnjfuKKWTgxY7TaUev3I4pBMb40G30knnJYfUbZiaiK SxKtPJdKFGuuTwIJ6jCQ5zX52tScw7XqfGoGqeMHWxnDWQBI2YW6O65zs Znf+dd3Jdu8d9LcOk2qV3qs6ukEDuKJHjzJIbL500oa3SFl+Gfaa7hCAo 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKqhd02rR7Hu/2dsb2JhbACmcnSmc5w2hWUEhSI X-IronPort-AV: E=Sophos;i="4.62,293,1297036800"; d="scan'208";a="413221608" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 09 Mar 2011 23:54:07 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p29Ns6iE000279; Wed, 9 Mar 2011 23:54:06 GMT Message-Id: <201103092354.p29Ns6iE000279@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 09 Mar 2011 17:54:04 -0600 To: Robert Sparks , SIPCORE Chairs From: "James M. Polk" In-Reply-To: References: <4D6C31DC.80005@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "draft-ietf-sipcore-location-conveyance@tools.ietf.org" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 23:52:51 -0000 Robert sure The only one I know I cannot address is the lack of form feeds per page. My dumb text editor doesn't allow me to insert them. James At 10:24 AM 3/9/2011, Robert Sparks wrote: >James - > >There are some nits that idnits points out - please address those >with the other WGLC comments. > >RjS > >On Feb 28, 2011, at 5:38 PM, Adam Roach - SIPCORE Chair wrote: > > > [as chair] > > > > The current editor of draft-ietf-sipcore-location-conveyance > believes that the document has no remaining technical issues[1], > and is ready for evaluation. Today, we are starting a two-week > working group last call period. This last call period ends on > Tuesday, March 15th. > > > > The latest version of the document can be retrieved here: > > > > http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance > > > > Any comments on the document should be sent to the SIPCORE mailing list. > > > > /a > > > > [1] John Elwell's editorial comments of February 25th have been > noted by the authors, and will be treated as WGLC comments. > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Wed Mar 9 16:19:22 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840B23A6A88 for ; Wed, 9 Mar 2011 16:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.585 X-Spam-Level: X-Spam-Status: No, score=-110.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-nD+VtfPMV8 for ; Wed, 9 Mar 2011 16:19:21 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2B5213A67D9 for ; Wed, 9 Mar 2011 16:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=5986; q=dns/txt; s=iport; t=1299716438; x=1300926038; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=csLCcRQ97zO+MTFSLc1pzd849BOvQT+LYs/zqe1XDpc=; b=c2knTx4tlO659mLFQ8EQ9tfs45R7g4qcCaOfEgJUPzxqThDUjET6oKyf ipOFRyPSCcyr40wxPD9sZvNeXP6QM3VcejcpARvvJ4k5IuBRWks0DEwRk hKt8mFbyf4dj5K1l42xWaKSrzR4ylxMbEB3L55tyzz411B5D3UW78ZJuG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJGnd02rR7Hu/2dsb2JhbACmcnSmd5w6hWUEhSI X-IronPort-AV: E=Sophos;i="4.62,293,1297036800"; d="scan'208";a="413228132" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 10 Mar 2011 00:20:38 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p2A0KbV6024147; Thu, 10 Mar 2011 00:20:37 GMT Message-Id: <201103100020.p2A0KbV6024147@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 09 Mar 2011 18:20:37 -0600 To: Robert Sparks , SIPCORE Chairs From: "James M. Polk" In-Reply-To: References: <4D6C31DC.80005@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-sipcore-location-conveyance@tools.ietf.org, "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 00:19:22 -0000 Robert Thanks for the scrubbing. These will be part of the post WGLC version. James At 02:45 PM 3/9/2011, Robert Sparks wrote: >There are a couple of larger and several small things to also >address in this document before requesting publication. > >The larger things: > >1) In section 4.4, the document talks about providing a text string >"RECOMMENDED for human readability". The document >needs to be clear who this is intended for. Do you expect this to be >rendered to a user or only read by an operator? >(Fortunately quoted-string allows non-ascii UTF-8 already, so we >won't have to argue about whether this needs to be >internationalized.) > >2) The Geolocation-Error ABNF and the IANA registration section use >a parameter name = value form (with a name of "code"). >Following those sections of the document, the examples should all look like >Geolocation-Error: 100;code="Cannot Process Location" >But all the examples currently look like >Geolocation-Error: 100 "Cannot Process Location" > >It's worth pointing out that 3261 (see the top of page 32) doesn't >allow the same parameter name to appear in >a header field value more than once, so the following is not allowed: >Geolocation-Error: 100;code="Cannot Process >Location";code="Impossible de processus de localisation" > >Are the values you are registering for code= suggested defaults >(like for SIP response start lines) or are >they what MUST appear? Is this OK? >Geolocation-Error: 100;code="Have a nice day" >If not, what in the document says so? > >3) I can't figure out what the paragraph in section 4.4 that starts >"Additionally, if a sip entity cannot..." and goes >onto talk about 503's is trying to say. I think some surrounding >context must have been lost or not captured. >Why would we be recommending sending a 503 here? > >4) Section 4.4 defines classes of error codes, and even default >values of error codes, but does not go on to say >that if an element receives an error code it doesn't understand, it >treats it like the default code in that class. >Surely that was the intent (otherwise, having the classes isn't >particularly useful). If it was, the document should >say so. > >--------------------------------------------------------- > >Here are the smaller things. >I've listed these in as close to document order as I could > >1) In 4.1, please call out what document's definition of HCOLON, >COMMA, LAQUOT, RAQUOT and SEMI that you are using. > Either call out that these are used in other places in the doc > (4.2 and 4.4) or similarly call out the terminals used in those > sections (be sure to catch DIGIT and EQUAL in 4.4). > >2) In section 4.1, I suggest replacing >OLD: A Geolocation header field MUST have at least one header-value. >with >NEW: A Geolocation header field MUST have at least on > >3) In 4.2, I suggest replacing >OLD: Values other than "yes" or "no" are permitted as a mechanism >for future extensions, and should be treated the same as "no". >with >NEW: The syntax allows values other than "yes" or "no" to appear to >allow for future extensions. Implementations not aware of an >extension SHOULD treat any other received value the same as "no". > >I also propose that this be MUST instead of SHOULD. > >4) 4.2.1, first paragraph, s/contained in a one or/contained in one >or/ (delete the spurious "a") > >5) I suggest the following replacement for the paragraph in section >4.3 that starts "It is only appropriate" > >It is only appropriate to generate a 424 response when the >responding entity needs a locationValue >and there are no values in the request that are usable by the >responder, or when the responder has >additional location information to provide. The latter case is shown >in Figure 4 of section 3.4. There, >a SIP intermediary is informing the upstream UA which location to >include in the next SIP request. > >6) In 4.4 was "any SIP non-100 response" intended to mean > a) any SIP response, including provisional responses other than 100 Trying > or > b) only SIP Final responses > ? > >7) Section 8.1 claims two actions for IANA, but provides only one. > >8) In section 8.5 step 2, please just say "Yes" under predefined >values instead of "yes*", and >delete the footnote. Section 8.6 is the next section and is easy to >find, and it will save >IANA having to ask if you are trying to put a * in the table in the registry. > >9) A.2 UAS-1 will cause confusion. We are allowing locations to >appear in responses, just not > the location of the responder. Please adjust it to avoid that > potential confusion. > > As an individual contributor, I don't think these appendices > add enough value to the document > to warrant the confusion they may cause and would be happier if > they were deleted. > > >On Feb 28, 2011, at 5:38 PM, Adam Roach - SIPCORE Chair wrote: > > > [as chair] > > > > The current editor of draft-ietf-sipcore-location-conveyance > believes that the document has no remaining technical issues[1], > and is ready for evaluation. Today, we are starting a two-week > working group last call period. This last call period ends on > Tuesday, March 15th. > > > > The latest version of the document can be retrieved here: > > > > http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance > > > > Any comments on the document should be sent to the SIPCORE mailing list. > > > > /a > > > > [1] John Elwell's editorial comments of February 25th have been > noted by the authors, and will be treated as WGLC comments. > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Wed Mar 9 16:19:58 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34213A6A88 for ; Wed, 9 Mar 2011 16:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.586 X-Spam-Level: X-Spam-Status: No, score=-110.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XkxTJJpLgCI for ; Wed, 9 Mar 2011 16:19:57 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D8BF83A67D9 for ; Wed, 9 Mar 2011 16:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2967; q=dns/txt; s=iport; t=1299716475; x=1300926075; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=uL8y3zwOfA852+dLz6oA2rHt/TSGHSKDEb2jKjJCbUQ=; b=GFXSiH66ZzOQr9Vs+8WHJdeBQDoyA/QxYyqoBm1J9+bWQ06dr2FFrUWc PxjBqrbbls7mC9seevnNW7cM1ZFvwGm4ywA+QRoDsv5MajmxIFxqu746w F9WelSTdQ6Y0gywXHjSLQHEZFzg+HdM3zgsl+CKRMiHf5Fuzmd507dRYC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALOod02rR7H+/2dsb2JhbACmcnSnE5w6hWUEhSI X-IronPort-AV: E=Sophos;i="4.62,293,1297036800"; d="scan'208";a="413228295" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 10 Mar 2011 00:21:10 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p2A0L9Z7005051; Thu, 10 Mar 2011 00:21:10 GMT Message-Id: <201103100021.p2A0L9Z7005051@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 09 Mar 2011 18:21:09 -0600 To: Robert Sparks , SIPCORE Chairs From: "James M. Polk" In-Reply-To: <8E762DE9-87F6-4765-9E44-21EF5548662D@nostrum.com> References: <4D6C31DC.80005@nostrum.com> <8E762DE9-87F6-4765-9E44-21EF5548662D@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "draft-ietf-sipcore-location-conveyance@tools.ietf.org" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Additional editorial suggestions (was Re: WGLC: draft-ietf-sipcore-location-conveyance) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 00:19:58 -0000 Robert Thanks for the additional scrubbing. These will also be part of the post WGLC version. James At 03:46 PM 3/9/2011, Robert Sparks wrote: >Hi document editors - > >Here are a few additional suggestions that are purely editorial that >I think would >make the document stronger - please consider them, but its up to you >whether to >do anything with them. > >a) I suggest "your favorite local pizza delivery service" instead of >"Pizza Hut" > >b) Replace 'The only conceivable way forward, when a second location >is placed into >the same SIP request by a SIP intermediary is to take a "you break >it, you bought it" philosophy >with respect to the inserting SIP intermediary' with 'This document >takes a "you break it, you bought it" >approach to dealing with second locations placed into a SIP request >by an intermediary entity.' > >c) Delete the parenthetical '(we are not going to discuss any other >reasons in this document, and >there are many)'. That's obvious and distracts from the point. > >d) Replace 'SIP intermediaries are NOT RECOMMENDED to modify >existing locationValue(s), >and further not to delete any either' with 'SIP intermediaries >SHOULD NOT modify or remove any >existing locationValue(s).' > >e) Replace the first sentence of the paragraph at the end of page 10 with >'A Geolocation-Routing header-value that is set to "no" has no >special security properties. It is >at most a request for behavior within SIP intermediaries.' > >f) Replace 'SIP intermediaries MUST NOT add, modify or delete the >location in a 424 response.' >with 'SIP intermediaries that are forwarding (as opposed to >generating) a 424 response MUST >NOT add, modify, or delete any location appearing in that response.' > >g) Delete the '- etc...' bullet in the non-exclusive list of reasons >for 1XX in section 4.4 > >h) Delete 'At this time,' in the paragraph after that list. This >document won''t alter things at >any other time either. > >i) Replace "This was first brought up in section 3.2." with "The end >of section 3.2 discusses >how transaction timing considerations lead to this requirement." > > >RjS > > > >On Feb 28, 2011, at 5:38 PM, Adam Roach - SIPCORE Chair wrote: > > > [as chair] > > > > The current editor of draft-ietf-sipcore-location-conveyance > believes that the document has no remaining technical issues[1], > and is ready for evaluation. Today, we are starting a two-week > working group last call period. This last call period ends on > Tuesday, March 15th. > > > > The latest version of the document can be retrieved here: > > > > http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance > > > > Any comments on the document should be sent to the SIPCORE mailing list. > > > > /a > > > > [1] John Elwell's editorial comments of February 25th have been > noted by the authors, and will be treated as WGLC comments. From pkyzivat@cisco.com Wed Mar 9 16:25:10 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B203A6AFE for ; Wed, 9 Mar 2011 16:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.538 X-Spam-Level: X-Spam-Status: No, score=-110.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u13tX2tGxmJN for ; Wed, 9 Mar 2011 16:25:09 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 185D13A6AF6 for ; Wed, 9 Mar 2011 16:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2918; q=dns/txt; s=iport; t=1299716786; x=1300926386; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=E0nPGy56YdJW21olFnDlXAxqgTrrlMlAlQWE4kN5B0I=; b=nDBF25vK9fDZZzhubMIoU+sVsvxfgDRyW2nCYprx4fLliTzCsGZPXS5b 8NGxIpJ2W5dwQu7HSDG4X5gzZt39C33P4SJ39yqxDoQGGZNOvAq1ndVtc 7fwS5tMtfTQIZEfWVkq4twXNBZNYPxHaG5yvtbkZ1hxYszxwi+4wR8rpS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGapd01AZnwN/2dsb2JhbACmcnSnAJw7hWUEhSKHGINI X-IronPort-AV: E=Sophos;i="4.62,293,1297036800"; d="scan'208";a="223760975" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2011 00:26:25 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p2A0QP1X021198; Thu, 10 Mar 2011 00:26:25 GMT Message-ID: <4D781AB1.8060605@cisco.com> Date: Wed, 09 Mar 2011 19:26:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Robert Sparks References: <4D6C31DC.80005@nostrum.com> <8E762DE9-87F6-4765-9E44-21EF5548662D@nostrum.com> In-Reply-To: <8E762DE9-87F6-4765-9E44-21EF5548662D@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-sipcore-location-conveyance@tools.ietf.org" , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Additional editorial suggestions (was Re: WGLC: draft-ietf-sipcore-location-conveyance) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 00:25:10 -0000 Robert, Thanks for the very thorough review. I agreed with everything you brought up. Thanks, Paul On 3/9/2011 4:46 PM, Robert Sparks wrote: > Hi document editors - > > Here are a few additional suggestions that are purely editorial that I think would > make the document stronger - please consider them, but its up to you whether to > do anything with them. > > a) I suggest "your favorite local pizza delivery service" instead of "Pizza Hut" > > b) Replace 'The only conceivable way forward, when a second location is placed into > the same SIP request by a SIP intermediary is to take a "you break it, you bought it" philosophy > with respect to the inserting SIP intermediary' with 'This document takes a "you break it, you bought it" > approach to dealing with second locations placed into a SIP request by an intermediary entity.' > > c) Delete the parenthetical '(we are not going to discuss any other reasons in this document, and > there are many)'. That's obvious and distracts from the point. > > d) Replace 'SIP intermediaries are NOT RECOMMENDED to modify existing locationValue(s), > and further not to delete any either' with 'SIP intermediaries SHOULD NOT modify or remove any > existing locationValue(s).' > > e) Replace the first sentence of the paragraph at the end of page 10 with > 'A Geolocation-Routing header-value that is set to "no" has no special security properties. It is > at most a request for behavior within SIP intermediaries.' > > f) Replace 'SIP intermediaries MUST NOT add, modify or delete the location in a 424 response.' > with 'SIP intermediaries that are forwarding (as opposed to generating) a 424 response MUST > NOT add, modify, or delete any location appearing in that response.' > > g) Delete the '- etc...' bullet in the non-exclusive list of reasons for 1XX in section 4.4 > > h) Delete 'At this time,' in the paragraph after that list. This document won''t alter things at > any other time either. > > i) Replace "This was first brought up in section 3.2." with "The end of section 3.2 discusses > how transaction timing considerations lead to this requirement." > > > RjS > > > > On Feb 28, 2011, at 5:38 PM, Adam Roach - SIPCORE Chair wrote: > >> [as chair] >> >> The current editor of draft-ietf-sipcore-location-conveyance believes that the document has no remaining technical issues[1], and is ready for evaluation. Today, we are starting a two-week working group last call period. This last call period ends on Tuesday, March 15th. >> >> The latest version of the document can be retrieved here: >> >> http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance >> >> Any comments on the document should be sent to the SIPCORE mailing list. >> >> /a >> >> [1] John Elwell's editorial comments of February 25th have been noted by the authors, and will be treated as WGLC comments. > > From rjsparks@nostrum.com Wed Mar 9 19:47:33 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161E23A67F7 for ; Wed, 9 Mar 2011 19:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3drM5WOhTeSH for ; Wed, 9 Mar 2011 19:47:32 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id BB1AE3A67D6 for ; Wed, 9 Mar 2011 19:47:31 -0800 (PST) Received: from [192.168.2.105] (pool-173-57-105-99.dllstx.fios.verizon.net [173.57.105.99]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p2A3mknI071051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Mar 2011 21:48:46 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <201103100020.p2A0KbV6024147@sj-core-5.cisco.com> Date: Wed, 9 Mar 2011 21:48:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <82D5D06C-07BE-495B-90E4-A51E8C7CB438@nostrum.com> References: <4D6C31DC.80005@nostrum.com> <201103100020.p2A0KbV6024147@sj-core-5.cisco.com> To: "James M. Polk" X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 173.57.105.99 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-location-conveyance@tools.ietf.org, "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 03:47:33 -0000 Hi James - I spotted one thing below that got mangled before I sent it - here's the = correction: On Mar 9, 2011, at 6:20 PM, James M. Polk wrote: > Robert >=20 > Thanks for the scrubbing. >=20 > These will be part of the post WGLC version. >=20 > James >=20 > At 02:45 PM 3/9/2011, Robert Sparks wrote: >> There are a couple of larger and several small things to also address = in this document before requesting publication. >>=20 >> The larger things: >>=20 >> Here are the smaller things. >> I've listed these in as close to document order as I could >>=20 >> 2) In section 4.1, I suggest replacing >> OLD: A Geolocation header field MUST have at least one header-value. >> with >> NEW: A Geolocation header field MUST have at least on >>=20 That got truncated somehow before I sent it. It should have said: NEW: A Geolocation header field MUST have at least one locationValue. RjS From jmpolk@cisco.com Wed Mar 9 22:08:27 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48BAF3A693B for ; Wed, 9 Mar 2011 22:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7fZXKZDL9HM for ; Wed, 9 Mar 2011 22:08:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3858E3A6934 for ; Wed, 9 Mar 2011 22:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1172; q=dns/txt; s=iport; t=1299737383; x=1300946983; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=hV4wytkejkLlYHk5Ay+b+AH5VVH3rmhRZFkIU7nweHA=; b=dZAgS2Nsf/8D/63gA0ukNrmR/DXsR24acZOKnikgpjOffW5JfSjedFfZ iwvgBacR/f7NBky6XXXpMXERuza+JjiB5KqgLWYArm0xvXFRYmxzlOln0 8HKRfXSUGU3XOGZ8pWhbH5vkLkQt03B5+uMNGDnOFC/fqey8GJo7OULMU 4=; X-IronPort-AV: E=Sophos;i="4.62,294,1297036800"; d="scan'208";a="273679258" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 10 Mar 2011 06:09:43 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p2A69gtV007096; Thu, 10 Mar 2011 06:09:43 GMT Message-Id: <201103100609.p2A69gtV007096@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Mar 2011 00:09:40 -0600 To: Robert Sparks , "James M. Polk" From: "James M. Polk" In-Reply-To: <82D5D06C-07BE-495B-90E4-A51E8C7CB438@nostrum.com> References: <4D6C31DC.80005@nostrum.com> <201103100020.p2A0KbV6024147@sj-core-5.cisco.com> <82D5D06C-07BE-495B-90E4-A51E8C7CB438@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-sipcore-location-conveyance@tools.ietf.org, "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 06:08:27 -0000 At 09:48 PM 3/9/2011, Robert Sparks wrote: >Hi James - > >I spotted one thing below that got mangled before I sent it I saw that when I glanced initially. I figured I'd ask about it once I dove into the edit. Thanks for correcting before I got into it. James >- here's the correction: > >On Mar 9, 2011, at 6:20 PM, James M. Polk wrote: > > > Robert > > > > Thanks for the scrubbing. > > > > These will be part of the post WGLC version. > > > > James > > > > At 02:45 PM 3/9/2011, Robert Sparks wrote: > >> There are a couple of larger and several small things to also > address in this document before requesting publication. > >> > >> The larger things: > > >> > >> Here are the smaller things. > >> I've listed these in as close to document order as I could > > >> > >> 2) In section 4.1, I suggest replacing > >> OLD: A Geolocation header field MUST have at least one header-value. > >> with > >> NEW: A Geolocation header field MUST have at least on > >> > >That got truncated somehow before I sent it. It should have said: > >NEW: A Geolocation header field MUST have at least one locationValue. > >RjS From john.elwell@siemens-enterprise.com Thu Mar 10 07:59:55 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6995C3A6B2B for ; Thu, 10 Mar 2011 07:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMqFP6W1s1WI for ; Thu, 10 Mar 2011 07:59:53 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 549BE3A6B2C for ; Thu, 10 Mar 2011 07:59:53 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3704531; Thu, 10 Mar 2011 17:01:10 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id F2E3323F0296; Thu, 10 Mar 2011 17:01:09 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 10 Mar 2011 17:01:09 +0100 From: "Elwell, John" To: "marianne.mohali@orange-ftgroup.com" , "pkyzivat@cisco.com" Date: Thu, 10 Mar 2011 17:01:07 +0100 Thread-Topic: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvcYISb0u1jdMeySTaPExDFDWj03gAgAOHgAJZ9baA= Message-ID: References: <4D6C2CB6.4040800@cisco.com> <4D6FD03A.8040507@cisco.com> <4D7429E9.5070607@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 15:59:55 -0000 I have already commented that this sort of usage of H-I is appropriate only= for closed networks. In addition to that, what I seem to be hearing is that the UAS needs to loo= k at H-I to determine how the request arrived, and in particular whether it= arrived because of retargeting due to premium rate (for example). Am I cor= rect so far? The whole concept behind 4244bis is that the UAS, in order to discover how = a request arrived, scans back through the hi-entries looking at the paramet= ers. So far we have two such parameters: "rc" and "mp". Marianne seems to b= e asserting that these two parameters are insufficient, and that other info= rmation in the hi-entries needs to be viewed in order to determine that ret= argeting due to premium rate (for example) took place. However, the propose= d solution is to add this in the "headers" component of the URI concerned, = rather than add a new hi-entry parameter. So the UAS, in order to analyse t= he history of the request, now has to scan for both hi-entry parameters AND= URI headers. I don't understand why hi-entry parameters are not proposed f= or such applications. Having said that, we had a longgggg discussion trying= to hammer out the set of hi-entry parameters that we really needed, and th= e final consensus was just to have "rc" and "mp". I would not want to open = up that discussion again, but on the other hand using a different mechanis= m for solving a similar problem seems inappropriate. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > marianne.mohali@orange-ftgroup.com > Sent: 07 March 2011 18:30 > To: pkyzivat@cisco.com > Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com > Subject: Re: [sipcore] I-DAction:=20 > draft-mohali-sipcore-reason-extension-application-01 >=20 > Paul, >=20 > I think that Christer's draft (proxy-feature) is about=20 > capabilities while this one (reason-extension-application) is=20 > about what really happened (like reason in general). It is=20 > provided only when the event happens and the purpose is to=20 > give an accuate information for applicative events.=20 >=20 > Let me give you an other example: > A reception AS called with several premium rate numbers (1=20 > per hosted application/service). The AS dispatches calls to=20 > several call centers (eg. Depending on charge, hour of the=20 > day/night...). The final destination needs to know the called=20 > service. The premuim rate number should be listed in the H-I=20 > header. Which entry? For which application/service invocated?=20 > As you can have a call forwarding reason associated to a 3xx=20 > or 486 Reason-cause, you could have an applicative reason to=20 > easily identify the premium rate dialed number. >=20 > Regards, > Marianne >=20 >=20 > > -----Message d'origine----- > > De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > > Envoy=E9 : lundi 7 mars 2011 01:42 > > =C0 : MOHALI Marianne RD-CORE-ISS > > Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com > > Objet : Re: [sipcore] I-DAction:=20 > > draft-mohali-sipcore-reason-extension-application-01 > >=20 > > Marianne=20 > >=20 > > On 3/4/2011 11:59 AM, marianne.mohali@orange-ftgroup.com wrote: > > > Hi Paul, > > > > > > My answer below [MM] > > > > > > Marianne > > >> -----Message d'origine----- > > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 :=20 > > jeudi 3 mars=20 > > >> 2011 18:31 =C0 : MOHALI Marianne RD-CORE-ISS Cc :=20 > sipcore@ietf.org;=20 > > >> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] I-DAction: > > >> draft-mohali-sipcore-reason-extension-application-01 > > >> > > >> Marianne, > > >> > > >> On 3/3/2011 11:51 AM, marianne.mohali@orange-ftgroup.com wrote: > > >>> Hi Paul, > > >>> > > >>> The purpose is to allow applications/services to be > > >> explicitely identified in the signaling path, so that others=20 > > >> services/applications/telephony-AS can act accordingly. > > >> Either to apply a process taking into account the service=20 > > interaction=20 > > >> or on the contrary, do not execute a feature already=20 > > covered by the=20 > > >> application. > > >>> For instance, a caller with a prepaid service calls a > > >> directory enquiries Server to ask for a restaurant phone=20 > > number. The=20 > > >> operator would suggest to connect the caller to the=20 > > researched phone=20 > > >> number EXCEPT if the caller has a prepaid service because=20 > > it is not=20 > > >> sure he has enough credit to pay for the communication. To=20 > > allow this=20 > > >> customized feature, the directory enquiries Application=20 > > needs to know=20 > > >> that the prepaid Application has been invocated. > > >> > > >> So once again, we are back to your wanting to use Reason not to=20 > > >> express a "reason" for anything, but rather as just a=20 > hook to hang=20 > > >> something on H-I. > > > [MM] The *reason* why the call has been=20 > > retargeted/rejected/modified is the invocation of a specific=20 > > application. > > > If you call a Service number and then the URI is changed=20 > > for routing to the real destination, the *reason* of the URI=20 > > modification (listed in H-I) is the application. > >=20 > > Based on your other replies, this is not necessarily so. > >=20 > > In fact the example above is a counter-example. > > The prepaid service is not responsible for any redirection,=20 > > and the operator service is looking for it for a reason other=20 > > than that it has been the cause of anything. Its looking for=20 > > it because it might be the cause of something in the future. > >=20 > > >> (With the causes you have defined, I can't imagine it making > > >> *any* sense to actually use one in a Reason header in a message,=20 > > >> because they aren't specific enough to be actionable.) > > >> > > >> I am now thinking there is a large overlap between what you are=20 > > >> trying to accomplish this way, and what Christer is trying to=20 > > >> accomplish with draft-holmberg-sipcore-proxy-feature. > > >> > > >> Is that true? > > >> > > >> (Christer: What do you think?) > > > [MM] I don't see the overlap with Christer's draft because=20 > > it is not about capabilities, it is about what's happened. > >=20 > > In your example above, it seems that the operator service is=20 > > looking for the prepaid service because the prepaid service=20 > > has the capability to influence billing, or something like=20 > > that. This seems at least somewhat in line with what Christer=20 > > is advocating. Looking in the Route header, or Record-Route=20 > > header would make at least as much sense for this case as=20 > > looking in H-I. H-I makes sense if you are indeed looking for=20 > > something that has already happened, perhaps on a path other=20 > > that the current one. > >=20 > > I think it would be helpful for the two of you to come to=20 > > some reconciliation of what you are trying to accomplish. > >=20 > > Thanks, > > Paul > >=20 > > >>> About your comment in case of several applications involved > > >> *simultaneously* in the call establishment, it is possible=20 > > to add 1=20 > > >> more hi-entry for the second application Cause you want to be=20 > > >> identified in the signaling path. > > >> > > >> Sure, you can indicate that they are "involved". But you=20 > > can't infer=20 > > >> anything about which one "caused" something. They might=20 > > have, but you=20 > > >> can't tell it from the presence of these headers. > > >> > > >> Thanks, > > >> Paul > > >> > > >>> Regards, > > >>> Marianne > > >>> > > >>> > > >>>> -----Message d'origine----- > > >>>> De : sipcore-bounces@ietf.org > > >>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul > > >> Kyzivat Envoy=E9 : > > >>>> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org Objet : Re:=20 > > [sipcore] > > >>>> I-DAction: > > >>>> draft-mohali-sipcore-reason-extension-application-01 > > >>>> > > >>>> (As individual) > > >>>> > > >>>> Marianne, > > >>>> > > >>>> I'm still struggling to make sense of this in the form=20 > proposed. > > >>>> > > >>>> I look at the various cause values, and all the > > >> descriptions are of > > >>>> the form. E.g.: > > >>>> > > >>>> Cause value: 2 > > >>>> Reason text: Freephone > > >>>> Description: A Freephone application has influenced=20 > > >>>> processing of > > >>>> the call (e.g. by translating a dialed Free Phone > > >> number to a > > >>>> routable directory number). > > >>>> > > >>>> I can't figure out how to make any actionable decision > > >> based on this. > > >>>> Rather, it seems I need to make a number of leaps of faith > > >> before I > > >>>> can decide what to do. > > >>>> > > >>>> For instance, if I get an error, it *might* be because I=20 > > dialed a=20 > > >>>> freephone number, and it isn't supported from my calling=20 > > location. > > >>>> (E.g. > > >>>> maybe I'm dialing +1-800-555-1234, but I'm doing so from > > >> France, and > > >>>> calling that number is only supported in the USA. > > >>>> > > >>>> But getting a application reason code with cause 2=20 > > doesn't really=20 > > >>>> tell me that is what happened. It could be that the call > > >> indeed was > > >>>> routed through a freephone application, and it properly=20 > > routed the=20 > > >>>> call, and the call failed for some other reason. But the=20 > > cause is=20 > > >>>> there because the application > > >>>> *did* influence the call routing. > > >>>> > > >>>> Also, these "applications" are not, AFAIK, mutually > > >> exclusive. E.g. I > > >>>> could be using a prepaid service to make a directory > > >> assistance call > > >>>> that costs extra $$$ that I don't have credits to=20 > cover. But you=20 > > >>>> can't include two cause values for the same protocol. (But > > >> it is true > > >>>> that you > > >>>> *can* have a number of servers each put one cause into > > >>>> *their* H-I entry.) > > >>>> > > >>>> So *maybe* I would see that my call failed, and that there > > >> is both a > > >>>> reason indicating a prepaid application on one H-I entry, > > >> and another > > >>>> indicating a another H-I indicating a directory service > > >> application. > > >>>> But what can I conclude from that? > > >>>> > > >>>> Bottom line, I just can't make sense how this could be > > >> used in a well > > >>>> defined and interoperable way. > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>>> > > >>>> On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: > > >>>>> Hello, > > >>>>> > > >>>>> Here is the new version of the draft. > > >>>>> Main changes are following: > > >>>>> - More details about the registration procedure for new values > > >>>>> - Clearer text in section 3.2 > > >>>>> - Add of Public and Private status for registered values. > > >>>>> - Add of a range for cause values registration > > >>>>> > > >>>>> Best Regards, > > >>>>> Marianne Mohali > > >>>>> > > >>>>> -----Message d'origine----- > > >>>>> Objet : New Version Notification for > > >>>>> draft-mohali-sipcore-reason-extension-application-01 > > >>>>> > > >>>>> A New Internet-Draft is available from the on-line > > >> Internet-Drafts > > >>>>> directories. > > >>>>> > > >>>>> Title : Extending the Session=20 > > Initiation Protocol > > >>>>> (SIP) Reason Header for Applications > > >>>>> Author(s) : M. Mohali, B. Chatras > > >>>>> Filename : > > >>>>> draft-mohali-sipcore-reason-extension-application-01.txt > > >>>>> Pages : 10 > > >>>>> Date : 2011-02-24 > > >>>>> > > >>>>> This document defines a new protocol value=20 > > "Application" for the=20 > > >>>>> Reason Header field and a new IANA Registry for registering=20 > > >>>>> application types. This new value enables signaling that a > > >>>> request or > > >>>>> response has been issued as a result of a decision made by a=20 > > >>>>> particular type of application or that an initial request > > >> has been > > >>>>> retargeted as a result of an application decision. > > >>>>> > > >>>>> A URL for this Internet-Draft is: > > >>>>> > > >>>> > > >>=20 > >=20 > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten > > >>>> s > > >>>>> io > > >>>>> n-application-01.txt > > >>>>> > > >>>>> Internet-Drafts are also available by anonymous FTP at: > > >>>>> ftp://ftp.ietf.org/internet-drafts/ > > >>>>> > > >>>>> Below is the data which will enable a MIME compliant=20 > > mail reader=20 > > >>>>> implementation to automatically retrieve the ASCII=20 > > version of the=20 > > >>>>> Internet-Draft. > > >>>>> > > >>>>> > > >>>> > > >>=20 > >=20 > > >>>> s > > >>>>> io > > >>>>> n-application-01.txt> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> I-D-Announce mailing list > > >>>>> I-D-Announce@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > > >>>>> Internet-Draft directories:=20 > http://www.ietf.org/shadow.html or=20 > > >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >>>>> _______________________________________________ > > >>>>> sipcore mailing list > > >>>>> sipcore@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > > >>>>> > > >>>> _______________________________________________ > > >>>> sipcore mailing list > > >>>> sipcore@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/sipcore > > >>>> > > >>> > > >> > > > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From Internet-Drafts@ietf.org Tue Mar 15 11:30:02 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647EF3A6E51; Tue, 15 Mar 2011 11:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfxyDmsydHUX; Tue, 15 Mar 2011 11:30:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2353A6E58; Tue, 15 Mar 2011 11:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110315183001.24369.74903.idtracker@localhost> Date: Tue, 15 Mar 2011 11:30:01 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 18:30:02 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, et al Filename : draft-ietf-sipcore-rfc4244bis-04.txt Pages : 32 Date : 2011-03-15 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this document defines a value for the Privacy header field specific to the History- Info header field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-rfc4244bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-15112948.I-D@ietf.org> --NextPart-- From mary.ietf.barnes@gmail.com Tue Mar 15 11:44:55 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63BF63A6E53 for ; Tue, 15 Mar 2011 11:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.396 X-Spam-Level: X-Spam-Status: No, score=-103.396 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sukWgEivJQBF for ; Tue, 15 Mar 2011 11:44:54 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 0D8A53A6B10 for ; Tue, 15 Mar 2011 11:44:53 -0700 (PDT) Received: by vws12 with SMTP id 12so1013829vws.31 for ; Tue, 15 Mar 2011 11:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=9kykIrsDJLblfVfUU2AVMZedRMbNfd2wHzBiAh9fm5E=; b=f77xw2/e0MUE6ZfIBlEH5fRcyz9dg/w8RzePTNxRRsV0rO7B3zWGHbct8grTj4ty4g SsMRH0JIzCr3a7mKKHSV4cTIoPvEIbWrOvfOOJlHIQMJ8FMJQnzU1oKZwhcTNBQDXGbV rLUXnuVBmy/bjVZmkG5euRiMR+YblyQPItLJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=rEuIn2gtLlOQrAZJ5L5UQLzW5syCCf6W9jzWhiGAmbc4fSMxZmWsxcUKgHqkER/6EY IFXemGIlzLjeXavTNnrK2nqP+iYFFXtMt+BOrH8c2QFieH1g/IpMBOp/BiQnV5A4YA+L g9MnZCQR/ZwaN8gRuq4zwwjoozTLvCncTNZ70= MIME-Version: 1.0 Received: by 10.52.180.166 with SMTP id dp6mr8475160vdc.63.1300214778445; Tue, 15 Mar 2011 11:46:18 -0700 (PDT) Received: by 10.52.167.137 with HTTP; Tue, 15 Mar 2011 11:46:18 -0700 (PDT) In-Reply-To: <20110315183001.24369.74903.idtracker@localhost> References: <20110315183001.24369.74903.idtracker@localhost> Date: Tue, 15 Mar 2011 13:46:18 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: multipart/alternative; boundary=bcaec51a83ee003f54049e89d8a3 Subject: [sipcore] Fwd: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 18:44:55 -0000 --bcaec51a83ee003f54049e89d8a3 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I have updated the document to incorporate the feedback on the -03 as follows: 1) The biggest change was the reformating inline with John's suggestion: http://www.ietf.org/mail-archive/web/sipcore/current/msg04010.html It is not verbatim, but rather I included some of the past text in the relevant sections and I included a bullet list in some cases rather than just a paragraph as that was one of the formatting changes we made between RFC4244 and 4244bis in that the text in paragraph form can be rather dense. I believe the spirit and intent of John's proposal has been accomodated (I don't know that as many words were saved). Also, I just noticed some of the bullet lists don't have the "o" - I'll have to fix that. I think one of the most important aspects of John's proposal was introducing the "caching" of the hi-entries as that wasn't clearly spelled out previously and that really did help to clarify the processing. I do think the breakdown in the sending/receiving of the request and sending/receiving of a response into common processing is quite helpful. 2) Removed the term "escape" with regards to the Privacy and Reason header fields and just stated that those header fields were included in the hi-targeted-to-uri. I think this also improves readbility. 3) Additional clarification around the Tel-URI. I think the doc should be ready for another WGLC. Thanks, Mary. ---------- Forwarded message ---------- From: Date: Tue, Mar 15, 2011 at 1:30 PM Subject: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt To: i-d-announce@ietf.org Cc: sipcore@ietf.org A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, et al Filename : draft-ietf-sipcore-rfc4244bis-04.txt Pages : 32 Date : 2011-03-15 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this document defines a value for the Privacy header field specific to the History- Info header field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --bcaec51a83ee003f54049e89d8a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

I have updated the document to incorporate the= feedback on the -03 as follows:

1) The biggest ch= ange was the reformating =A0inline with John's suggestion:
http://www.ietf.org/mail-archive/web/sipcore/current/msg04010.html
It is not verbatim, but rather I included some of the past text in the= relevant sections and I included a bullet list in some cases rather than j= ust a paragraph as that was one of the formatting changes we made between R= FC4244 and 4244bis in that the text in paragraph form can be rather dense. = =A0I believe the spirit and intent of John's proposal has been accomoda= ted (I don't know that as many words were saved). Also, I just noticed = some of the bullet lists don't have the "o" - I'll have t= o fix that. =A0I think one of the most important aspects of John's prop= osal was introducing the "caching" of the hi-entries as that wasn= 't clearly spelled out previously and that really did help to clarify t= he processing. =A0I do think the breakdown in the sending/receiving of the = request and sending/receiving of a response into common processing is quite= helpful.=A0

2) Removed the term "escape" with regards to = the Privacy and Reason header fields and just stated that those header fiel= ds were included in the hi-targeted-to-uri. =A0I think this also improves r= eadbility. =A0

3) Additional clarification around the Tel-URI.

I think the doc should be ready for another WGLC.=A0

Thanks,
Mary.=A0

---------- Forwarded message ----------
From: <= Internet-Drafts@ietf.org>
Date: Tue, Mar 15, 2011 at 1:30 = PM
Subject: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt
To: i-d-announce@ietf.org
Cc: sipcore@ietf.org


A new Internet-Draf= t is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core Working G= roup of the IETF.

=A0 =A0Title =A0 =A0 =A0 =A0 : An Extension to the Session Initiation Prot= ocol (SIP) for Request History Information
=A0 =A0Author(s) =A0 =A0 : M. Barnes, et al
=A0 =A0Filename =A0 =A0 =A0: draft-ietf-sipcore-rfc4244bis-04.txt
=A0 =A0Pages =A0 =A0 =A0 =A0 : 32
=A0 =A0Date =A0 =A0 =A0 =A0 =A0: 2011-03-15

=A0 This document defines a standard mechanism for capturing the history =A0 information associated with a Session Initiation Protocol (SIP)
=A0 request. =A0This capability enables many enhanced services by providin= g
=A0 the information as to how and why a SIP request arrives at a specific<= br> =A0 application or user. =A0This document defines an optional SIP header =A0 field, History-Info, for capturing the history information in
=A0 requests. =A0The document also defines SIP header field parameters for=
=A0 the History-Info and Contact header fields to tag the method by which<= br> =A0 the target of a request is determined. =A0In addition, this document =A0 defines a value for the Privacy header field specific to the History-<= br> =A0 Info header field.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-= sipcore-rfc4244bis-04.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--bcaec51a83ee003f54049e89d8a3-- From john.elwell@siemens-enterprise.com Wed Mar 16 14:42:50 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F973A69DF for ; Wed, 16 Mar 2011 14:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td0z548DkHga for ; Wed, 16 Mar 2011 14:42:48 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C478B3A69A0 for ; Wed, 16 Mar 2011 14:42:47 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3771630; Wed, 16 Mar 2011 22:44:14 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 0AA9023F0278; Wed, 16 Mar 2011 22:44:14 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 16 Mar 2011 22:44:14 +0100 From: "Elwell, John" To: Mary Barnes , SIPCORE Date: Wed, 16 Mar 2011 22:44:12 +0100 Thread-Topic: [sipcore] Fwd: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt Thread-Index: AcvjQX1pxRr9/1s3T/+Yjm3Cb5ZnnwA22Qog Message-ID: References: <20110315183001.24369.74903.idtracker@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Fwd: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 21:42:50 -0000 Mary, Thanks for adopting the principles I proposed. Although I agree with much o= f the minor rewording you carried out, I do have some issues as follows. Al= so I still need to comment on other parts of the document - these comments = apply to sections 6 to 9 only. 1. Section 6: "forward hi-entries received in requests at the UAS to the request=20 being forwarded by the UAC" Change "the request" to "requests". 2. Section 6: "carrying forward responses=20 received" Change to "carrying forward hi-entries in responses received" 3. Section 6.1: "The UAC MUST include the "histinfo" option tag in the Supported header" Change "header" to "header field". 4. Section 6.1: "Note that in the case of an initial request , there is no cache of hi- entries with which to populate the History-info header field..." We should also observe that when a UAC is part of a B2BUA, the cache might = not be empty (I failed to cover this in my proposed text). I suggest: "Note that in the case of an initial request, except where the UAC is part = of a B2BUA, there is no cache of hi- entries with which to populate the History-info header field..." 5. Section 6.1: "as described in and the hi-index is set to 1 per Section 10.3." The words "as described in" should be deleted. 6. Section 7: In my opinion it would be more logical to list the 4 cases in= order of the sections they reference (9.1, 9.2, 9.3, 9.4), as I proposed. 7. Section 7: "For each outgoing request relating to a target in the target set, the intermediary MUST add an hi-entry for the specific target, per the procedures in Section 9.2." This is wrong. ALL the procedures of 9.2 apply, not just the one about addi= ng an hi-entry for the specific target. Just say "...MUST follow the proced= ures of Section 9.2" - don't try to repeat things from the referenced secti= on. 8. Section 7: "for for" 9. Section 7: "An intermediary MUST follow the procedures of Section 9.3 when a SIP response containing hi-entries is received." The procedures of 9.3 cover ALL SIP responses, whether or not they contain = hi-entries. For example, if the UAS does not support H-I, it will not send= back any hi-entries, but the procedures of 9.3 still apply to the intermed= iary that receives such a response. Delete "containing hi-entries" 10. Section 9: "This section describes the procedures for SIP entities for the handling of SIP requests and responses containing the History-Info header fields." I think it would be better to say "This section describes the procedures for SIP entities for the handling of= the History-Info header field in SIP requests and responses". My reasoning is that not all received requests and responses contain the he= ader field, but there are still procedures that apply to such requests and = responses, perhaps leading to the inclusion of the header field in forwarde= d requests/responses. So saying "SIP requests and responses containing the = History-Info header fields" doesn't seem quite right. 11. "9.1. Receiving a Request with History-Info " Delete "with History-Info". The procedures cover all requests, even if rece= ived with no H-I. 12. Section 9.1: "The SIP entity MUST set the hi-index parameter to a value of "1" , as described in Section 10.3." Delete 'to a value of "1"'. This is not always true, if there are hi-entrie= s from upstream entities, but the hi-entry from the last entity is missing = and needs to be added. 13. Section 9.2: "MUST add a new hi-entry to the outgoing request" Just to be clear, it might be worth saying: "MUST add a new hi-entry to the outgoing request (but not the cache)" 14. Section 9.2: "populating the header field as follows:" I think this should say: "populating the hi-entry as follows:" 15. Section 9.2: "The SIP entity MUST include an "rc" or "mp" header field parameter in the hi-entry, if applicable, per the procedures in Section 10.4." The following text that I proposed before seems to be missing: "If the sent request is a direct result of retargeting to a contact URI rec= eived in a 3xx response and the Contact header field in that response conta= ined an "rc" or "mp" header field parameter, the entity MUST include the co= rresponding parameter in the new hi-entry in accordance with 10.4." (although I am not certain the words "in accordance with 10.4 are needed - = in retrospect I would delete those words) 16. Section 9.3: "e.g., 1.2.1 comes after 1.2 but before 1.3 )" Just to be even clearer, I would suggest: "e.g., 1.2.1 comes after 1.2 but before 1.2.2 or 1.3 )" 17. Section 9.3: "The SIP entity then MUST add a Reason header field" I think this should say: "The SIP entity then MUST add one or more Reason header fields" This is because, according to 10.2, more than one can be added in some case= s. 18. Section 9.4: "When sending a response other than a 100, a SIP entity MUST include all the cached hi-entries in the response with the following exception: If the received request contained no hi-entries and there is no "histinfo" option tag in the Supported header field, the SIP entity MUST NOT include hi-entries in the response. In the former case , the privacy procedures as described in Section 10.1.2 MUST be followed." I find the words "In the former case" a little confusing. Also, if there ar= e exceptions to the normative statement in the first sentence, they should = probably be made clear in that first sentence. I would propose: "When sending a response other than a 100, a SIP entity MUST include all the cached hi-entries in the response, subject to the privacy consid= erations in Section 10.1.2 and with the following exception: If the received request contained no hi-entries and there is no "histinfo" option tag in the Supported header field, the SIP entity MUST NOT include hi-entries in the response." John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 15 March 2011 18:46 > To: SIPCORE > Subject: [sipcore] Fwd: I-D=20 > ACTION:draft-ietf-sipcore-rfc4244bis-04.txt >=20 > Hi folks,=20 >=20 > I have updated the document to incorporate the feedback on=20 > the -03 as follows: >=20 > 1) The biggest change was the reformating inline with John's=20 > suggestion: > http://www.ietf.org/mail-archive/web/sipcore/current/msg04010.html > It is not verbatim, but rather I included some of the past=20 > text in the relevant sections and I included a bullet list in=20 > some cases rather than just a paragraph as that was one of=20 > the formatting changes we made between RFC4244 and 4244bis in=20 > that the text in paragraph form can be rather dense. I=20 > believe the spirit and intent of John's proposal has been=20 > accomodated (I don't know that as many words were saved).=20 > Also, I just noticed some of the bullet lists don't have the=20 > "o" - I'll have to fix that. I think one of the most=20 > important aspects of John's proposal was introducing the=20 > "caching" of the hi-entries as that wasn't clearly spelled=20 > out previously and that really did help to clarify the=20 > processing. I do think the breakdown in the=20 > sending/receiving of the request and sending/receiving of a=20 > response into common processing is quite helpful.=20 >=20 > 2) Removed the term "escape" with regards to the Privacy and=20 > Reason header fields and just stated that those header fields=20 > were included in the hi-targeted-to-uri. I think this also=20 > improves readbility. =20 >=20 > 3) Additional clarification around the Tel-URI. >=20 > I think the doc should be ready for another WGLC.=20 >=20 > Thanks, > Mary.=20 >=20 >=20 > ---------- Forwarded message ---------- > From: > Date: Tue, Mar 15, 2011 at 1:30 PM > Subject: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt > To: i-d-announce@ietf.org > Cc: sipcore@ietf.org >=20 >=20 > A new Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Core Working Group of the IETF. >=20 > Title : An Extension to the Session Initiation=20 > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, et al > Filename : draft-ietf-sipcore-rfc4244bis-04.txt > Pages : 32 > Date : 2011-03-15 >=20 > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol (SIP) > request. This capability enables many enhanced services by=20 > providing > the information as to how and why a SIP request arrives at=20 > a specific > application or user. This document defines an optional SIP header > field, History-Info, for capturing the history information in > requests. The document also defines SIP header field parameters for > the History-Info and Contact header fields to tag the=20 > method by which > the target of a request is determined. In addition, this document > defines a value for the Privacy header field specific to=20 > the History- > Info header field. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244 > bis-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft=20 > aft> directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 >=20 > = From marianne.mohali@orange-ftgroup.com Thu Mar 17 09:29:21 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25743A69DB for ; Thu, 17 Mar 2011 09:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.962 X-Spam-Level: X-Spam-Status: No, score=-2.962 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX3UQU5lgi9I for ; Thu, 17 Mar 2011 09:29:20 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 69AC13A6996 for ; Thu, 17 Mar 2011 09:29:20 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 34AC68B8002; Thu, 17 Mar 2011 17:31:17 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 29D3C8B800B; Thu, 17 Mar 2011 17:31:17 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 17:30:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Mar 2011 17:30:43 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvZyONLW9FOvLuUTUqkYcckL0it7wDKxr0yAFSpeNAAEGYxoAGIbH+g References: <4D6C2CB6.4040800@cisco.com>, <4D6FD03A.8040507@cisco.com> , From: To: , X-OriginalArrivalTime: 17 Mar 2011 16:30:44.0589 (UTC) FILETIME=[A9EC71D0:01CBE4C0] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 16:29:21 -0000 Hi Dale, Here is a simple call flow to illustrate the example mentioned in my = email (you can see 2 more examples in the I-D with Reason header inside = History-Info header or NOT): Alice calls a Toll Free Directory service to retreive a restaurant phone = number in Prague.=20 She is calling from a public phone using her Prepaid card. Alice Prepaid service Toll Free Directory Restaurant | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | |---------------->| | | | | INVITE F3 | | | |---------------->| =20 F1: INVITE Alice -> Prepaid INVITE sip:+18005555555@prepaid.com;user=3Dphone SIP/2.0 From: Alice ; tag=3D1234567 To: Prepaid service Supported: histinfo ... F2: INVITE Prepaid -> Toll Free Directory INVITE sip:+18005551212@phone2net.com SIP/2.0 From: Alice ; tag=3D1234567 To: sip:+18005551212@phone2net.com;user=3Dphone Supported: histinfo History-Info: = ;index=3D1 ;index=3D1.1;mp=3D1 ... =20 F3: INVITE Toll Free Directory -> Restaurant INVITE sip:+420224841111@prague.com SIP/2.0 From: Alice ; tag=3D1234567 To: sip:+420224841111@prague.com;user=3Dphone Supported: histinfo History-Info: = ;index=3D1, ;index=3D1.1;mp=3D1, index=3D1.1.1 ... Regards, Marianne > -----Message d'origine----- > De : Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20 > Envoy=E9 : mercredi 9 mars 2011 19:32 > =C0 : MOHALI Marianne RD-CORE-ISS; pkyzivat@cisco.com > Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com > Objet : RE: [sipcore]=20 > I-DAction:draft-mohali-sipcore-reason-extension-application-01 >=20 > ________________________________________ > From: marianne.mohali@orange-ftgroup.com=20 > [marianne.mohali@orange-ftgroup.com] >=20 > > -----Message d'origine----- > > De : Worley, Dale R (Dale) [mailto:dworley@avaya.com] > > > > Could we see an example of how this is expected to be done? > > (Or have I overlooked the example?) There are various=20 > subtlties in a=20 > > protocol feature whose *absence* in the signaling tells another=20 > > application that a certain action may be taken. >=20 > [MM] In my network, I have an agreement with the Prepaid=20 > application that is to identify itself in the signaling (in=20 > the H-I header) when applied. > So that, I can offer to all of my clients a customized=20 > service with a connection to the reseached phone number=20 > except for prepaid callers. > Callers from other networks will not be able to enjoy the=20 > customized service (with the connection) as they are=20 > considered as untrusted. > _______________________________________ >=20 > I was thinking of a call flow, showing the critical header=20 > fields, the various proxies involved, etc. >=20 > Dale >=20 From marianne.mohali@orange-ftgroup.com Thu Mar 17 09:38:45 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B503A6A59 for ; Thu, 17 Mar 2011 09:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pquyhjefBr2 for ; Thu, 17 Mar 2011 09:38:44 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 20CFA3A69BE for ; Thu, 17 Mar 2011 09:38:44 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0FAD06F8007; Thu, 17 Mar 2011 17:40:44 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id E8EED6C0002; Thu, 17 Mar 2011 17:40:43 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 17:40:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Mar 2011 17:40:10 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore]I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvZyONLW9FOvLuUTUqkYcckL0it7wDKxr0yAFSpeNAAEGYxoAGIbH+gAAXa6LA= References: <4D6C2CB6.4040800@cisco.com>, <4D6FD03A.8040507@cisco.com>, From: To: X-OriginalArrivalTime: 17 Mar 2011 16:40:11.0318 (UTC) FILETIME=[FBB86D60:01CBE4C1] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 16:38:45 -0000 Oups, to following my example,=20 F3 flow should be a 200 OK (to Alice) And F4 would be a BYE from the Toll Free Directory to Alice (Alice is a = prepaid card caller so it would not be proposed a connection to the = Restaurant). =20 Sorry > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de=20 > marianne.mohali@orange-ftgroup.com > Envoy=E9 : jeudi 17 mars 2011 17:31 > =C0 : dworley@avaya.com; pkyzivat@cisco.com > Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com > Objet : Re:=20 > [sipcore]I-DAction:draft-mohali-sipcore-reason-extension-appli > cation-01 >=20 >=20 > Hi Dale, >=20 > Here is a simple call flow to illustrate the example=20 > mentioned in my email (you can see 2 more examples in the I-D=20 > with Reason header inside History-Info header or NOT): >=20 > Alice calls a Toll Free Directory service to retreive a=20 > restaurant phone number in Prague.=20 > She is calling from a public phone using her Prepaid card. >=20 > Alice Prepaid service Toll Free Directory Restaurant > | | | | > | INVITE F1 | | | > |--------------->| INVITE F2 | | > | |---------------->| | > | | | INVITE F3 | > | | |---------------->| =20 >=20 > F1: INVITE Alice -> Prepaid >=20 > INVITE sip:+18005555555@prepaid.com;user=3Dphone SIP/2.0 > From: Alice ; tag=3D1234567 > To: Prepaid service > Supported: histinfo > ... >=20 > F2: INVITE Prepaid -> Toll Free Directory >=20 > INVITE sip:+18005551212@phone2net.com SIP/2.0 > From: Alice ; tag=3D1234567 > To: sip:+18005551212@phone2net.com;user=3Dphone > Supported: histinfo > History-Info:=20 > %3Bcause%3D9%3B text%3D "Prepaid">;index=3D1 > ;index=3D1.1;mp=3D1 > ... > =20 > F3: INVITE Toll Free Directory -> Restaurant >=20 > INVITE sip:+420224841111@prague.com SIP/2.0 > From: Alice ; tag=3D1234567 > To: sip:+420224841111@prague.com;user=3Dphone > Supported: histinfo > History-Info:=20 > %3Bcause%3D9%3B text%3D "Prepaid">;index=3D1, > %3Bcause%3D11%3B text%3D "Toll = Free">;index=3D1.1;mp=3D1, > index=3D1.1.1 > ... >=20 >=20 > Regards, > Marianne >=20 > > -----Message d'origine----- > > De : Worley, Dale R (Dale) [mailto:dworley@avaya.com] Envoy=E9 :=20 > > mercredi 9 mars 2011 19:32 =C0 : MOHALI Marianne RD-CORE-ISS;=20 > > pkyzivat@cisco.com Cc : sipcore@ietf.org;=20 > > Christer.Holmberg@ericsson.com Objet : RE: [sipcore] > > I-DAction:draft-mohali-sipcore-reason-extension-application-01 > >=20 > > ________________________________________ > > From: marianne.mohali@orange-ftgroup.com > > [marianne.mohali@orange-ftgroup.com] > >=20 > > > -----Message d'origine----- > > > De : Worley, Dale R (Dale) [mailto:dworley@avaya.com] > > > > > > Could we see an example of how this is expected to be done? > > > (Or have I overlooked the example?) There are various > > subtlties in a > > > protocol feature whose *absence* in the signaling tells another=20 > > > application that a certain action may be taken. > >=20 > > [MM] In my network, I have an agreement with the Prepaid=20 > application=20 > > that is to identify itself in the signaling (in the H-I=20 > header) when=20 > > applied. > > So that, I can offer to all of my clients a customized=20 > service with a=20 > > connection to the reseached phone number except for prepaid callers. > > Callers from other networks will not be able to enjoy the=20 > customized=20 > > service (with the connection) as they are considered as untrusted. > > _______________________________________ > >=20 > > I was thinking of a call flow, showing the critical header=20 > fields, the=20 > > various proxies involved, etc. > >=20 > > Dale > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From marianne.mohali@orange-ftgroup.com Thu Mar 17 14:15:13 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D823A699A for ; Thu, 17 Mar 2011 14:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApLW0L9aXaSg for ; Thu, 17 Mar 2011 14:15:11 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 177C53A6AF0 for ; Thu, 17 Mar 2011 14:15:11 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 405D56F8007; Thu, 17 Mar 2011 22:17:11 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 305286C0006; Thu, 17 Mar 2011 22:17:11 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 22:16:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Mar 2011 22:16:34 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvcYISb0u1jdMeySTaPExDFDWj03gAgAOHgAJZ9baABW91BUA== References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com> From: To: , X-OriginalArrivalTime: 17 Mar 2011 21:16:38.0125 (UTC) FILETIME=[9A3A51D0:01CBE4E8] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 21:15:13 -0000 Hi John,=20 > -----Message d'origine----- > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Envoy=E9 : jeudi 10 mars 2011 17:01 > =C0 : MOHALI Marianne RD-CORE-ISS; pkyzivat@cisco.com > Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com > Objet : RE: [sipcore]=20 > I-DAction:draft-mohali-sipcore-reason-extension-application-01 >=20 > I have already commented that this sort of usage of H-I is=20 > appropriate only for closed networks. [MM] Correct. The draft extends the Reason header not only for H-I = case, but also for *normal* use of Reason header field.=20 >=20 > In addition to that, what I seem to be hearing is that the=20 > UAS needs to look at H-I to determine how the request=20 > arrived, and in particular whether it arrived because of=20 > retargeting due to premium rate (for example). Am I correct so far? [MM] The UAS should be itself a service using this information. It is = not considered as a need for the UAS, but as an enhanced feature for the = service and the customers.=20 >=20 > The whole concept behind 4244bis is that the UAS, in order to=20 > discover how a request arrived, scans back through the=20 > hi-entries looking at the parameters. So far we have two such=20 > parameters: "rc" and "mp". Marianne seems to be asserting=20 > that these two parameters are insufficient, and that other=20 > information in the hi-entries needs to be viewed in order to=20 > determine that retargeting due to premium rate (for example)=20 > took place. However, the proposed solution is to add this in=20 > the "headers" component of the URI concerned, rather than add=20 > a new hi-entry parameter. So the UAS, in order to analyse the=20 > history of the request, now has to scan for both hi-entry=20 > parameters AND URI headers. I don't understand why hi-entry=20 > parameters are not proposed for such applications. Having=20 > said that, we had a longgggg discussion trying to hammer out=20 > the set of hi-entry parameters that we really needed, and the=20 > final consensus was just to have "rc" and "mp". I would not=20 > want to open up that discussion again, but on the other hand=20 > using a different mechanism for solving a similar problem=20 > seems inappropriate. [MM] UAS already has to scan URI headers to apply Privacy or to find the = call forwarding reason (according to 3GPP 24.604). "rc" and "mp" could be usefull but are not sufficient for enhanced = supplementary services needs. I expressed the need for applications when = discussion started for "rc" and "mp"...=20 About having a H-I parameter, I'm not against it. The cons is that it = may not be possible to have this application-specific reason for SIP = responses and other SIP methods where Reason header field can be used. Marianne =20 >=20 > John >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > > marianne.mohali@orange-ftgroup.com > > Sent: 07 March 2011 18:30 > > To: pkyzivat@cisco.com > > Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com > > Subject: Re: [sipcore] I-DAction:=20 > > draft-mohali-sipcore-reason-extension-application-01 > >=20 > > Paul, > >=20 > > I think that Christer's draft (proxy-feature) is about capabilities=20 > > while this one (reason-extension-application) is about what really=20 > > happened (like reason in general). It is provided only when=20 > the event=20 > > happens and the purpose is to give an accuate information for=20 > > applicative events. > >=20 > > Let me give you an other example: > > A reception AS called with several premium rate numbers (1=20 > per hosted=20 > > application/service). The AS dispatches calls to several=20 > call centers=20 > > (eg. Depending on charge, hour of the day/night...). The final=20 > > destination needs to know the called service. The premuim=20 > rate number=20 > > should be listed in the H-I header. Which entry? For which=20 > > application/service invocated? > > As you can have a call forwarding reason associated to a 3xx or 486=20 > > Reason-cause, you could have an applicative reason to=20 > easily identify=20 > > the premium rate dialed number. > >=20 > > Regards, > > Marianne > >=20 > >=20 > > > -----Message d'origine----- > > > De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 :=20 > lundi 7 mars=20 > > > 2011 01:42 =C0 : MOHALI Marianne RD-CORE-ISS Cc : = sipcore@ietf.org;=20 > > > Christer.Holmberg@ericsson.com Objet : Re: [sipcore] I-DAction: > > > draft-mohali-sipcore-reason-extension-application-01 > > >=20 > > > Marianne > > >=20 > > > On 3/4/2011 11:59 AM, marianne.mohali@orange-ftgroup.com wrote: > > > > Hi Paul, > > > > > > > > My answer below [MM] > > > > > > > > Marianne > > > >> -----Message d'origine----- > > > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 :=20 > > > jeudi 3 mars > > > >> 2011 18:31 =C0 : MOHALI Marianne RD-CORE-ISS Cc :=20 > > sipcore@ietf.org; > > > >> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] I-DAction: > > > >> draft-mohali-sipcore-reason-extension-application-01 > > > >> > > > >> Marianne, > > > >> > > > >> On 3/3/2011 11:51 AM, marianne.mohali@orange-ftgroup.com wrote: > > > >>> Hi Paul, > > > >>> > > > >>> The purpose is to allow applications/services to be > > > >> explicitely identified in the signaling path, so that others=20 > > > >> services/applications/telephony-AS can act accordingly. > > > >> Either to apply a process taking into account the service > > > interaction > > > >> or on the contrary, do not execute a feature already > > > covered by the > > > >> application. > > > >>> For instance, a caller with a prepaid service calls a > > > >> directory enquiries Server to ask for a restaurant phone > > > number. The > > > >> operator would suggest to connect the caller to the > > > researched phone > > > >> number EXCEPT if the caller has a prepaid service because > > > it is not > > > >> sure he has enough credit to pay for the communication. To > > > allow this > > > >> customized feature, the directory enquiries Application > > > needs to know > > > >> that the prepaid Application has been invocated. > > > >> > > > >> So once again, we are back to your wanting to use=20 > Reason not to=20 > > > >> express a "reason" for anything, but rather as just a > > hook to hang > > > >> something on H-I. > > > > [MM] The *reason* why the call has been > > > retargeted/rejected/modified is the invocation of a specific=20 > > > application. > > > > If you call a Service number and then the URI is changed > > > for routing to the real destination, the *reason* of the URI=20 > > > modification (listed in H-I) is the application. > > >=20 > > > Based on your other replies, this is not necessarily so. > > >=20 > > > In fact the example above is a counter-example. > > > The prepaid service is not responsible for any=20 > redirection, and the=20 > > > operator service is looking for it for a reason other=20 > than that it=20 > > > has been the cause of anything. Its looking for it=20 > because it might=20 > > > be the cause of something in the future. > > >=20 > > > >> (With the causes you have defined, I can't imagine it making > > > >> *any* sense to actually use one in a Reason header in=20 > a message,=20 > > > >> because they aren't specific enough to be actionable.) > > > >> > > > >> I am now thinking there is a large overlap between=20 > what you are=20 > > > >> trying to accomplish this way, and what Christer is trying to=20 > > > >> accomplish with draft-holmberg-sipcore-proxy-feature. > > > >> > > > >> Is that true? > > > >> > > > >> (Christer: What do you think?) > > > > [MM] I don't see the overlap with Christer's draft because > > > it is not about capabilities, it is about what's happened. > > >=20 > > > In your example above, it seems that the operator service=20 > is looking=20 > > > for the prepaid service because the prepaid service has the=20 > > > capability to influence billing, or something like that.=20 > This seems=20 > > > at least somewhat in line with what Christer is=20 > advocating. Looking=20 > > > in the Route header, or Record-Route header would make at=20 > least as=20 > > > much sense for this case as looking in H-I. H-I makes=20 > sense if you=20 > > > are indeed looking for something that has already=20 > happened, perhaps=20 > > > on a path other that the current one. > > >=20 > > > I think it would be helpful for the two of you to come to some=20 > > > reconciliation of what you are trying to accomplish. > > >=20 > > > Thanks, > > > Paul > > >=20 > > > >>> About your comment in case of several applications involved > > > >> *simultaneously* in the call establishment, it is possible > > > to add 1 > > > >> more hi-entry for the second application Cause you want to be=20 > > > >> identified in the signaling path. > > > >> > > > >> Sure, you can indicate that they are "involved". But you > > > can't infer > > > >> anything about which one "caused" something. They might > > > have, but you > > > >> can't tell it from the presence of these headers. > > > >> > > > >> Thanks, > > > >> Paul > > > >> > > > >>> Regards, > > > >>> Marianne > > > >>> > > > >>> > > > >>>> -----Message d'origine----- > > > >>>> De : sipcore-bounces@ietf.org > > > >>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul > > > >> Kyzivat Envoy=E9 : > > > >>>> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org Objet : Re:=20 > > > [sipcore] > > > >>>> I-DAction: > > > >>>> draft-mohali-sipcore-reason-extension-application-01 > > > >>>> > > > >>>> (As individual) > > > >>>> > > > >>>> Marianne, > > > >>>> > > > >>>> I'm still struggling to make sense of this in the form > > proposed. > > > >>>> > > > >>>> I look at the various cause values, and all the > > > >> descriptions are of > > > >>>> the form. E.g.: > > > >>>> > > > >>>> Cause value: 2 > > > >>>> Reason text: Freephone > > > >>>> Description: A Freephone application has influenced=20 > > > >>>> processing of > > > >>>> the call (e.g. by translating a dialed Free Phone > > > >> number to a > > > >>>> routable directory number). > > > >>>> > > > >>>> I can't figure out how to make any actionable decision > > > >> based on this. > > > >>>> Rather, it seems I need to make a number of leaps of faith > > > >> before I > > > >>>> can decide what to do. > > > >>>> > > > >>>> For instance, if I get an error, it *might* be because I > > > dialed a > > > >>>> freephone number, and it isn't supported from my calling > > > location. > > > >>>> (E.g. > > > >>>> maybe I'm dialing +1-800-555-1234, but I'm doing so from > > > >> France, and > > > >>>> calling that number is only supported in the USA. > > > >>>> > > > >>>> But getting a application reason code with cause 2 > > > doesn't really > > > >>>> tell me that is what happened. It could be that the call > > > >> indeed was > > > >>>> routed through a freephone application, and it properly > > > routed the > > > >>>> call, and the call failed for some other reason. But the > > > cause is > > > >>>> there because the application > > > >>>> *did* influence the call routing. > > > >>>> > > > >>>> Also, these "applications" are not, AFAIK, mutually > > > >> exclusive. E.g. I > > > >>>> could be using a prepaid service to make a directory > > > >> assistance call > > > >>>> that costs extra $$$ that I don't have credits to > > cover. But you > > > >>>> can't include two cause values for the same protocol. (But > > > >> it is true > > > >>>> that you > > > >>>> *can* have a number of servers each put one cause into > > > >>>> *their* H-I entry.) > > > >>>> > > > >>>> So *maybe* I would see that my call failed, and that there > > > >> is both a > > > >>>> reason indicating a prepaid application on one H-I entry, > > > >> and another > > > >>>> indicating a another H-I indicating a directory service > > > >> application. > > > >>>> But what can I conclude from that? > > > >>>> > > > >>>> Bottom line, I just can't make sense how this could be > > > >> used in a well > > > >>>> defined and interoperable way. > > > >>>> > > > >>>> Thanks, > > > >>>> Paul > > > >>>> > > > >>>> On 2/28/2011 9:58 AM,=20 > marianne.mohali@orange-ftgroup.com wrote: > > > >>>>> Hello, > > > >>>>> > > > >>>>> Here is the new version of the draft. > > > >>>>> Main changes are following: > > > >>>>> - More details about the registration procedure for=20 > new values > > > >>>>> - Clearer text in section 3.2 > > > >>>>> - Add of Public and Private status for registered values. > > > >>>>> - Add of a range for cause values registration > > > >>>>> > > > >>>>> Best Regards, > > > >>>>> Marianne Mohali > > > >>>>> > > > >>>>> -----Message d'origine----- > > > >>>>> Objet : New Version Notification for > > > >>>>> draft-mohali-sipcore-reason-extension-application-01 > > > >>>>> > > > >>>>> A New Internet-Draft is available from the on-line > > > >> Internet-Drafts > > > >>>>> directories. > > > >>>>> > > > >>>>> Title : Extending the Session=20 > > > Initiation Protocol > > > >>>>> (SIP) Reason Header for Applications > > > >>>>> Author(s) : M. Mohali, B. Chatras > > > >>>>> Filename : > > > >>>>> draft-mohali-sipcore-reason-extension-application-01.txt > > > >>>>> Pages : 10 > > > >>>>> Date : 2011-02-24 > > > >>>>> > > > >>>>> This document defines a new protocol value > > > "Application" for the > > > >>>>> Reason Header field and a new IANA Registry for registering=20 > > > >>>>> application types. This new value enables signaling that a > > > >>>> request or > > > >>>>> response has been issued as a result of a decision=20 > made by a=20 > > > >>>>> particular type of application or that an initial request > > > >> has been > > > >>>>> retargeted as a result of an application decision. > > > >>>>> > > > >>>>> A URL for this Internet-Draft is: > > > >>>>> > > > >>>> > > > >>=20 > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten > > > >>>> s > > > >>>>> io > > > >>>>> n-application-01.txt > > > >>>>> > > > >>>>> Internet-Drafts are also available by anonymous FTP at: > > > >>>>> ftp://ftp.ietf.org/internet-drafts/ > > > >>>>> > > > >>>>> Below is the data which will enable a MIME compliant > > > mail reader > > > >>>>> implementation to automatically retrieve the ASCII > > > version of the > > > >>>>> Internet-Draft. > > > >>>>> > > > >>>>> > > > >>>> > > > >>=20 > > >=20 > >=20 > > > >>>> s > > > >>>>> io > > > >>>>> n-application-01.txt> > > > >>>>> > > > >>>>> _______________________________________________ > > > >>>>> I-D-Announce mailing list > > > >>>>> I-D-Announce@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > > > >>>>> Internet-Draft directories:=20 > > http://www.ietf.org/shadow.html or > > > >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >>>>> _______________________________________________ > > > >>>>> sipcore mailing list > > > >>>>> sipcore@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > > > >>>>> > > > >>>> _______________________________________________ > > > >>>> sipcore mailing list > > > >>>> sipcore@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/sipcore > > > >>>> > > > >>> > > > >> > > > > > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 From john.elwell@siemens-enterprise.com Fri Mar 18 00:32:22 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917143A6A07 for ; Fri, 18 Mar 2011 00:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uB+dTCln2zn for ; Fri, 18 Mar 2011 00:32:20 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A51413A6A4B for ; Fri, 18 Mar 2011 00:32:19 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3792422; Fri, 18 Mar 2011 08:33:47 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 2595623F0278; Fri, 18 Mar 2011 08:33:47 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 18 Mar 2011 08:33:47 +0100 From: "Elwell, John" To: "marianne.mohali@orange-ftgroup.com" , "pkyzivat@cisco.com" Date: Fri, 18 Mar 2011 08:33:45 +0100 Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvcYISb0u1jdMeySTaPExDFDWj03gAgAOHgAJZ9baABW91BUAAk6kVQ Message-ID: References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 07:32:22 -0000 > -----Original Message----- > From: marianne.mohali@orange-ftgroup.com > [mailto:marianne.mohali@orange-ftgroup.com] > Sent: 17 March 2011 21:17 > To: Elwell, John; pkyzivat@cisco.com > Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com > Subject: RE: [sipcore] > I-DAction:draft-mohali-sipcore-reason-extension-application-01 > > Hi John, > > > -----Message d'origine----- > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Envoy=E9 : jeudi 10 mars 2011 17:01 > > =C0 : MOHALI Marianne RD-CORE-ISS; pkyzivat@cisco.com > > Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com > > Objet : RE: [sipcore] > > I-DAction:draft-mohali-sipcore-reason-extension-application-01 > > > > I have already commented that this sort of usage of H-I is > > appropriate only for closed networks. > [MM] Correct. The draft extends the Reason header not only > for H-I case, but also for *normal* use of Reason header field. > > > > In addition to that, what I seem to be hearing is that the > > UAS needs to look at H-I to determine how the request > > arrived, and in particular whether it arrived because of > > retargeting due to premium rate (for example). Am I correct so far? > [MM] The UAS should be itself a service using this > information. It is not considered as a need for the UAS, but > as an enhanced feature for the service and the customers. > > > > The whole concept behind 4244bis is that the UAS, in order to > > discover how a request arrived, scans back through the > > hi-entries looking at the parameters. So far we have two such > > parameters: "rc" and "mp". Marianne seems to be asserting > > that these two parameters are insufficient, and that other > > information in the hi-entries needs to be viewed in order to > > determine that retargeting due to premium rate (for example) > > took place. However, the proposed solution is to add this in > > the "headers" component of the URI concerned, rather than add > > a new hi-entry parameter. So the UAS, in order to analyse the > > history of the request, now has to scan for both hi-entry > > parameters AND URI headers. I don't understand why hi-entry > > parameters are not proposed for such applications. Having > > said that, we had a longgggg discussion trying to hammer out > > the set of hi-entry parameters that we really needed, and the > > final consensus was just to have "rc" and "mp". I would not > > want to open up that discussion again, but on the other hand > > using a different mechanism for solving a similar problem > > seems inappropriate. > [MM] UAS already has to scan URI headers to apply Privacy or > to find the call forwarding reason (according to 3GPP 24.604). > "rc" and "mp" could be usefull but are not sufficient for > enhanced supplementary services needs. I expressed the need > for applications when discussion started for "rc" and "mp"... > About having a H-I parameter, I'm not against it. The cons is > that it may not be possible to have this application-specific > reason for SIP responses and other SIP methods where Reason > header field can be used. [JRE] This does not fully address the point I was making. I was making the = point that to find the particular hi-entry you are interested in you need, = at present, to scan hi-entries looking at their parameters - you do not nee= d to look at the URIs in those hi-entries and the URIs' "headers" component= s in order to find the hi-entry you are looking for. Of course, once you ha= ve found the hi-entry you are looking for, you will be interested in the UR= I and in anything attached to it, including Privacy and Reason header field= s within its "headers" component. The draft under discussion seems to chang= e that principle so that in order to find the hi-entry you are looking for = you need to look inside the URIs. This seems to me like a change of princip= le - the logic of including the proposed application information in the URI= as a header field, rather than in hi-entry parameters, is not at all clear= to me. John > > Marianne > > > > John > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > > marianne.mohali@orange-ftgroup.com > > > Sent: 07 March 2011 18:30 > > > To: pkyzivat@cisco.com > > > Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com > > > Subject: Re: [sipcore] I-DAction: > > > draft-mohali-sipcore-reason-extension-application-01 > > > > > > Paul, > > > > > > I think that Christer's draft (proxy-feature) is about > capabilities > > > while this one (reason-extension-application) is about > what really > > > happened (like reason in general). It is provided only when > > the event > > > happens and the purpose is to give an accuate information for > > > applicative events. > > > > > > Let me give you an other example: > > > A reception AS called with several premium rate numbers (1 > > per hosted > > > application/service). The AS dispatches calls to several > > call centers > > > (eg. Depending on charge, hour of the day/night...). The final > > > destination needs to know the called service. The premuim > > rate number > > > should be listed in the H-I header. Which entry? For which > > > application/service invocated? > > > As you can have a call forwarding reason associated to a > 3xx or 486 > > > Reason-cause, you could have an applicative reason to > > easily identify > > > the premium rate dialed number. > > > > > > Regards, > > > Marianne > > > > > > > > > > -----Message d'origine----- > > > > De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : > > lundi 7 mars > > > > 2011 01:42 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > sipcore@ietf.org; > > > > Christer.Holmberg@ericsson.com Objet : Re: [sipcore] I-DAction: > > > > draft-mohali-sipcore-reason-extension-application-01 > > > > > > > > Marianne > > > > > > > > On 3/4/2011 11:59 AM, marianne.mohali@orange-ftgroup.com wrote: > > > > > Hi Paul, > > > > > > > > > > My answer below [MM] > > > > > > > > > > Marianne > > > > >> -----Message d'origine----- > > > > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : > > > > jeudi 3 mars > > > > >> 2011 18:31 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > > > sipcore@ietf.org; > > > > >> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] > I-DAction: > > > > >> draft-mohali-sipcore-reason-extension-application-01 > > > > >> > > > > >> Marianne, > > > > >> > > > > >> On 3/3/2011 11:51 AM, > marianne.mohali@orange-ftgroup.com wrote: > > > > >>> Hi Paul, > > > > >>> > > > > >>> The purpose is to allow applications/services to be > > > > >> explicitely identified in the signaling path, so that others > > > > >> services/applications/telephony-AS can act accordingly. > > > > >> Either to apply a process taking into account the service > > > > interaction > > > > >> or on the contrary, do not execute a feature already > > > > covered by the > > > > >> application. > > > > >>> For instance, a caller with a prepaid service calls a > > > > >> directory enquiries Server to ask for a restaurant phone > > > > number. The > > > > >> operator would suggest to connect the caller to the > > > > researched phone > > > > >> number EXCEPT if the caller has a prepaid service because > > > > it is not > > > > >> sure he has enough credit to pay for the communication. To > > > > allow this > > > > >> customized feature, the directory enquiries Application > > > > needs to know > > > > >> that the prepaid Application has been invocated. > > > > >> > > > > >> So once again, we are back to your wanting to use > > Reason not to > > > > >> express a "reason" for anything, but rather as just a > > > hook to hang > > > > >> something on H-I. > > > > > [MM] The *reason* why the call has been > > > > retargeted/rejected/modified is the invocation of a specific > > > > application. > > > > > If you call a Service number and then the URI is changed > > > > for routing to the real destination, the *reason* of the URI > > > > modification (listed in H-I) is the application. > > > > > > > > Based on your other replies, this is not necessarily so. > > > > > > > > In fact the example above is a counter-example. > > > > The prepaid service is not responsible for any > > redirection, and the > > > > operator service is looking for it for a reason other > > than that it > > > > has been the cause of anything. Its looking for it > > because it might > > > > be the cause of something in the future. > > > > > > > > >> (With the causes you have defined, I can't imagine it making > > > > >> *any* sense to actually use one in a Reason header in > > a message, > > > > >> because they aren't specific enough to be actionable.) > > > > >> > > > > >> I am now thinking there is a large overlap between > > what you are > > > > >> trying to accomplish this way, and what Christer is > trying to > > > > >> accomplish with draft-holmberg-sipcore-proxy-feature. > > > > >> > > > > >> Is that true? > > > > >> > > > > >> (Christer: What do you think?) > > > > > [MM] I don't see the overlap with Christer's draft because > > > > it is not about capabilities, it is about what's happened. > > > > > > > > In your example above, it seems that the operator service > > is looking > > > > for the prepaid service because the prepaid service has the > > > > capability to influence billing, or something like that. > > This seems > > > > at least somewhat in line with what Christer is > > advocating. Looking > > > > in the Route header, or Record-Route header would make at > > least as > > > > much sense for this case as looking in H-I. H-I makes > > sense if you > > > > are indeed looking for something that has already > > happened, perhaps > > > > on a path other that the current one. > > > > > > > > I think it would be helpful for the two of you to come to some > > > > reconciliation of what you are trying to accomplish. > > > > > > > > Thanks, > > > > Paul > > > > > > > > >>> About your comment in case of several applications involved > > > > >> *simultaneously* in the call establishment, it is possible > > > > to add 1 > > > > >> more hi-entry for the second application Cause you > want to be > > > > >> identified in the signaling path. > > > > >> > > > > >> Sure, you can indicate that they are "involved". But you > > > > can't infer > > > > >> anything about which one "caused" something. They might > > > > have, but you > > > > >> can't tell it from the presence of these headers. > > > > >> > > > > >> Thanks, > > > > >> Paul > > > > >> > > > > >>> Regards, > > > > >>> Marianne > > > > >>> > > > > >>> > > > > >>>> -----Message d'origine----- > > > > >>>> De : sipcore-bounces@ietf.org > > > > >>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul > > > > >> Kyzivat Envoy=E9 : > > > > >>>> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org Objet : Re: > > > > [sipcore] > > > > >>>> I-DAction: > > > > >>>> draft-mohali-sipcore-reason-extension-application-01 > > > > >>>> > > > > >>>> (As individual) > > > > >>>> > > > > >>>> Marianne, > > > > >>>> > > > > >>>> I'm still struggling to make sense of this in the form > > > proposed. > > > > >>>> > > > > >>>> I look at the various cause values, and all the > > > > >> descriptions are of > > > > >>>> the form. E.g.: > > > > >>>> > > > > >>>> Cause value: 2 > > > > >>>> Reason text: Freephone > > > > >>>> Description: A Freephone application has > influenced > > > > >>>> processing of > > > > >>>> the call (e.g. by translating a dialed Free Phone > > > > >> number to a > > > > >>>> routable directory number). > > > > >>>> > > > > >>>> I can't figure out how to make any actionable decision > > > > >> based on this. > > > > >>>> Rather, it seems I need to make a number of leaps of faith > > > > >> before I > > > > >>>> can decide what to do. > > > > >>>> > > > > >>>> For instance, if I get an error, it *might* be because I > > > > dialed a > > > > >>>> freephone number, and it isn't supported from my calling > > > > location. > > > > >>>> (E.g. > > > > >>>> maybe I'm dialing +1-800-555-1234, but I'm doing so from > > > > >> France, and > > > > >>>> calling that number is only supported in the USA. > > > > >>>> > > > > >>>> But getting a application reason code with cause 2 > > > > doesn't really > > > > >>>> tell me that is what happened. It could be that the call > > > > >> indeed was > > > > >>>> routed through a freephone application, and it properly > > > > routed the > > > > >>>> call, and the call failed for some other reason. But the > > > > cause is > > > > >>>> there because the application > > > > >>>> *did* influence the call routing. > > > > >>>> > > > > >>>> Also, these "applications" are not, AFAIK, mutually > > > > >> exclusive. E.g. I > > > > >>>> could be using a prepaid service to make a directory > > > > >> assistance call > > > > >>>> that costs extra $$$ that I don't have credits to > > > cover. But you > > > > >>>> can't include two cause values for the same protocol. (But > > > > >> it is true > > > > >>>> that you > > > > >>>> *can* have a number of servers each put one cause into > > > > >>>> *their* H-I entry.) > > > > >>>> > > > > >>>> So *maybe* I would see that my call failed, and that there > > > > >> is both a > > > > >>>> reason indicating a prepaid application on one H-I entry, > > > > >> and another > > > > >>>> indicating a another H-I indicating a directory service > > > > >> application. > > > > >>>> But what can I conclude from that? > > > > >>>> > > > > >>>> Bottom line, I just can't make sense how this could be > > > > >> used in a well > > > > >>>> defined and interoperable way. > > > > >>>> > > > > >>>> Thanks, > > > > >>>> Paul > > > > >>>> > > > > >>>> On 2/28/2011 9:58 AM, > > marianne.mohali@orange-ftgroup.com wrote: > > > > >>>>> Hello, > > > > >>>>> > > > > >>>>> Here is the new version of the draft. > > > > >>>>> Main changes are following: > > > > >>>>> - More details about the registration procedure for > > new values > > > > >>>>> - Clearer text in section 3.2 > > > > >>>>> - Add of Public and Private status for registered values. > > > > >>>>> - Add of a range for cause values registration > > > > >>>>> > > > > >>>>> Best Regards, > > > > >>>>> Marianne Mohali > > > > >>>>> > > > > >>>>> -----Message d'origine----- > > > > >>>>> Objet : New Version Notification for > > > > >>>>> draft-mohali-sipcore-reason-extension-application-01 > > > > >>>>> > > > > >>>>> A New Internet-Draft is available from the on-line > > > > >> Internet-Drafts > > > > >>>>> directories. > > > > >>>>> > > > > >>>>> Title : Extending the Session > > > > Initiation Protocol > > > > >>>>> (SIP) Reason Header for Applications > > > > >>>>> Author(s) : M. Mohali, B. Chatras > > > > >>>>> Filename : > > > > >>>>> draft-mohali-sipcore-reason-extension-application-01.txt > > > > >>>>> Pages : 10 > > > > >>>>> Date : 2011-02-24 > > > > >>>>> > > > > >>>>> This document defines a new protocol value > > > > "Application" for the > > > > >>>>> Reason Header field and a new IANA Registry for > registering > > > > >>>>> application types. This new value enables > signaling that a > > > > >>>> request or > > > > >>>>> response has been issued as a result of a decision > > made by a > > > > >>>>> particular type of application or that an initial request > > > > >> has been > > > > >>>>> retargeted as a result of an application decision. > > > > >>>>> > > > > >>>>> A URL for this Internet-Draft is: > > > > >>>>> > > > > >>>> > > > > >> > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten > > > > >>>> s > > > > >>>>> io > > > > >>>>> n-application-01.txt > > > > >>>>> > > > > >>>>> Internet-Drafts are also available by anonymous FTP at: > > > > >>>>> ftp://ftp.ietf.org/internet-drafts/ > > > > >>>>> > > > > >>>>> Below is the data which will enable a MIME compliant > > > > mail reader > > > > >>>>> implementation to automatically retrieve the ASCII > > > > version of the > > > > >>>>> Internet-Draft. > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >> > > > > > > > > > > > > > >>>> s > > > > >>>>> io > > > > >>>>> n-application-01.txt> > > > > >>>>> > > > > >>>>> _______________________________________________ > > > > >>>>> I-D-Announce mailing list > > > > >>>>> I-D-Announce@ietf.org > > > > >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > > > > >>>>> Internet-Draft directories: > > > http://www.ietf.org/shadow.html or > > > > >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > >>>>> _______________________________________________ > > > > >>>>> sipcore mailing list > > > > >>>>> sipcore@ietf.org > > > > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > > > > >>>>> > > > > >>>> _______________________________________________ > > > > >>>> sipcore mailing list > > > > >>>> sipcore@ietf.org > > > > >>>> https://www.ietf.org/mailman/listinfo/sipcore > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > From marianne.mohali@orange-ftgroup.com Fri Mar 18 02:28:15 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7CFA3A6AF5 for ; Fri, 18 Mar 2011 02:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYX4YoPIy0al for ; Fri, 18 Mar 2011 02:28:12 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 0B7F43A680E for ; Fri, 18 Mar 2011 02:28:11 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 74C08FC4007; Fri, 18 Mar 2011 10:29:45 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 63C94FC4001; Fri, 18 Mar 2011 10:29:45 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 10:29:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Mar 2011 10:29:35 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvcYISb0u1jdMeySTaPExDFDWj03gAgAOHgAJZ9baABW91BUAAk6kVQAAEMsiA= References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com> From: To: , X-OriginalArrivalTime: 18 Mar 2011 09:29:38.0964 (UTC) FILETIME=[00D9C540:01CBE54F] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 09:28:15 -0000 =20 > -----Message d'origine----- > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Envoy=E9 : vendredi 18 mars 2011 08:34 > =C0 : MOHALI Marianne RD-CORE-ISS; pkyzivat@cisco.com > Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com > Objet : RE: [sipcore]=20 > I-DAction:draft-mohali-sipcore-reason-extension-application-01 >=20 >=20 >=20 > > -----Original Message----- > > From: marianne.mohali@orange-ftgroup.com > > [mailto:marianne.mohali@orange-ftgroup.com] > > Sent: 17 March 2011 21:17 > > To: Elwell, John; pkyzivat@cisco.com > > Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com > > Subject: RE: [sipcore] > > I-DAction:draft-mohali-sipcore-reason-extension-application-01 > > > > Hi John, > > > > > -----Message d'origine----- > > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Envoy=E9 : jeudi 10 mars 2011 17:01 > > > =C0 : MOHALI Marianne RD-CORE-ISS; pkyzivat@cisco.com Cc :=20 > > > sipcore@ietf.org; Christer.Holmberg@ericsson.com Objet : RE:=20 > > > [sipcore] > > > I-DAction:draft-mohali-sipcore-reason-extension-application-01 > > > > > > I have already commented that this sort of usage of H-I is=20 > > > appropriate only for closed networks. > > [MM] Correct. The draft extends the Reason header not only for H-I=20 > > case, but also for *normal* use of Reason header field. > > > > > > In addition to that, what I seem to be hearing is that=20 > the UAS needs=20 > > > to look at H-I to determine how the request arrived, and in=20 > > > particular whether it arrived because of retargeting due=20 > to premium=20 > > > rate (for example). Am I correct so far? > > [MM] The UAS should be itself a service using this=20 > information. It is=20 > > not considered as a need for the UAS, but as an enhanced=20 > feature for=20 > > the service and the customers. > > > > > > The whole concept behind 4244bis is that the UAS, in order to=20 > > > discover how a request arrived, scans back through the hi-entries=20 > > > looking at the parameters. So far we have two such > > > parameters: "rc" and "mp". Marianne seems to be asserting=20 > that these=20 > > > two parameters are insufficient, and that other=20 > information in the=20 > > > hi-entries needs to be viewed in order to determine that=20 > retargeting=20 > > > due to premium rate (for example) took place. However,=20 > the proposed=20 > > > solution is to add this in the "headers" component of the URI=20 > > > concerned, rather than add a new hi-entry parameter. So=20 > the UAS, in=20 > > > order to analyse the history of the request, now has to scan for=20 > > > both hi-entry parameters AND URI headers. I don't understand why=20 > > > hi-entry parameters are not proposed for such=20 > applications. Having=20 > > > said that, we had a longgggg discussion trying to hammer=20 > out the set=20 > > > of hi-entry parameters that we really needed, and the final=20 > > > consensus was just to have "rc" and "mp". I would not=20 > want to open=20 > > > up that discussion again, but on the other hand using a =20 > different=20 > > > mechanism for solving a similar problem seems inappropriate. > > [MM] UAS already has to scan URI headers to apply Privacy=20 > or to find=20 > > the call forwarding reason (according to 3GPP 24.604). > > "rc" and "mp" could be usefull but are not sufficient for enhanced=20 > > supplementary services needs. I expressed the need for applications=20 > > when discussion started for "rc" and "mp"... > > About having a H-I parameter, I'm not against it. The cons=20 > is that it=20 > > may not be possible to have this application-specific=20 > reason for SIP=20 > > responses and other SIP methods where Reason header field=20 > can be used. > [JRE] This does not fully address the point I was making. I=20 > was making the point that to find the particular hi-entry you=20 > are interested in you need, at present, to scan hi-entries=20 > looking at their parameters - you do not need to look at the=20 > URIs in those hi-entries and the URIs' "headers" components=20 > in order to find the hi-entry you are looking for. Of course,=20 > once you have found the hi-entry you are looking for, you=20 > will be interested in the URI and in anything attached to it,=20 > including Privacy and Reason header fields within its=20 > "headers" component. The draft under discussion seems to=20 > change that principle so that in order to find the hi-entry=20 > you are looking for you need to look inside the URIs. This=20 > seems to me like a change of principle - the logic of=20 > including the proposed application information in the URI as=20 > a header field, rather than in hi-entry parameters, is not at=20 > all clear to me. [MM] I don't see the problem with your point. hi-entry parameters=20 are not incompatible with URIs' headers. hi-entry parameters, allow to do a first sort in hi-entries, then,=20 according to UAS needs, URI headers or parameters give a complementary information. =20 Imagine a situation where you have Alice calling Bob with a prepaid=20 calling card and Bod doesn't answer so the call is retargeted to the=20 voicemail. You would have the following sequence in the last INVITE (last leg):=20 I didn't show possible intermediary proxies entries) History-Info: ;index=3D1, = ;index=3D1.1;mp=3D= 1, = index=3D1.1.1;mp=3D= 1.1 Marianne >=20 > John >=20 >=20 > > > > Marianne > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > > > > marianne.mohali@orange-ftgroup.com > > > > Sent: 07 March 2011 18:30 > > > > To: pkyzivat@cisco.com > > > > Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com > > > > Subject: Re: [sipcore] I-DAction: > > > > draft-mohali-sipcore-reason-extension-application-01 > > > > > > > > Paul, > > > > > > > > I think that Christer's draft (proxy-feature) is about > > capabilities > > > > while this one (reason-extension-application) is about > > what really > > > > happened (like reason in general). It is provided only when > > > the event > > > > happens and the purpose is to give an accuate information for=20 > > > > applicative events. > > > > > > > > Let me give you an other example: > > > > A reception AS called with several premium rate numbers (1 > > > per hosted > > > > application/service). The AS dispatches calls to several > > > call centers > > > > (eg. Depending on charge, hour of the day/night...). The final=20 > > > > destination needs to know the called service. The premuim > > > rate number > > > > should be listed in the H-I header. Which entry? For which=20 > > > > application/service invocated? > > > > As you can have a call forwarding reason associated to a > > 3xx or 486 > > > > Reason-cause, you could have an applicative reason to > > > easily identify > > > > the premium rate dialed number. > > > > > > > > Regards, > > > > Marianne > > > > > > > > > > > > > -----Message d'origine----- > > > > > De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : > > > lundi 7 mars > > > > > 2011 01:42 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > > sipcore@ietf.org; > > > > > Christer.Holmberg@ericsson.com Objet : Re: [sipcore]=20 > I-DAction: > > > > > draft-mohali-sipcore-reason-extension-application-01 > > > > > > > > > > Marianne > > > > > > > > > > On 3/4/2011 11:59 AM,=20 > marianne.mohali@orange-ftgroup.com wrote: > > > > > > Hi Paul, > > > > > > > > > > > > My answer below [MM] > > > > > > > > > > > > Marianne > > > > > >> -----Message d'origine----- > > > > > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : > > > > > jeudi 3 mars > > > > > >> 2011 18:31 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > > > > sipcore@ietf.org; > > > > > >> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] > > I-DAction: > > > > > >> draft-mohali-sipcore-reason-extension-application-01 > > > > > >> > > > > > >> Marianne, > > > > > >> > > > > > >> On 3/3/2011 11:51 AM, > > marianne.mohali@orange-ftgroup.com wrote: > > > > > >>> Hi Paul, > > > > > >>> > > > > > >>> The purpose is to allow applications/services to be > > > > > >> explicitely identified in the signaling path, so=20 > that others=20 > > > > > >> services/applications/telephony-AS can act accordingly. > > > > > >> Either to apply a process taking into account the service > > > > > interaction > > > > > >> or on the contrary, do not execute a feature already > > > > > covered by the > > > > > >> application. > > > > > >>> For instance, a caller with a prepaid service calls a > > > > > >> directory enquiries Server to ask for a restaurant phone > > > > > number. The > > > > > >> operator would suggest to connect the caller to the > > > > > researched phone > > > > > >> number EXCEPT if the caller has a prepaid service because > > > > > it is not > > > > > >> sure he has enough credit to pay for the communication. To > > > > > allow this > > > > > >> customized feature, the directory enquiries Application > > > > > needs to know > > > > > >> that the prepaid Application has been invocated. > > > > > >> > > > > > >> So once again, we are back to your wanting to use > > > Reason not to > > > > > >> express a "reason" for anything, but rather as just a > > > > hook to hang > > > > > >> something on H-I. > > > > > > [MM] The *reason* why the call has been > > > > > retargeted/rejected/modified is the invocation of a specific=20 > > > > > application. > > > > > > If you call a Service number and then the URI is changed > > > > > for routing to the real destination, the *reason* of the URI=20 > > > > > modification (listed in H-I) is the application. > > > > > > > > > > Based on your other replies, this is not necessarily so. > > > > > > > > > > In fact the example above is a counter-example. > > > > > The prepaid service is not responsible for any > > > redirection, and the > > > > > operator service is looking for it for a reason other > > > than that it > > > > > has been the cause of anything. Its looking for it > > > because it might > > > > > be the cause of something in the future. > > > > > > > > > > >> (With the causes you have defined, I can't imagine=20 > it making > > > > > >> *any* sense to actually use one in a Reason header in > > > a message, > > > > > >> because they aren't specific enough to be actionable.) > > > > > >> > > > > > >> I am now thinking there is a large overlap between > > > what you are > > > > > >> trying to accomplish this way, and what Christer is > > trying to > > > > > >> accomplish with draft-holmberg-sipcore-proxy-feature. > > > > > >> > > > > > >> Is that true? > > > > > >> > > > > > >> (Christer: What do you think?) > > > > > > [MM] I don't see the overlap with Christer's draft because > > > > > it is not about capabilities, it is about what's happened. > > > > > > > > > > In your example above, it seems that the operator service > > > is looking > > > > > for the prepaid service because the prepaid service has the=20 > > > > > capability to influence billing, or something like that. > > > This seems > > > > > at least somewhat in line with what Christer is > > > advocating. Looking > > > > > in the Route header, or Record-Route header would make at > > > least as > > > > > much sense for this case as looking in H-I. H-I makes > > > sense if you > > > > > are indeed looking for something that has already > > > happened, perhaps > > > > > on a path other that the current one. > > > > > > > > > > I think it would be helpful for the two of you to=20 > come to some=20 > > > > > reconciliation of what you are trying to accomplish. > > > > > > > > > > Thanks, > > > > > Paul > > > > > > > > > > >>> About your comment in case of several=20 > applications involved > > > > > >> *simultaneously* in the call establishment, it is possible > > > > > to add 1 > > > > > >> more hi-entry for the second application Cause you > > want to be > > > > > >> identified in the signaling path. > > > > > >> > > > > > >> Sure, you can indicate that they are "involved". But you > > > > > can't infer > > > > > >> anything about which one "caused" something. They might > > > > > have, but you > > > > > >> can't tell it from the presence of these headers. > > > > > >> > > > > > >> Thanks, > > > > > >> Paul > > > > > >> > > > > > >>> Regards, > > > > > >>> Marianne > > > > > >>> > > > > > >>> > > > > > >>>> -----Message d'origine----- De :=20 > sipcore-bounces@ietf.org=20 > > > > > >>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul > > > > > >> Kyzivat Envoy=E9 : > > > > > >>>> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org Objet : = Re: > > > > > [sipcore] > > > > > >>>> I-DAction: > > > > > >>>> draft-mohali-sipcore-reason-extension-application-01 > > > > > >>>> > > > > > >>>> (As individual) > > > > > >>>> > > > > > >>>> Marianne, > > > > > >>>> > > > > > >>>> I'm still struggling to make sense of this in the form > > > > proposed. > > > > > >>>> > > > > > >>>> I look at the various cause values, and all the > > > > > >> descriptions are of > > > > > >>>> the form. E.g.: > > > > > >>>> > > > > > >>>> Cause value: 2 > > > > > >>>> Reason text: Freephone > > > > > >>>> Description: A Freephone application has > > influenced > > > > > >>>> processing of > > > > > >>>> the call (e.g. by translating a dialed=20 > Free Phone > > > > > >> number to a > > > > > >>>> routable directory number). > > > > > >>>> > > > > > >>>> I can't figure out how to make any actionable decision > > > > > >> based on this. > > > > > >>>> Rather, it seems I need to make a number of=20 > leaps of faith > > > > > >> before I > > > > > >>>> can decide what to do. > > > > > >>>> > > > > > >>>> For instance, if I get an error, it *might* be because I > > > > > dialed a > > > > > >>>> freephone number, and it isn't supported from my calling > > > > > location. > > > > > >>>> (E.g. > > > > > >>>> maybe I'm dialing +1-800-555-1234, but I'm doing so from > > > > > >> France, and > > > > > >>>> calling that number is only supported in the USA. > > > > > >>>> > > > > > >>>> But getting a application reason code with cause 2 > > > > > doesn't really > > > > > >>>> tell me that is what happened. It could be that the call > > > > > >> indeed was > > > > > >>>> routed through a freephone application, and it properly > > > > > routed the > > > > > >>>> call, and the call failed for some other reason. But the > > > > > cause is > > > > > >>>> there because the application > > > > > >>>> *did* influence the call routing. > > > > > >>>> > > > > > >>>> Also, these "applications" are not, AFAIK, mutually > > > > > >> exclusive. E.g. I > > > > > >>>> could be using a prepaid service to make a directory > > > > > >> assistance call > > > > > >>>> that costs extra $$$ that I don't have credits to > > > > cover. But you > > > > > >>>> can't include two cause values for the same=20 > protocol. (But > > > > > >> it is true > > > > > >>>> that you > > > > > >>>> *can* have a number of servers each put one cause into > > > > > >>>> *their* H-I entry.) > > > > > >>>> > > > > > >>>> So *maybe* I would see that my call failed, and=20 > that there > > > > > >> is both a > > > > > >>>> reason indicating a prepaid application on one H-I entry, > > > > > >> and another > > > > > >>>> indicating a another H-I indicating a directory service > > > > > >> application. > > > > > >>>> But what can I conclude from that? > > > > > >>>> > > > > > >>>> Bottom line, I just can't make sense how this could be > > > > > >> used in a well > > > > > >>>> defined and interoperable way. > > > > > >>>> > > > > > >>>> Thanks, > > > > > >>>> Paul > > > > > >>>> > > > > > >>>> On 2/28/2011 9:58 AM, > > > marianne.mohali@orange-ftgroup.com wrote: > > > > > >>>>> Hello, > > > > > >>>>> > > > > > >>>>> Here is the new version of the draft. > > > > > >>>>> Main changes are following: > > > > > >>>>> - More details about the registration procedure for > > > new values > > > > > >>>>> - Clearer text in section 3.2 > > > > > >>>>> - Add of Public and Private status for=20 > registered values. > > > > > >>>>> - Add of a range for cause values registration > > > > > >>>>> > > > > > >>>>> Best Regards, > > > > > >>>>> Marianne Mohali > > > > > >>>>> > > > > > >>>>> -----Message d'origine----- Objet : New Version=20 > > > > > >>>>> Notification for > > > > > >>>>> draft-mohali-sipcore-reason-extension-application-01 > > > > > >>>>> > > > > > >>>>> A New Internet-Draft is available from the on-line > > > > > >> Internet-Drafts > > > > > >>>>> directories. > > > > > >>>>> > > > > > >>>>> Title : Extending the Session > > > > > Initiation Protocol > > > > > >>>>> (SIP) Reason Header for Applications > > > > > >>>>> Author(s) : M. Mohali, B. Chatras > > > > > >>>>> Filename : > > > > > >>>>> draft-mohali-sipcore-reason-extension-application-01.txt > > > > > >>>>> Pages : 10 > > > > > >>>>> Date : 2011-02-24 > > > > > >>>>> > > > > > >>>>> This document defines a new protocol value > > > > > "Application" for the > > > > > >>>>> Reason Header field and a new IANA Registry for > > registering > > > > > >>>>> application types. This new value enables > > signaling that a > > > > > >>>> request or > > > > > >>>>> response has been issued as a result of a decision > > > made by a > > > > > >>>>> particular type of application or that an=20 > initial request > > > > > >> has been > > > > > >>>>> retargeted as a result of an application decision. > > > > > >>>>> > > > > > >>>>> A URL for this Internet-Draft is: > > > > > >>>>> > > > > > >>>> > > > > > >> > > > > > > > > > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten > > > > > >>>> s > > > > > >>>>> io > > > > > >>>>> n-application-01.txt > > > > > >>>>> > > > > > >>>>> Internet-Drafts are also available by anonymous FTP at: > > > > > >>>>> ftp://ftp.ietf.org/internet-drafts/ > > > > > >>>>> > > > > > >>>>> Below is the data which will enable a MIME compliant > > > > > mail reader > > > > > >>>>> implementation to automatically retrieve the ASCII > > > > > version of the > > > > > >>>>> Internet-Draft. > > > > > >>>>> > > > > > >>>>> > > > > > >>>> > > > > > >> > > > > > > > > > > > > > >=20 > > > > > >>>> s > > > > > >>>>> io > > > > > >>>>> n-application-01.txt> > > > > > >>>>> > > > > > >>>>> _______________________________________________ > > > > > >>>>> I-D-Announce mailing list > > > > > >>>>> I-D-Announce@ietf.org > > > > > >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > >>>>> Internet-Draft directories: > > > > http://www.ietf.org/shadow.html or > > > > > >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >>>>> _______________________________________________ > > > > > >>>>> sipcore mailing list > > > > > >>>>> sipcore@ietf.org > > > > > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > > > > > >>>>> > > > > > >>>> _______________________________________________ > > > > > >>>> sipcore mailing list > > > > > >>>> sipcore@ietf.org > > > > > >>>> https://www.ietf.org/mailman/listinfo/sipcore > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > >=20 From john.elwell@siemens-enterprise.com Fri Mar 18 03:50:16 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D483A6B03 for ; Fri, 18 Mar 2011 03:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ncDctGE4m8e for ; Fri, 18 Mar 2011 03:50:14 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4360A3A6B05 for ; Fri, 18 Mar 2011 03:50:13 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3795231; Fri, 18 Mar 2011 11:51:42 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 285B823F028E; Fri, 18 Mar 2011 11:51:42 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 18 Mar 2011 11:51:42 +0100 From: "Elwell, John" To: "marianne.mohali@orange-ftgroup.com" , "pkyzivat@cisco.com" Date: Fri, 18 Mar 2011 11:51:40 +0100 Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvcYISb0u1jdMeySTaPExDFDWj03gAgAOHgAJZ9baABW91BUAAk6kVQAAEMsiAABX52gA== Message-ID: References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 10:50:16 -0000 > > [JRE] This does not fully address the point I was making. I > > was making the point that to find the particular hi-entry you > > are interested in you need, at present, to scan hi-entries > > looking at their parameters - you do not need to look at the > > URIs in those hi-entries and the URIs' "headers" components > > in order to find the hi-entry you are looking for. Of course, > > once you have found the hi-entry you are looking for, you > > will be interested in the URI and in anything attached to it, > > including Privacy and Reason header fields within its > > "headers" component. The draft under discussion seems to > > change that principle so that in order to find the hi-entry > > you are looking for you need to look inside the URIs. This > > seems to me like a change of principle - the logic of > > including the proposed application information in the URI as > > a header field, rather than in hi-entry parameters, is not at > > all clear to me. > [MM] I don't see the problem with your point. hi-entry parameters > are not incompatible with URIs' headers. > hi-entry parameters, allow to do a first sort in hi-entries, then, > according to UAS needs, URI headers or parameters give a complementary > information. > Imagine a situation where you have Alice calling Bob with a prepaid > calling card and Bod doesn't answer so the call is retargeted to the > voicemail. > You would have the following sequence in the last INVITE (last leg): > I didn't show possible intermediary proxies entries) > History-Info: > ;cause=3D9;text=3D"Prepaid">;index=3D1, > > ;index=3D1.1;mp= =3D1, > > index=3D1.1.1;mp= =3D1.1 [JRE] So in this particular case, the application might search for the earl= iest entry marked mp, which points to the hi-entry with index 1, and that c= ontains the Prepaid reason. I suppose that works (subject to my earlier cav= eat about needing to be in a closed network to rely on that information). H= owever, the fact that it works in this particular scenario does not necessa= rily mean it is the correct mechanism, and I would like to hear other opini= ons. John > > Marianne > > > > John > > > > > > > > > > Marianne > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > > > > marianne.mohali@orange-ftgroup.com > > > > > Sent: 07 March 2011 18:30 > > > > > To: pkyzivat@cisco.com > > > > > Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com > > > > > Subject: Re: [sipcore] I-DAction: > > > > > draft-mohali-sipcore-reason-extension-application-01 > > > > > > > > > > Paul, > > > > > > > > > > I think that Christer's draft (proxy-feature) is about > > > capabilities > > > > > while this one (reason-extension-application) is about > > > what really > > > > > happened (like reason in general). It is provided only when > > > > the event > > > > > happens and the purpose is to give an accuate information for > > > > > applicative events. > > > > > > > > > > Let me give you an other example: > > > > > A reception AS called with several premium rate numbers (1 > > > > per hosted > > > > > application/service). The AS dispatches calls to several > > > > call centers > > > > > (eg. Depending on charge, hour of the day/night...). > The final > > > > > destination needs to know the called service. The premuim > > > > rate number > > > > > should be listed in the H-I header. Which entry? For which > > > > > application/service invocated? > > > > > As you can have a call forwarding reason associated to a > > > 3xx or 486 > > > > > Reason-cause, you could have an applicative reason to > > > > easily identify > > > > > the premium rate dialed number. > > > > > > > > > > Regards, > > > > > Marianne > > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : > > > > lundi 7 mars > > > > > > 2011 01:42 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > > > sipcore@ietf.org; > > > > > > Christer.Holmberg@ericsson.com Objet : Re: [sipcore] > > I-DAction: > > > > > > draft-mohali-sipcore-reason-extension-application-01 > > > > > > > > > > > > Marianne > > > > > > > > > > > > On 3/4/2011 11:59 AM, > > marianne.mohali@orange-ftgroup.com wrote: > > > > > > > Hi Paul, > > > > > > > > > > > > > > My answer below [MM] > > > > > > > > > > > > > > Marianne > > > > > > >> -----Message d'origine----- > > > > > > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : > > > > > > jeudi 3 mars > > > > > > >> 2011 18:31 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > > > > > sipcore@ietf.org; > > > > > > >> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] > > > I-DAction: > > > > > > >> draft-mohali-sipcore-reason-extension-application-01 > > > > > > >> > > > > > > >> Marianne, > > > > > > >> > > > > > > >> On 3/3/2011 11:51 AM, > > > marianne.mohali@orange-ftgroup.com wrote: > > > > > > >>> Hi Paul, > > > > > > >>> > > > > > > >>> The purpose is to allow applications/services to be > > > > > > >> explicitely identified in the signaling path, so > > that others > > > > > > >> services/applications/telephony-AS can act accordingly. > > > > > > >> Either to apply a process taking into account the service > > > > > > interaction > > > > > > >> or on the contrary, do not execute a feature already > > > > > > covered by the > > > > > > >> application. > > > > > > >>> For instance, a caller with a prepaid service calls a > > > > > > >> directory enquiries Server to ask for a restaurant phone > > > > > > number. The > > > > > > >> operator would suggest to connect the caller to the > > > > > > researched phone > > > > > > >> number EXCEPT if the caller has a prepaid service because > > > > > > it is not > > > > > > >> sure he has enough credit to pay for the > communication. To > > > > > > allow this > > > > > > >> customized feature, the directory enquiries Application > > > > > > needs to know > > > > > > >> that the prepaid Application has been invocated. > > > > > > >> > > > > > > >> So once again, we are back to your wanting to use > > > > Reason not to > > > > > > >> express a "reason" for anything, but rather as just a > > > > > hook to hang > > > > > > >> something on H-I. > > > > > > > [MM] The *reason* why the call has been > > > > > > retargeted/rejected/modified is the invocation of a > specific > > > > > > application. > > > > > > > If you call a Service number and then the URI is changed > > > > > > for routing to the real destination, the *reason* > of the URI > > > > > > modification (listed in H-I) is the application. > > > > > > > > > > > > Based on your other replies, this is not necessarily so. > > > > > > > > > > > > In fact the example above is a counter-example. > > > > > > The prepaid service is not responsible for any > > > > redirection, and the > > > > > > operator service is looking for it for a reason other > > > > than that it > > > > > > has been the cause of anything. Its looking for it > > > > because it might > > > > > > be the cause of something in the future. > > > > > > > > > > > > >> (With the causes you have defined, I can't imagine > > it making > > > > > > >> *any* sense to actually use one in a Reason header in > > > > a message, > > > > > > >> because they aren't specific enough to be actionable.) > > > > > > >> > > > > > > >> I am now thinking there is a large overlap between > > > > what you are > > > > > > >> trying to accomplish this way, and what Christer is > > > trying to > > > > > > >> accomplish with draft-holmberg-sipcore-proxy-feature. > > > > > > >> > > > > > > >> Is that true? > > > > > > >> > > > > > > >> (Christer: What do you think?) > > > > > > > [MM] I don't see the overlap with Christer's draft because > > > > > > it is not about capabilities, it is about what's happened. > > > > > > > > > > > > In your example above, it seems that the operator service > > > > is looking > > > > > > for the prepaid service because the prepaid service has the > > > > > > capability to influence billing, or something like that. > > > > This seems > > > > > > at least somewhat in line with what Christer is > > > > advocating. Looking > > > > > > in the Route header, or Record-Route header would make at > > > > least as > > > > > > much sense for this case as looking in H-I. H-I makes > > > > sense if you > > > > > > are indeed looking for something that has already > > > > happened, perhaps > > > > > > on a path other that the current one. > > > > > > > > > > > > I think it would be helpful for the two of you to > > come to some > > > > > > reconciliation of what you are trying to accomplish. > > > > > > > > > > > > Thanks, > > > > > > Paul > > > > > > > > > > > > >>> About your comment in case of several > > applications involved > > > > > > >> *simultaneously* in the call establishment, it > is possible > > > > > > to add 1 > > > > > > >> more hi-entry for the second application Cause you > > > want to be > > > > > > >> identified in the signaling path. > > > > > > >> > > > > > > >> Sure, you can indicate that they are "involved". But you > > > > > > can't infer > > > > > > >> anything about which one "caused" something. They might > > > > > > have, but you > > > > > > >> can't tell it from the presence of these headers. > > > > > > >> > > > > > > >> Thanks, > > > > > > >> Paul > > > > > > >> > > > > > > >>> Regards, > > > > > > >>> Marianne > > > > > > >>> > > > > > > >>> > > > > > > >>>> -----Message d'origine----- De : > > sipcore-bounces@ietf.org > > > > > > >>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul > > > > > > >> Kyzivat Envoy=E9 : > > > > > > >>>> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org > Objet : Re: > > > > > > [sipcore] > > > > > > >>>> I-DAction: > > > > > > >>>> draft-mohali-sipcore-reason-extension-application-01 > > > > > > >>>> > > > > > > >>>> (As individual) > > > > > > >>>> > > > > > > >>>> Marianne, > > > > > > >>>> > > > > > > >>>> I'm still struggling to make sense of this in the form > > > > > proposed. > > > > > > >>>> > > > > > > >>>> I look at the various cause values, and all the > > > > > > >> descriptions are of > > > > > > >>>> the form. E.g.: > > > > > > >>>> > > > > > > >>>> Cause value: 2 > > > > > > >>>> Reason text: Freephone > > > > > > >>>> Description: A Freephone application has > > > influenced > > > > > > >>>> processing of > > > > > > >>>> the call (e.g. by translating a dialed > > Free Phone > > > > > > >> number to a > > > > > > >>>> routable directory number). > > > > > > >>>> > > > > > > >>>> I can't figure out how to make any actionable decision > > > > > > >> based on this. > > > > > > >>>> Rather, it seems I need to make a number of > > leaps of faith > > > > > > >> before I > > > > > > >>>> can decide what to do. > > > > > > >>>> > > > > > > >>>> For instance, if I get an error, it *might* be > because I > > > > > > dialed a > > > > > > >>>> freephone number, and it isn't supported from > my calling > > > > > > location. > > > > > > >>>> (E.g. > > > > > > >>>> maybe I'm dialing +1-800-555-1234, but I'm > doing so from > > > > > > >> France, and > > > > > > >>>> calling that number is only supported in the USA. > > > > > > >>>> > > > > > > >>>> But getting a application reason code with cause 2 > > > > > > doesn't really > > > > > > >>>> tell me that is what happened. It could be > that the call > > > > > > >> indeed was > > > > > > >>>> routed through a freephone application, and it properly > > > > > > routed the > > > > > > >>>> call, and the call failed for some other > reason. But the > > > > > > cause is > > > > > > >>>> there because the application > > > > > > >>>> *did* influence the call routing. > > > > > > >>>> > > > > > > >>>> Also, these "applications" are not, AFAIK, mutually > > > > > > >> exclusive. E.g. I > > > > > > >>>> could be using a prepaid service to make a directory > > > > > > >> assistance call > > > > > > >>>> that costs extra $$$ that I don't have credits to > > > > > cover. But you > > > > > > >>>> can't include two cause values for the same > > protocol. (But > > > > > > >> it is true > > > > > > >>>> that you > > > > > > >>>> *can* have a number of servers each put one cause into > > > > > > >>>> *their* H-I entry.) > > > > > > >>>> > > > > > > >>>> So *maybe* I would see that my call failed, and > > that there > > > > > > >> is both a > > > > > > >>>> reason indicating a prepaid application on one > H-I entry, > > > > > > >> and another > > > > > > >>>> indicating a another H-I indicating a directory service > > > > > > >> application. > > > > > > >>>> But what can I conclude from that? > > > > > > >>>> > > > > > > >>>> Bottom line, I just can't make sense how this could be > > > > > > >> used in a well > > > > > > >>>> defined and interoperable way. > > > > > > >>>> > > > > > > >>>> Thanks, > > > > > > >>>> Paul > > > > > > >>>> > > > > > > >>>> On 2/28/2011 9:58 AM, > > > > marianne.mohali@orange-ftgroup.com wrote: > > > > > > >>>>> Hello, > > > > > > >>>>> > > > > > > >>>>> Here is the new version of the draft. > > > > > > >>>>> Main changes are following: > > > > > > >>>>> - More details about the registration procedure for > > > > new values > > > > > > >>>>> - Clearer text in section 3.2 > > > > > > >>>>> - Add of Public and Private status for > > registered values. > > > > > > >>>>> - Add of a range for cause values registration > > > > > > >>>>> > > > > > > >>>>> Best Regards, > > > > > > >>>>> Marianne Mohali > > > > > > >>>>> > > > > > > >>>>> -----Message d'origine----- Objet : New Version > > > > > > >>>>> Notification for > > > > > > >>>>> draft-mohali-sipcore-reason-extension-application-01 > > > > > > >>>>> > > > > > > >>>>> A New Internet-Draft is available from the on-line > > > > > > >> Internet-Drafts > > > > > > >>>>> directories. > > > > > > >>>>> > > > > > > >>>>> Title : Extending the Session > > > > > > Initiation Protocol > > > > > > >>>>> (SIP) Reason Header for Applications > > > > > > >>>>> Author(s) : M. Mohali, B. Chatras > > > > > > >>>>> Filename : > > > > > > >>>>> > draft-mohali-sipcore-reason-extension-application-01.txt > > > > > > >>>>> Pages : 10 > > > > > > >>>>> Date : 2011-02-24 > > > > > > >>>>> > > > > > > >>>>> This document defines a new protocol value > > > > > > "Application" for the > > > > > > >>>>> Reason Header field and a new IANA Registry for > > > registering > > > > > > >>>>> application types. This new value enables > > > signaling that a > > > > > > >>>> request or > > > > > > >>>>> response has been issued as a result of a decision > > > > made by a > > > > > > >>>>> particular type of application or that an > > initial request > > > > > > >> has been > > > > > > >>>>> retargeted as a result of an application decision. > > > > > > >>>>> > > > > > > >>>>> A URL for this Internet-Draft is: > > > > > > >>>>> > > > > > > >>>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten > > > > > > >>>> s > > > > > > >>>>> io > > > > > > >>>>> n-application-01.txt > > > > > > >>>>> > > > > > > >>>>> Internet-Drafts are also available by > anonymous FTP at: > > > > > > >>>>> ftp://ftp.ietf.org/internet-drafts/ > > > > > > >>>>> > > > > > > >>>>> Below is the data which will enable a MIME compliant > > > > > > mail reader > > > > > > >>>>> implementation to automatically retrieve the ASCII > > > > > > version of the > > > > > > >>>>> Internet-Draft. > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> s > > > > > > >>>>> io > > > > > > >>>>> n-application-01.txt> > > > > > > >>>>> > > > > > > >>>>> _______________________________________________ > > > > > > >>>>> I-D-Announce mailing list > > > > > > >>>>> I-D-Announce@ietf.org > > > > > > >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > > >>>>> Internet-Draft directories: > > > > > http://www.ietf.org/shadow.html or > > > > > > >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > >>>>> _______________________________________________ > > > > > > >>>>> sipcore mailing list > > > > > > >>>>> sipcore@ietf.org > > > > > > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > > > > > > >>>>> > > > > > > >>>> _______________________________________________ > > > > > > >>>> sipcore mailing list > > > > > > >>>> sipcore@ietf.org > > > > > > >>>> https://www.ietf.org/mailman/listinfo/sipcore > > > > > > >>>> > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > sipcore mailing list > > > > > sipcore@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > From pkyzivat@cisco.com Fri Mar 18 05:42:04 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81CC3A68F2 for ; Fri, 18 Mar 2011 05:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.541 X-Spam-Level: X-Spam-Status: No, score=-110.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZVDQAHSZaX7 for ; Fri, 18 Mar 2011 05:42:03 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E679D3A68D3 for ; Fri, 18 Mar 2011 05:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=716; q=dns/txt; s=iport; t=1300452213; x=1301661813; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=C9izgqEOhxu62QUCx0LmOae4Z5NUvQYgwPOgDA9/RCU=; b=Evxr2L4HPNCrSze2kr2dmrX4noNbag4BWLOl3F11Flm6cNtcfD40KwQ5 L7uUFQPPXFr9t3Ek9zgSkGJt8Z2sKSRXI56jl0jszw+M9x1cN/ndiFLAt fEZoPE3jCpUlF/xqBgTQYTlqqNOYEy22qzCSRLMcqvcGuD4qCuvUIRrvd w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQHADLwgk2tJXHB/2dsb2JhbACYdYx2d4hNnWacEIVjBIxjg08 X-IronPort-AV: E=Sophos;i="4.63,205,1299456000"; d="scan'208";a="348726368" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 18 Mar 2011 12:43:32 +0000 Received: from [161.44.174.126] (dhcp-161-44-174-126.cisco.com [161.44.174.126]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2IChWW8009720; Fri, 18 Mar 2011 12:43:32 GMT Message-ID: <4D835374.8070007@cisco.com> Date: Fri, 18 Mar 2011 08:43:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: marianne.mohali@orange-ftgroup.com References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 12:42:04 -0000 On 3/18/2011 5:29 AM, marianne.mohali@orange-ftgroup.com wrote: > Imagine a situation where you have Alice calling Bob with a prepaid > calling card and Bod doesn't answer so the call is retargeted to the > voicemail. > You would have the following sequence in the last INVITE (last leg): > I didn't show possible intermediary proxies entries) > History-Info: > ;cause=9;text="Prepaid">;index=1, > ;index=1.1;mp=1, > index=1.1.1;mp=1.1 Where is Alice in this? Shouldn't Alice be index=1? Thanks, Paul From pkyzivat@cisco.com Fri Mar 18 05:49:44 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA3E33A68F4 for ; Fri, 18 Mar 2011 05:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqRGP2tH8WAK for ; Fri, 18 Mar 2011 05:49:43 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id ED5BC3A68F6 for ; Fri, 18 Mar 2011 05:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=16484; q=dns/txt; s=iport; t=1300452672; x=1301662272; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gckck1ItTe3lfHEPj7rSwcNhCXaM6izWFcfPS7SYMaY=; b=m7lMJdGj4qI+VJfd67xRBzyEIsSlm+ZXg6drtef3RK8l+MW0QCfjSVqT jFK0JN4FHNRBWMV5TFYcaIR5MhSUiLY3j5Gx97J4DKC2LJnMOPdgdPcLc Ohu+21xV9EvSHQMjufWvVBWnNITNFvv5vpshmDL7+XXkomQ1XzXbBwOjQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIvygk2tJXG//2dsb2JhbACla3emNJwSgnsTB4JOBIxjg08 X-IronPort-AV: E=Sophos;i="4.63,205,1299456000"; d="scan'208";a="348729352" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-5.cisco.com with ESMTP; 18 Mar 2011 12:50:51 +0000 Received: from [161.44.174.126] (dhcp-161-44-174-126.cisco.com [161.44.174.126]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2ICopqD026679; Fri, 18 Mar 2011 12:50:51 GMT Message-ID: <4D83552A.3040805@cisco.com> Date: Fri, 18 Mar 2011 08:50:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Elwell, John" References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 12:49:44 -0000 [as individual] IMO the question John asks is pertinent to almost *any* piece of information you might want to derive from H-I. I have the feeling that generally the algorithm you might come up with will be highly dependent on the individual behaviors of elements in the network, and so will be highly fragile, except in specific closed environments. Thanks, Paul On 3/18/2011 6:51 AM, Elwell, John wrote: > >>> [JRE] This does not fully address the point I was making. I >>> was making the point that to find the particular hi-entry you >>> are interested in you need, at present, to scan hi-entries >>> looking at their parameters - you do not need to look at the >>> URIs in those hi-entries and the URIs' "headers" components >>> in order to find the hi-entry you are looking for. Of course, >>> once you have found the hi-entry you are looking for, you >>> will be interested in the URI and in anything attached to it, >>> including Privacy and Reason header fields within its >>> "headers" component. The draft under discussion seems to >>> change that principle so that in order to find the hi-entry >>> you are looking for you need to look inside the URIs. This >>> seems to me like a change of principle - the logic of >>> including the proposed application information in the URI as >>> a header field, rather than in hi-entry parameters, is not at >>> all clear to me. >> [MM] I don't see the problem with your point. hi-entry parameters >> are not incompatible with URIs' headers. >> hi-entry parameters, allow to do a first sort in hi-entries, then, >> according to UAS needs, URI headers or parameters give a complementary >> information. >> Imagine a situation where you have Alice calling Bob with a prepaid >> calling card and Bod doesn't answer so the call is retargeted to the >> voicemail. >> You would have the following sequence in the last INVITE (last leg): >> I didn't show possible intermediary proxies entries) >> History-Info: >> > ;cause=9;text="Prepaid">;index=1, >> >> ;index=1.1;mp=1, >> >> index=1.1.1;mp=1.1 > > [JRE] So in this particular case, the application might search for the earliest entry marked mp, which points to the hi-entry with index 1, and that contains the Prepaid reason. I suppose that works (subject to my earlier caveat about needing to be in a closed network to rely on that information). However, the fact that it works in this particular scenario does not necessarily mean it is the correct mechanism, and I would like to hear other opinions. > > John > >> >> Marianne >>> >>> John >>> >>> >>>> >>>> Marianne >>>>> >>>>> John >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: sipcore-bounces@ietf.org >>>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of >>>>>> marianne.mohali@orange-ftgroup.com >>>>>> Sent: 07 March 2011 18:30 >>>>>> To: pkyzivat@cisco.com >>>>>> Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com >>>>>> Subject: Re: [sipcore] I-DAction: >>>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>>> >>>>>> Paul, >>>>>> >>>>>> I think that Christer's draft (proxy-feature) is about >>>> capabilities >>>>>> while this one (reason-extension-application) is about >>>> what really >>>>>> happened (like reason in general). It is provided only when >>>>> the event >>>>>> happens and the purpose is to give an accuate information for >>>>>> applicative events. >>>>>> >>>>>> Let me give you an other example: >>>>>> A reception AS called with several premium rate numbers (1 >>>>> per hosted >>>>>> application/service). The AS dispatches calls to several >>>>> call centers >>>>>> (eg. Depending on charge, hour of the day/night...). >> The final >>>>>> destination needs to know the called service. The premuim >>>>> rate number >>>>>> should be listed in the H-I header. Which entry? For which >>>>>> application/service invocated? >>>>>> As you can have a call forwarding reason associated to a >>>> 3xx or 486 >>>>>> Reason-cause, you could have an applicative reason to >>>>> easily identify >>>>>> the premium rate dialed number. >>>>>> >>>>>> Regards, >>>>>> Marianne >>>>>> >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoyé : >>>>> lundi 7 mars >>>>>>> 2011 01:42 À : MOHALI Marianne RD-CORE-ISS Cc : >>>> sipcore@ietf.org; >>>>>>> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] >>> I-DAction: >>>>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>>>> >>>>>>> Marianne >>>>>>> >>>>>>> On 3/4/2011 11:59 AM, >>> marianne.mohali@orange-ftgroup.com wrote: >>>>>>>> Hi Paul, >>>>>>>> >>>>>>>> My answer below [MM] >>>>>>>> >>>>>>>> Marianne >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoyé : >>>>>>> jeudi 3 mars >>>>>>>>> 2011 18:31 À : MOHALI Marianne RD-CORE-ISS Cc : >>>>>> sipcore@ietf.org; >>>>>>>>> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] >>>> I-DAction: >>>>>>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>>>>>> >>>>>>>>> Marianne, >>>>>>>>> >>>>>>>>> On 3/3/2011 11:51 AM, >>>> marianne.mohali@orange-ftgroup.com wrote: >>>>>>>>>> Hi Paul, >>>>>>>>>> >>>>>>>>>> The purpose is to allow applications/services to be >>>>>>>>> explicitely identified in the signaling path, so >>> that others >>>>>>>>> services/applications/telephony-AS can act accordingly. >>>>>>>>> Either to apply a process taking into account the service >>>>>>> interaction >>>>>>>>> or on the contrary, do not execute a feature already >>>>>>> covered by the >>>>>>>>> application. >>>>>>>>>> For instance, a caller with a prepaid service calls a >>>>>>>>> directory enquiries Server to ask for a restaurant phone >>>>>>> number. The >>>>>>>>> operator would suggest to connect the caller to the >>>>>>> researched phone >>>>>>>>> number EXCEPT if the caller has a prepaid service because >>>>>>> it is not >>>>>>>>> sure he has enough credit to pay for the >> communication. To >>>>>>> allow this >>>>>>>>> customized feature, the directory enquiries Application >>>>>>> needs to know >>>>>>>>> that the prepaid Application has been invocated. >>>>>>>>> >>>>>>>>> So once again, we are back to your wanting to use >>>>> Reason not to >>>>>>>>> express a "reason" for anything, but rather as just a >>>>>> hook to hang >>>>>>>>> something on H-I. >>>>>>>> [MM] The *reason* why the call has been >>>>>>> retargeted/rejected/modified is the invocation of a >> specific >>>>>>> application. >>>>>>>> If you call a Service number and then the URI is changed >>>>>>> for routing to the real destination, the *reason* >> of the URI >>>>>>> modification (listed in H-I) is the application. >>>>>>> >>>>>>> Based on your other replies, this is not necessarily so. >>>>>>> >>>>>>> In fact the example above is a counter-example. >>>>>>> The prepaid service is not responsible for any >>>>> redirection, and the >>>>>>> operator service is looking for it for a reason other >>>>> than that it >>>>>>> has been the cause of anything. Its looking for it >>>>> because it might >>>>>>> be the cause of something in the future. >>>>>>> >>>>>>>>> (With the causes you have defined, I can't imagine >>> it making >>>>>>>>> *any* sense to actually use one in a Reason header in >>>>> a message, >>>>>>>>> because they aren't specific enough to be actionable.) >>>>>>>>> >>>>>>>>> I am now thinking there is a large overlap between >>>>> what you are >>>>>>>>> trying to accomplish this way, and what Christer is >>>> trying to >>>>>>>>> accomplish with draft-holmberg-sipcore-proxy-feature. >>>>>>>>> >>>>>>>>> Is that true? >>>>>>>>> >>>>>>>>> (Christer: What do you think?) >>>>>>>> [MM] I don't see the overlap with Christer's draft because >>>>>>> it is not about capabilities, it is about what's happened. >>>>>>> >>>>>>> In your example above, it seems that the operator service >>>>> is looking >>>>>>> for the prepaid service because the prepaid service has the >>>>>>> capability to influence billing, or something like that. >>>>> This seems >>>>>>> at least somewhat in line with what Christer is >>>>> advocating. Looking >>>>>>> in the Route header, or Record-Route header would make at >>>>> least as >>>>>>> much sense for this case as looking in H-I. H-I makes >>>>> sense if you >>>>>>> are indeed looking for something that has already >>>>> happened, perhaps >>>>>>> on a path other that the current one. >>>>>>> >>>>>>> I think it would be helpful for the two of you to >>> come to some >>>>>>> reconciliation of what you are trying to accomplish. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>>>> About your comment in case of several >>> applications involved >>>>>>>>> *simultaneously* in the call establishment, it >> is possible >>>>>>> to add 1 >>>>>>>>> more hi-entry for the second application Cause you >>>> want to be >>>>>>>>> identified in the signaling path. >>>>>>>>> >>>>>>>>> Sure, you can indicate that they are "involved". But you >>>>>>> can't infer >>>>>>>>> anything about which one "caused" something. They might >>>>>>> have, but you >>>>>>>>> can't tell it from the presence of these headers. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Marianne >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Message d'origine----- De : >>> sipcore-bounces@ietf.org >>>>>>>>>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul >>>>>>>>> Kyzivat Envoyé : >>>>>>>>>>> mardi 1 mars 2011 00:16 À : sipcore@ietf.org >> Objet : Re: >>>>>>> [sipcore] >>>>>>>>>>> I-DAction: >>>>>>>>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>>>>>>>> >>>>>>>>>>> (As individual) >>>>>>>>>>> >>>>>>>>>>> Marianne, >>>>>>>>>>> >>>>>>>>>>> I'm still struggling to make sense of this in the form >>>>>> proposed. >>>>>>>>>>> >>>>>>>>>>> I look at the various cause values, and all the >>>>>>>>> descriptions are of >>>>>>>>>>> the form. E.g.: >>>>>>>>>>> >>>>>>>>>>> Cause value: 2 >>>>>>>>>>> Reason text: Freephone >>>>>>>>>>> Description: A Freephone application has >>>> influenced >>>>>>>>>>> processing of >>>>>>>>>>> the call (e.g. by translating a dialed >>> Free Phone >>>>>>>>> number to a >>>>>>>>>>> routable directory number). >>>>>>>>>>> >>>>>>>>>>> I can't figure out how to make any actionable decision >>>>>>>>> based on this. >>>>>>>>>>> Rather, it seems I need to make a number of >>> leaps of faith >>>>>>>>> before I >>>>>>>>>>> can decide what to do. >>>>>>>>>>> >>>>>>>>>>> For instance, if I get an error, it *might* be >> because I >>>>>>> dialed a >>>>>>>>>>> freephone number, and it isn't supported from >> my calling >>>>>>> location. >>>>>>>>>>> (E.g. >>>>>>>>>>> maybe I'm dialing +1-800-555-1234, but I'm >> doing so from >>>>>>>>> France, and >>>>>>>>>>> calling that number is only supported in the USA. >>>>>>>>>>> >>>>>>>>>>> But getting a application reason code with cause 2 >>>>>>> doesn't really >>>>>>>>>>> tell me that is what happened. It could be >> that the call >>>>>>>>> indeed was >>>>>>>>>>> routed through a freephone application, and it properly >>>>>>> routed the >>>>>>>>>>> call, and the call failed for some other >> reason. But the >>>>>>> cause is >>>>>>>>>>> there because the application >>>>>>>>>>> *did* influence the call routing. >>>>>>>>>>> >>>>>>>>>>> Also, these "applications" are not, AFAIK, mutually >>>>>>>>> exclusive. E.g. I >>>>>>>>>>> could be using a prepaid service to make a directory >>>>>>>>> assistance call >>>>>>>>>>> that costs extra $$$ that I don't have credits to >>>>>> cover. But you >>>>>>>>>>> can't include two cause values for the same >>> protocol. (But >>>>>>>>> it is true >>>>>>>>>>> that you >>>>>>>>>>> *can* have a number of servers each put one cause into >>>>>>>>>>> *their* H-I entry.) >>>>>>>>>>> >>>>>>>>>>> So *maybe* I would see that my call failed, and >>> that there >>>>>>>>> is both a >>>>>>>>>>> reason indicating a prepaid application on one >> H-I entry, >>>>>>>>> and another >>>>>>>>>>> indicating a another H-I indicating a directory service >>>>>>>>> application. >>>>>>>>>>> But what can I conclude from that? >>>>>>>>>>> >>>>>>>>>>> Bottom line, I just can't make sense how this could be >>>>>>>>> used in a well >>>>>>>>>>> defined and interoperable way. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>> >>>>>>>>>>> On 2/28/2011 9:58 AM, >>>>> marianne.mohali@orange-ftgroup.com wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Here is the new version of the draft. >>>>>>>>>>>> Main changes are following: >>>>>>>>>>>> - More details about the registration procedure for >>>>> new values >>>>>>>>>>>> - Clearer text in section 3.2 >>>>>>>>>>>> - Add of Public and Private status for >>> registered values. >>>>>>>>>>>> - Add of a range for cause values registration >>>>>>>>>>>> >>>>>>>>>>>> Best Regards, >>>>>>>>>>>> Marianne Mohali >>>>>>>>>>>> >>>>>>>>>>>> -----Message d'origine----- Objet : New Version >>>>>>>>>>>> Notification for >>>>>>>>>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>>>>>>>>> >>>>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>> Internet-Drafts >>>>>>>>>>>> directories. >>>>>>>>>>>> >>>>>>>>>>>> Title : Extending the Session >>>>>>> Initiation Protocol >>>>>>>>>>>> (SIP) Reason Header for Applications >>>>>>>>>>>> Author(s) : M. Mohali, B. Chatras >>>>>>>>>>>> Filename : >>>>>>>>>>>> >> draft-mohali-sipcore-reason-extension-application-01.txt >>>>>>>>>>>> Pages : 10 >>>>>>>>>>>> Date : 2011-02-24 >>>>>>>>>>>> >>>>>>>>>>>> This document defines a new protocol value >>>>>>> "Application" for the >>>>>>>>>>>> Reason Header field and a new IANA Registry for >>>> registering >>>>>>>>>>>> application types. This new value enables >>>> signaling that a >>>>>>>>>>> request or >>>>>>>>>>>> response has been issued as a result of a decision >>>>> made by a >>>>>>>>>>>> particular type of application or that an >>> initial request >>>>>>>>> has been >>>>>>>>>>>> retargeted as a result of an application decision. >>>>>>>>>>>> >>>>>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten >>>>>>>>>>> s >>>>>>>>>>>> io >>>>>>>>>>>> n-application-01.txt >>>>>>>>>>>> >>>>>>>>>>>> Internet-Drafts are also available by >> anonymous FTP at: >>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>> >>>>>>>>>>>> Below is the data which will enable a MIME compliant >>>>>>> mail reader >>>>>>>>>>>> implementation to automatically retrieve the ASCII >>>>>>> version of the >>>>>>>>>>>> Internet-Draft. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >>>>>>>>>> s >>>>>>>>>>>> io >>>>>>>>>>>> n-application-01.txt> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> I-D-Announce mailing list >>>>>>>>>>>> I-D-Announce@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>> Internet-Draft directories: >>>>>> http://www.ietf.org/shadow.html or >>>>>>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sipcore mailing list >>>>>>>>>>>> sipcore@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sipcore mailing list >>>>>>>>>>> sipcore@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>>> >>>> >>> >> > From marianne.mohali@orange-ftgroup.com Fri Mar 18 06:01:54 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67563A68F4 for ; Fri, 18 Mar 2011 06:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfDeUiuHYevr for ; Fri, 18 Mar 2011 06:01:54 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id C455B3A68F9 for ; Fri, 18 Mar 2011 06:01:53 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 98D62778004; Fri, 18 Mar 2011 14:09:11 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 90471778001; Fri, 18 Mar 2011 14:09:11 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 14:03:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Mar 2011 14:03:21 +0100 Message-ID: In-Reply-To: <4D835374.8070007@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvlahhdLWrnzXLdRrOR2/uKgxQjZAAAqPwg References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com> <4D835374.8070007@cisco.com> From: To: X-OriginalArrivalTime: 18 Mar 2011 13:03:23.0101 (UTC) FILETIME=[DCA1C8D0:01CBE56C] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 13:01:54 -0000 > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Envoy=E9 : vendredi 18 mars 2011 13:44 > =C0 : MOHALI Marianne RD-CORE-ISS > Cc : john.elwell@siemens-enterprise.com; sipcore@ietf.org;=20 > Christer.Holmberg@ericsson.com > Objet : Re: [sipcore]=20 > I-DAction:draft-mohali-sipcore-reason-extension-application-01 >=20 >=20 >=20 > On 3/18/2011 5:29 AM, marianne.mohali@orange-ftgroup.com wrote: >=20 > > Imagine a situation where you have Alice calling Bob with a prepaid=20 > > calling card and Bod doesn't answer so the call is=20 > retargeted to the=20 > > voicemail. > > You would have the following sequence in the last INVITE (last leg): > > I didn't show possible intermediary proxies entries) > > History-Info: > > > ;cause=3D9;text=3D"Prepaid">;index=3D1, > > =20 > = ;index=3D1.1;mp=3D= 1, > > =20 > >=20 > = index=3D1.1.1;mp=3D= 1.1 >=20 > Where is Alice in this? Shouldn't Alice be index=3D1? [MM] Alice is in the From header field. No? >=20 > Thanks, > Paul >=20 From pkyzivat@cisco.com Fri Mar 18 06:23:55 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04873A68F4 for ; Fri, 18 Mar 2011 06:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.543 X-Spam-Level: X-Spam-Status: No, score=-110.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKDWnd6ByLBk for ; Fri, 18 Mar 2011 06:23:54 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3E82F3A68B1 for ; Fri, 18 Mar 2011 06:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1397; q=dns/txt; s=iport; t=1300454723; x=1301664323; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=F7ufZo5cgio9PQZ874PseHnKtJMYRWNByUs7PhXS98c=; b=JKTMZ5XlI3Wq7TkiqJ/DHirOSXxwP0Utefg2KEqvpf+W+SjniYVwPoGm 1F5K+m6RK4phPmU9bEcqPLa3xUQd8M25leELBH0z+t8CYmgG5zcxRyP7e D619ZZCnoFVwfg5LvGTzxRR4lz4QC2Wqh8RyK5pyE+DHyeYm4oq8d2Xmy g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQHAAv6gk2tJXG9/2dsb2JhbACYdYx2d6YvnBGFYwSMY4NP X-IronPort-AV: E=Sophos;i="4.63,205,1299456000"; d="scan'208";a="279572865" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 18 Mar 2011 13:25:23 +0000 Received: from [161.44.174.126] (dhcp-161-44-174-126.cisco.com [161.44.174.126]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2IDPMhX004876; Fri, 18 Mar 2011 13:25:22 GMT Message-ID: <4D835D42.2030400@cisco.com> Date: Fri, 18 Mar 2011 09:25:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: marianne.mohali@orange-ftgroup.com References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com> <4D835374.8070007@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 13:23:55 -0000 At end... On 3/18/2011 9:03 AM, marianne.mohali@orange-ftgroup.com wrote: > >> -----Message d'origine----- >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Envoyé : vendredi 18 mars 2011 13:44 >> À : MOHALI Marianne RD-CORE-ISS >> Cc : john.elwell@siemens-enterprise.com; sipcore@ietf.org; >> Christer.Holmberg@ericsson.com >> Objet : Re: [sipcore] >> I-DAction:draft-mohali-sipcore-reason-extension-application-01 >> >> >> >> On 3/18/2011 5:29 AM, marianne.mohali@orange-ftgroup.com wrote: >> >>> Imagine a situation where you have Alice calling Bob with a prepaid >>> calling card and Bod doesn't answer so the call is >> retargeted to the >>> voicemail. >>> You would have the following sequence in the last INVITE (last leg): >>> I didn't show possible intermediary proxies entries) >>> History-Info: >>> >> ;cause=9;text="Prepaid">;index=1, >>> >> ;index=1.1;mp=1, >>> >>> >> index=1.1.1;mp=1.1 >> >> Where is Alice in this? Shouldn't Alice be index=1? > [MM] Alice is in the From header field. No? Well, presumably. But IIUC, either Alice should make the first H-I entry for herself, or the first element that supports H-I should do so on her behalf. Thanks, Paul From marianne.mohali@orange-ftgroup.com Fri Mar 18 06:48:55 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336D93A6903 for ; Fri, 18 Mar 2011 06:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.019 X-Spam-Level: X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tv+txG+e8kfL for ; Fri, 18 Mar 2011 06:48:54 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 18CE93A68F9 for ; Fri, 18 Mar 2011 06:48:54 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 84947858005; Fri, 18 Mar 2011 14:56:11 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 7B714778001; Fri, 18 Mar 2011 14:56:11 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 14:50:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Mar 2011 14:50:21 +0100 Message-ID: In-Reply-To: <4D835D42.2030400@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: Acvlb/C0bZYvkwJYQSSiODGtACCuZAAAllOw References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com> <4D835374.8070007@cisco.com> <4D835D42.2030400@cisco.com> From: To: X-OriginalArrivalTime: 18 Mar 2011 13:50:23.0062 (UTC) FILETIME=[6D75AF60:01CBE573] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 13:48:55 -0000 My answer below=20 > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Envoy=E9 : vendredi 18 mars 2011 14:25 > =C0 : MOHALI Marianne RD-CORE-ISS > Cc : john.elwell@siemens-enterprise.com; sipcore@ietf.org;=20 > Christer.Holmberg@ericsson.com > Objet : Re: [sipcore]=20 > I-DAction:draft-mohali-sipcore-reason-extension-application-01 >=20 > At end... >=20 > On 3/18/2011 9:03 AM, marianne.mohali@orange-ftgroup.com wrote: > > > >> -----Message d'origine----- > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : vendredi = 18=20 > >> mars 2011 13:44 =C0 : MOHALI Marianne RD-CORE-ISS Cc :=20 > >> john.elwell@siemens-enterprise.com; sipcore@ietf.org;=20 > >> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] > >> I-DAction:draft-mohali-sipcore-reason-extension-application-01 > >> > >> > >> > >> On 3/18/2011 5:29 AM, marianne.mohali@orange-ftgroup.com wrote: > >> > >>> Imagine a situation where you have Alice calling Bob with=20 > a prepaid > >>> calling card and Bod doesn't answer so the call is > >> retargeted to the > >>> voicemail. > >>> You would have the following sequence in the last INVITE=20 > (last leg): > >>> I didn't show possible intermediary proxies entries) > >>> History-Info: > >>> >>> ;cause=3D9;text=3D"Prepaid">;index=3D1, > >>> > >>=20 > = ;index=3D1.1;mp=3D= 1, > >>> > >>> > >>=20 > = index=3D1.1.1;mp=3D= 1.1 > >> > >> Where is Alice in this? Shouldn't Alice be index=3D1? > > [MM] Alice is in the From header field. No? >=20 > Well, presumably. >=20 > But IIUC, either Alice should make the first H-I entry for=20 > herself, or=20 > the first element that supports H-I should do so on her behalf. [MM] Not in my understanding. According to 4244bis and the call flow = draft, the originating UA should insert a "supported: histinfo" but no = H-I header. It would be the first retageting entity that insert a H-I header with 2 = hi-entries : a 1st for itself and a 2nd for the new target (old and new = values of the R-URI). After that, each retageting/proxying entity should = add a hi-entry with the new target and complete its own hi-entry if = necessary. No? Marianne >=20 > Thanks, > Paul >=20 From mary.ietf.barnes@gmail.com Fri Mar 18 07:34:27 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3ECB3A692D for ; Fri, 18 Mar 2011 07:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.369 X-Spam-Level: X-Spam-Status: No, score=-103.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX0BD2jYxzZ0 for ; Fri, 18 Mar 2011 07:34:18 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4223C3A68F9 for ; Fri, 18 Mar 2011 07:34:15 -0700 (PDT) Received: by vws12 with SMTP id 12so4309443vws.31 for ; Fri, 18 Mar 2011 07:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+vVQbnFDvZclKKSp+rGVDoUQJ/8uJUqVOa0JNbnwF/s=; b=fy4sKycLo5NwBpijESIVrj3KYCky4eIR6541RDwYheuSm3nM2qAfUWh5KhVbE7M49e 33F8jTafdDEaVgjmDVGoRifVdIhK2x9qQna5WDk+oXEE+p7lyhddSP+RCbFnacvkxZg+ cQf7ROOMKbz5O2n30Dn/EkojD/ewkvHdX6rUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nDrJ4PVftHeh6eY2D7qXJ3uwSMTy9PaZa4EOPSuGNEUOjjpvAYVZQ0jWYaCd//PO5n mBrk931NnO/2SFkLvIX6awkgZhp2kTCIOaFSQg63pRKcZuVmitzwM6taBDavLSJj6c7b fQzRC0kriF5SKi9XEPOlmxVUD4uNm3f9ZKg30= MIME-Version: 1.0 Received: by 10.52.65.225 with SMTP id a1mr280062vdt.183.1300458944654; Fri, 18 Mar 2011 07:35:44 -0700 (PDT) Received: by 10.52.167.137 with HTTP; Fri, 18 Mar 2011 07:35:44 -0700 (PDT) In-Reply-To: References: <4D6C2CB6.4040800@cisco.com> <4D6FD03A.8040507@cisco.com> <4D7429E9.5070607@cisco.com> <4D835374.8070007@cisco.com> <4D835D42.2030400@cisco.com> Date: Fri, 18 Mar 2011 09:35:44 -0500 Message-ID: From: Mary Barnes To: marianne.mohali@orange-ftgroup.com Content-Type: multipart/alternative; boundary=20cf307f38ea70f17f049ec2b158 Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 14:34:27 -0000 --20cf307f38ea70f17f049ec2b158 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marianne, The intent is for the originating UAC to add the hi-entry, although maybe w= e should fix figure one to emphasize that. The functionality in both RFC4244 and rfc4244bis is that anytime an entity that supports HI receives an incoming request that doesn't have an hi-entry for the Request-URI in the incoming request, the entity adds the hi-entry on behalf of the previous entity (and then adds one for the Request-URI in the outgoing request that it generates). The situation can occur not just in the case of the UAC sending the request without an hi-entry - it can occur in cases where there might be an intermediary that doesn't support History-info. The supported:histinfo is used by the UAC to indicate that it wants to receive the hi-entries in the response. Mary. On Fri, Mar 18, 2011 at 8:50 AM, wrote= : > My answer below > > > -----Message d'origine----- > > De : Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Envoy=E9 : vendredi 18 mars 2011 14:25 > > =C0 : MOHALI Marianne RD-CORE-ISS > > Cc : john.elwell@siemens-enterprise.com; sipcore@ietf.org; > > Christer.Holmberg@ericsson.com > > Objet : Re: [sipcore] > > I-DAction:draft-mohali-sipcore-reason-extension-application-01 > > > > At end... > > > > On 3/18/2011 9:03 AM, marianne.mohali@orange-ftgroup.com wrote: > > > > > >> -----Message d'origine----- > > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : vendredi 18 > > >> mars 2011 13:44 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > > >> john.elwell@siemens-enterprise.com; sipcore@ietf.org; > > >> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] > > >> I-DAction:draft-mohali-sipcore-reason-extension-application-01 > > >> > > >> > > >> > > >> On 3/18/2011 5:29 AM, marianne.mohali@orange-ftgroup.com wrote: > > >> > > >>> Imagine a situation where you have Alice calling Bob with > > a prepaid > > >>> calling card and Bod doesn't answer so the call is > > >> retargeted to the > > >>> voicemail. > > >>> You would have the following sequence in the last INVITE > > (last leg): > > >>> I didn't show possible intermediary proxies entries) > > >>> History-Info: > > >>> > >>> ;cause=3D9;text=3D"Prepaid">;index=3D1, > > >>> > > >> > > ;index=3D1.1;m= p=3D1, > > >>> > > >>> > > >> > > index=3D1.1.1;m= p=3D1.1 > > >> > > >> Where is Alice in this? Shouldn't Alice be index=3D1? > > > [MM] Alice is in the From header field. No? > > > > Well, presumably. > > > > But IIUC, either Alice should make the first H-I entry for > > herself, or > > the first element that supports H-I should do so on her behalf. > [MM] Not in my understanding. According to 4244bis and the call flow draf= t, > the originating UA should insert a "supported: histinfo" but no H-I heade= r. > It would be the first retageting entity that insert a H-I header with 2 > hi-entries : a 1st for itself and a 2nd for the new target (old and new > values of the R-URI). After that, each retageting/proxying entity should = add > a hi-entry with the new target and complete its own hi-entry if necessary= . > No? > > Marianne > > > > Thanks, > > Paul > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --20cf307f38ea70f17f049ec2b158 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Marianne,

The intent is for the originating UAC to= add the hi-entry, although maybe we should fix figure one to emphasize tha= t. The functionality in both RFC4244 and rfc4244bis is that anytime an enti= ty that supports HI receives an incoming request that doesn't have an h= i-entry for the Request-URI in the incoming request, the entity adds the hi= -entry on behalf of the previous entity (and then adds one for the Request-= URI in the outgoing request that it generates). =A0 The situation can occur= not just in the case of the UAC sending the request without an hi-entry - = it can occur in cases where there might be an intermediary that doesn't= support History-info.

The supported:histinfo is used by the UAC to indicate that i= t wants to receive the hi-entries in the response.=A0

<= div>Mary.=A0

On Fri, Mar 18, 2011 at 8:50= AM, <marianne.mohali@orange-ftgroup.com> wrote:
My answer below

> -----Message d'origine-----
> De : Paul Kyzivat [mailto:pkyziv= at@cisco.com]
> Envoy=E9 : vendredi 18 mars 2011 14:25
> =C0 : MOHALI Marianne RD-CORE-ISS
> Cc : john.elwell= @siemens-enterprise.com; sipcore@ie= tf.org;
> Christer.Holmberg@er= icsson.com
> Objet : Re: [sipcore]
> I-DAction:draft-mohali-sipcore-reason-extension-application-01
>
> At end...
>
> On 3/18/2011 9:03 AM, marianne.mohali@orange-ftgroup.com wrote:
> >
> >> -----Message d'origine-----
> >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : vendredi 18
> >> mars 2011 13:44 =C0 : MOHALI Marianne RD-CORE-ISS Cc :
> >> john.el= well@siemens-enterprise.com; sipcor= e@ietf.org;
> >> Christer.Ho= lmberg@ericsson.com Objet : Re: [sipcore]
> >> I-DAction:draft-mohali-sipcore-reason-extension-application-0= 1
> >>
> >>
> >>
> >> On 3/18/2011 5:29 AM, marianne.mohali@orange-ftgroup.com wrote:
> >>
> >>> Imagine a situation where you have Alice calling Bob with=
> a prepaid
> >>> calling card and Bod doesn't answer so the call is > >> retargeted to the
> >>> voicemail.
> >>> You would have the following sequence in the last INVITE<= br> > (last leg):
> >>> I didn't show possible intermediary proxies entries)<= br> > >>> History-Info:
> >>> =A0 <sip:+18005555555@prepaid.com;user=3Dphone?Reason=3Dapplication
> >>> =A0 =A0 =A0 =A0 ;cause=3D9;text=3D"Prepaid">= ;index=3D1,
> >>>
> >>
> <sip:+33145294514@b= ob.com;user=3Dphone?Privacy=3Dhistory>;index=3D1.1;mp=3D1,
> >>>
> >>>
> >>
> <sip:+42222222= 22@voicemail.com;user=3Dphone;cause=3D408>index=3D1.1.1;mp=3D1.1
> >>
> >> Where is Alice in this? Shouldn't Alice be index=3D1?
> > [MM] Alice is in the From header field. No?
>
> Well, presumably.
>
> But IIUC, either Alice should make the first H-I entry for
> herself, or
> the first element that supports H-I should do so on her behalf.
[MM] Not in my understanding. According to 4244bis and the call= flow draft, the originating UA should insert a "supported: histinfo&q= uot; but no H-I header.
It would be the first retageting entity that insert a H-I header with 2 hi-= entries : a 1st for itself and a 2nd for the new target (old and new values= of the R-URI). After that, each retageting/proxying entity should add a hi= -entry with the new target and complete its own hi-entry if necessary.
No?

Marianne
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--20cf307f38ea70f17f049ec2b158-- From marianne.mohali@orange-ftgroup.com Fri Mar 18 08:43:43 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1954F3A691C for ; Fri, 18 Mar 2011 08:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.039 X-Spam-Level: X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8611xkyOhffW for ; Fri, 18 Mar 2011 08:43:41 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 44A9F3A67DB for ; Fri, 18 Mar 2011 08:43:41 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 13C45858004; Fri, 18 Mar 2011 16:50:59 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 01D7A778001; Fri, 18 Mar 2011 16:50:59 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 16:45:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE583.75F8DCB0" Date: Fri, 18 Mar 2011 16:45:08 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvlecT5sV/e/TIQSQOZBuyu8zAUZQAAR2bg References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com><4D835374.8070007@cisco.com><4D835D42.2030400@cisco.com> From: To: X-OriginalArrivalTime: 18 Mar 2011 15:45:09.0746 (UTC) FILETIME=[763E4520:01CBE583] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:43:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE583.75F8DCB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mary, =20 I think that you missed my point: Even if UAC adds a hi-entry, it should = be with the URI contained in the Request-URI (as hi-targeted-to-uri = captures the R-URIs) and not the URI contained in the From header.=20 So, in my example, Alice's URI should not be present in the H-I. Right? Marianne ________________________________ De : Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Envoy=E9 : vendredi 18 mars 2011 15:36 =C0 : MOHALI Marianne RD-CORE-ISS Cc : pkyzivat@cisco.com; sipcore@ietf.org; = Christer.Holmberg@ericsson.com Objet : Re: [sipcore] = I-DAction:draft-mohali-sipcore-reason-extension-application-01 =09 =09 Marianne, The intent is for the originating UAC to add the hi-entry, although = maybe we should fix figure one to emphasize that. The functionality in = both RFC4244 and rfc4244bis is that anytime an entity that supports HI = receives an incoming request that doesn't have an hi-entry for the = Request-URI in the incoming request, the entity adds the hi-entry on = behalf of the previous entity (and then adds one for the Request-URI in = the outgoing request that it generates). The situation can occur not = just in the case of the UAC sending the request without an hi-entry - it = can occur in cases where there might be an intermediary that doesn't = support History-info.=20 The supported:histinfo is used by the UAC to indicate that it wants to = receive the hi-entries in the response.=20 Mary.=20 =09 =09 On Fri, Mar 18, 2011 at 8:50 AM, = wrote: =09 My answer below =09 > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com] > Envoy=E9 : vendredi 18 mars 2011 14:25 > =C0 : MOHALI Marianne RD-CORE-ISS > Cc : john.elwell@siemens-enterprise.com; sipcore@ietf.org; > Christer.Holmberg@ericsson.com > Objet : Re: [sipcore] > I-DAction:draft-mohali-sipcore-reason-extension-application-01 > > At end... > > On 3/18/2011 9:03 AM, marianne.mohali@orange-ftgroup.com wrote: > > > >> -----Message d'origine----- > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : vendredi = 18 > >> mars 2011 13:44 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > >> john.elwell@siemens-enterprise.com; sipcore@ietf.org; > >> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] > >> I-DAction:draft-mohali-sipcore-reason-extension-application-01 > >> > >> > >> > >> On 3/18/2011 5:29 AM, marianne.mohali@orange-ftgroup.com wrote: > >> > >>> Imagine a situation where you have Alice calling Bob with > a prepaid > >>> calling card and Bod doesn't answer so the call is > >> retargeted to the > >>> voicemail. > >>> You would have the following sequence in the last INVITE > (last leg): > >>> I didn't show possible intermediary proxies entries) > >>> History-Info: > >>> = ;user=3Dphone?Reason=3Dapplication > >>> ;cause=3D9;text=3D"Prepaid">;index=3D1, > >>> > >> > = ;user=3Dphone?Privacy=3Dhistory>;index=3D1.1;mp=3D1, > >>> > >>> > >> > = ;user=3Dphone;cause=3D408>index=3D1.1.1;mp=3D1.1 > >> > >> Where is Alice in this? Shouldn't Alice be index=3D1? > > [MM] Alice is in the From header field. No? > > Well, presumably. > > But IIUC, either Alice should make the first H-I entry for > herself, or > the first element that supports H-I should do so on her behalf. =09 [MM] Not in my understanding. According to 4244bis and the call flow = draft, the originating UA should insert a "supported: histinfo" but no = H-I header. It would be the first retageting entity that insert a H-I header with = 2 hi-entries : a 1st for itself and a 2nd for the new target (old and = new values of the R-URI). After that, each retageting/proxying entity = should add a hi-entry with the new target and complete its own hi-entry = if necessary. No? =09 Marianne =09 > > Thanks, > Paul > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ------_=_NextPart_001_01CBE583.75F8DCB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Mary,
 
I think that you missed my point:=20 Even if UAC adds a hi-entry, it should be = with the URI=20 contained in the Request-URI (as hi-targeted-to-uri captures the=20 R-URIs) and not the URI contained in the From header.=20
So, in my example, Alice's URI should not = be present=20 in the H-I. Right?
Marianne

De : Mary Barnes=20 [mailto:mary.ietf.barnes@gmail.com]
Envoy=E9 : = vendredi 18 mars=20 2011 15:36
=C0 : MOHALI Marianne = RD-CORE-ISS
Cc :=20 pkyzivat@cisco.com; sipcore@ietf.org;=20 Christer.Holmberg@ericsson.com
Objet : Re: [sipcore]=20 = I-DAction:draft-mohali-sipcore-reason-extension-application-01
=
Marianne,

The intent is for the originating UAC to add the = hi-entry,=20 although maybe we should fix figure one to emphasize that. The = functionality=20 in both RFC4244 and rfc4244bis is that anytime an entity that supports = HI=20 receives an incoming request that doesn't have an hi-entry for the = Request-URI=20 in the incoming request, the entity adds the hi-entry on behalf of the = previous entity (and then adds one for the Request-URI in the outgoing = request=20 that it generates).   The situation can occur not just in the = case of the=20 UAC sending the request without an hi-entry - it can occur in cases = where=20 there might be an intermediary that doesn't support History-info.

The supported:histinfo is used by the UAC to indicate that it = wants to=20 receive the hi-entries in the response. 

Mary. 

On Fri, Mar 18, 2011 at 8:50 AM, <marianne.mohali@orange= -ftgroup.com>=20 wrote:
My=20 answer below

> -----Message d'origine-----
> De : = Paul Kyzivat=20 [mailto:pkyzivat@cisco.com]
>=20 Envoy=E9 : vendredi 18 mars 2011 14:25
> =C0 : MOHALI Marianne = RD-CORE-ISS
> Cc : john.elwell@siemens-en= terprise.com;=20 sipcore@ietf.org;
> Christer.Holmberg@ericsson= .com
>=20 Objet : Re: [sipcore]
>=20 = I-DAction:draft-mohali-sipcore-reason-extension-application-01
>>=20 At end...
>
> On 3/18/2011 9:03 AM, marianne.mohali@orange= -ftgroup.com=20 wrote:
> >
> >> -----Message = d'origine-----
>=20 >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 = : vendredi=20 18
> >> mars 2011 13:44 =C0 : MOHALI Marianne = RD-CORE-ISS Cc=20 :
> >> john.elwell@siemens-en= terprise.com;=20 sipcore@ietf.org;
> = >> Christer.Holmberg@ericsson= .com=20 Objet : Re: [sipcore]
> >>=20 = I-DAction:draft-mohali-sipcore-reason-extension-application-01
>=20 >>
> >>
> >>
> >> On = 3/18/2011=20 5:29 AM, marianne.mohali@orange= -ftgroup.com=20 wrote:
> >>
> >>> Imagine a situation = where you=20 have Alice calling Bob with
> a prepaid
> >>> = calling=20 card and Bod doesn't answer so the call is
> >> = retargeted to=20 the
> >>> voicemail.
> >>> You would = have the=20 following sequence in the last INVITE
> (last leg):
>=20 >>> I didn't show possible intermediary proxies = entries)
>=20 >>> History-Info:
> >>>   <sip:+18005555555@prepaid= .com;user=3Dphone?Reason=3Dapplication
>=20 >>>        =20 ;cause=3D9;text=3D"Prepaid">;index=3D1,
> = >>>
>=20 >>
> <sip:+33145294514@bob.com= ;user=3Dphone?Privacy=3Dhistory>;index=3D1.1;mp=3D1,
>=20 >>>
> >>>
> >>
> <sip:+4222222222@voicema= il.com;user=3Dphone;cause=3D408>index=3D1.1.1;mp=3D1.1
>=20 >>
> >> Where is Alice in this? Shouldn't Alice be = index=3D1?
> > [MM] Alice is in the From header field.=20 No?
>
> Well, presumably.
>
> But IIUC, = either Alice=20 should make the first H-I entry for
> herself, or
> the = first=20 element that supports H-I should do so on her = behalf.
[MM]=20 Not in my understanding. According to 4244bis and the call flow = draft, the=20 originating UA should insert a "supported: histinfo" but no H-I=20 header.
It would be the first retageting entity that insert a H-I = header=20 with 2 hi-entries : a 1st for itself and a 2nd for the new target = (old and=20 new values of the R-URI). After that, each retageting/proxying = entity should=20 add a hi-entry with the new target and complete its own hi-entry if=20 necessary.
No?

Marianne
>
>       Thanks,
> =  =20    =20 = Paul
>
_______________________________________________
sipcor= e=20 mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

------_=_NextPart_001_01CBE583.75F8DCB0-- From mary.ietf.barnes@gmail.com Fri Mar 18 09:14:19 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91E193A6920 for ; Fri, 18 Mar 2011 09:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4SvFfEWQmqj for ; Fri, 18 Mar 2011 09:14:17 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 951BA3A691B for ; Fri, 18 Mar 2011 09:14:17 -0700 (PDT) Received: by vws12 with SMTP id 12so4423627vws.31 for ; Fri, 18 Mar 2011 09:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8L+J+bs3gQCERRf3mgPf6yPsrsHP4RiHUc3Sxp60qK4=; b=O3WU+63EM+47t7SCT9Xor471AdcjO1uDHNWwcptypqRSpsHEeyq0A5TvVlevYHppGm GHUdwwRzVwsgpi0iXwLAfuQ49PZFzPszWpF9dlayWSzqzximImnKiXfNRX0c2tUvHhYj ETh4l9ZvY1BzKTD5saMut1KROy4ShLjfimsjQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gZY8zVNm914nPULCv3Mel/j21apnlYiJGpG6nB8R/H0be+kZP7cKI37XsR/KFwTuYP BQfhAp1FF+9npL123O7C/AFBjxfFpYhWWK0z/WtKvsNe2l2tGzrIChcWrbT/JoxQvwrr Wc0sLTc+bBzE2LNcaqEfPcP0nviqfiK6s5buo= MIME-Version: 1.0 Received: by 10.52.175.104 with SMTP id bz8mr1841660vdc.143.1300464946639; Fri, 18 Mar 2011 09:15:46 -0700 (PDT) Received: by 10.52.167.137 with HTTP; Fri, 18 Mar 2011 09:15:46 -0700 (PDT) In-Reply-To: References: <4D6C2CB6.4040800@cisco.com> <4D6FD03A.8040507@cisco.com> <4D7429E9.5070607@cisco.com> <4D835374.8070007@cisco.com> <4D835D42.2030400@cisco.com> Date: Fri, 18 Mar 2011 11:15:46 -0500 Message-ID: From: Mary Barnes To: marianne.mohali@orange-ftgroup.com Content-Type: multipart/alternative; boundary=bcaec51969852ff3a7049ec41735 Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:14:19 -0000 --bcaec51969852ff3a7049ec41735 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Correct - Alice's URI would not be in the hi-entries at all. There is an error in your example in F2 for the first hi-entry which should contain: sip:+18005555555@prepaid.com rather than: sip:+18005555555@example.com. What I was suggesting was that this is the preferred way to do this (skipping the example.com entry): F1: INVITE Alice -> Prepaid INVITE sip:+18005555555@prepaid.com;user=3Dphone SIP/2.0 From: Alice ; tag=3D1234567 To: Prepaid service Supported: histinfo History-Info: ;index=3D1, ... F2: INVITE Prepaid -> Toll Free Directory INVITE sip:+18005551212@phone2net.com SIP/2.0 From: Alice ; tag=3D1234567 To: sip:+18005551212@phone2net.com;user=3Dphone Supported: histinfo History-Info: ;index=3D1 ;index=3D1.1.;mp=3D1 ... F3: INVITE Toll Free Directory -> Restaurant INVITE sip:+420224841111@prague.com SIP/2.0 From: Alice ; tag=3D1234567 To: sip:+420224841111@prague.com;user=3Dphone Supported: histinfo History-Info: ;index=3D1, %3Bcause%3D11%3B text%3D "Toll Free">;index=3D1.1;mp=3D1, index=3D1.1.1 ... On Fri, Mar 18, 2011 at 10:45 AM, wrote= : > Mary, > > I think that you missed my point: Even if UAC adds a hi-entry, it should > be with the URI contained in the Request-URI (as hi-targeted-to-uri captu= res > the R-URIs) and not the URI contained in the From header. > So, in my example, Alice's URI should not be present in the H-I. Right? > > Marianne > > > ------------------------------ > *De :* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Envoy=E9 :* vendredi 18 mars 2011 15:36 > > *=C0 :* MOHALI Marianne RD-CORE-ISS > *Cc :* pkyzivat@cisco.com; sipcore@ietf.org; > Christer.Holmberg@ericsson.com > > *Objet :* Re: [sipcore] > I-DAction:draft-mohali-sipcore-reason-extension-application-01 > > Marianne, > > The intent is for the originating UAC to add the hi-entry, although maybe > we should fix figure one to emphasize that. The functionality in both > RFC4244 and rfc4244bis is that anytime an entity that supports HI receive= s > an incoming request that doesn't have an hi-entry for the Request-URI in = the > incoming request, the entity adds the hi-entry on behalf of the previous > entity (and then adds one for the Request-URI in the outgoing request tha= t > it generates). The situation can occur not just in the case of the UAC > sending the request without an hi-entry - it can occur in cases where the= re > might be an intermediary that doesn't support History-info. > > The supported:histinfo is used by the UAC to indicate that it wants to > receive the hi-entries in the response. > > Mary. > > On Fri, Mar 18, 2011 at 8:50 AM, wrot= e: > >> My answer below >> >> > -----Message d'origine----- >> > De : Paul Kyzivat [mailto:pkyzivat@cisco.com] >> > Envoy=E9 : vendredi 18 mars 2011 14:25 >> > =C0 : MOHALI Marianne RD-CORE-ISS >> > Cc : john.elwell@siemens-enterprise.com; sipcore@ietf.org; >> > Christer.Holmberg@ericsson.com >> > Objet : Re: [sipcore] >> > I-DAction:draft-mohali-sipcore-reason-extension-application-01 >> > >> > At end... >> > >> > On 3/18/2011 9:03 AM, marianne.mohali@orange-ftgroup.com wrote: >> > > >> > >> -----Message d'origine----- >> > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : vendredi 1= 8 >> > >> mars 2011 13:44 =C0 : MOHALI Marianne RD-CORE-ISS Cc : >> > >> john.elwell@siemens-enterprise.com; sipcore@ietf.org; >> > >> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] >> > >> I-DAction:draft-mohali-sipcore-reason-extension-application-01 >> > >> >> > >> >> > >> >> > >> On 3/18/2011 5:29 AM, marianne.mohali@orange-ftgroup.com wrote: >> > >> >> > >>> Imagine a situation where you have Alice calling Bob with >> > a prepaid >> > >>> calling card and Bod doesn't answer so the call is >> > >> retargeted to the >> > >>> voicemail. >> > >>> You would have the following sequence in the last INVITE >> > (last leg): >> > >>> I didn't show possible intermediary proxies entries) >> > >>> History-Info: >> > >>> > > >>> ;cause=3D9;text=3D"Prepaid">;index=3D1, >> > >>> >> > >> >> > ;index=3D1.1;= mp=3D1, >> > >>> >> > >>> >> > >> >> > index=3D1.1.1;= mp=3D1.1 >> > >> >> > >> Where is Alice in this? Shouldn't Alice be index=3D1? >> > > [MM] Alice is in the From header field. No? >> > >> > Well, presumably. >> > >> > But IIUC, either Alice should make the first H-I entry for >> > herself, or >> > the first element that supports H-I should do so on her behalf. >> [MM] Not in my understanding. According to 4244bis and the call flow >> draft, the originating UA should insert a "supported: histinfo" but no H= -I >> header. >> It would be the first retageting entity that insert a H-I header with 2 >> hi-entries : a 1st for itself and a 2nd for the new target (old and new >> values of the R-URI). After that, each retageting/proxying entity should= add >> a hi-entry with the new target and complete its own hi-entry if necessar= y. >> No? >> >> Marianne >> > >> > Thanks, >> > Paul >> > >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > --bcaec51969852ff3a7049ec41735 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Correct - Alice's URI would not be in the hi-entries at all. =A0There i= s an error in your example in F2 for the first hi-entry which should contai= n:=A0=A0sip:+180055= 55555@prepaid.com=A0 =A0rather than: =A0=A0sip:+18005555555@example.com. =A0=A0=

<= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">What I= was suggesting was that this is the preferred way to do this (skipping the= example.com entry):

= F1: INVITE Alice -> Prepaid

INVITE=A0sip:+18005555555@= prepaid.com;user=3Dphone SIP/2.0
From: Alice <sip:alice@example.com>; tag=3D1234567
To: Prepa= id service <sip:info@prepaid.biloxie.com>
Supported: histinfo
History-Info: <sip:+18005555555@prepaid.com;user= =3Dphone?>;index=3D1,
...

F2: INVITE Prepaid -> Toll Free Directory

INVITE=A0sip:+18005551212@phone2net.com=A0SIP/2.0
From: Alice <<= a href=3D"mailto:sip%3Aalice@example.com" style=3D"color: rgb(0, 0, 204); "= >sip:alice@example.com>; tag=3D1234567
To:=A0sip:+18005551212@phone2net.com;user=3Dphone
Suppo= rted: histinfo
History-Info:=A0<sip:+18005555555@prepaid.com;user=3Dphone?Rea= son=3Dapplication
=A0 =A0 =A0 =A0 =A0 =A0 =A0%3B= cause%3D9%3B text%3D "Prepaid">;index=3D1
=A0 =A0 =A0 =A0 =A0 =A0 =A0<sip:+18005551212@phone2net.com>;index=3D1.1.;mp=3D1
...

F3: INVITE Toll Free Directory -> Restaurant

INVITE=A0= sip:+420224841111@prague.com=A0SIP/2.0
From: Alice <= sip:alice@example.com>; tag=3D1234567
To:=A0sip:+420224841111@prague.com;user=3Dphone
Supported= : histinfo
History-Info: <sip:+18005555555@prepaid.com= ;user=3Dphone?Reason=3Dapplication
=A0 =A0 =A0 =A0 =A0 =A0 =A0%3Bcause%3D9%3B text%3D "Prepaid">;= index=3D1,
= =A0 =A0 =A0 =A0 =A0 =A0 =A0<sip:+18005551212@phone2net.com?Reason=3Dapplication
=A0 =A0 =A0 =A0 =A0 =A0 =A0%3Bcause%3D11%3B text%3D "Toll Free"&g= t;;index=3D1.1;mp=3D1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<sip:+420224841111@prague.com>index=3D1.1.1
...



= On Fri, Mar 18, 2011 at 10:45 AM, <marianne.mohali@orange-ftgroup.com&= gt; wrote:
Mary,
=A0
I think that you missed my point:=20 Even if UAC adds a hi-entry, it should be with the URI=20 contained in the Request-URI (as hi-targeted-to-uri captures the=20 R-URIs)=A0and not the URI contained in the From header.=20
So, in my example, Alice's URI=A0should not be prese= nt=20 in the H-I. Right?
Marianne

De=A0: Mary Barnes=20 [mailto:m= ary.ietf.barnes@gmail.com]
Envoy=E9=A0: vendredi 18 mars=20 2011 15:36

=C0=A0: MOHALI Marianne RD-CORE-IS= S
Cc=A0:=20 pkyzivat@cisco.co= m; sipcore@ietf.o= rg;=20 Chris= ter.Holmberg@ericsson.com

Objet= =A0: Re: [sipcore]=20 I-DAction:draft-mohali-sipcore-reason-extension-application-01
<= /div>
Marianne,

The intent is for the originating UAC to add the hi-entry,= =20 although maybe we should fix figure one to emphasize that. The functional= ity=20 in both RFC4244 and rfc4244bis is that anytime an entity that supports HI= =20 receives an incoming request that doesn't have an hi-entry for the Re= quest-URI=20 in the incoming request, the entity adds the hi-entry on behalf of the=20 previous entity (and then adds one for the Request-URI in the outgoing re= quest=20 that it generates). =A0 The situation can occur not just in the case of t= he=20 UAC sending the request without an hi-entry - it can occur in cases where= =20 there might be an intermediary that doesn't support History-info.

The supported:histinfo is used by the UAC to indicate that it wants = to=20 receive the hi-entries in the response.=A0

Mary.=A0

On Fri, Mar 18, 2011 at 8:50 AM, <marianne.mohali@orange-ftgroup.com>=20 wrote:
My=20 answer below

> -----Message d'origine-----
> De : Paul Kyzivat= =20 [mailto:pkyziva= t@cisco.com]
>=20 Envoy=E9 : vendredi 18 mars 2011 14:25
> =C0 : MOHALI Marianne=20 RD-CORE-ISS
> Cc : john.elwell@siemens-enterprise.com;=20 sipcore@ietf.org<= /a>;
> Christer.Holmberg@ericsson.com
>=20 Objet : Re: [sipcore]
>=20 I-DAction:draft-mohali-sipcore-reason-extension-application-01
><= br>>=20 At end...
>
> On 3/18/2011 9:03 AM, marianne.mohali@orange-ftg= roup.com=20 wrote:
> >
> >> -----Message d'origine----->=20 >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : vendredi=20 18
> >> mars 2011 13:44 =C0 : MOHALI Marianne RD-CORE-ISS C= c=20 :
> >> john.elwell@siemens-enterprise.com;=20 sipcore@ietf.org<= /a>;
> >> Christer.Holmberg@ericsson.com=20 Objet : Re: [sipcore]
> >>=20 I-DAction:draft-mohali-sipcore-reason-extension-application-01
>= =20 >>
> >>
> >>
> >> On 3/18/201= 1=20 5:29 AM, marianne.mohali@orange-ftgroup.com=20 wrote:
> >>
> >>> Imagine a situation where = you=20 have Alice calling Bob with
> a prepaid
> >>> call= ing=20 card and Bod doesn't answer so the call is
> >> retarge= ted to=20 the
> >>> voicemail.
> >>> You would have= the=20 following sequence in the last INVITE
> (last leg):
>=20 >>> I didn't show possible intermediary proxies entries)>=20 >>> History-Info:
> >>> =A0 <sip:+18005555555@pre= paid.com;user=3Dphone?Reason=3Dapplication
>=20 >>> =A0 =A0 =A0 =A0=20 ;cause=3D9;text=3D"Prepaid">;index=3D1,
> >>&g= t;
>=20 >>
> <sip:+33145294514@bob.com;user=3Dphone?Privacy=3Dhistory= >;index=3D1.1;mp=3D1,
>=20 >>>
> >>>
> >>
> <sip:+422222= 2222@voicemail.com;user=3Dphone;cause=3D408>index=3D1.1.1;mp=3D1.1>=20 >>
> >> Where is Alice in this? Shouldn't Alice b= e=20 index=3D1?
> > [MM] Alice is in the From header field.=20 No?
>
> Well, presumably.
>
> But IIUC, either = Alice=20 should make the first H-I entry for
> herself, or
> the fir= st=20 element that supports H-I should do so on her behalf.
[M= M]=20 Not in my understanding. According to 4244bis and the call flow draft, = the=20 originating UA should insert a "supported: histinfo" but no H= -I=20 header.
It would be the first retageting entity that insert a H-I he= ader=20 with 2 hi-entries : a 1st for itself and a 2nd for the new target (old = and=20 new values of the R-URI). After that, each retageting/proxying entity s= hould=20 add a hi-entry with the new target and complete its own hi-entry if=20 necessary.
No?

Marianne
>
> =A0 =A0 =A0 Thanks,
> =A0=20 =A0 =A0=20 Paul
>
_______________________________________________
sipc= ore=20 mailing list
s= ipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


--bcaec51969852ff3a7049ec41735-- From marianne.mohali@orange-ftgroup.com Fri Mar 18 09:24:02 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 172563A6954 for ; Fri, 18 Mar 2011 09:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfuGJe+wurfG for ; Fri, 18 Mar 2011 09:24:00 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 6DD863A691C for ; Fri, 18 Mar 2011 09:23:59 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8E431FC4005; Fri, 18 Mar 2011 17:25:34 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 7B05BFC4001; Fri, 18 Mar 2011 17:25:34 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 17:25:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE589.174939E8" Date: Fri, 18 Mar 2011 17:25:26 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: Acvlh9CHnCiW6j8+St6jLNQxDmgdAwAAJBdg References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com><4D835374.8070007@cisco.com><4D835D42.2030400@cisco.com> From: To: X-OriginalArrivalTime: 18 Mar 2011 16:25:27.0824 (UTC) FILETIME=[1787B100:01CBE589] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:24:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE589.174939E8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK ! There is also a missing "mp" (mp=3D1.1) in the last hi-entry in F3 Sorry, I do this example too quickly. =20 Marianne ________________________________ De : Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Envoy=E9 : vendredi 18 mars 2011 17:16 =C0 : MOHALI Marianne RD-CORE-ISS Cc : pkyzivat@cisco.com; sipcore@ietf.org; = Christer.Holmberg@ericsson.com Objet : Re: [sipcore] = I-DAction:draft-mohali-sipcore-reason-extension-application-01 =09 =09 Correct - Alice's URI would not be in the hi-entries at all. There is = an error in your example in F2 for the first hi-entry which should = contain: sip:+18005555555@prepaid.com = rather than: = sip:+18005555555@example.com . = =20 =09 =09 What I was suggesting was that this is the preferred way to do this = (skipping the example.com entry): F1: INVITE Alice -> Prepaid =09 INVITE sip:+18005555555@prepaid.com = ;user=3Dphone SIP/2.0 From: Alice >; = tag=3D1234567 To: Prepaid service > Supported: histinfo History-Info: ;user=3Dphone?>;index=3D1, ... =09 F2: INVITE Prepaid -> Toll Free Directory =09 INVITE sip:+18005551212@phone2net.com = SIP/2.0 From: Alice >; = tag=3D1234567 To: sip:+18005551212@phone2net.com = ;user=3Dphone Supported: histinfo History-Info: = ;user=3Dphone?Reason=3Dapplication %3Bcause%3D9%3B text%3D "Prepaid">;index=3D1=20 >;index=3D1.1.;mp=3D1 ... =09 F3: INVITE Toll Free Directory -> Restaurant =09 INVITE sip:+420224841111@prague.com = SIP/2.0 From: Alice >; = tag=3D1234567 To: sip:+420224841111@prague.com = ;user=3Dphone Supported: histinfo History-Info: = ;user=3Dphone?Reason=3Dapplication %3Bcause%3D9%3B text%3D "Prepaid">;index=3D1, =20 %3Bcause%3D11%3B text%3D "Toll Free">;index=3D1.1;mp=3D1, >index=3D1.1.1 ... =09 On Fri, Mar 18, 2011 at 10:45 AM, = wrote: =09 Mary, =20 I think that you missed my point: Even if UAC adds a hi-entry, it = should be with the URI contained in the Request-URI (as = hi-targeted-to-uri captures the R-URIs) and not the URI contained in the = >From header.=20 So, in my example, Alice's URI should not be present in the H-I. = Right? Marianne ________________________________ De : Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Envoy=E9 : vendredi 18 mars 2011 15:36=20 =C0 : MOHALI Marianne RD-CORE-ISS =09 Cc : pkyzivat@cisco.com; sipcore@ietf.org; = Christer.Holmberg@ericsson.com=20 Objet : Re: [sipcore] = I-DAction:draft-mohali-sipcore-reason-extension-application-01 =09 Marianne, The intent is for the originating UAC to add the hi-entry, although = maybe we should fix figure one to emphasize that. The functionality in = both RFC4244 and rfc4244bis is that anytime an entity that supports HI = receives an incoming request that doesn't have an hi-entry for the = Request-URI in the incoming request, the entity adds the hi-entry on = behalf of the previous entity (and then adds one for the Request-URI in = the outgoing request that it generates). The situation can occur not = just in the case of the UAC sending the request without an hi-entry - it = can occur in cases where there might be an intermediary that doesn't = support History-info.=20 The supported:histinfo is used by the UAC to indicate that it wants = to receive the hi-entries in the response.=20 Mary.=20 =09 =09 On Fri, Mar 18, 2011 at 8:50 AM, = wrote: =09 My answer below =09 > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com] > Envoy=E9 : vendredi 18 mars 2011 14:25 > =C0 : MOHALI Marianne RD-CORE-ISS > Cc : john.elwell@siemens-enterprise.com; sipcore@ietf.org; > Christer.Holmberg@ericsson.com > Objet : Re: [sipcore] > I-DAction:draft-mohali-sipcore-reason-extension-application-01 > > At end... > > On 3/18/2011 9:03 AM, marianne.mohali@orange-ftgroup.com wrote: > > > >> -----Message d'origine----- > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : = vendredi 18 > >> mars 2011 13:44 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > >> john.elwell@siemens-enterprise.com; sipcore@ietf.org; > >> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] > >> I-DAction:draft-mohali-sipcore-reason-extension-application-01 > >> > >> > >> > >> On 3/18/2011 5:29 AM, marianne.mohali@orange-ftgroup.com wrote: > >> > >>> Imagine a situation where you have Alice calling Bob with > a prepaid > >>> calling card and Bod doesn't answer so the call is > >> retargeted to the > >>> voicemail. > >>> You would have the following sequence in the last INVITE > (last leg): > >>> I didn't show possible intermediary proxies entries) > >>> History-Info: > >>> = ;user=3Dphone?Reason=3Dapplication > >>> ;cause=3D9;text=3D"Prepaid">;index=3D1, > >>> > >> > = ;user=3Dphone?Privacy=3Dhistory>;index=3D1.1;mp=3D1, > >>> > >>> > >> > = ;user=3Dphone;cause=3D408>index=3D1.1.1;mp=3D1.1 > >> > >> Where is Alice in this? Shouldn't Alice be index=3D1? > > [MM] Alice is in the From header field. No? > > Well, presumably. > > But IIUC, either Alice should make the first H-I entry for > herself, or > the first element that supports H-I should do so on her behalf. =09 [MM] Not in my understanding. According to 4244bis and the call flow = draft, the originating UA should insert a "supported: histinfo" but no = H-I header. It would be the first retageting entity that insert a H-I header = with 2 hi-entries : a 1st for itself and a 2nd for the new target (old = and new values of the R-URI). After that, each retageting/proxying = entity should add a hi-entry with the new target and complete its own = hi-entry if necessary. No? =09 Marianne =09 > > Thanks, > Paul > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ------_=_NextPart_001_01CBE589.174939E8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
OK !
There is also a missing "mp" (mp=3D1.1) in the = last hi-entry=20 in F3
Sorry, I do this example too = quickly.
 
Marianne
De : Mary Barnes=20 [mailto:mary.ietf.barnes@gmail.com]
Envoy=E9 : = vendredi 18 mars=20 2011 17:16
=C0 : MOHALI Marianne = RD-CORE-ISS
Cc :=20 pkyzivat@cisco.com; sipcore@ietf.org;=20 Christer.Holmberg@ericsson.com
Objet : Re: [sipcore]=20 = I-DAction:draft-mohali-sipcore-reason-extension-application-01
=
Correct - Alice's URI would not be in the hi-entries at = all.=20  There is an error in your example in F2 for the first hi-entry = which=20 should contain:  sip:+18005555555@prepaid= .com =20  rather than:   sip:+18005555555@example= .com.=20   

What I = was suggesting=20 was that this is the preferred way to do this (skipping the example.com = entry):

F1:=20 INVITE Alice -> Prepaid

INVITE sip:+18005555555@prepaid= .com;user=3Dphone=20 SIP/2.0
From: Alice <sip:alice@example.com>; = tag=3D1234567
To: Prepaid service <sip:info@prepaid.biloxie.c= om>
Supported:=20 histinfo
History-Info:=20 <sip:+18005555555@prepaid= .com;user=3Dphone?>;index=3D1,
...

F2:=20 INVITE Prepaid -> Toll Free Directory

INVITE sip:+18005551212@phone= 2net.com SIP/2.0
From:=20 Alice <sip:alice@example.com>; = tag=3D1234567
To: sip:+18005551212@phone= 2net.com;user=3Dphone
Supported:=20 histinfo
History-Info: <sip:+18005555555@prepaid= .com;user=3Dphone?Reason=3Dapplication
 =20            %3Bcause%3D9%3B text%3D=20 "Prepaid">;index=3D1
 =20            <sip:+18005551212@phone= 2net.com>;index=3D1.1.;mp=3D1
...

F3:=20 INVITE Toll Free Directory -> Restaurant

INVITE sip:+420224841111@prague= .com SIP/2.0
From:=20 Alice <sip:alice@example.com>; = tag=3D1234567
To: sip:+420224841111@prague= .com;user=3Dphone
Supported:=20 histinfo
History-Info: <sip:+18005555555@prepaid= .com;user=3Dphone?Reason=3Dapplication
 =20            %3Bcause%3D9%3B text%3D=20 "Prepaid">;index=3D1,
 =20            <sip:+18005551212@phone2net.com?Reason=3Dapplication =20            %3Bcause%3D11%3B text%3D = "Toll=20 Free">;index=3D1.1;mp=3D1,
          =    =20    <sip:+420224841111@prague= .com>index=3D1.1.1
...



On Fri, Mar 18, 2011 at 10:45 AM, <marianne.mohali@orange= -ftgroup.com>=20 wrote:
Mary,
 
I=20 think that you missed my point: Even if UAC adds a = hi-entry, it should=20 be with the URI contained in the Request-URI (as hi-targeted-to-uri = captures=20 the R-URIs) and not the URI contained in the From header.=20
So, in my example, Alice's URI should not be present = in the H-I.=20 Right?
Marianne

De : Mary Barnes = [mailto:mary.ietf.barnes@gmail.com] =
Envoy=E9 :=20 vendredi 18 mars 2011 15:36

=C0 : MOHALI Marianne=20 RD-CORE-ISS
Cc : pkyzivat@cisco.com; sipcore@ietf.org; Christer.Holmberg@ericsson.com

Objet : Re: [sipcore]=20 = I-DAction:draft-mohali-sipcore-reason-extension-application-01
<= /DIV>
Marianne,

The intent is for the originating UAC to add the = hi-entry,=20 although maybe we should fix figure one to emphasize that. The=20 functionality in both RFC4244 and rfc4244bis is that anytime an = entity=20 that supports HI receives an incoming request that doesn't have an = hi-entry for the Request-URI in the incoming request, the entity = adds the=20 hi-entry on behalf of the previous entity (and then adds one for = the=20 Request-URI in the outgoing request that it generates).   The = situation can occur not just in the case of the UAC sending the = request=20 without an hi-entry - it can occur in cases where there might be = an=20 intermediary that doesn't support History-info.=20

The supported:histinfo is used by the UAC to indicate that it = wants=20 to receive the hi-entries in the response. 

Mary. 

On Fri, Mar 18, 2011 at 8:50 AM, <marianne.mohali@orange-ftgroup.com> = wrote:
My=20 answer below

> -----Message d'origine-----
> De : Paul = Kyzivat=20 [mailto:pkyzivat@cisco.com]
> Envoy=E9 : = vendredi 18 mars=20 2011 14:25
> =C0 : MOHALI Marianne RD-CORE-ISS
> Cc = : john.elwell@siemens-enterprise.com; sipcore@ietf.org;
> Christer.Holmberg@ericsson.com
> Objet = : Re:=20 [sipcore]
>=20 = I-DAction:draft-mohali-sipcore-reason-extension-application-01
>>=20 At end...
>
> On 3/18/2011 9:03 AM, marianne.mohali@orange-ftgroup.com = wrote:
>=20 >
> >> -----Message d'origine-----
> = >> De :=20 Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : vendredi = 18
>=20 >> mars 2011 13:44 =C0 : MOHALI Marianne RD-CORE-ISS Cc = :
>=20 >> john.elwell@siemens-enterprise.com; sipcore@ietf.org;
> >> Christer.Holmberg@ericsson.com Objet : Re:=20 [sipcore]
> >>=20 = I-DAction:draft-mohali-sipcore-reason-extension-application-01
>=20 >>
> >>
> >>
> >> On = 3/18/2011=20 5:29 AM, marianne.mohali@orange-ftgroup.com = wrote:
>=20 >>
> >>> Imagine a situation where you have = Alice=20 calling Bob with
> a prepaid
> >>> calling = card and=20 Bod doesn't answer so the call is
> >> retargeted to = the
> >>> voicemail.
> >>> You = would have=20 the following sequence in the last INVITE
> (last = leg):
>=20 >>> I didn't show possible intermediary proxies=20 entries)
> >>> History-Info:
> >>> =  =20 <sip:+18005555555@prepaid.com;user=3Dphone?Reason=3Dap= plication
>=20 >>>        =20 ;cause=3D9;text=3D"Prepaid">;index=3D1,
> = >>>
>=20 >>
> <sip:+33145294514@bob.com;user=3Dphone?Privacy=3Dhisto= ry>;index=3D1.1;mp=3D1,
>=20 >>>
> >>>
> >>
> = <sip:+4222222222@voicemail.com;user=3Dphone;cause=3D40= 8>index=3D1.1.1;mp=3D1.1
>=20 >>
> >> Where is Alice in this? Shouldn't = Alice be=20 index=3D1?
> > [MM] Alice is in the From header field.=20 No?
>
> Well, presumably.
>
> But IIUC, = either=20 Alice should make the first H-I entry for
> herself, = or
>=20 the first element that supports H-I should do so on her=20 behalf.
[MM] Not in my understanding. According = to=20 4244bis and the call flow draft, the originating UA should = insert a=20 "supported: histinfo" but no H-I header.
It would be the = first=20 retageting entity that insert a H-I header with 2 hi-entries : a = 1st for=20 itself and a 2nd for the new target (old and new values of the = R-URI).=20 After that, each retageting/proxying entity should add a = hi-entry with=20 the new target and complete its own hi-entry if=20 necessary.
No?

Marianne
>
>       Thanks,
>   =  =20  =20 = Paul
>
_______________________________________________
sipcor= e=20 mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


------_=_NextPart_001_01CBE589.174939E8-- From dean.willis@softarmor.com Sat Mar 19 10:14:36 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527283A6931; Sat, 19 Mar 2011 10:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.613 X-Spam-Level: X-Spam-Status: No, score=-103.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVZ5ROh9ZwbC; Sat, 19 Mar 2011 10:14:35 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 3DD0E3A695E; Sat, 19 Mar 2011 10:14:29 -0700 (PDT) Received: by yic13 with SMTP id 13so2297036yic.31 for ; Sat, 19 Mar 2011 10:16:00 -0700 (PDT) Received: by 10.146.50.6 with SMTP id x6mr2281438yax.17.1300554959802; Sat, 19 Mar 2011 10:15:59 -0700 (PDT) Received: from [192.168.89.100] (cpe-66-25-8-214.tx.res.rr.com [66.25.8.214]) by mx.google.com with ESMTPS id c24sm1364136ana.21.2011.03.19.10.15.57 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 Mar 2011 10:15:58 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Sat, 19 Mar 2011 12:15:56 -0500 To: Sambasiva Rao MANCHILI X-Mailer: Apple Mail (2.1082) Cc: soc@ietf.org, ietf@ietf.org, sambasiva.manchili@nexustelecom.com, sipcore@ietf.org, tsvwg@ietf.org, p2psip@ietf.org Subject: [sipcore] Redirect to sip-implementors: was( Re: SIP UDP packet loss?) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 17:14:36 -0000 You'll probably get a million of these replies, but I'll try and head = them off: Rather than the lists coped here (which deal with a wide variety of = other topics), please try the SIP Implementors List: sip-implementors@lists.cs.columbia.edu Thanks! Sorry to the rest of the folks I'm spamming here. -- Dean Willis= From marianne.mohali@orange-ftgroup.com Mon Mar 21 09:30:28 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360D23A68A6 for ; Mon, 21 Mar 2011 09:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DqBZrncU1-p for ; Mon, 21 Mar 2011 09:30:26 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id AF7FC3A687B for ; Mon, 21 Mar 2011 09:30:25 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E025C858004; Mon, 21 Mar 2011 17:37:49 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id D60C6778001; Mon, 21 Mar 2011 17:37:49 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Mar 2011 17:31:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Mar 2011 17:31:56 +0100 Message-ID: In-Reply-To: <4D83552A.3040805@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvlayvKqDgE+Zp5QUeQLyk36sbWagACLbWA References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com> <4D83552A.3040805@cisco.com> From: To: , X-OriginalArrivalTime: 21 Mar 2011 16:31:57.0391 (UTC) FILETIME=[7EF825F0:01CBE7E5] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 16:30:28 -0000 Paul, > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Envoy=E9 : vendredi 18 mars 2011 13:51 > =C0 : Elwell, John > Cc : MOHALI Marianne RD-CORE-ISS; sipcore@ietf.org;=20 > Christer.Holmberg@ericsson.com > Objet : Re: [sipcore]=20 > I-DAction:draft-mohali-sipcore-reason-extension-application-01 >=20 > [as individual] >=20 > IMO the question John asks is pertinent to almost *any* piece=20 > of information you might want to derive from H-I. I have the=20 > feeling that generally the algorithm you might come up with=20 > will be highly dependent on the individual behaviors of=20 > elements in the network, and so will be highly fragile,=20 > except in specific closed environments. [MM] Each service interaction is a specific case and only a closed = environment can ensure a end-to-end information BUT: First, this comment is also valid for other information in the H-I (eg. = Call forwarding information);=20 Second, the only solution to avoid case by case solutions for having = enhanced services between networks is to have a shared standard. This example was showing a specific case but the Reason extension intend = to be also used in SIP request (see eg with a BYE in the draft) or = answers (eg. 4xx, 5xx..). Marianne >=20 > Thanks, > Paul >=20 > On 3/18/2011 6:51 AM, Elwell, John wrote: > > > >>> [JRE] This does not fully address the point I was making. I was=20 > >>> making the point that to find the particular hi-entry you are=20 > >>> interested in you need, at present, to scan hi-entries looking at=20 > >>> their parameters - you do not need to look at the URIs in those=20 > >>> hi-entries and the URIs' "headers" components in order to=20 > find the=20 > >>> hi-entry you are looking for. Of course, once you have found the=20 > >>> hi-entry you are looking for, you will be interested in=20 > the URI and=20 > >>> in anything attached to it, including Privacy and Reason header=20 > >>> fields within its "headers" component. The draft under discussion=20 > >>> seems to change that principle so that in order to find=20 > the hi-entry=20 > >>> you are looking for you need to look inside the URIs.=20 > This seems to=20 > >>> me like a change of principle - the logic of including=20 > the proposed=20 > >>> application information in the URI as a header field,=20 > rather than in=20 > >>> hi-entry parameters, is not at all clear to me. > >> [MM] I don't see the problem with your point. hi-entry=20 > parameters are=20 > >> not incompatible with URIs' headers. > >> hi-entry parameters, allow to do a first sort in hi-entries, then,=20 > >> according to UAS needs, URI headers or parameters give a=20 > complementary > >> information. > >> Imagine a situation where you have Alice calling Bob with=20 > a prepaid=20 > >> calling card and Bod doesn't answer so the call is=20 > retargeted to the=20 > >> voicemail. > >> You would have the following sequence in the last INVITE=20 > (last leg): > >> I didn't show possible intermediary proxies entries) > >> History-Info: > >> = >> ;cause=3D9;text=3D"Prepaid">;index=3D1, > >> > >>=20 > = ;index=3D1.1;mp=3D= 1, > >> > >>=20 > = index=3D1.1.1;mp=3D= 1. > >> 1 > > > > [JRE] So in this particular case, the application might=20 > search for the earliest entry marked mp, which points to the=20 > hi-entry with index 1, and that contains the Prepaid reason.=20 > I suppose that works (subject to my earlier caveat about=20 > needing to be in a closed network to rely on that=20 > information). However, the fact that it works in this=20 > particular scenario does not necessarily mean it is the=20 > correct mechanism, and I would like to hear other opinions. > > > > John > > > >> > >> Marianne > >>> > >>> John > >>> > >>> > >>>> > >>>> Marianne > >>>>> > >>>>> John > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: sipcore-bounces@ietf.org > >>>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > >>>>>> marianne.mohali@orange-ftgroup.com > >>>>>> Sent: 07 March 2011 18:30 > >>>>>> To: pkyzivat@cisco.com > >>>>>> Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com > >>>>>> Subject: Re: [sipcore] I-DAction: > >>>>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>>> > >>>>>> Paul, > >>>>>> > >>>>>> I think that Christer's draft (proxy-feature) is about > >>>> capabilities > >>>>>> while this one (reason-extension-application) is about > >>>> what really > >>>>>> happened (like reason in general). It is provided only when > >>>>> the event > >>>>>> happens and the purpose is to give an accuate information for=20 > >>>>>> applicative events. > >>>>>> > >>>>>> Let me give you an other example: > >>>>>> A reception AS called with several premium rate numbers (1 > >>>>> per hosted > >>>>>> application/service). The AS dispatches calls to several > >>>>> call centers > >>>>>> (eg. Depending on charge, hour of the day/night...). > >> The final > >>>>>> destination needs to know the called service. The premuim > >>>>> rate number > >>>>>> should be listed in the H-I header. Which entry? For which=20 > >>>>>> application/service invocated? > >>>>>> As you can have a call forwarding reason associated to a > >>>> 3xx or 486 > >>>>>> Reason-cause, you could have an applicative reason to > >>>>> easily identify > >>>>>> the premium rate dialed number. > >>>>>> > >>>>>> Regards, > >>>>>> Marianne > >>>>>> > >>>>>> > >>>>>>> -----Message d'origine----- > >>>>>>> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : > >>>>> lundi 7 mars > >>>>>>> 2011 01:42 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > >>>> sipcore@ietf.org; > >>>>>>> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] > >>> I-DAction: > >>>>>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>>>> > >>>>>>> Marianne > >>>>>>> > >>>>>>> On 3/4/2011 11:59 AM, > >>> marianne.mohali@orange-ftgroup.com wrote: > >>>>>>>> Hi Paul, > >>>>>>>> > >>>>>>>> My answer below [MM] > >>>>>>>> > >>>>>>>> Marianne > >>>>>>>>> -----Message d'origine----- > >>>>>>>>> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : > >>>>>>> jeudi 3 mars > >>>>>>>>> 2011 18:31 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > >>>>>> sipcore@ietf.org; > >>>>>>>>> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] > >>>> I-DAction: > >>>>>>>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>>>>>> > >>>>>>>>> Marianne, > >>>>>>>>> > >>>>>>>>> On 3/3/2011 11:51 AM, > >>>> marianne.mohali@orange-ftgroup.com wrote: > >>>>>>>>>> Hi Paul, > >>>>>>>>>> > >>>>>>>>>> The purpose is to allow applications/services to be > >>>>>>>>> explicitely identified in the signaling path, so > >>> that others > >>>>>>>>> services/applications/telephony-AS can act accordingly. > >>>>>>>>> Either to apply a process taking into account the service > >>>>>>> interaction > >>>>>>>>> or on the contrary, do not execute a feature already > >>>>>>> covered by the > >>>>>>>>> application. > >>>>>>>>>> For instance, a caller with a prepaid service calls a > >>>>>>>>> directory enquiries Server to ask for a restaurant phone > >>>>>>> number. The > >>>>>>>>> operator would suggest to connect the caller to the > >>>>>>> researched phone > >>>>>>>>> number EXCEPT if the caller has a prepaid service because > >>>>>>> it is not > >>>>>>>>> sure he has enough credit to pay for the > >> communication. To > >>>>>>> allow this > >>>>>>>>> customized feature, the directory enquiries Application > >>>>>>> needs to know > >>>>>>>>> that the prepaid Application has been invocated. > >>>>>>>>> > >>>>>>>>> So once again, we are back to your wanting to use > >>>>> Reason not to > >>>>>>>>> express a "reason" for anything, but rather as just a > >>>>>> hook to hang > >>>>>>>>> something on H-I. > >>>>>>>> [MM] The *reason* why the call has been > >>>>>>> retargeted/rejected/modified is the invocation of a > >> specific > >>>>>>> application. > >>>>>>>> If you call a Service number and then the URI is changed > >>>>>>> for routing to the real destination, the *reason* > >> of the URI > >>>>>>> modification (listed in H-I) is the application. > >>>>>>> > >>>>>>> Based on your other replies, this is not necessarily so. > >>>>>>> > >>>>>>> In fact the example above is a counter-example. > >>>>>>> The prepaid service is not responsible for any > >>>>> redirection, and the > >>>>>>> operator service is looking for it for a reason other > >>>>> than that it > >>>>>>> has been the cause of anything. Its looking for it > >>>>> because it might > >>>>>>> be the cause of something in the future. > >>>>>>> > >>>>>>>>> (With the causes you have defined, I can't imagine > >>> it making > >>>>>>>>> *any* sense to actually use one in a Reason header in > >>>>> a message, > >>>>>>>>> because they aren't specific enough to be actionable.) > >>>>>>>>> > >>>>>>>>> I am now thinking there is a large overlap between > >>>>> what you are > >>>>>>>>> trying to accomplish this way, and what Christer is > >>>> trying to > >>>>>>>>> accomplish with draft-holmberg-sipcore-proxy-feature. > >>>>>>>>> > >>>>>>>>> Is that true? > >>>>>>>>> > >>>>>>>>> (Christer: What do you think?) > >>>>>>>> [MM] I don't see the overlap with Christer's draft because > >>>>>>> it is not about capabilities, it is about what's happened. > >>>>>>> > >>>>>>> In your example above, it seems that the operator service > >>>>> is looking > >>>>>>> for the prepaid service because the prepaid service has the=20 > >>>>>>> capability to influence billing, or something like that. > >>>>> This seems > >>>>>>> at least somewhat in line with what Christer is > >>>>> advocating. Looking > >>>>>>> in the Route header, or Record-Route header would make at > >>>>> least as > >>>>>>> much sense for this case as looking in H-I. H-I makes > >>>>> sense if you > >>>>>>> are indeed looking for something that has already > >>>>> happened, perhaps > >>>>>>> on a path other that the current one. > >>>>>>> > >>>>>>> I think it would be helpful for the two of you to > >>> come to some > >>>>>>> reconciliation of what you are trying to accomplish. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>> > >>>>>>>>>> About your comment in case of several > >>> applications involved > >>>>>>>>> *simultaneously* in the call establishment, it > >> is possible > >>>>>>> to add 1 > >>>>>>>>> more hi-entry for the second application Cause you > >>>> want to be > >>>>>>>>> identified in the signaling path. > >>>>>>>>> > >>>>>>>>> Sure, you can indicate that they are "involved". But you > >>>>>>> can't infer > >>>>>>>>> anything about which one "caused" something. They might > >>>>>>> have, but you > >>>>>>>>> can't tell it from the presence of these headers. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Paul > >>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> Marianne > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Message d'origine----- De : > >>> sipcore-bounces@ietf.org > >>>>>>>>>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul > >>>>>>>>> Kyzivat Envoy=E9 : > >>>>>>>>>>> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org > >> Objet : Re: > >>>>>>> [sipcore] > >>>>>>>>>>> I-DAction: > >>>>>>>>>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>>>>>>>> > >>>>>>>>>>> (As individual) > >>>>>>>>>>> > >>>>>>>>>>> Marianne, > >>>>>>>>>>> > >>>>>>>>>>> I'm still struggling to make sense of this in the form > >>>>>> proposed. > >>>>>>>>>>> > >>>>>>>>>>> I look at the various cause values, and all the > >>>>>>>>> descriptions are of > >>>>>>>>>>> the form. E.g.: > >>>>>>>>>>> > >>>>>>>>>>> Cause value: 2 > >>>>>>>>>>> Reason text: Freephone > >>>>>>>>>>> Description: A Freephone application has > >>>> influenced > >>>>>>>>>>> processing of > >>>>>>>>>>> the call (e.g. by translating a dialed > >>> Free Phone > >>>>>>>>> number to a > >>>>>>>>>>> routable directory number). > >>>>>>>>>>> > >>>>>>>>>>> I can't figure out how to make any actionable decision > >>>>>>>>> based on this. > >>>>>>>>>>> Rather, it seems I need to make a number of > >>> leaps of faith > >>>>>>>>> before I > >>>>>>>>>>> can decide what to do. > >>>>>>>>>>> > >>>>>>>>>>> For instance, if I get an error, it *might* be > >> because I > >>>>>>> dialed a > >>>>>>>>>>> freephone number, and it isn't supported from > >> my calling > >>>>>>> location. > >>>>>>>>>>> (E.g. > >>>>>>>>>>> maybe I'm dialing +1-800-555-1234, but I'm > >> doing so from > >>>>>>>>> France, and > >>>>>>>>>>> calling that number is only supported in the USA. > >>>>>>>>>>> > >>>>>>>>>>> But getting a application reason code with cause 2 > >>>>>>> doesn't really > >>>>>>>>>>> tell me that is what happened. It could be > >> that the call > >>>>>>>>> indeed was > >>>>>>>>>>> routed through a freephone application, and it properly > >>>>>>> routed the > >>>>>>>>>>> call, and the call failed for some other > >> reason. But the > >>>>>>> cause is > >>>>>>>>>>> there because the application > >>>>>>>>>>> *did* influence the call routing. > >>>>>>>>>>> > >>>>>>>>>>> Also, these "applications" are not, AFAIK, mutually > >>>>>>>>> exclusive. E.g. I > >>>>>>>>>>> could be using a prepaid service to make a directory > >>>>>>>>> assistance call > >>>>>>>>>>> that costs extra $$$ that I don't have credits to > >>>>>> cover. But you > >>>>>>>>>>> can't include two cause values for the same > >>> protocol. (But > >>>>>>>>> it is true > >>>>>>>>>>> that you > >>>>>>>>>>> *can* have a number of servers each put one cause into > >>>>>>>>>>> *their* H-I entry.) > >>>>>>>>>>> > >>>>>>>>>>> So *maybe* I would see that my call failed, and > >>> that there > >>>>>>>>> is both a > >>>>>>>>>>> reason indicating a prepaid application on one > >> H-I entry, > >>>>>>>>> and another > >>>>>>>>>>> indicating a another H-I indicating a directory service > >>>>>>>>> application. > >>>>>>>>>>> But what can I conclude from that? > >>>>>>>>>>> > >>>>>>>>>>> Bottom line, I just can't make sense how this could be > >>>>>>>>> used in a well > >>>>>>>>>>> defined and interoperable way. > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> Paul > >>>>>>>>>>> > >>>>>>>>>>> On 2/28/2011 9:58 AM, > >>>>> marianne.mohali@orange-ftgroup.com wrote: > >>>>>>>>>>>> Hello, > >>>>>>>>>>>> > >>>>>>>>>>>> Here is the new version of the draft. > >>>>>>>>>>>> Main changes are following: > >>>>>>>>>>>> - More details about the registration procedure for > >>>>> new values > >>>>>>>>>>>> - Clearer text in section 3.2 > >>>>>>>>>>>> - Add of Public and Private status for > >>> registered values. > >>>>>>>>>>>> - Add of a range for cause values registration > >>>>>>>>>>>> > >>>>>>>>>>>> Best Regards, > >>>>>>>>>>>> Marianne Mohali > >>>>>>>>>>>> > >>>>>>>>>>>> -----Message d'origine----- Objet : New Version=20 > >>>>>>>>>>>> Notification for > >>>>>>>>>>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>>>>>>>>> > >>>>>>>>>>>> A New Internet-Draft is available from the on-line > >>>>>>>>> Internet-Drafts > >>>>>>>>>>>> directories. > >>>>>>>>>>>> > >>>>>>>>>>>> Title : Extending the Session > >>>>>>> Initiation Protocol > >>>>>>>>>>>> (SIP) Reason Header for Applications > >>>>>>>>>>>> Author(s) : M. Mohali, B. Chatras > >>>>>>>>>>>> Filename : > >>>>>>>>>>>> > >> draft-mohali-sipcore-reason-extension-application-01.txt > >>>>>>>>>>>> Pages : 10 > >>>>>>>>>>>> Date : 2011-02-24 > >>>>>>>>>>>> > >>>>>>>>>>>> This document defines a new protocol value > >>>>>>> "Application" for the > >>>>>>>>>>>> Reason Header field and a new IANA Registry for > >>>> registering > >>>>>>>>>>>> application types. This new value enables > >>>> signaling that a > >>>>>>>>>>> request or > >>>>>>>>>>>> response has been issued as a result of a decision > >>>>> made by a > >>>>>>>>>>>> particular type of application or that an > >>> initial request > >>>>>>>>> has been > >>>>>>>>>>>> retargeted as a result of an application decision. > >>>>>>>>>>>> > >>>>>>>>>>>> A URL for this Internet-Draft is: > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>=20 > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten > >>>>>>>>>>> s > >>>>>>>>>>>> io > >>>>>>>>>>>> n-application-01.txt > >>>>>>>>>>>> > >>>>>>>>>>>> Internet-Drafts are also available by > >> anonymous FTP at: > >>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>>>>>>>> > >>>>>>>>>>>> Below is the data which will enable a MIME compliant > >>>>>>> mail reader > >>>>>>>>>>>> implementation to automatically retrieve the ASCII > >>>>>>> version of the > >>>>>>>>>>>> Internet-Draft. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>=20 > >>>>>>>>>>> s > >>>>>>>>>>>> io > >>>>>>>>>>>> n-application-01.txt> > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> I-D-Announce mailing list > >>>>>>>>>>>> I-D-Announce@ietf.org > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>>>>>>>>>> Internet-Draft directories: > >>>>>> http://www.ietf.org/shadow.html or > >>>>>>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> sipcore mailing list > >>>>>>>>>>>> sipcore@ietf.org > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> sipcore mailing list > >>>>>>>>>>> sipcore@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> sipcore mailing list > >>>>>> sipcore@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>> > >>>>> > >>>> > >>> > >> > > >=20 From dworley@avaya.com Thu Mar 24 13:37:45 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9FD28C13D for ; Thu, 24 Mar 2011 13:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.064 X-Spam-Level: X-Spam-Status: No, score=-103.064 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvCmcWw-NutN for ; Thu, 24 Mar 2011 13:37:44 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id A8F7228C119 for ; Thu, 24 Mar 2011 13:37:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMtcU2HCzI1/2dsb2JhbACmZXSkeQKZFgKDBoJZBJAMiDM X-IronPort-AV: E=Sophos;i="4.63,238,1299474000"; d="scan'208";a="271214914" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Mar 2011 16:39:18 -0400 X-IronPort-AV: E=Sophos;i="4.63,238,1299474000"; d="scan'208";a="629382562" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Mar 2011 16:39:18 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 24 Mar 2011 16:39:18 -0400 From: "Worley, Dale R (Dale)" To: "marianne.mohali@orange-ftgroup.com" Date: Thu, 24 Mar 2011 16:39:18 -0400 Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: Acvlh9baP6VCKsDzS7+F065ZFqx3vAE2szaG Message-ID: References: <4D6C2CB6.4040800@cisco.com> <4D6FD03A.8040507@cisco.com> <4D7429E9.5070607@cisco.com> <4D835374.8070007@cisco.com> <4D835D42.2030400@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 20:37:45 -0000 I'm behind on this discussion, but I think that the example has some data m= isplaced, in that the "Reason" header item is attached to the URI for which it gives the reason for its cr= eation or invocation. So if the prepaid service is invoked by 18005555555 and turns the request i= nto 18005551212, the "prepaid" Reason would be on 18005551212: F1: INVITE Alice -> Prepaid INVITE sip:+18005555555@prepaid.com;user=3Dphone SIP/2.0 From: Alice ; tag=3D1234567 To: Prepaid service Supported: histinfo History-Info: ;index=3D1, ... F2: INVITE Prepaid -> Toll Free Directory INVITE sip:+18005551212@phone2net.com SIP/2.0 From: Alice ; tag=3D1234567 To: sip:+18005551212@phone2net.com;user=3Dphone Supported: histinfo History-Info: ;index=3D1 ;index=3D1.1.;mp=3D1 ... F3: INVITE Toll Free Directory -> Restaurant INVITE sip:+420224841111@prague.com SIP/2.0 From: Alice ; tag=3D1234567 To: sip:+420224841111@prague.com;user=3Dphone Supported: histinfo History-Info: ;index=3D1, ;index=3D1.1;mp=3D1, index=3D1.1.1 Or am I mistaken? Dale From john.elwell@siemens-enterprise.com Fri Mar 25 07:45:33 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F8328C0EF for ; Fri, 25 Mar 2011 07:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk+3xf0eTuT9 for ; Fri, 25 Mar 2011 07:45:31 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id CE1FC28C0EE for ; Fri, 25 Mar 2011 07:45:30 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3888217; Fri, 25 Mar 2011 15:47:03 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id A23061EB82B4; Fri, 25 Mar 2011 15:47:01 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 25 Mar 2011 15:47:02 +0100 From: "Elwell, John" To: Mary Barnes , SIPCORE Date: Fri, 25 Mar 2011 15:46:59 +0100 Thread-Topic: [sipcore] Fwd: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt Thread-Index: AcvjQX1pxRr9/1s3T/+Yjm3Cb5ZnnwA22Qog Message-ID: References: <20110315183001.24369.74903.idtracker@localhost> Keywords: SIPCORE In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Fwd: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 14:45:33 -0000 Mary, I already sent you my comments on sections 6 to 9. Now I finally got round = to reading much of the rest of the document (up to section 12). Sorry, my e= nergy ran out after that - I will leave it to others to check the rest. I h= ave to say that these sections are not yet ready to go - quite a few inaccu= racies and inconsistent use of terminology. Here goes: 1. Section 1: "Many services that SIP is anticipated to support require the ability to determine why and how a SIP requests arrived at a specific application." Change "requests" to "request". 2. Section 5: "By adding the new entries in order (i.e., following existing entries per the details in Section 10.3), including the index and securing the header, the ordering of the History-info header fields in the request is assured." What is meant by "securing the header"? Why just the header and not the bod= y? Surely the only means we are suggesting is TLS, which secures the body a= s well as the header. 3. Section 5: "hi-target-param: An optional parameter reflecting the mechanism by which the Request URI captured in the hi-targeted-to-uri in the hi-entry was determined." The term "hi-entry" has not been introduced yet. 4. Section 5: ""rc": The hi-targeted-to-URI is a contact for the Request-URI, in the incoming request, that is bound to an AOR in an abstract location service." What is bound? Presumably the contact, not the Request-URI, and not the req= uest. Wording is ambiguous, because "that is bound" is too separated from "= contact". Also "Request-URI is ambiguous - the Request-URI before or after = retargeting. I think it should say something like "...is a contact bound to= an AOR in an abstract location service, that AOR being the Request-URI tha= t was retargeted." 5. Section 5: "This occurs when a request is to statically or dynamically retargeted " Delete "to". 6. Section 5: "The value of the index in the "mp" header field parameter represents the value of the hi-index in the hi-entry with an hi-targeted-to- uri that reflects the Request-URI that was retargeted, thus identifying the "mapped from" target." What is meant by "the value of the index" at the start of the sentence? Isn= 't this simply the value of the "mp" parameter? In any case, shouldn't we u= se a similar formulation to that used in the corresponding sentence in the = definition of "rc"? 7. Section 5: "hi-param =3D hi-index / hi-target / hi-extension" There is no definition of hi-target - I think it should be "hi-target-param= ". However, there are other places in the document where "hi-target" is ref= erred to. I think hi-target-param is better - please align all instances. 8. Section5: "addition to the parameters defined by the ABNF, an hi-entry may also include a Reason header field and a Privacy header field" I think it should say "...and/or a Privacy header field. We can have one wi= thout the other. 9. Section 5: "which are both included in the hi-targeted-to-uri as described below:" To make it clear where in the hi-targeted-to-uri, I think it should say "..= .included in the "headers" component of the hi-targeted-to-uri". 10. Section 5: "A reason is included for the hi-targeted-to-uri that was retargeted as opposed to the hi-targeted-to-uri to which it was retargeted." Ambiguous. Does it mean it appears in the hi-entry for that URI, or does it= mean it relates to that URI even though it appears in the URI resulting fr= om retargeting? In addition, a reason can be included (and will appear in t= he response) even if there is no retargeting as a result of that reason. I = would suggest: "A reason is included in the hi-targeted-to-uri of an hi-ent= ry to reflect information received in a response to the request sent to tha= t URI." 11. Section 5.1: "and the headers in the URI are not shown properly formatted for escaping." I am not sure what this is talking about - if it is talking about "headers"= component in a URI, I don't see any in the example. Delete this part of th= e sentence? 12. Section 10.1: "Section 10.1.1 describes the use of the Privacy header field defined in [RFC3323] to indicate the privacy to be applied to the History-Info header field entries." I think 10.1.1 only describes insertion - it doesn't describe use on receip= t. Change "the use of" to "the insertion of". 13. Section 10.1: "Section 10.1.2 describes the processing of the priv-values in the Privacy header field to privacy protect the History-Info header field entries in the request or response that is being forwarded." I think this would be clearer if it said "Section 10.1.2 describes how to a= pply privacy to a request or response that is being forwarded, based on the= presence of the Privacy header field." 14. Section 10.1.1: "The Privacy header field is used by the UAC to indicate the privacy to be applied to all the hi- entries in the request as follows:" This seems to suggest it is used to indicate whether privacy is to be appli= ed or not, but the bullets below are specific to the case where privacy IS = to be applied. I would suggest "...to indicate that privacy is to be applie= d" 15. Section 10.1.1: "for each hi-entry added by intermediary, as the request is retargeted within the domain for which the SIP entity is responsible." Does "each hi-entry added by intermediary" include any hi-entries that have= been received in responses from downstream entities, these hi-entries then= being added to any additional branches? 16. Section 10.1.2: "When a request is retargeted to a URI associated with a domain for which the SIP intermediary is not responsible or a response is forwarded" I think the words "to ... a domain for which the SIP intermediary is not re= sponsible" applies also when forwarding a response. Should it say: "When a request is retargeted to a URI associated with a domain for which the SIP intermediary is not responsible or a response is forwarded to a domain for which the SIP intermediary is not responsible" 17. In the same sentence: "a Privacy Service at the boundary of the domain applies" Where is "Privacy Service" defined (for priv-value "history")? Presumably t= he following paragraphs specify the Privacy Service, but this is not clear. 18. In the same sentence: "at the boundary of the domain" How do we ensure the presence of a Privacy Service at a domain boundary? Fo= r example, a proxy inserts an hi-entry marked with privacy and sends it to = the next node in its domain. But that node doesn't support H-I, so just pas= ses H-I on transparently, perhaps outside the domain. There needs to be an = element of trust here, similar to RFC 3325, where information subject to pr= ivacy is sent only to trusted entities within the domain, but furthermore, = to be trusted an entity needs to support H-I. See also my last comment (on = section 12). 19. Section 10.1.2: "If there is a Privacy header field in the request with a priv-value of "header" or "history"," I think this is talking about a Privacy header field in the message header,= as opposed to a Privacy header field in the "headers" component of an hi-t= argeted-to-uri. This should be made clear, although there is no obvious ter= minology we can call on. Perhaps: "If there is a Privacy header field in the request, other than in the "head= ers" component of an hi-targeted-to-uri, with a priv-value of "header" or "history"," 20. The same quoted text talks about requests, but don't we need similar pr= ocedures for responses? 21. In the same sentence: "then the hi-targeted-to-uris in the hi- entries, associated with the domain for which a SIP intermediary is responsible, are anonymized." I think this is trying to say "a SIP intermediary anonymizes any hi-target= ed-to-uris associated with its own domain". But I am rather confused that t= his sentence talks about "a SIP intermediary" and the next sentence, which = seems to repeat things in normative language, talks about "The Privacy Serv= ice". We could do with some rationalization of the two sentences. 22. Section 10.1.2: "If there is not a Privacy header field in the request or response that is being forwarded" Again I think we need to qualify this by adding "other than in the "headers= " component of an hi-targeted-to-uri". 23. Concerning the same sentence, again I have trouble with this sentence a= nd the next sentence covering essentially the same thing with different ter= minology. 24. Section 10.2: "If the retargeting is due to receipt of an explicit SIP response and the response contains any Reason header fields (see [RFC3326]), then the SIP entity MUST include the Reason header fields in the hi- targeted-to-uri containing the URI of the request that was retargeted" According to 9.3 step 2, we add Reason to the cached hi-entries, and indepe= ndently of whether the request then gets retargeted. I think it should say = something like: "To add Reason header fields to a cached hi-entry as a res= ult of receiving a response to the request sent to the hi-entry's hi-target= ed-to-uri, a SIP entity MUST use any Reason header fields received in the r= esponse" 25. Section 10.2: "MUST include a Reason header field, containing the SIP Response Code" What if it is a 2xx response - does this make sense? 26. In the same sentence: "that triggered the retargeting, in the hi-targeted-to-uri containing the URI of the request that was retargeted" Delete these words, because it gets added to the cached hi-entry independen= tly of whether it is then retargeted. 27. Section 10.2: "containing a SIP error response code of 408 "Request Timeout" in hi-targeted-to-uri containing the URI of the request that was retargeted. " Again, delete "in hi-targeted-to-uri containing the URI of the request that was retargeted. " because we are just talking about adding to the cache. 28. Section 10.2: "The SIP entity MAY also include a Reason header field in the hi-targeted-to- uri containing the URI of the request that was retargeted as a result of internal retargeting." Change "the request" to "a request". 29. Section 10.2: "If additional Reason headers are defined in the future " Does this mean "additional protocol values"? However, no specific protocol = values are mentioned above, so why to we need to mention "additional" proto= col values? 30. Section 10.3: "Basic Forwarding: " What is "Basic Forwarding"? 31. Section 10.3, item 1: "In the case of a request that is being forwarded" Any request can be forwarded eventually, even it has been retargeted, redir= ected, etc.. So how exactly does this case 1 differ from some of the other = cases? 32. Also in item 1: "MUST add another level of indexing by appending the dot delimiter followed by an initial hi-index for the new level of 1." The new level is not, in general, level 1. I think this should say "An init= ial value of 1 for the new level." Unfortunately the ABNF fails to give a n= ame to a single component of hi-index, so I have just called it "value". 33. "a proxy would add an hi-entry with an hi-index to 1.1.1 " Change "to" to "of". 34. In item 3: "Retargeting within a processing entity - subsequent instance: For each subsequent retargeting of a request by the same SIP entity, the SIP entity MUST add another branch." What exactly is "another branch"? RFC 3261 already talks about creating bra= nches, so why do we need a normative statement here to tell us to do someth= ing that is normatively specified in RFC 3261? We should only be making nor= mative statements that are specific to H-I. 35. Also in item 3: "The SIP entity MUST calculate the hi-index for each new branch by incrementing the value from the hi-index in the last hi-entry at the current level." It is unclear what "value" means. I think it is the value of the rightmost = level. 36. In item 4: "That is, the lowest/last digit of the hi-index MUST be incremented" Since a value for a particular level within hi-index can comprise more than= one digit, the word "digit" here is not correct. It is the integer that sh= ould be incremented. 37. In the same sentence: "MUST be incremented (i.e., a new branch is created), with the increment of 1" I think "with the increment of 1" can be deleted. 38. In item 5: "Note that for each individual fork, only the hi-entry corresponding to that fork is included (e.g., the hi- entry for fork 1.1.1 is not included in the request sent to fork 1.1.2, and vice-versa)." I don't think this is true. For example, I receive hi-entry 1.2, I fork fir= st of all with hi-entry 1.2.1. This receives a response 4xx, so I then fork= again, this time with hi-entry 1.2.2. I thought in this case hi-entry 1.2.= 1, as well as 1.2.2, would be included in the new forwarded request (since= 1.2.1 will be in the cache at this stage). 39. "10.4. Mechanism for Target Determination in the History-Info Header Field" Wrong title - the section is to do with indicating how the target was deter= mined, not with the determination mechanism itself. Perhaps "10.4 Indicatin= g the mechanism by which the target was determined..." 40. Section 10.4: " This specification defines two header field parameters, "rc" and "mp", indicating two non-inclusive mechanisms by which a new target for a request is determined." I am not sure what "non-inclusive" means here. 41. Section 10.4: "in the case of 3xx responses" I think this should say "in the case of retargeting to a contact URI receiv= ed in a 3xx response". 42. Section 10.4: "If the Contact header field does not contain an "rc" or "mp" header field parameter, then the SIP entity MUST NOT include an "rc" or "mp" in the hi-entry when the request is retargeted." I think this sentence is still talking about the 3xx case, but it is not cl= ear. Should say: "....when the request is retargeted to a contact URI received in a 3xx resp= onse". 43. Section 10.4: ""rc": The target was determined based on a contact that is bound to an AOR in an abstract location service for the Request-URI being retargeted." This doesn't make it clear that the Request-URI is the AOR. However, for bo= th this and the "mp" bullet point, we should perhaps refer to section 5, wh= ere those are defined, rather than reproducing the definition here with the= risk of it being different. 44. Section 10.4: "The mapping was done due to receiving a 3xx response, in which case the mp-value is an earlier sibling of the hi-entry's index, that of the downstream request which received the 3xx response." I don't think this is right, since the issuer of the 3xx will build the rc = or mp parameter, and therefore it will reference the index received by that= entity. This could indeed be a sibling, but it could also be a child of a = sibling, a child of a child of a sibling, and so on. 45. Section 11: "Thus, if gaps are detected, the SIP entity MUST NOT treat this as an error, but rather indicate to any applications that there are gaps." I think changing "rather indicate" to "MUST indicate" would be clearer, if = we do indeed intend it normatively. 46. Section 11: "The most complete information available to the application is the History-Info entries starting with the last hi-entry with an index of "1"." This is not true. The most complete is the complete set of hi-entries. Even= if there are gaps, the information subsequent to the last gap will not be = as complete as the total information. 47. Section 11: "The following summarizes the categories of information that applications can use:" I thinks these are only examples, rather than a summary of everything an ap= plication could used. Change "summarizes" to "examples". 48. Section 11, item 2: "the index that matches the value of the last hi- entry with ..." An index cannot match an entire hi-entry. I think this should say "the inde= x that matches the value of the "rc" parameter in the last hi- entry with ..." A similar correction should be applied to items 3, 4 and 5 too. 49. Section 11, item 2: "rc" header parameter" I am not sure that "header parameter" is the right way to describe "rc". It= might be more accurate to say "hi-entry parameter" or, to use the ABNF nam= e, "hi-target-parameter", or simply "parameter". Whatever is chosen, it nee= ds to be consistent throughout the document. A similar correction should be applied to items 3, 4 and 5 too. 50. Section 11, item 2: "i.e., the Request URI associated with the destination of the request was determined based on an AOR-to-contact binding in an abstract location service." This is confusing, because the Request-URI changes during retargeting, and = it is not clear to which Request-URI and to which request we refer. Perhaps= it means the final target, but that is not necessarily true - I am sure th= ere must be some corner cases where there is a non-"rc" retarget after the = last "rc" retarget. I think all we can say for certain is something like: "= i.e., the last AOR that was retargeted to a contact based on an AOR-to-cont= act binding in an abstract location service." Note that a formulation like = this would better match the style of the formulation in item 3. 51. Section 11, item 4: "thus the first hi-entry with an "rc" header parameter within the domain associated with the target URI at the destination is more likely to be useful." I think this should say: "thus the hi-entry that matches the value of the "rc" parameter of the firs= t hi-entry with an "rc" parameter within the domain..." A similar correction should be applied to item 5 too. 52. Section 11: "hi-entry who index " Change to: "hi-entry whose index " 53. Section 11: "matches the index of the first" I think this should say: "matches value of the "mp" parameter of the first" 54. Section 11: "History-Info entry" Why not "hi-entry" as elsewhere? Similarly "History-Info entries" later in sentence. 55. Section 11: "with an hi-target value of "mp" " Whatever terminology we end up with from comment 49, we should align here t= oo, e.g., "with an "mp" parameter". Similarly for "rc" later in sentence. 56. Section 11: "Since support for History-info header field is optional, a service MUST define default behavior for requests and responses not containing History-Info headers." Change "History-Info headers" to "a History-Info header field". 57. Section 11: "For example, an entity may receive only partial History-Info entries or entries" Surely each hi-entry will be a complete entry, but an entity might receive = an incomplete set of hi-entries. Also correct the terminology. Change to: "For example, an entity may receive an incomplete set of hi-entries" 58. Section 12: If an entity forwards a request containing an hi-entry marked as private to= another entity within the same domain, it expects that other entity to ano= nymize the hi-entry before forwarding outside the domain. However, what hap= pens if that other entity doesn't support H-I? Presumably the RFC 3325 conc= ept of Trust Domain needs to be extended somehow to RFC4424bis, such that f= or an entity to be considered in the same Trust Domain it must support RFC4= 424bis. There should be some discussion around this. See also comment 18. John > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 15 March 2011 18:46 > To: SIPCORE > Subject: [sipcore] Fwd: I-D > ACTION:draft-ietf-sipcore-rfc4244bis-04.txt > > Hi folks, > > I have updated the document to incorporate the feedback on > the -03 as follows: > > 1) The biggest change was the reformating inline with John's > suggestion: > http://www.ietf.org/mail-archive/web/sipcore/current/msg04010.html > It is not verbatim, but rather I included some of the past > text in the relevant sections and I included a bullet list in > some cases rather than just a paragraph as that was one of > the formatting changes we made between RFC4244 and 4244bis in > that the text in paragraph form can be rather dense. I > believe the spirit and intent of John's proposal has been > accomodated (I don't know that as many words were saved). > Also, I just noticed some of the bullet lists don't have the > "o" - I'll have to fix that. I think one of the most > important aspects of John's proposal was introducing the > "caching" of the hi-entries as that wasn't clearly spelled > out previously and that really did help to clarify the > processing. I do think the breakdown in the > sending/receiving of the request and sending/receiving of a > response into common processing is quite helpful. > > 2) Removed the term "escape" with regards to the Privacy and > Reason header fields and just stated that those header fields > were included in the hi-targeted-to-uri. I think this also > improves readbility. > > 3) Additional clarification around the Tel-URI. > > I think the doc should be ready for another WGLC. > > Thanks, > Mary. > > > ---------- Forwarded message ---------- > From: > Date: Tue, Mar 15, 2011 at 1:30 PM > Subject: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt > To: i-d-announce@ietf.org > Cc: sipcore@ietf.org > > > A new Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol > Core Working Group of the IETF. > > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, et al > Filename : draft-ietf-sipcore-rfc4244bis-04.txt > Pages : 32 > Date : 2011-03-15 > > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol (SIP) > request. This capability enables many enhanced services by > providing > the information as to how and why a SIP request arrives at > a specific > application or user. This document defines an optional SIP header > field, History-Info, for capturing the history information in > requests. The document also defines SIP header field parameters for > the History-Info and Contact header fields to tag the > method by which > the target of a request is determined. In addition, this document > defines a value for the Privacy header field specific to > the History- > Info header field. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244 > bis-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft > aft> directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > From shida@ntt-at.com Sat Mar 26 02:58:58 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620FA3A690F for ; Sat, 26 Mar 2011 02:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWDlBIIZYnEY for ; Sat, 26 Mar 2011 02:58:55 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.14.8]) by core3.amsl.com (Postfix) with SMTP id 101BE3A690E for ; Sat, 26 Mar 2011 02:58:54 -0700 (PDT) Received: (qmail 300 invoked from network); 26 Mar 2011 10:00:08 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway04.websitewelcome.com with SMTP; 26 Mar 2011 10:00:08 -0000 Received: from [90.176.238.10] (port=56799 helo=[10.42.202.12]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q3QID-0003ff-CN; Sat, 26 Mar 2011 05:00:29 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Shida Schubert In-Reply-To: Date: Sat, 26 Mar 2011 10:39:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 09:58:58 -0000 My apology for joining the conversation late.=20 We discussed few things related to this in the past.=20 To distinguish the service such as the ones described in the=20 draft, I had proposed using URN schema that we can attach=20 and expand to H-I when we first start discussing 4244bis and=20 target draft.=20 =20 Hadriel also mentioned a potential need for a parameter beside=20 mp and rc that can distinguish diversion from another mapping=20 (toll-free etc.) prior or during the WGLC last year.=20 Although these additional information may be nice to have,=20 because of how premium or toll-free services are usually=20 implemented and deployed, I believe current specification=20 is sufficient as illustrated/described in the call-flow spec=20 we recently submitted.=20 I believe because these services affect billing greatly, and=20 can raise potential lawsuits etc, the service will always be=20 implemented/deployed in rather predictable way. Allowing=20 receiving entity to easily scan the H-I to find that the call is =20 a toll-free call or premium call.=20 For example, what would happen if you call a toll-free number=20 and it gets forwarded to premium number? You think you are=20 calling a number for free but realize later that what you thought=20 was a call free has ballooned your phone bill. This doesn't=20 happen in practice.=20 Regards Shida On Mar 18, 2011, at 8:33 AM, Elwell, John wrote: >=20 >=20 >> -----Original Message----- >> From: marianne.mohali@orange-ftgroup.com >> [mailto:marianne.mohali@orange-ftgroup.com] >> Sent: 17 March 2011 21:17 >> To: Elwell, John; pkyzivat@cisco.com >> Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com >> Subject: RE: [sipcore] >> I-DAction:draft-mohali-sipcore-reason-extension-application-01 >>=20 >> Hi John, >>=20 >>> -----Message d'origine----- >>> De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Envoy=E9 : jeudi 10 mars 2011 17:01 >>> =C0 : MOHALI Marianne RD-CORE-ISS; pkyzivat@cisco.com >>> Cc : sipcore@ietf.org; Christer.Holmberg@ericsson.com >>> Objet : RE: [sipcore] >>> I-DAction:draft-mohali-sipcore-reason-extension-application-01 >>>=20 >>> I have already commented that this sort of usage of H-I is >>> appropriate only for closed networks. >> [MM] Correct. The draft extends the Reason header not only >> for H-I case, but also for *normal* use of Reason header field. >>>=20 >>> In addition to that, what I seem to be hearing is that the >>> UAS needs to look at H-I to determine how the request >>> arrived, and in particular whether it arrived because of >>> retargeting due to premium rate (for example). Am I correct so far? >> [MM] The UAS should be itself a service using this >> information. It is not considered as a need for the UAS, but >> as an enhanced feature for the service and the customers. >>>=20 >>> The whole concept behind 4244bis is that the UAS, in order to >>> discover how a request arrived, scans back through the >>> hi-entries looking at the parameters. So far we have two such >>> parameters: "rc" and "mp". Marianne seems to be asserting >>> that these two parameters are insufficient, and that other >>> information in the hi-entries needs to be viewed in order to >>> determine that retargeting due to premium rate (for example) >>> took place. However, the proposed solution is to add this in >>> the "headers" component of the URI concerned, rather than add >>> a new hi-entry parameter. So the UAS, in order to analyse the >>> history of the request, now has to scan for both hi-entry >>> parameters AND URI headers. I don't understand why hi-entry >>> parameters are not proposed for such applications. Having >>> said that, we had a longgggg discussion trying to hammer out >>> the set of hi-entry parameters that we really needed, and the >>> final consensus was just to have "rc" and "mp". I would not >>> want to open up that discussion again, but on the other hand >>> using a different mechanism for solving a similar problem >>> seems inappropriate. >> [MM] UAS already has to scan URI headers to apply Privacy or >> to find the call forwarding reason (according to 3GPP 24.604). >> "rc" and "mp" could be usefull but are not sufficient for >> enhanced supplementary services needs. I expressed the need >> for applications when discussion started for "rc" and "mp"... >> About having a H-I parameter, I'm not against it. The cons is >> that it may not be possible to have this application-specific >> reason for SIP responses and other SIP methods where Reason >> header field can be used. > [JRE] This does not fully address the point I was making. I was making = the point that to find the particular hi-entry you are interested in you = need, at present, to scan hi-entries looking at their parameters - you = do not need to look at the URIs in those hi-entries and the URIs' = "headers" components in order to find the hi-entry you are looking for. = Of course, once you have found the hi-entry you are looking for, you = will be interested in the URI and in anything attached to it, including = Privacy and Reason header fields within its "headers" component. The = draft under discussion seems to change that principle so that in order = to find the hi-entry you are looking for you need to look inside the = URIs. This seems to me like a change of principle - the logic of = including the proposed application information in the URI as a header = field, rather than in hi-entry parameters, is not at all clear to me. >=20 > John >=20 >=20 >>=20 >> Marianne >>>=20 >>> John >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of >>>> marianne.mohali@orange-ftgroup.com >>>> Sent: 07 March 2011 18:30 >>>> To: pkyzivat@cisco.com >>>> Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com >>>> Subject: Re: [sipcore] I-DAction: >>>> draft-mohali-sipcore-reason-extension-application-01 >>>>=20 >>>> Paul, >>>>=20 >>>> I think that Christer's draft (proxy-feature) is about >> capabilities >>>> while this one (reason-extension-application) is about >> what really >>>> happened (like reason in general). It is provided only when >>> the event >>>> happens and the purpose is to give an accuate information for >>>> applicative events. >>>>=20 >>>> Let me give you an other example: >>>> A reception AS called with several premium rate numbers (1 >>> per hosted >>>> application/service). The AS dispatches calls to several >>> call centers >>>> (eg. Depending on charge, hour of the day/night...). The final >>>> destination needs to know the called service. The premuim >>> rate number >>>> should be listed in the H-I header. Which entry? For which >>>> application/service invocated? >>>> As you can have a call forwarding reason associated to a >> 3xx or 486 >>>> Reason-cause, you could have an applicative reason to >>> easily identify >>>> the premium rate dialed number. >>>>=20 >>>> Regards, >>>> Marianne >>>>=20 >>>>=20 >>>>> -----Message d'origine----- >>>>> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : >>> lundi 7 mars >>>>> 2011 01:42 =C0 : MOHALI Marianne RD-CORE-ISS Cc : >> sipcore@ietf.org; >>>>> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] I-DAction: >>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>>=20 >>>>> Marianne >>>>>=20 >>>>> On 3/4/2011 11:59 AM, marianne.mohali@orange-ftgroup.com wrote: >>>>>> Hi Paul, >>>>>>=20 >>>>>> My answer below [MM] >>>>>>=20 >>>>>> Marianne >>>>>>> -----Message d'origine----- >>>>>>> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : >>>>> jeudi 3 mars >>>>>>> 2011 18:31 =C0 : MOHALI Marianne RD-CORE-ISS Cc : >>>> sipcore@ietf.org; >>>>>>> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] >> I-DAction: >>>>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>>>>=20 >>>>>>> Marianne, >>>>>>>=20 >>>>>>> On 3/3/2011 11:51 AM, >> marianne.mohali@orange-ftgroup.com wrote: >>>>>>>> Hi Paul, >>>>>>>>=20 >>>>>>>> The purpose is to allow applications/services to be >>>>>>> explicitely identified in the signaling path, so that others >>>>>>> services/applications/telephony-AS can act accordingly. >>>>>>> Either to apply a process taking into account the service >>>>> interaction >>>>>>> or on the contrary, do not execute a feature already >>>>> covered by the >>>>>>> application. >>>>>>>> For instance, a caller with a prepaid service calls a >>>>>>> directory enquiries Server to ask for a restaurant phone >>>>> number. The >>>>>>> operator would suggest to connect the caller to the >>>>> researched phone >>>>>>> number EXCEPT if the caller has a prepaid service because >>>>> it is not >>>>>>> sure he has enough credit to pay for the communication. To >>>>> allow this >>>>>>> customized feature, the directory enquiries Application >>>>> needs to know >>>>>>> that the prepaid Application has been invocated. >>>>>>>=20 >>>>>>> So once again, we are back to your wanting to use >>> Reason not to >>>>>>> express a "reason" for anything, but rather as just a >>>> hook to hang >>>>>>> something on H-I. >>>>>> [MM] The *reason* why the call has been >>>>> retargeted/rejected/modified is the invocation of a specific >>>>> application. >>>>>> If you call a Service number and then the URI is changed >>>>> for routing to the real destination, the *reason* of the URI >>>>> modification (listed in H-I) is the application. >>>>>=20 >>>>> Based on your other replies, this is not necessarily so. >>>>>=20 >>>>> In fact the example above is a counter-example. >>>>> The prepaid service is not responsible for any >>> redirection, and the >>>>> operator service is looking for it for a reason other >>> than that it >>>>> has been the cause of anything. Its looking for it >>> because it might >>>>> be the cause of something in the future. >>>>>=20 >>>>>>> (With the causes you have defined, I can't imagine it making >>>>>>> *any* sense to actually use one in a Reason header in >>> a message, >>>>>>> because they aren't specific enough to be actionable.) >>>>>>>=20 >>>>>>> I am now thinking there is a large overlap between >>> what you are >>>>>>> trying to accomplish this way, and what Christer is >> trying to >>>>>>> accomplish with draft-holmberg-sipcore-proxy-feature. >>>>>>>=20 >>>>>>> Is that true? >>>>>>>=20 >>>>>>> (Christer: What do you think?) >>>>>> [MM] I don't see the overlap with Christer's draft because >>>>> it is not about capabilities, it is about what's happened. >>>>>=20 >>>>> In your example above, it seems that the operator service >>> is looking >>>>> for the prepaid service because the prepaid service has the >>>>> capability to influence billing, or something like that. >>> This seems >>>>> at least somewhat in line with what Christer is >>> advocating. Looking >>>>> in the Route header, or Record-Route header would make at >>> least as >>>>> much sense for this case as looking in H-I. H-I makes >>> sense if you >>>>> are indeed looking for something that has already >>> happened, perhaps >>>>> on a path other that the current one. >>>>>=20 >>>>> I think it would be helpful for the two of you to come to some >>>>> reconciliation of what you are trying to accomplish. >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>>>>> About your comment in case of several applications involved >>>>>>> *simultaneously* in the call establishment, it is possible >>>>> to add 1 >>>>>>> more hi-entry for the second application Cause you >> want to be >>>>>>> identified in the signaling path. >>>>>>>=20 >>>>>>> Sure, you can indicate that they are "involved". But you >>>>> can't infer >>>>>>> anything about which one "caused" something. They might >>>>> have, but you >>>>>>> can't tell it from the presence of these headers. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Paul >>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Marianne >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : sipcore-bounces@ietf.org >>>>>>>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul >>>>>>> Kyzivat Envoy=E9 : >>>>>>>>> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org Objet : Re: >>>>> [sipcore] >>>>>>>>> I-DAction: >>>>>>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>>>>>>=20 >>>>>>>>> (As individual) >>>>>>>>>=20 >>>>>>>>> Marianne, >>>>>>>>>=20 >>>>>>>>> I'm still struggling to make sense of this in the form >>>> proposed. >>>>>>>>>=20 >>>>>>>>> I look at the various cause values, and all the >>>>>>> descriptions are of >>>>>>>>> the form. E.g.: >>>>>>>>>=20 >>>>>>>>> Cause value: 2 >>>>>>>>> Reason text: Freephone >>>>>>>>> Description: A Freephone application has >> influenced >>>>>>>>> processing of >>>>>>>>> the call (e.g. by translating a dialed Free Phone >>>>>>> number to a >>>>>>>>> routable directory number). >>>>>>>>>=20 >>>>>>>>> I can't figure out how to make any actionable decision >>>>>>> based on this. >>>>>>>>> Rather, it seems I need to make a number of leaps of faith >>>>>>> before I >>>>>>>>> can decide what to do. >>>>>>>>>=20 >>>>>>>>> For instance, if I get an error, it *might* be because I >>>>> dialed a >>>>>>>>> freephone number, and it isn't supported from my calling >>>>> location. >>>>>>>>> (E.g. >>>>>>>>> maybe I'm dialing +1-800-555-1234, but I'm doing so from >>>>>>> France, and >>>>>>>>> calling that number is only supported in the USA. >>>>>>>>>=20 >>>>>>>>> But getting a application reason code with cause 2 >>>>> doesn't really >>>>>>>>> tell me that is what happened. It could be that the call >>>>>>> indeed was >>>>>>>>> routed through a freephone application, and it properly >>>>> routed the >>>>>>>>> call, and the call failed for some other reason. But the >>>>> cause is >>>>>>>>> there because the application >>>>>>>>> *did* influence the call routing. >>>>>>>>>=20 >>>>>>>>> Also, these "applications" are not, AFAIK, mutually >>>>>>> exclusive. E.g. I >>>>>>>>> could be using a prepaid service to make a directory >>>>>>> assistance call >>>>>>>>> that costs extra $$$ that I don't have credits to >>>> cover. But you >>>>>>>>> can't include two cause values for the same protocol. (But >>>>>>> it is true >>>>>>>>> that you >>>>>>>>> *can* have a number of servers each put one cause into >>>>>>>>> *their* H-I entry.) >>>>>>>>>=20 >>>>>>>>> So *maybe* I would see that my call failed, and that there >>>>>>> is both a >>>>>>>>> reason indicating a prepaid application on one H-I entry, >>>>>>> and another >>>>>>>>> indicating a another H-I indicating a directory service >>>>>>> application. >>>>>>>>> But what can I conclude from that? >>>>>>>>>=20 >>>>>>>>> Bottom line, I just can't make sense how this could be >>>>>>> used in a well >>>>>>>>> defined and interoperable way. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>>=20 >>>>>>>>> On 2/28/2011 9:58 AM, >>> marianne.mohali@orange-ftgroup.com wrote: >>>>>>>>>> Hello, >>>>>>>>>>=20 >>>>>>>>>> Here is the new version of the draft. >>>>>>>>>> Main changes are following: >>>>>>>>>> - More details about the registration procedure for >>> new values >>>>>>>>>> - Clearer text in section 3.2 >>>>>>>>>> - Add of Public and Private status for registered values. >>>>>>>>>> - Add of a range for cause values registration >>>>>>>>>>=20 >>>>>>>>>> Best Regards, >>>>>>>>>> Marianne Mohali >>>>>>>>>>=20 >>>>>>>>>> -----Message d'origine----- >>>>>>>>>> Objet : New Version Notification for >>>>>>>>>> draft-mohali-sipcore-reason-extension-application-01 >>>>>>>>>>=20 >>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>> Internet-Drafts >>>>>>>>>> directories. >>>>>>>>>>=20 >>>>>>>>>> Title : Extending the Session >>>>> Initiation Protocol >>>>>>>>>> (SIP) Reason Header for Applications >>>>>>>>>> Author(s) : M. Mohali, B. Chatras >>>>>>>>>> Filename : >>>>>>>>>> draft-mohali-sipcore-reason-extension-application-01.txt >>>>>>>>>> Pages : 10 >>>>>>>>>> Date : 2011-02-24 >>>>>>>>>>=20 >>>>>>>>>> This document defines a new protocol value >>>>> "Application" for the >>>>>>>>>> Reason Header field and a new IANA Registry for >> registering >>>>>>>>>> application types. This new value enables >> signaling that a >>>>>>>>> request or >>>>>>>>>> response has been issued as a result of a decision >>> made by a >>>>>>>>>> particular type of application or that an initial request >>>>>>> has been >>>>>>>>>> retargeted as a result of an application decision. >>>>>>>>>>=20 >>>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >> http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten >>>>>>>>> s >>>>>>>>>> io >>>>>>>>>> n-application-01.txt >>>>>>>>>>=20 >>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>=20 >>>>>>>>>> Below is the data which will enable a MIME compliant >>>>> mail reader >>>>>>>>>> implementation to automatically retrieve the ASCII >>>>> version of the >>>>>>>>>> Internet-Draft. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >> >>>>>>>> s >>>>>>>>>> io >>>>>>>>>> n-application-01.txt> >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> I-D-Announce mailing list >>>>>>>>>> I-D-Announce@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>> Internet-Draft directories: >>>> http://www.ietf.org/shadow.html or >>>>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>>> _______________________________________________ >>>>>>>>>> sipcore mailing list >>>>>>>>>> sipcore@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> sipcore mailing list >>>>>>>>> sipcore@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>=20 >>>=20 >>=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From marianne.mohali@orange-ftgroup.com Mon Mar 28 09:54:30 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19FB33A6879 for ; Mon, 28 Mar 2011 09:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.072 X-Spam-Level: X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99hhZzjxyqMM for ; Mon, 28 Mar 2011 09:54:28 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 6BD853A67A1 for ; Mon, 28 Mar 2011 09:54:27 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A73C88B801D; Mon, 28 Mar 2011 18:56:35 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 925DB8B8017; Mon, 28 Mar 2011 18:56:35 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 18:55:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Mar 2011 18:55:41 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvrnLmBRKR0Ckn3TOemgDvuZfujWABxJ4ng References: <4D6C2CB6.4040800@cisco.com><4D6FD03A.8040507@cisco.com><4D7429E9.5070607@cisco.com> From: To: , X-OriginalArrivalTime: 28 Mar 2011 16:55:43.0421 (UTC) FILETIME=[F9D74ED0:01CBED68] Cc: sipcore@ietf.org, Christer.Holmberg@ericsson.com Subject: Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:54:30 -0000 Hi Shida, First, note that the discussion will be moved to DISPATCH as recommended = by Paul and Adam. About your comments, I want to remind the 3 distinct uses we want to = address: 1) To convey a list of services having "acted" on the call, in order to = allow a downstream application to manage services interactions. This = could be done with a separate parameter from H-I and Reason headers. 2) To convey the identity (dialled number) of the application having = caused a specific number translation and allow the transfer target to = find out the good application number in case of successive number = translation. This can only be done in H-I (in Reason or anywhere else). 3) To convey the identity of the application having released the call, = towards an upstream application that can take specific decisions. This = could be done with a totally new parameter (independent from the Reason = header). Finally, to address the point Hadriel mentionned about the call = forwarding identification, I've thought about registering a public cause = value in this draft dedicated to "call forwarding" that can be used to = identify H-I entries representing diverting users (in the sense of 3GPP = 24.602). Our though is that Reason header can address all these needs. 'mp' H-I parameter could be a macro information and the Reason a = detailed information when needed. Best Regards, Marianne=20 > -----Message d'origine----- > De : Shida Schubert [mailto:shida@ntt-at.com]=20 > Envoy=E9 : samedi 26 mars 2011 10:39 > =C0 : Elwell, John > Cc : MOHALI Marianne RD-CORE-ISS; pkyzivat@cisco.com;=20 > sipcore@ietf.org; Christer.Holmberg@ericsson.com > Objet : Re: [sipcore]=20 > I-DAction:draft-mohali-sipcore-reason-extension-application-01 >=20 >=20 > My apology for joining the conversation late.=20 >=20 > We discussed few things related to this in the past.=20 >=20 > To distinguish the service such as the ones described in the=20 > draft, I had proposed using URN schema that we can attach and=20 > expand to H-I when we first start discussing 4244bis and=20 > target draft.=20 > =20 > Hadriel also mentioned a potential need for a parameter=20 > beside mp and rc that can distinguish diversion from another=20 > mapping (toll-free etc.) prior or during the WGLC last year.=20 >=20 > Although these additional information may be nice to have,=20 > because of how premium or toll-free services are usually=20 > implemented and deployed, I believe current specification is=20 > sufficient as illustrated/described in the call-flow spec we=20 > recently submitted.=20 >=20 > I believe because these services affect billing greatly, and=20 > can raise potential lawsuits etc, the service will always be=20 > implemented/deployed in rather predictable way. Allowing=20 > receiving entity to easily scan the H-I to find that the call=20 > is a toll-free call or premium call.=20 >=20 > For example, what would happen if you call a toll-free=20 > number and it gets forwarded to premium number? You think you=20 > are calling a number for free but realize later that what you=20 > thought was a call free has ballooned your phone bill. This=20 > doesn't happen in practice.=20 >=20 > Regards > Shida >=20 > On Mar 18, 2011, at 8:33 AM, Elwell, John wrote: >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: marianne.mohali@orange-ftgroup.com > >> [mailto:marianne.mohali@orange-ftgroup.com] > >> Sent: 17 March 2011 21:17 > >> To: Elwell, John; pkyzivat@cisco.com > >> Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com > >> Subject: RE: [sipcore] > >> I-DAction:draft-mohali-sipcore-reason-extension-application-01 > >>=20 > >> Hi John, > >>=20 > >>> -----Message d'origine----- > >>> De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>> Envoy=E9 : jeudi 10 mars 2011 17:01 > >>> =C0 : MOHALI Marianne RD-CORE-ISS; pkyzivat@cisco.com Cc :=20 > >>> sipcore@ietf.org; Christer.Holmberg@ericsson.com Objet : RE:=20 > >>> [sipcore] > >>> I-DAction:draft-mohali-sipcore-reason-extension-application-01 > >>>=20 > >>> I have already commented that this sort of usage of H-I is=20 > >>> appropriate only for closed networks. > >> [MM] Correct. The draft extends the Reason header not=20 > only for H-I=20 > >> case, but also for *normal* use of Reason header field. > >>>=20 > >>> In addition to that, what I seem to be hearing is that=20 > the UAS needs=20 > >>> to look at H-I to determine how the request arrived, and in=20 > >>> particular whether it arrived because of retargeting due=20 > to premium=20 > >>> rate (for example). Am I correct so far? > >> [MM] The UAS should be itself a service using this=20 > information. It is=20 > >> not considered as a need for the UAS, but as an enhanced=20 > feature for=20 > >> the service and the customers. > >>>=20 > >>> The whole concept behind 4244bis is that the UAS, in order to=20 > >>> discover how a request arrived, scans back through the hi-entries=20 > >>> looking at the parameters. So far we have two such > >>> parameters: "rc" and "mp". Marianne seems to be asserting=20 > that these=20 > >>> two parameters are insufficient, and that other=20 > information in the=20 > >>> hi-entries needs to be viewed in order to determine that=20 > retargeting=20 > >>> due to premium rate (for example) took place. However,=20 > the proposed=20 > >>> solution is to add this in the "headers" component of the URI=20 > >>> concerned, rather than add a new hi-entry parameter. So=20 > the UAS, in=20 > >>> order to analyse the history of the request, now has to scan for=20 > >>> both hi-entry parameters AND URI headers. I don't understand why=20 > >>> hi-entry parameters are not proposed for such=20 > applications. Having=20 > >>> said that, we had a longgggg discussion trying to hammer=20 > out the set=20 > >>> of hi-entry parameters that we really needed, and the final=20 > >>> consensus was just to have "rc" and "mp". I would not=20 > want to open=20 > >>> up that discussion again, but on the other hand using a =20 > different=20 > >>> mechanism for solving a similar problem seems inappropriate. > >> [MM] UAS already has to scan URI headers to apply Privacy=20 > or to find=20 > >> the call forwarding reason (according to 3GPP 24.604). > >> "rc" and "mp" could be usefull but are not sufficient for enhanced=20 > >> supplementary services needs. I expressed the need for=20 > applications=20 > >> when discussion started for "rc" and "mp"... > >> About having a H-I parameter, I'm not against it. The cons=20 > is that it=20 > >> may not be possible to have this application-specific=20 > reason for SIP=20 > >> responses and other SIP methods where Reason header field can be=20 > >> used. > > [JRE] This does not fully address the point I was making. I=20 > was making the point that to find the particular hi-entry you=20 > are interested in you need, at present, to scan hi-entries=20 > looking at their parameters - you do not need to look at the=20 > URIs in those hi-entries and the URIs' "headers" components=20 > in order to find the hi-entry you are looking for. Of course,=20 > once you have found the hi-entry you are looking for, you=20 > will be interested in the URI and in anything attached to it,=20 > including Privacy and Reason header fields within its=20 > "headers" component. The draft under discussion seems to=20 > change that principle so that in order to find the hi-entry=20 > you are looking for you need to look inside the URIs. This=20 > seems to me like a change of principle - the logic of=20 > including the proposed application information in the URI as=20 > a header field, rather than in hi-entry parameters, is not at=20 > all clear to me. > >=20 > > John > >=20 > >=20 > >>=20 > >> Marianne > >>>=20 > >>> John > >>>=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: sipcore-bounces@ietf.org > >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > >>>> marianne.mohali@orange-ftgroup.com > >>>> Sent: 07 March 2011 18:30 > >>>> To: pkyzivat@cisco.com > >>>> Cc: sipcore@ietf.org; Christer.Holmberg@ericsson.com > >>>> Subject: Re: [sipcore] I-DAction: > >>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>=20 > >>>> Paul, > >>>>=20 > >>>> I think that Christer's draft (proxy-feature) is about > >> capabilities > >>>> while this one (reason-extension-application) is about > >> what really > >>>> happened (like reason in general). It is provided only when > >>> the event > >>>> happens and the purpose is to give an accuate information for=20 > >>>> applicative events. > >>>>=20 > >>>> Let me give you an other example: > >>>> A reception AS called with several premium rate numbers (1 > >>> per hosted > >>>> application/service). The AS dispatches calls to several > >>> call centers > >>>> (eg. Depending on charge, hour of the day/night...). The final=20 > >>>> destination needs to know the called service. The premuim > >>> rate number > >>>> should be listed in the H-I header. Which entry? For which=20 > >>>> application/service invocated? > >>>> As you can have a call forwarding reason associated to a > >> 3xx or 486 > >>>> Reason-cause, you could have an applicative reason to > >>> easily identify > >>>> the premium rate dialed number. > >>>>=20 > >>>> Regards, > >>>> Marianne > >>>>=20 > >>>>=20 > >>>>> -----Message d'origine----- > >>>>> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : > >>> lundi 7 mars > >>>>> 2011 01:42 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > >> sipcore@ietf.org; > >>>>> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] I-DAction: > >>>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>>=20 > >>>>> Marianne > >>>>>=20 > >>>>> On 3/4/2011 11:59 AM, marianne.mohali@orange-ftgroup.com wrote: > >>>>>> Hi Paul, > >>>>>>=20 > >>>>>> My answer below [MM] > >>>>>>=20 > >>>>>> Marianne > >>>>>>> -----Message d'origine----- > >>>>>>> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : > >>>>> jeudi 3 mars > >>>>>>> 2011 18:31 =C0 : MOHALI Marianne RD-CORE-ISS Cc : > >>>> sipcore@ietf.org; > >>>>>>> Christer.Holmberg@ericsson.com Objet : Re: [sipcore] > >> I-DAction: > >>>>>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>>>>=20 > >>>>>>> Marianne, > >>>>>>>=20 > >>>>>>> On 3/3/2011 11:51 AM, > >> marianne.mohali@orange-ftgroup.com wrote: > >>>>>>>> Hi Paul, > >>>>>>>>=20 > >>>>>>>> The purpose is to allow applications/services to be > >>>>>>> explicitely identified in the signaling path, so that others=20 > >>>>>>> services/applications/telephony-AS can act accordingly. > >>>>>>> Either to apply a process taking into account the service > >>>>> interaction > >>>>>>> or on the contrary, do not execute a feature already > >>>>> covered by the > >>>>>>> application. > >>>>>>>> For instance, a caller with a prepaid service calls a > >>>>>>> directory enquiries Server to ask for a restaurant phone > >>>>> number. The > >>>>>>> operator would suggest to connect the caller to the > >>>>> researched phone > >>>>>>> number EXCEPT if the caller has a prepaid service because > >>>>> it is not > >>>>>>> sure he has enough credit to pay for the communication. To > >>>>> allow this > >>>>>>> customized feature, the directory enquiries Application > >>>>> needs to know > >>>>>>> that the prepaid Application has been invocated. > >>>>>>>=20 > >>>>>>> So once again, we are back to your wanting to use > >>> Reason not to > >>>>>>> express a "reason" for anything, but rather as just a > >>>> hook to hang > >>>>>>> something on H-I. > >>>>>> [MM] The *reason* why the call has been > >>>>> retargeted/rejected/modified is the invocation of a specific=20 > >>>>> application. > >>>>>> If you call a Service number and then the URI is changed > >>>>> for routing to the real destination, the *reason* of the URI=20 > >>>>> modification (listed in H-I) is the application. > >>>>>=20 > >>>>> Based on your other replies, this is not necessarily so. > >>>>>=20 > >>>>> In fact the example above is a counter-example. > >>>>> The prepaid service is not responsible for any > >>> redirection, and the > >>>>> operator service is looking for it for a reason other > >>> than that it > >>>>> has been the cause of anything. Its looking for it > >>> because it might > >>>>> be the cause of something in the future. > >>>>>=20 > >>>>>>> (With the causes you have defined, I can't imagine it making > >>>>>>> *any* sense to actually use one in a Reason header in > >>> a message, > >>>>>>> because they aren't specific enough to be actionable.) > >>>>>>>=20 > >>>>>>> I am now thinking there is a large overlap between > >>> what you are > >>>>>>> trying to accomplish this way, and what Christer is > >> trying to > >>>>>>> accomplish with draft-holmberg-sipcore-proxy-feature. > >>>>>>>=20 > >>>>>>> Is that true? > >>>>>>>=20 > >>>>>>> (Christer: What do you think?) > >>>>>> [MM] I don't see the overlap with Christer's draft because > >>>>> it is not about capabilities, it is about what's happened. > >>>>>=20 > >>>>> In your example above, it seems that the operator service > >>> is looking > >>>>> for the prepaid service because the prepaid service has the=20 > >>>>> capability to influence billing, or something like that. > >>> This seems > >>>>> at least somewhat in line with what Christer is > >>> advocating. Looking > >>>>> in the Route header, or Record-Route header would make at > >>> least as > >>>>> much sense for this case as looking in H-I. H-I makes > >>> sense if you > >>>>> are indeed looking for something that has already > >>> happened, perhaps > >>>>> on a path other that the current one. > >>>>>=20 > >>>>> I think it would be helpful for the two of you to come to some=20 > >>>>> reconciliation of what you are trying to accomplish. > >>>>>=20 > >>>>> Thanks, > >>>>> Paul > >>>>>=20 > >>>>>>>> About your comment in case of several applications involved > >>>>>>> *simultaneously* in the call establishment, it is possible > >>>>> to add 1 > >>>>>>> more hi-entry for the second application Cause you > >> want to be > >>>>>>> identified in the signaling path. > >>>>>>>=20 > >>>>>>> Sure, you can indicate that they are "involved". But you > >>>>> can't infer > >>>>>>> anything about which one "caused" something. They might > >>>>> have, but you > >>>>>>> can't tell it from the presence of these headers. > >>>>>>>=20 > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>>=20 > >>>>>>>> Regards, > >>>>>>>> Marianne > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>>> -----Message d'origine----- > >>>>>>>>> De : sipcore-bounces@ietf.org > >>>>>>>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul > >>>>>>> Kyzivat Envoy=E9 : > >>>>>>>>> mardi 1 mars 2011 00:16 =C0 : sipcore@ietf.org Objet : Re: > >>>>> [sipcore] > >>>>>>>>> I-DAction: > >>>>>>>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>>>>>>=20 > >>>>>>>>> (As individual) > >>>>>>>>>=20 > >>>>>>>>> Marianne, > >>>>>>>>>=20 > >>>>>>>>> I'm still struggling to make sense of this in the form > >>>> proposed. > >>>>>>>>>=20 > >>>>>>>>> I look at the various cause values, and all the > >>>>>>> descriptions are of > >>>>>>>>> the form. E.g.: > >>>>>>>>>=20 > >>>>>>>>> Cause value: 2 > >>>>>>>>> Reason text: Freephone > >>>>>>>>> Description: A Freephone application has > >> influenced > >>>>>>>>> processing of > >>>>>>>>> the call (e.g. by translating a dialed Free Phone > >>>>>>> number to a > >>>>>>>>> routable directory number). > >>>>>>>>>=20 > >>>>>>>>> I can't figure out how to make any actionable decision > >>>>>>> based on this. > >>>>>>>>> Rather, it seems I need to make a number of leaps of faith > >>>>>>> before I > >>>>>>>>> can decide what to do. > >>>>>>>>>=20 > >>>>>>>>> For instance, if I get an error, it *might* be because I > >>>>> dialed a > >>>>>>>>> freephone number, and it isn't supported from my calling > >>>>> location. > >>>>>>>>> (E.g. > >>>>>>>>> maybe I'm dialing +1-800-555-1234, but I'm doing so from > >>>>>>> France, and > >>>>>>>>> calling that number is only supported in the USA. > >>>>>>>>>=20 > >>>>>>>>> But getting a application reason code with cause 2 > >>>>> doesn't really > >>>>>>>>> tell me that is what happened. It could be that the call > >>>>>>> indeed was > >>>>>>>>> routed through a freephone application, and it properly > >>>>> routed the > >>>>>>>>> call, and the call failed for some other reason. But the > >>>>> cause is > >>>>>>>>> there because the application > >>>>>>>>> *did* influence the call routing. > >>>>>>>>>=20 > >>>>>>>>> Also, these "applications" are not, AFAIK, mutually > >>>>>>> exclusive. E.g. I > >>>>>>>>> could be using a prepaid service to make a directory > >>>>>>> assistance call > >>>>>>>>> that costs extra $$$ that I don't have credits to > >>>> cover. But you > >>>>>>>>> can't include two cause values for the same protocol. (But > >>>>>>> it is true > >>>>>>>>> that you > >>>>>>>>> *can* have a number of servers each put one cause into > >>>>>>>>> *their* H-I entry.) > >>>>>>>>>=20 > >>>>>>>>> So *maybe* I would see that my call failed, and that there > >>>>>>> is both a > >>>>>>>>> reason indicating a prepaid application on one H-I entry, > >>>>>>> and another > >>>>>>>>> indicating a another H-I indicating a directory service > >>>>>>> application. > >>>>>>>>> But what can I conclude from that? > >>>>>>>>>=20 > >>>>>>>>> Bottom line, I just can't make sense how this could be > >>>>>>> used in a well > >>>>>>>>> defined and interoperable way. > >>>>>>>>>=20 > >>>>>>>>> Thanks, > >>>>>>>>> Paul > >>>>>>>>>=20 > >>>>>>>>> On 2/28/2011 9:58 AM, > >>> marianne.mohali@orange-ftgroup.com wrote: > >>>>>>>>>> Hello, > >>>>>>>>>>=20 > >>>>>>>>>> Here is the new version of the draft. > >>>>>>>>>> Main changes are following: > >>>>>>>>>> - More details about the registration procedure for > >>> new values > >>>>>>>>>> - Clearer text in section 3.2 > >>>>>>>>>> - Add of Public and Private status for registered values. > >>>>>>>>>> - Add of a range for cause values registration > >>>>>>>>>>=20 > >>>>>>>>>> Best Regards, > >>>>>>>>>> Marianne Mohali > >>>>>>>>>>=20 > >>>>>>>>>> -----Message d'origine----- > >>>>>>>>>> Objet : New Version Notification for > >>>>>>>>>> draft-mohali-sipcore-reason-extension-application-01 > >>>>>>>>>>=20 > >>>>>>>>>> A New Internet-Draft is available from the on-line > >>>>>>> Internet-Drafts > >>>>>>>>>> directories. > >>>>>>>>>>=20 > >>>>>>>>>> Title : Extending the Session > >>>>> Initiation Protocol > >>>>>>>>>> (SIP) Reason Header for Applications > >>>>>>>>>> Author(s) : M. Mohali, B. Chatras > >>>>>>>>>> Filename : > >>>>>>>>>> draft-mohali-sipcore-reason-extension-application-01.txt > >>>>>>>>>> Pages : 10 > >>>>>>>>>> Date : 2011-02-24 > >>>>>>>>>>=20 > >>>>>>>>>> This document defines a new protocol value > >>>>> "Application" for the > >>>>>>>>>> Reason Header field and a new IANA Registry for > >> registering > >>>>>>>>>> application types. This new value enables > >> signaling that a > >>>>>>>>> request or > >>>>>>>>>> response has been issued as a result of a decision > >>> made by a > >>>>>>>>>> particular type of application or that an initial request > >>>>>>> has been > >>>>>>>>>> retargeted as a result of an application decision. > >>>>>>>>>>=20 > >>>>>>>>>> A URL for this Internet-Draft is: > >>>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>=20 > >>>>>=20 > >>>>=20 > >>>=20 > >>=20 > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten > >>>>>>>>> s > >>>>>>>>>> io > >>>>>>>>>> n-application-01.txt > >>>>>>>>>>=20 > >>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>>>>>>=20 > >>>>>>>>>> Below is the data which will enable a MIME compliant > >>>>> mail reader > >>>>>>>>>> implementation to automatically retrieve the ASCII > >>>>> version of the > >>>>>>>>>> Internet-Draft. > >>>>>>>>>>=20 > >>>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>=20 > >>>>>=20 > >>>>=20 > >>>=20 > >>=20 > >>>>>>>>> s > >>>>>>>>>> io > >>>>>>>>>> n-application-01.txt> > >>>>>>>>>>=20 > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> I-D-Announce mailing list > >>>>>>>>>> I-D-Announce@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>>>>>>>> Internet-Draft directories: > >>>> http://www.ietf.org/shadow.html or > >>>>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> sipcore mailing list > >>>>>>>>>> sipcore@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>>>>>=20 > >>>>>>>>> _______________________________________________ > >>>>>>>>> sipcore mailing list > >>>>>>>>> sipcore@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>=20 > >>>>>>=20 > >>>>>=20 > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>=20 > >>>=20 > >>=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 From jmpolk@cisco.com Tue Mar 29 01:45:42 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32C93A69FC for ; Tue, 29 Mar 2011 01:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd+0zFJ2ylbK for ; Tue, 29 Mar 2011 01:45:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A11483A68CE for ; Tue, 29 Mar 2011 01:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1091; q=dns/txt; s=iport; t=1301388430; x=1302598030; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=cJb3bRyWGpnwMj0FixbBmMgEwvajOTpfJWRv9vthRFw=; b=GHKja/sno2L/uAIwhrsVqEEs1vy2Q1oR3QuM/uvMD9CztQWdU66R39Mi beuaN7Dnw/ssIc8yMymJJnvdWsQQgSWsdnJVOdbWoJBzqfMAR6TEox9t8 hPy8Ewc3xZ1+MKb9XUD1xNF3c6OmHtXWzYvKSPwk+VgolTyv5Yh9wfsV+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO2bkU2rRDoG/2dsb2JhbAClRnenTZxChWoEhTw X-IronPort-AV: E=Sophos;i="4.63,260,1299456000"; d="scan'208";a="284736050" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2011 08:47:10 +0000 Received: from jmpolk-wxp01.cisco.com ([10.89.8.40]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2T8l7uW032563; Tue, 29 Mar 2011 08:47:08 GMT Message-Id: <201103290847.p2T8l7uW032563@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Mar 2011 03:47:05 -0500 To: Robert Sparks , SIPCORE Chairs From: "James M. Polk" In-Reply-To: References: <4D6C31DC.80005@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-sipcore-location-conveyance@tools.ietf.org, "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:45:42 -0000 At 03:45 PM 3/9/2011, Robert Sparks wrote: >There are a couple of larger and several small things to also >address in this document before requesting publication. > >The larger things: > >3) I can't figure out what the paragraph in section 4.4 that starts >"Additionally, if a sip entity cannot..." and goes >onto talk about 503's is trying to say. I think some surrounding >context must have been lost or not captured. >Why would we be recommending sending a 503 here? pick on this one point, there was an error code for that basically said "couldn't process the location you just sent me, but it's ok to try again" *and* "couldn't process the location you just sent me, don't try to resend it for a while". Jon didn't like the idea of something that he feels duplicates the 503 with a retry after header field. He was on a mission to reduce the number of geolocation-error codes, and these two go whacked. That's where this text comes from. I'll get with him about writing this section better - or do you have an alternate plan we should pursue? James From pkyzivat@cisco.com Tue Mar 29 04:50:21 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220723A697D for ; Tue, 29 Mar 2011 04:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhN4HFAerlTM for ; Tue, 29 Mar 2011 04:50:19 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 917533A683E for ; Tue, 29 Mar 2011 04:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=459; q=dns/txt; s=iport; t=1301399517; x=1302609117; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=F42eg4OnEoe9d7PNZk9gQi7GxurgBsmiVwxOk6aoaXw=; b=Qb0j4mV4IXJdNZ7E0fH4ym9J4znaEC1JF5F46sOHWaJ6Y0X8l1VOlGyc 6TRlQmZbsKP9qXVaps4sfl9qIhLbU8OVkGX5UqTKgynb3eDyh3KS76SjO G8JLNE68uMTbGxkp0PHhkXUbgwBPXUNs9mmSnHP6C1ZiPJ4VZ9kYnDEQv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgEAI/HkU2Q/khMgWdsb2JhbAClRRQBARYmJahonFCFagSNAoNU X-IronPort-AV: E=Sophos;i="4.63,262,1299456000"; d="scan'208";a="23621005" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2011 11:51:46 +0000 Received: from [10.61.85.87] (ams3-vpn-dhcp5464.cisco.com [10.61.85.87]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2TBpkAm006497 for ; Tue, 29 Mar 2011 11:51:46 GMT Message-ID: <4D91C7D2.7030707@cisco.com> Date: Tue, 29 Mar 2011 07:51:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] scribes and jabber scribe for sipcore session Wed morning X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 11:50:21 -0000 We can short circuit the process of soliciting scribes for the meeting by getting volunteers ahead of time. Can we have some volunteers? We need at least one primary scribe to take notes for the minutes, and preferably a backup. We also need someone to monitor the jabber room. Any volunteers? (Else we'll have to twist arms at the meeting.) Scribes will get a pass on scribing at further sipcore sessions during ietf80. Thanks, Paul From rjsparks@nostrum.com Tue Mar 29 04:58:22 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4903A67D4 for ; Tue, 29 Mar 2011 04:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dD0QAFYeAvv9 for ; Tue, 29 Mar 2011 04:58:22 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D34C53A67C3 for ; Tue, 29 Mar 2011 04:58:20 -0700 (PDT) Received: from dhcp-6772.meeting.ietf.org ([130.129.103.114]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p2TBxs3L055798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Mar 2011 06:59:56 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <201103290847.p2T8l7uW032563@mtv-core-1.cisco.com> Date: Tue, 29 Mar 2011 13:59:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58E2D7DB-CDAF-41CF-B24B-DCC6E8D67702@nostrum.com> References: <4D6C31DC.80005@nostrum.com> <201103290847.p2T8l7uW032563@mtv-core-1.cisco.com> To: "James M. Polk" X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 130.129.103.114 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-location-conveyance@tools.ietf.org, "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 11:58:22 -0000 Thanks for the reminder - I reread the text and talked with Jon. I think = the only thing that needs to change is the actual error code. 503 is to extreme - it would cut off all SIP = traffic from the peer receiving the response, not just traffic related to this request. I think the right code in this = context is 500 (which can also use the Retry-After mechanism). More concisely, my suggestion is s/503/500/ RjS On Mar 29, 2011, at 10:47 AM, James M. Polk wrote: > At 03:45 PM 3/9/2011, Robert Sparks wrote: >> There are a couple of larger and several small things to also address = in this document before requesting publication. >>=20 >> The larger things: >>=20 >> 3) I can't figure out what the paragraph in section 4.4 that starts = "Additionally, if a sip entity cannot..." and goes >> onto talk about 503's is trying to say. I think some surrounding = context must have been lost or not captured. >> Why would we be recommending sending a 503 here? >=20 > pick on this one point, there was an error code for that basically = said "couldn't process the location you just sent me, but it's ok to try = again" *and* "couldn't process the location you just sent me, don't try = to resend it for a while". Jon didn't like the idea of something that he = feels duplicates the 503 with a retry after header field. He was on a = mission to reduce the number of geolocation-error codes, and these two = go whacked. That's where this text comes from. I'll get with him about = writing this section better - or do you have an alternate plan we should = pursue? >=20 > James=20 From jmpolk@cisco.com Tue Mar 29 05:20:20 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908893A67C0 for ; Tue, 29 Mar 2011 05:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25Q2CnQ2Oft4 for ; Tue, 29 Mar 2011 05:20:19 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7189E3A67B6 for ; Tue, 29 Mar 2011 05:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1754; q=dns/txt; s=iport; t=1301401317; x=1302610917; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=bGfXSTeFeQb60HcbE4DHOWOpTNi86WeJIGV+y4LHcGM=; b=nB74h0bJ68IY89qdOb5XuUO3uVsZLLvFDmjaimzSbSVh/NVUMMdFhX4Y GkdhDgVKkTdSG2TG6+YAaJZkvzlKk9/X0h6miov0BHKOns4v3p9zpy3uZ xKl9qmvGD88PJPWrvZMIqoAn/UPRWJYhzs/NiTEP0DoCL7hWDdDeR66Jb 0=; X-IronPort-AV: E=Sophos;i="4.63,262,1299456000"; d="scan'208";a="284860256" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2011 12:21:57 +0000 Received: from jmpolk-wxp01.cisco.com ([10.89.13.223]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2TCLsnm022265; Tue, 29 Mar 2011 12:21:55 GMT Message-Id: <201103291221.p2TCLsnm022265@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Mar 2011 07:21:52 -0500 To: Robert Sparks , "James M. Polk" From: "James M. Polk" In-Reply-To: <58E2D7DB-CDAF-41CF-B24B-DCC6E8D67702@nostrum.com> References: <4D6C31DC.80005@nostrum.com> <201103290847.p2T8l7uW032563@mtv-core-1.cisco.com> <58E2D7DB-CDAF-41CF-B24B-DCC6E8D67702@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-sipcore-location-conveyance@tools.ietf.org, "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:20:20 -0000 At 06:59 AM 3/29/2011, Robert Sparks wrote: >Thanks for the reminder - I reread the text and talked with Jon. I >think the only thing that needs to change >is the actual error code. 503 is to extreme - it would cut off all >SIP traffic from the peer receiving the response, >not just traffic related to this request. yes - that would be bad. >I think the right code in this context is 500 (which can also use >the Retry-After mechanism). > >More concisely, my suggestion is s/503/500/ got it Thanks James >RjS > >On Mar 29, 2011, at 10:47 AM, James M. Polk wrote: > > > At 03:45 PM 3/9/2011, Robert Sparks wrote: > >> There are a couple of larger and several small things to also > address in this document before requesting publication. > >> > >> The larger things: > >> > >> 3) I can't figure out what the paragraph in section 4.4 that > starts "Additionally, if a sip entity cannot..." and goes > >> onto talk about 503's is trying to say. I think some surrounding > context must have been lost or not captured. > >> Why would we be recommending sending a 503 here? > > > > pick on this one point, there was an error code for that > basically said "couldn't process the location you just sent me, but > it's ok to try again" *and* "couldn't process the location you just > sent me, don't try to resend it for a while". Jon didn't like the > idea of something that he feels duplicates the 503 with a retry > after header field. He was on a mission to reduce the number of > geolocation-error codes, and these two go whacked. That's where > this text comes from. I'll get with him about writing this section > better - or do you have an alternate plan we should pursue? > > > > James From mary.ietf.barnes@gmail.com Tue Mar 29 05:38:34 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CD593A67DB for ; Tue, 29 Mar 2011 05:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.368 X-Spam-Level: X-Spam-Status: No, score=-103.368 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54Jhw05KqudA for ; Tue, 29 Mar 2011 05:38:31 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id DA1B03A63CA for ; Tue, 29 Mar 2011 05:38:30 -0700 (PDT) Received: by vws12 with SMTP id 12so91277vws.31 for ; Tue, 29 Mar 2011 05:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fpnWjO+Mh1t2xENaBtbXO9dNK2uyXISIp9W7AG03gSc=; b=loeS9pxrZ3WzspKjxTZekrCf3ycT12GrWswLq7wvEOyDiBQU1RYY2r1Iw4J1UV5Bbj QQEAeXAwT6lg7NpdqSTb9DEgAhY5uSBvDI8h0YHAbvFzd9yQf0j0Jp2W6BpBiV7c+6qq cLj5xdJu3ewZ6MlH7Orn0P7VIR0j8BbY15Oic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=x58qBgk0/7F+DI1AhyIJU4jm7BqGXSSpQohfZ8ytNABIxUY94StVAzPVT3Zr6YWTq+ x42Yrd+iRY4aou3jb2tYz2xJ5KZnMYt1znrNs2hMYqqx70I9vT9NDvdSTXEybwInsYyz Vd1YFjhq7cMBraiwhG/cn+SxG74ciM7PzFDzI= MIME-Version: 1.0 Received: by 10.52.65.225 with SMTP id a1mr1191930vdt.183.1301402407403; Tue, 29 Mar 2011 05:40:07 -0700 (PDT) Received: by 10.52.167.137 with HTTP; Tue, 29 Mar 2011 05:40:07 -0700 (PDT) In-Reply-To: References: <20110315183001.24369.74903.idtracker@localhost> Date: Tue, 29 Mar 2011 07:40:07 -0500 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=20cf307f38ea340225049f9e5c8d Cc: SIPCORE Subject: Re: [sipcore] Fwd: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:38:34 -0000 --20cf307f38ea340225049f9e5c8d Content-Type: text/plain; charset=ISO-8859-1 John, Thanks for taking the time to review the updated doc. Overall, I agree with your suggestions for editorial clarifications and issue fixes - just a few comments inline below [MB]. Mary. On Wed, Mar 16, 2011 at 4:44 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Mary, > > Thanks for adopting the principles I proposed. Although I agree with much > of the minor rewording you carried out, I do have some issues as follows. > Also I still need to comment on other parts of the document - these comments > apply to sections 6 to 9 only. > > 1. Section 6: > "forward hi-entries received in requests at the UAS to the request > being forwarded by the UAC" > Change "the request" to "requests". > > 2. Section 6: > "carrying forward responses > received" > Change to "carrying forward hi-entries in responses received" > > 3. Section 6.1: > "The UAC MUST include the "histinfo" option tag in the Supported > header" > Change "header" to "header field". > > 4. Section 6.1: > "Note > that in the case of an initial request , there is no cache of hi- > entries with which to populate the History-info header field..." > We should also observe that when a UAC is part of a B2BUA, the cache might > not be empty (I failed to cover this in my proposed text). I suggest: > "Note that in the case of an initial request, except where the UAC is part > of a B2BUA, there is no cache of hi- > entries with which to populate the History-info header field..." > > 5. Section 6.1: > "as > described in and the hi-index is set to 1 per Section 10.3." > The words "as described in" should be deleted. > > 6. Section 7: In my opinion it would be more logical to list the 4 cases in > order of the sections they reference (9.1, 9.2, 9.3, 9.4), as I proposed. > > 7. Section 7: > "For each outgoing request relating to a target in the target set, > the intermediary MUST add an hi-entry for the specific target, per > the procedures in Section 9.2." > This is wrong. ALL the procedures of 9.2 apply, not just the one about > adding an hi-entry for the specific target. Just say "...MUST follow the > procedures of Section 9.2" - don't try to repeat things from the referenced > section. > [MB] It's not wrong - the intent was that all the procedures of 9.2 apply, but I agree that your suggestion is much clearer. [/MB] > > 8. Section 7: > "for for" > > 9. Section 7: > "An intermediary MUST follow the procedures of Section 9.3 when a > SIP response containing hi-entries is received." > The procedures of 9.3 cover ALL SIP responses, whether or not they contain > hi-entries. For example, if the UAS does not support H-I, it will not send > back any hi-entries, but the procedures of 9.3 still apply to the > intermediary that receives such a response. Delete "containing hi-entries" > 10. Section 9: > "This section describes the procedures for SIP entities for the > handling of SIP requests and responses containing the History-Info > header fields." > I think it would be better to say > "This section describes the procedures for SIP entities for the handling of > the History-Info header field in SIP requests and responses". > My reasoning is that not all received requests and responses contain the > header field, but there are still procedures that apply to such requests and > responses, perhaps leading to the inclusion of the header field in forwarded > requests/responses. So saying "SIP requests and responses containing the > History-Info header fields" doesn't seem quite right. > > 11. "9.1. Receiving a Request with History-Info " > Delete "with History-Info". The procedures cover all requests, even if > received with no H-I. > > 12. Section 9.1: > "The SIP entity MUST set the hi-index parameter to a value of "1" , > as described in Section 10.3." > Delete 'to a value of "1"'. This is not always true, if there are > hi-entries from upstream entities, but the hi-entry from the last entity is > missing and needs to be added. > [MB] That's fine - per your comment 7, it really is clearer to refer directly to the sections rather than briefly (and incompletely) re-iterate what is described in the referenced section. [/MB] > > 13. Section 9.2: > "MUST add a new > hi-entry to the outgoing request" > Just to be clear, it might be worth saying: > "MUST add a new > hi-entry to the outgoing request (but not the cache)" > > 14. Section 9.2: > "populating the header field as > follows:" > I think this should say: > "populating the hi-entry as follows:" > > 15. Section 9.2: > "The SIP entity MUST include an "rc" or "mp" header field parameter > in the hi-entry, if applicable, per the procedures in > Section 10.4." > The following text that I proposed before seems to be missing: > "If the sent request is a direct result of retargeting to a contact URI > received in a 3xx response and the Contact header field in that response > contained an "rc" or "mp" header field parameter, the entity MUST include > the corresponding parameter in the new hi-entry in accordance with 10.4." > (although I am not certain the words "in accordance with 10.4 are needed - > in retrospect I would delete those words) > [MB] Per your suggestions above (i.e, 7) in terms of not repeating things in the referenced section, I thought that it was more confusing to include the handling of 3xx responses in this section. [/MB] > > 16. Section 9.3: > "e.g., 1.2.1 comes after 1.2 but > before 1.3 )" > Just to be even clearer, I would suggest: > "e.g., 1.2.1 comes after 1.2 but > before 1.2.2 or 1.3 )" > > 17. Section 9.3: > "The SIP entity then MUST add a Reason header field" > I think this should say: > "The SIP entity then MUST add one or more Reason header fields" > This is because, according to 10.2, more than one can be added in some > cases. > > 18. Section 9.4: > "When sending a response other than a 100, a SIP entity MUST include > all the cached hi-entries in the response with the following > exception: If the received request contained no hi-entries and there > is no "histinfo" option tag in the Supported header field, the SIP > entity MUST NOT include hi-entries in the response. In the former > case , the privacy procedures as described in Section 10.1.2 MUST be > followed." > I find the words "In the former case" a little confusing. Also, if there > are exceptions to the normative statement in the first sentence, they should > probably be made clear in that first sentence. I would propose: > "When sending a response other than a 100, a SIP entity MUST include > all the cached hi-entries in the response, subject to the privacy > considerations in Section 10.1.2 and with the following > exception: If the received request contained no hi-entries and there > is no "histinfo" option tag in the Supported header field, the SIP > entity MUST NOT include hi-entries in the response." > > John > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > Sent: 15 March 2011 18:46 > > To: SIPCORE > > Subject: [sipcore] Fwd: I-D > > ACTION:draft-ietf-sipcore-rfc4244bis-04.txt > > > > Hi folks, > > > > I have updated the document to incorporate the feedback on > > the -03 as follows: > > > > 1) The biggest change was the reformating inline with John's > > suggestion: > > http://www.ietf.org/mail-archive/web/sipcore/current/msg04010.html > > It is not verbatim, but rather I included some of the past > > text in the relevant sections and I included a bullet list in > > some cases rather than just a paragraph as that was one of > > the formatting changes we made between RFC4244 and 4244bis in > > that the text in paragraph form can be rather dense. I > > believe the spirit and intent of John's proposal has been > > accomodated (I don't know that as many words were saved). > > Also, I just noticed some of the bullet lists don't have the > > "o" - I'll have to fix that. I think one of the most > > important aspects of John's proposal was introducing the > > "caching" of the hi-entries as that wasn't clearly spelled > > out previously and that really did help to clarify the > > processing. I do think the breakdown in the > > sending/receiving of the request and sending/receiving of a > > response into common processing is quite helpful. > > > > 2) Removed the term "escape" with regards to the Privacy and > > Reason header fields and just stated that those header fields > > were included in the hi-targeted-to-uri. I think this also > > improves readbility. > > > > 3) Additional clarification around the Tel-URI. > > > > I think the doc should be ready for another WGLC. > > > > Thanks, > > Mary. > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Tue, Mar 15, 2011 at 1:30 PM > > Subject: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt > > To: i-d-announce@ietf.org > > Cc: sipcore@ietf.org > > > > > > A new Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Session Initiation Protocol > > Core Working Group of the IETF. > > > > Title : An Extension to the Session Initiation > > Protocol (SIP) for Request History Information > > Author(s) : M. Barnes, et al > > Filename : draft-ietf-sipcore-rfc4244bis-04.txt > > Pages : 32 > > Date : 2011-03-15 > > > > This document defines a standard mechanism for capturing the history > > information associated with a Session Initiation Protocol (SIP) > > request. This capability enables many enhanced services by > > providing > > the information as to how and why a SIP request arrives at > > a specific > > application or user. This document defines an optional SIP header > > field, History-Info, for capturing the history information in > > requests. The document also defines SIP header field parameters for > > the History-Info and Contact header fields to tag the > > method by which > > the target of a request is determined. In addition, this document > > defines a value for the Privacy header field specific to > > the History- > > Info header field. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244 > > bis-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft > > > aft> directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > --20cf307f38ea340225049f9e5c8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John,

Thanks for taking the time to review the updated d= oc. =A0Overall, I agree with your suggestions for editorial clarifications = and issue fixes - just a few comments inline below [MB].

Mary.=A0

On Wed, Mar 16, 2011 at 4:4= 4 PM, Elwell, John <john.elwell@siemens-enterprise.com> wrote= :
Mary,

Thanks for adopting the principles I proposed. Although I agree with much o= f the minor rewording you carried out, I do have some issues as follows. Al= so I still need to comment on other parts of the document - these comments = apply to sections 6 to 9 only.

1. Section 6:
"forward hi-entries received in requests at the UAS to the request
=A0 being forwarded by the UAC"
Change "the request" to "requests".

2. Section 6:
"carrying forward responses
=A0 received"
Change to "carrying forward hi-entries in responses received"

3. Section 6.1:
"The UAC MUST include the "histinfo" option tag in the Suppo= rted
=A0 header"
Change "header" to "header field".

4. Section 6.1:
"Note
=A0 that in the case of an initial request , there is no cache of hi-
=A0 entries with which to populate the History-info header field..."<= br> We should also observe that when a UAC is part of a B2BUA, the cache might = not be empty (I failed to cover this in my proposed text). I suggest:
"Note that in the case of an initial request, except where the UAC is = part of a B2BUA, there is no cache of hi-
=A0 entries with which to populate the History-info header field..."<= br>
5. Section 6.1:
"as
=A0 described in =A0and the hi-index is set to 1 per Section 10.3." The words "as described in" should be deleted.

6. Section 7: In my opinion it would be more logical to list the 4 cases in= order of the sections they reference (9.1, 9.2, 9.3, 9.4), as I proposed.<= br>
7. Section 7:
"For each outgoing request relating to a target in the target set,
=A0 =A0 =A0the intermediary MUST add an hi-entry for the specific target, = per
=A0 =A0 =A0the procedures in Section 9.2."
This is wrong. ALL the procedures of 9.2 apply, not just the one about addi= ng an hi-entry for the specific target. Just say "...MUST follow the p= rocedures of Section 9.2" - don't try to repeat things from the re= ferenced section.

[MB] It's not wrong - the intent was t= hat all the procedures of 9.2 apply, but I agree that your suggestion is mu= ch clearer. [/MB]=A0

8. Section 7:
"for for"

9. Section 7:
"An intermediary MUST follow the procedures of Section 9.3 when a
=A0 =A0 =A0SIP response containing hi-entries =A0is received."
The procedures of 9.3 cover ALL SIP responses, whether or not they contain = hi-entries. For example, =A0if the UAS does not support H-I, it will not se= nd back any hi-entries, but the procedures of 9.3 still apply to the interm= ediary that receives such a response. Delete "containing hi-entries&qu= ot;=A0

10. Section 9:
"This section describes the procedures for SIP entities for the
=A0 handling of SIP requests and responses containing the History-Info
=A0 header fields."
I think it would be better to say
"This section describes the procedures for SIP entities for the handli= ng of the History-Info header field in SIP requests and responses". My reasoning is that not all received requests and responses contain the he= ader field, but there are still procedures that apply to such requests and = responses, perhaps leading to the inclusion of the header field in forwarde= d requests/responses. So saying "SIP requests and responses containing= the History-Info header fields" doesn't seem quite right.

11. "9.1. =A0Receiving a Request with History-Info "
Delete "with History-Info". The procedures cover all requests, ev= en if received with no H-I.

12. Section 9.1:
"The SIP entity MUST set the hi-index parameter to a value of "1&= quot; ,
=A0 =A0 =A0as described in Section 10.3."
Delete 'to a value of "1"'. This is not always true, if t= here are hi-entries from upstream entities, but the hi-entry from the last = entity is missing and needs to be added.
[MB] =A0That&= #39;s fine - per your comment 7, it really is clearer to refer directly to = the sections rather than briefly (and incompletely) re-iterate what is desc= ribed in the referenced section. [/MB]=A0

13. Section 9.2:
"MUST add a new
=A0 hi-entry to the outgoing request"
Just to be clear, it might be worth saying:
"MUST add a new
=A0 hi-entry to the outgoing request (but not the cache)"

14. Section 9.2:
"populating the header field =A0as
=A0 follows:"
I think this should say:
"populating the hi-entry as follows:"

15. Section 9.2:
"The SIP entity MUST include an "rc" or "mp" heade= r field parameter
=A0 =A0 =A0in the hi-entry, if applicable, per the procedures in
=A0 =A0 =A0Section 10.4."
The following text that I proposed before seems to be missing:
"If the sent request is a direct result of retargeting to a contact UR= I received in a 3xx response and the Contact header field in that response = contained an "rc" or "mp" header field parameter, the e= ntity MUST include the corresponding parameter in the new hi-entry in accor= dance with 10.4."
(although I am not certain the words "in accordance with 10.4 are need= ed - in retrospect I would delete those words)
[MB] Pe= r your suggestions above (i.e, 7) in terms of not repeating things in the r= eferenced section, I thought that it was more confusing to include the hand= ling of 3xx responses in this section. [/MB]

16. Section 9.3:
"e.g., 1.2.1 comes after 1.2 but
=A0 =A0 =A0before 1.3 )"
Just to be even clearer, I would suggest:
"e.g., 1.2.1 comes after 1.2 but
=A0 =A0 =A0before 1.2.2 or 1.3 )"

17. Section 9.3:
"The SIP entity then MUST add a =A0Reason header field"
I think this should say:
"The SIP entity then MUST add one or more Reason header fields" This is because, according to 10.2, more than one can be added in some case= s.

18. Section 9.4:
"When sending a response other than a 100, a SIP entity MUST include =A0 all the cached hi-entries in the response =A0with the following
=A0 exception: If the received request contained no hi-entries and there =A0 is no "histinfo" option tag in the Supported header field, t= he SIP
=A0 entity MUST NOT include hi-entries in the response. =A0In the former =A0 case , the privacy procedures as described in Section 10.1.2 MUST be =A0 followed."
I find the words "In the former case" a little confusing. Also, i= f there are exceptions to the normative statement in the first sentence, th= ey should probably be made clear in that first sentence. I would propose: "When sending a response other than a 100, a SIP entity MUST include =A0 all the cached hi-entries in the response, subject to the privacy cons= iderations in Section 10.1.2 and with the following
=A0 exception: If the received request contained no hi-entries and there =A0 is no "histinfo" option tag in the Supported header field, t= he SIP
=A0 entity MUST NOT include hi-entries in the response."

John

> -----Original Message-----
> From: sipcore-bounces@ietf= .org
> [mailto:sipcore-bounces@ie= tf.org] On Behalf Of Mary Barnes
> Sent: 15 March 2011 18:46
> To: SIPCORE
> Subject: [sipcore] Fwd: I-D
> ACTION:draft-ietf-sipcore-rfc4244bis-04.txt
>
> Hi folks,
>
> I have updated the document to incorporate the feedback on
> the -03 as follows:
>
> 1) The biggest change was the reformating =A0inline with John's > suggestion:
> http://www.ietf.org/mail-archive/web/sipcore/cur= rent/msg04010.html
> It is not verbatim, but rather I included some of the past
> text in the relevant sections and I included a bullet list in
> some cases rather than just a paragraph as that was one of
> the formatting changes we made between RFC4244 and 4244bis in
> that the text in paragraph form can be rather dense. =A0I
> believe the spirit and intent of John's proposal has been
> accomodated (I don't know that as many words were saved).
> Also, I just noticed some of the bullet lists don't have the
> "o" - I'll have to fix that. =A0I think one of the most<= br> > important aspects of John's proposal was introducing the
> "caching" of the hi-entries as that wasn't clearly spell= ed
> out previously and that really did help to clarify the
> processing. =A0I do think the breakdown in the
> sending/receiving of the request and sending/receiving of a
> response into common processing is quite helpful.
>
> 2) Removed the term "escape" with regards to the Privacy and=
> Reason header fields and just stated that those header fields
> were included in the hi-targeted-to-uri. =A0I think this also
> improves readbility.
>
> 3) Additional clarification around the Tel-URI.
>
> I think the doc should be ready for another WGLC.
>
> Thanks,
> Mary.
>
>
> ---------- Forwarded message ----------
> From: <Internet-Drafts@= ietf.org>
> Date: Tue, Mar 15, 2011 at 1:30 PM
> Subject: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt
> To: i-d-announce@ietf.org=
> Cc: sipcore@ietf.org
>
>
> A new Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Session Initiation Protocol
> Core Working Group of the IETF.
>
> =A0 =A0Title =A0 =A0 =A0 =A0 : An Extension to the Session Initiation<= br> > Protocol (SIP) for Request History Information
> =A0 =A0Author(s) =A0 =A0 : M. Barnes, et al
> =A0 =A0Filename =A0 =A0 =A0: draft-ietf-sipcore-rfc4244bis-04.txt
> =A0 =A0Pages =A0 =A0 =A0 =A0 : 32
> =A0 =A0Date =A0 =A0 =A0 =A0 =A0: 2011-03-15
>
> =A0 This document defines a standard mechanism for capturing the histo= ry
> =A0 information associated with a Session Initiation Protocol (SIP) > =A0 request. =A0This capability enables many enhanced services by
> providing
> =A0 the information as to how and why a SIP request arrives at
> a specific
> =A0 application or user. =A0This document defines an optional SIP head= er
> =A0 field, History-Info, for capturing the history information in
> =A0 requests. =A0The document also defines SIP header field parameters= for
> =A0 the History-Info and Contact header fields to tag the
> method by which
> =A0 the target of a request is determined. =A0In addition, this docume= nt
> =A0 defines a value for the Privacy header field specific to
> the History-
> =A0 Info header field.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sipco= re-rfc4244
> bis-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft
> <https://www.ietf.org/mailman/listinfo/i-d-announc= eInternet-Dr
> aft> =A0directories: http://www.ietf.org/shadow.html

--20cf307f38ea340225049f9e5c8d-- From mary.ietf.barnes@gmail.com Tue Mar 29 22:07:59 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A62A3A6AD4 for ; Tue, 29 Mar 2011 22:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.874 X-Spam-Level: X-Spam-Status: No, score=-102.874 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DbyOYQtcIzx for ; Tue, 29 Mar 2011 22:07:48 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id AE9843A694F for ; Tue, 29 Mar 2011 22:07:47 -0700 (PDT) Received: by vxg33 with SMTP id 33so853945vxg.31 for ; Tue, 29 Mar 2011 22:09:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NvwlWN3ghIndJ262Be0htFJK+Sg17FX6pDmmm7OQt5U=; b=M+JNIfBLSvc95SCiuXaFCwpDS7nw2JGJ5cp4+ptEVRTLgkuFFBT+ZAKo9C/GCnCtzh EnmKrDM6yGv/G6Dfb+0mfh3WwGAMm0tfkqW1orkS1Enk9rmBtcN3r7R3NtEpT+GVoJD6 M1+IPVsq4nspb+aO9GQIo5S6Z0qZ3t2eiXtp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gN1zHEglHWDbHZXkNP1bRsuxB+SlCiyygX73dHDuVJLauOLoRUjB0Lv8zWKpLrVDxb WJyEhrh+GoYqDdF3zXZoB6TTAfGSwP+kgcS0clo1iQpeV4Xr9ccHWI1yWT/6GYILaCFt QlQ0i0jfES+0TB6V+rlv37TkMuOWhmitBxt9M= MIME-Version: 1.0 Received: by 10.52.172.34 with SMTP id az2mr958045vdc.143.1301461765944; Tue, 29 Mar 2011 22:09:25 -0700 (PDT) Received: by 10.52.167.137 with HTTP; Tue, 29 Mar 2011 22:09:25 -0700 (PDT) In-Reply-To: References: <20110315183001.24369.74903.idtracker@localhost> Date: Wed, 30 Mar 2011 00:09:25 -0500 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=bcaec53f95ef3f762b049fac2e8e Cc: SIPCORE Subject: Re: [sipcore] Fwd: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 05:07:59 -0000 --bcaec53f95ef3f762b049fac2e8e Content-Type: text/plain; charset=ISO-8859-1 John, Thanks for the additional comments. Per my other response, I agree with your suggestions for the most part, with just a few responses inline below [MB]. Thanks, Mary. On Fri, Mar 25, 2011 at 9:46 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Mary, > > I already sent you my comments on sections 6 to 9. Now I finally got round > to reading much of the rest of the document (up to section 12). Sorry, my > energy ran out after that - I will leave it to others to check the rest. I > have to say that these sections are not yet ready to go - quite a few > inaccuracies and inconsistent use of terminology. Here goes: > > 1. Section 1: > "Many services that SIP is anticipated to support require the ability > to determine why and how a SIP requests arrived at a specific > application." > Change "requests" to "request". > > 2. Section 5: > "By adding the new > entries in order (i.e., following existing entries per the details > in Section 10.3), including the index and securing the header, the > ordering of the History-info header fields in the request is > assured." > What is meant by "securing the header"? Why just the header and not the > body? Surely the only means we are suggesting is TLS, which secures the body > as well as the header. > [MB] The intent is that if the SIP header fields are protected, then you have confidence that the values are real. That's not necessarily saying that the bodies aren't also protected by TLS - it's just not mentioned since the bodies aren't relevant to History-Info header fields. I could change that to "sending the messages using a secure transport". [/MB] > > 3. Section 5: > "hi-target-param: An optional parameter reflecting the mechanism by > which the Request URI captured in the hi-targeted-to-uri in the > hi-entry was determined." > The term "hi-entry" has not been introduced yet. > > 4. Section 5: > ""rc": The hi-targeted-to-URI is a contact for the Request-URI, > in the incoming request, that is bound to an AOR in an abstract > location service." > What is bound? Presumably the contact, not the Request-URI, and not the > request. Wording is ambiguous, because "that is bound" is too separated from > "contact". Also "Request-URI is ambiguous - the Request-URI before or after > retargeting. I think it should say something like "...is a contact bound to > an AOR in an abstract location service, that AOR being the Request-URI that > was retargeted." > > 5. Section 5: > "This occurs when a request is to > statically or dynamically retargeted " > Delete "to". > > 6. Section 5: > "The > value of the index in the "mp" header field parameter > represents the value of the hi-index in the hi-entry with an > hi-targeted-to- uri that reflects the Request-URI that was > retargeted, thus identifying the "mapped from" target." > What is meant by "the value of the index" at the start of the sentence? > Isn't this simply the value of the "mp" parameter? In any case, shouldn't we > use a similar formulation to that used in the corresponding sentence in the > definition of "rc"? > [MB] The "value of the index" refers the value of the "mp" header field parameter which contains an "index" as defined by the ABNF. However, I'll make the change as you suggest. [/MB] > > 7. Section 5: > "hi-param = hi-index / hi-target / hi-extension" > There is no definition of hi-target - I think it should be > "hi-target-param". However, there are other places in the document where > "hi-target" is referred to. I think hi-target-param is better - please align > all instances. > > 8. Section5: > "addition to the parameters defined by the ABNF, an hi-entry may > also include a Reason header field and a Privacy header field" > I think it should say "...and/or a Privacy header field. We can have one > without the other. > > 9. Section 5: > "which > are both included in the hi-targeted-to-uri as described below:" > To make it clear where in the hi-targeted-to-uri, I think it should say > "...included in the "headers" component of the hi-targeted-to-uri". > > 10. Section 5: > "A reason is > included for the hi-targeted-to-uri that was retargeted as opposed > to the hi-targeted-to-uri to which it was retargeted." > Ambiguous. Does it mean it appears in the hi-entry for that URI, or does it > mean it relates to that URI even though it appears in the URI resulting from > retargeting? In addition, a reason can be included (and will appear in the > response) even if there is no retargeting as a result of that reason. I > would suggest: "A reason is included in the hi-targeted-to-uri of an > hi-entry to reflect information received in a response to the request sent > to that URI." > > 11. Section 5.1: > "and > the headers in the URI are not shown properly formatted for escaping." > I am not sure what this is talking about - if it is talking about "headers" > component in a URI, I don't see any in the example. Delete this part of the > sentence? > [MB] That's a hangover from the improper usage of "escape" in prior versions. So, yes, I will delete. [/MB] > > 12. Section 10.1: > "Section 10.1.1 describes the use of the Privacy header > field defined in [RFC3323] to indicate the privacy to be applied to > the History-Info header field entries." > I think 10.1.1 only describes insertion - it doesn't describe use on > receipt. Change "the use of" to "the insertion of". > > 13. Section 10.1: > "Section 10.1.2 describes the > processing of the priv-values in the Privacy header field to privacy > protect the History-Info header field entries in the request or > response that is being forwarded." > I think this would be clearer if it said "Section 10.1.2 describes how to > apply privacy to a request or response that is being forwarded, based on the > presence of the Privacy header field." > > 14. Section 10.1.1: > "The Privacy header field is > used by the UAC to indicate the privacy to be applied to all the hi- > entries in the request as follows:" > This seems to suggest it is used to indicate whether privacy is to be > applied or not, but the bullets below are specific to the case where privacy > IS to be applied. I would suggest "...to indicate that privacy is to be > applied" > > 15. Section 10.1.1: > "for each hi-entry added by intermediary, as the request is > retargeted within the domain for which the SIP entity is responsible." > Does "each hi-entry added by intermediary" include any hi-entries that have > been received in responses from downstream entities, these hi-entries then > being added to any additional branches? > [MB] No, it does not include the hi-entries added by the branches as the entity that is doing the retargeting applies the privacy as appropriate. If the entities are in the same domain one would expect that the entity doing the retargeting would indicate and apply privacy as appropriate. [/MB] 16. Section 10.1.2: > "When a request is retargeted to a URI associated with a domain for > which the SIP intermediary is not responsible or a response is > forwarded" > I think the words "to ... a domain for which the SIP intermediary is not > responsible" applies also when forwarding a response. Should it say: > "When a request is retargeted to a URI associated with a domain for > which the SIP intermediary is not responsible or a response is > forwarded to a domain for which the SIP intermediary is not responsible" > > 17. In the same sentence: > "a Privacy Service at the boundary of the domain applies" > Where is "Privacy Service" defined (for priv-value "history")? Presumably > the following paragraphs specify the Privacy Service, but this is not clear. > [MB] Privacy service is a logical role as defined in RFC 3323 and the next paragraphs define the behavior for the entity serving in that logical role. [/MB] > > 18. In the same sentence: > "at the boundary of the domain" > How do we ensure the presence of a Privacy Service at a domain boundary? > For example, a proxy inserts an hi-entry marked with privacy and sends it to > the next node in its domain. But that node doesn't support H-I, so just > passes H-I on transparently, perhaps outside the domain. There needs to be > an element of trust here, similar to RFC 3325, where information subject to > privacy is sent only to trusted entities within the domain, but furthermore, > to be trusted an entity needs to support H-I. See also my last comment (on > section 12). > [MB] The protocol itself can't ensure the presence of a privacy service, however, if whomever wants privacy applied needs to ensure that the entities within its domain are capable of applying the required privacy when the request leaves the domain. The privacy won't work unless all entities in the domain have implemented this RFC (or 4244 for that matter. I don't see that adding the RFC 3325 trust domain model helps. We have also discussed the latter in the past and we add ed clarification in section 2 that this document is dealing with the definition of a domain as per RFC 3261 and we aren't describing the use in the context of RFC 3325. [/MB] > > 19. Section 10.1.2: > "If there is a Privacy header field in the request with a priv-value > of "header" or "history"," > I think this is talking about a Privacy header field in the message header, > as opposed to a Privacy header field in the "headers" component of an > hi-targeted-to-uri. This should be made clear, although there is no obvious > terminology we can call on. Perhaps: > "If there is a Privacy header field in the request, other than in the > "headers" component of an hi-targeted-to-uri, with a priv-value > of "header" or "history"," > > 20. The same quoted text talks about requests, but don't we need similar > procedures for responses? > [MB] Yes. [/MB] > > 21. In the same sentence: > "then the hi-targeted-to-uris in the hi- > entries, associated with the domain for which a SIP intermediary is > responsible, are anonymized." > I think this is trying to say "a SIP intermediary anonymizes any > hi-targeted-to-uris associated with its own domain". But I am rather > confused that this sentence talks about "a SIP intermediary" and the next > sentence, which seems to repeat things in normative language, talks about > "The Privacy Service". We could do with some rationalization of the two > sentences. > [MB] The Privacy Service is a logical role as described in my response to 17 above. The usage of domain and SIP intermediary is used as described in section 2. I'll change the last part of that first sentence to "are anonymized by the Privacy Service". [/MB] > > 22. Section 10.1.2: > "If there is not a Privacy header field in the request or response > that is being forwarded" > Again I think we need to qualify this by adding "other than in the > "headers" component of an hi-targeted-to-uri". > > 23. Concerning the same sentence, again I have trouble with this sentence > and the next sentence covering essentially the same thing with different > terminology. > > 24. Section 10.2: > "If the retargeting is due to receipt of an explicit SIP response and > the response contains any Reason header fields (see [RFC3326]), then > the SIP entity MUST include the Reason header fields in the hi- > targeted-to-uri containing the URI of the request that was > retargeted" > According to 9.3 step 2, we add Reason to the cached hi-entries, and > independently of whether the request then gets retargeted. I think it should > say something like: "To add Reason header fields to a cached hi-entry as a > result of receiving a response to the request sent to the hi-entry's > hi-targeted-to-uri, a SIP entity MUST use any Reason header fields received > in the response" > [MB] See response to 25. [/MB] > > 25. Section 10.2: > "MUST > include a Reason header field, containing the SIP Response Code" > What if it is a 2xx response - does this make sense? > [MB] If it was a 2xx response, then we are not retargeting, which is the subject of that sentence. So, we should update 9.3 to read "other than a 100 or 2xx". [/MB] > > 26. In the same sentence: > "that > triggered the retargeting, in the hi-targeted-to-uri containing the > URI of the request that was retargeted" > Delete these words, because it gets added to the cached hi-entry > independently of whether it is then retargeted. > [MB] Per my response above, it only gets added when it is retargeted. So, we need to clarify this in section 9.3 which is caching. However, there are times when we need to cache an hi-entry so it gets sent in a response AND it doesn't need to have a Reason header added. I think we introduced a bug when the cache concept was introduced. [/MB] > > 27. Section 10.2: > "containing a SIP > error response code of 408 "Request Timeout" in hi-targeted-to-uri > containing the URI of the request that was retargeted. " > Again, delete "in hi-targeted-to-uri > containing the URI of the request that was retargeted. " > because we are just talking about adding to the cache. > > 28. Section 10.2: > "The SIP > entity MAY also include a Reason header field in the hi-targeted-to- > uri containing the URI of the request that was retargeted as a result > of internal retargeting." > Change "the request" to "a request". > > 29. Section 10.2: > "If additional Reason headers are defined in the future " > Does this mean "additional protocol values"? However, no specific protocol > values are mentioned above, so why to we need to mention "additional" > protocol values? > [MB] This is saying that if there are new Reason header field values defined, then they also MUST be added to the hi-entry as described in that section. So, perhaps rather than "described above" we say "as described in this section". This is intended to mean that you don't need to update HI if you add new Reason header field values since this document references the ones defined in RFC 3326.[/MB] > > 30. Section 10.3: > "Basic Forwarding: " > What is "Basic Forwarding"? > [MB] We'll remove "basic". It's referring to when a request is sent from one entity to another entity across different intermediary without changing the target.[/MB] > > 31. Section 10.3, item 1: > "In the case of a request that is being > forwarded" > Any request can be forwarded eventually, even it has been retargeted, > redirected, etc.. So how exactly does this case 1 differ from some of the > other cases? > [MB] See 30. [/MB] 32. Also in item 1: > "MUST > add another level of indexing by appending the dot delimiter > followed by an initial hi-index for the new level of 1." > The new level is not, in general, level 1. I think this should say "An > initial value of 1 for the new level." Unfortunately the ABNF fails to give > a name to a single component of hi-index, so I have just called it "value". > > 33. "a proxy would add an hi-entry with > an hi-index to 1.1.1 " > Change "to" to "of". > > 34. In item 3: > "Retargeting within a processing entity - subsequent instance: For > each subsequent retargeting of a request by the same SIP entity, > the SIP entity MUST add another branch." > What exactly is "another branch"? RFC 3261 already talks about creating > branches, so why do we need a normative statement here to tell us to do > something that is normatively specified in RFC 3261? We should only be > making normative statements that are specific to H-I. > [MB] We meant to represent the additional branch by setting a hi-entry with value incrementing the hi-entry of previous branch by 1. Initial branch = 1.1.1 Second branch = 1.1.2 I guess we can remove the MUST add and change the following sentence as follows. "The SIP entity MUST calculate and add the hi-index for each new branch.." [/MB] > > 35. Also in item 3: > "The SIP entity MUST > calculate the hi-index for each new branch by incrementing the > value from the hi-index in the last hi-entry at the current > level." > It is unclear what "value" means. I think it is the value of the rightmost > level. > > 36. In item 4: > "That is, the lowest/last > digit of the hi-index MUST be incremented" > Since a value for a particular level within hi-index can comprise more than > one digit, the word "digit" here is not correct. It is the integer that > should be incremented. > [MB] It's not an integer. We could say the lowest/last "value".[/MB] > > 37. In the same sentence: > "MUST be incremented (i.e., a new branch is > created), with the increment of 1" > I think "with the increment of 1" can be deleted. > > 38. In item 5: > "Note that for each individual fork, only the > hi-entry corresponding to that fork is included (e.g., the hi- > entry for fork 1.1.1 is not included in the request sent to fork > 1.1.2, and vice-versa)." > I don't think this is true. For example, I receive hi-entry 1.2, I fork > first of all with hi-entry 1.2.1. This receives a response 4xx, so I then > fork again, this time with hi-entry 1.2.2. I thought in this case hi-entry > 1.2.1, as well as 1.2.2, would be included in the new forwarded request > (since 1.2.1 will be in the cache at this stage). > [MB] That just applies to parallel forking. Will change to "Note, that in the case of parallel forking, only the hi-entry corresponding to the fork is included in the request.[/MB] > > 39. "10.4. Mechanism for Target Determination in the History-Info Header > Field" > Wrong title - the section is to do with indicating how the target was > determined, not with the determination mechanism itself. Perhaps "10.4 > Indicating the mechanism by which the target was determined..." > > 40. Section 10.4: > " This specification defines two header field parameters, "rc" and > "mp", indicating two non-inclusive mechanisms by which a new target > for a request is determined." > I am not sure what "non-inclusive" means here. > [MB] Meaning that those are not the only mechanisms by which a target is determined - this goes back to when we had others identified and was added when we changed it to not tag each hi-entry with something. We can just delete the "non-inclusive". [/MB] > > 41. Section 10.4: > "in the case of 3xx responses" > I think this should say "in the case of retargeting to a contact URI > received in a 3xx response". > > 42. Section 10.4: > "If the Contact header field > does not contain an "rc" or "mp" header field parameter, then the SIP > entity MUST NOT include an "rc" or "mp" in the hi-entry when the > request is retargeted." > I think this sentence is still talking about the 3xx case, but it is not > clear. Should say: > "....when the request is retargeted to a contact URI received in a 3xx > response". > > 43. Section 10.4: > ""rc": The target was determined based on a contact that is bound > to an AOR in an abstract location service for the Request-URI > being retargeted." > This doesn't make it clear that the Request-URI is the AOR. However, for > both this and the "mp" bullet point, we should perhaps refer to section 5, > where those are defined, rather than reproducing the definition here with > the risk of it being different. > > 44. Section 10.4: > "The mapping was done due to receiving a 3xx response, in which > case the mp-value is an earlier sibling of the hi-entry's index, > that of the downstream request which received the 3xx response." > I don't think this is right, since the issuer of the 3xx will build the rc > or mp parameter, and therefore it will reference the index received by that > entity. This could indeed be a sibling, but it could also be a child of a > sibling, a child of a child of a sibling, and so on. > [MB] > > 45. Section 11: > "Thus, if gaps are detected, > the SIP entity MUST NOT treat this as an error, but rather indicate > to any applications that there are gaps." > I think changing "rather indicate" to "MUST indicate" would be clearer, if > we do indeed intend it normatively. > [MB] This is bascially saying that the SIP entity is the one that can interpret the information and if there are gaps, it MUST NOT generate an error but it just needs to provide an indication to the application that there are gaps. We added this MUST NOT generate an error based on a comment from Hadriel a while back. I don't know what we can anticipate by saying MUST indicate, as we aren't providing a protocol mechanism for the indication. There being a gap is an indication that there is a gap and that is that. 46. Section 11: > "The most complete > information available to the application is the History-Info entries > starting with the last hi-entry with an index of "1"." > This is not true. The most complete is the complete set of hi-entries. Even > if there are gaps, the information subsequent to the last gap will not be as > complete as the total information. > [MB] We can just strike that sentence [/MB] > > 47. Section 11: > "The following summarizes the categories of information that > applications can use:" > I thinks these are only examples, rather than a summary of everything an > application could used. Change "summarizes" to "examples". > [MB] I would prefer "describes some categories" [/MB] > > 48. Section 11, item 2: > "the index that matches the value of the last hi- > entry with ..." > An index cannot match an entire hi-entry. I think this should say "the > index that matches the value of the "rc" parameter in the last hi- > entry with ..." > A similar correction should be applied to items 3, 4 and 5 too. > > 49. Section 11, item 2: > "rc" header parameter" > I am not sure that "header parameter" is the right way to describe "rc". It > might be more accurate to say "hi-entry parameter" or, to use the ABNF name, > "hi-target-parameter", or simply "parameter". Whatever is chosen, it needs > to be consistent throughout the document. > A similar correction should be applied to items 3, 4 and 5 too. > [MB] "rc" is a header field parameter that is in an hi-entry. [/MB] > > 50. Section 11, item 2: > "i.e., the Request URI associated with the destination of > the request was determined based on an AOR-to-contact binding in > an abstract location service." > This is confusing, because the Request-URI changes during retargeting, and > it is not clear to which Request-URI and to which request we refer. Perhaps > it means the final target, but that is not necessarily true - I am sure > there must be some corner cases where there is a non-"rc" retarget after the > last "rc" retarget. I think all we can say for certain is something like: > "i.e., the last AOR that was retargeted to a contact based on an > AOR-to-contact binding in an abstract location service." Note that a > formulation like this would better match the style of the formulation in > item 3. > > 51. Section 11, item 4: > "thus the > first hi-entry with an "rc" header parameter within the domain > associated with the target URI at the destination is more likely > to be useful." > I think this should say: > "thus the hi-entry that matches the value of the "rc" parameter of the > first hi-entry with an "rc" parameter within the domain..." > A similar correction should be applied to item 5 too. > > 52. Section 11: > "hi-entry who index " > Change to: > "hi-entry whose index " > > 53. Section 11: > "matches the index of the first" > I think this should say: > "matches value of the "mp" parameter of the first" > > 54. Section 11: > "History-Info entry" > Why not "hi-entry" as elsewhere? > Similarly "History-Info entries" later in sentence. > > 55. Section 11: > "with an hi-target value of "mp" " > Whatever terminology we end up with from comment 49, we should align here > too, e.g., "with an "mp" parameter". > Similarly for "rc" later in sentence. > > 56. Section 11: > "Since support for History-info header field is optional, a service > MUST define default behavior for requests and responses not > containing History-Info headers." > Change "History-Info headers" to "a History-Info header field". > > 57. Section 11: > "For example, an entity may receive > only partial History-Info entries or entries" > Surely each hi-entry will be a complete entry, but an entity might receive > an incomplete set of hi-entries. Also correct the terminology. Change to: > "For example, an entity may receive an incomplete set of hi-entries" > > 58. Section 12: > If an entity forwards a request containing an hi-entry marked as private to > another entity within the same domain, it expects that other entity to > anonymize the hi-entry before forwarding outside the domain. However, what > happens if that other entity doesn't support H-I? Presumably the RFC 3325 > concept of Trust Domain needs to be extended somehow to RFC4424bis, such > that for an entity to be considered in the same Trust Domain it must support > RFC4424bis. There should be some discussion around this. See also comment > 18. > [MB] See response to 18 above. [/MB] > > John > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > Sent: 15 March 2011 18:46 > > To: SIPCORE > > Subject: [sipcore] Fwd: I-D > > ACTION:draft-ietf-sipcore-rfc4244bis-04.txt > > > > Hi folks, > > > > I have updated the document to incorporate the feedback on > > the -03 as follows: > > > > 1) The biggest change was the reformating inline with John's > > suggestion: > > http://www.ietf.org/mail-archive/web/sipcore/current/msg04010.html > > It is not verbatim, but rather I included some of the past > > text in the relevant sections and I included a bullet list in > > some cases rather than just a paragraph as that was one of > > the formatting changes we made between RFC4244 and 4244bis in > > that the text in paragraph form can be rather dense. I > > believe the spirit and intent of John's proposal has been > > accomodated (I don't know that as many words were saved). > > Also, I just noticed some of the bullet lists don't have the > > "o" - I'll have to fix that. I think one of the most > > important aspects of John's proposal was introducing the > > "caching" of the hi-entries as that wasn't clearly spelled > > out previously and that really did help to clarify the > > processing. I do think the breakdown in the > > sending/receiving of the request and sending/receiving of a > > response into common processing is quite helpful. > > > > 2) Removed the term "escape" with regards to the Privacy and > > Reason header fields and just stated that those header fields > > were included in the hi-targeted-to-uri. I think this also > > improves readbility. > > > > 3) Additional clarification around the Tel-URI. > > > > I think the doc should be ready for another WGLC. > > > > Thanks, > > Mary. > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Tue, Mar 15, 2011 at 1:30 PM > > Subject: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt > > To: i-d-announce@ietf.org > > Cc: sipcore@ietf.org > > > > > > A new Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Session Initiation Protocol > > Core Working Group of the IETF. > > > > Title : An Extension to the Session Initiation > > Protocol (SIP) for Request History Information > > Author(s) : M. Barnes, et al > > Filename : draft-ietf-sipcore-rfc4244bis-04.txt > > Pages : 32 > > Date : 2011-03-15 > > > > This document defines a standard mechanism for capturing the history > > information associated with a Session Initiation Protocol (SIP) > > request. This capability enables many enhanced services by > > providing > > the information as to how and why a SIP request arrives at > > a specific > > application or user. This document defines an optional SIP header > > field, History-Info, for capturing the history information in > > requests. The document also defines SIP header field parameters for > > the History-Info and Contact header fields to tag the > > method by which > > the target of a request is determined. In addition, this document > > defines a value for the Privacy header field specific to > > the History- > > Info header field. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244 > > bis-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft > > > aft> directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > --bcaec53f95ef3f762b049fac2e8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John,

Thanks for the additional comments. =A0Per my othe= r response, I agree with your suggestions for the most part, with just a fe= w responses inline below [MB].

Thanks,
Mary.=A0

On Fri, Mar 25, 2011 at 9= :46 AM, Elwell, John <john.elwell@siemens-enterprise.com<= /a>> wrote:
Mary,

I already sent you my comments on sections 6 to 9. Now I finally got round = to reading much of the rest of the document (up to section 12). Sorry, my e= nergy ran out after that - I will leave it to others to check the rest. I h= ave to say that these sections are not yet ready to go - quite a few inaccu= racies and inconsistent use of terminology. Here goes:

1. Section 1:
"Many services that SIP is anticipated to support require the ability<= br> =A0 to determine why and how a SIP requests arrived at a specific
=A0 application."
Change "requests" to "request".

2. Section 5:
"By adding the new
=A0 =A0 =A0entries in order (i.e., following existing entries per the deta= ils
=A0 =A0 =A0in Section 10.3), including the index and securing the header, = the
=A0 =A0 =A0ordering of the History-info header fields in the request is =A0 =A0 =A0assured."
What is meant by "securing the header"? Why just the header and n= ot the body? Surely the only means we are suggesting is TLS, which secures = the body as well as the header.
[MB] The intent is tha= t if the SIP header fields are protected, then you have confidence that the= values are real. That's not necessarily saying that the bodies aren= 9;t also protected by TLS - it's just not mentioned since the bodies ar= en't =A0relevant to History-Info header fields. I could change that to = "sending the messages using a secure transport". [/MB]

3. Section 5:
"hi-target-param: An optional parameter reflecting the mechanism by =A0 =A0 =A0which the Request URI captured in the hi-targeted-to-uri in the=
=A0 =A0 =A0hi-entry was determined."
The term "hi-entry" has not been introduced yet.

4. Section 5:
""rc": The hi-targeted-to-URI is a contact for the Request-U= RI,
=A0 =A0 =A0 =A0 in the incoming request, that is bound to an AOR in an abs= tract
=A0 =A0 =A0 =A0 location service."
What is bound? Presumably the contact, not the Request-URI, and not the req= uest. Wording is ambiguous, because "that is bound" is too separa= ted from "contact". Also "Request-URI is ambiguous - the Req= uest-URI before or after retargeting. I think it should say something like = "...is a contact bound to an AOR in an abstract location service, that= AOR being the Request-URI that was retargeted."

5. Section 5:
"This occurs when a request is to
=A0 =A0 =A0 =A0 statically or dynamically retargeted "
Delete "to".

6. Section 5:
"The
=A0 =A0 =A0 =A0 value of the index in the "mp" header field para= meter
=A0 =A0 =A0 =A0 represents the value of the hi-index in the hi-entry with = an
=A0 =A0 =A0 =A0 hi-targeted-to- uri that reflects the Request-URI that was=
=A0 =A0 =A0 =A0 retargeted, thus identifying the "mapped from" t= arget."
What is meant by "the value of the index" at the start of the sen= tence? Isn't this simply the value of the "mp" parameter? In = any case, shouldn't we use a similar formulation to that used in the co= rresponding sentence in the definition of "rc"?
[MB] The "value of the index" refers the value = of the "mp" header field parameter which contains an "index&= quot; as defined by the ABNF. However, I'll make the change as you sugg= est. [/MB]=A0

7. Section 5:
"hi-param =3D hi-index / hi-target / hi-extension"
There is no definition of hi-target - I think it should be "hi-target-= param". However, there are other places in the document where "hi= -target" is referred to. I think hi-target-param is better - please al= ign all instances.

8. Section5:
"addition to the parameters defined by the ABNF, an hi-entry may
=A0 also include a Reason header field and a Privacy header field" I think it should say "...and/or a Privacy header field. We can have o= ne without the other.

9. Section 5:
"which
=A0 are both included in the hi-targeted-to-uri as described below:"<= br> To make it clear where in the hi-targeted-to-uri, I think it should say &qu= ot;...included in the "headers" component of the hi-targeted-to-u= ri".

10. Section 5:
"A reason is
=A0 =A0 =A0included for the hi-targeted-to-uri that was retargeted as oppo= sed
=A0 =A0 =A0to the hi-targeted-to-uri to which it was retargeted."
Ambiguous. Does it mean it appears in the hi-entry for that URI, or does it= mean it relates to that URI even though it appears in the URI resulting fr= om retargeting? In addition, a reason can be included (and will appear in t= he response) even if there is no retargeting as a result of that reason. I = would suggest: "A reason is included in the hi-targeted-to-uri of an h= i-entry to reflect information received in a response to the request sent t= o that URI."

11. Section 5.1:
"and
=A0 the headers in the URI are not shown properly formatted for escaping.&= quot;
I am not sure what this is talking about - if it is talking about "hea= ders" component in a URI, I don't see any in the example. Delete t= his part of the sentence?
[MB] That's a hangover f= rom the improper usage of "escape" in prior versions. So, yes, I = will delete. [/MB]=A0

12. Section 10.1:
"Section 10.1.1 describes the use of the Privacy header
=A0 field defined in [RFC3323] to indicate the privacy to be applied to =A0 the History-Info header field entries."
I think 10.1.1 only describes insertion - it doesn't describe use on re= ceipt. Change "the use of" to "the insertion of".

13. Section 10.1:
"Section 10.1.2 describes the
=A0 processing of the priv-values in the Privacy header field to privacy =A0 protect the History-Info header field entries in the request or
=A0 response that is being forwarded."
I think this would be clearer if it said "Section 10.1.2 describes how= to apply privacy to a request or response that is being forwarded, based o= n the presence of the Privacy header field."

14. Section 10.1.1:
"The Privacy header field is
=A0 used by the UAC to indicate the privacy to be applied to all the hi- =A0 entries in the request as follows:"
This seems to suggest it is used to indicate whether privacy is to be appli= ed or not, but the bullets below are specific to the case where privacy IS = to be applied. I would suggest "...to indicate that privacy is to be a= pplied"

15. Section 10.1.1:
"for each hi-entry added by intermediary, as the request is
=A0 retargeted within the domain for which the SIP entity is responsible.&= quot;
Does "each hi-entry added by intermediary" include any hi-entries= that have been received in responses from downstream entities, these hi-en= tries then being added to any additional branches?
[MB] No, it does not include the hi-entries added by the branches as the en= tity that is doing the retargeting applies the privacy as appropriate. =A0I= f the entities are in the same domain one would expect that the entity doin= g the retargeting would indicate and apply privacy as appropriate. [/MB]

16. Section 10.1.2:
"When a request is retargeted to a URI associated with a domain for =A0 which the SIP intermediary is not responsible or a response is
=A0 forwarded"
I think the words "to ... a domain for which the SIP intermediary is n= ot responsible" applies also when forwarding a response. Should it say= :
"When a request is retargeted to a URI associated with a domain for =A0 which the SIP intermediary is not responsible or a response is
=A0 forwarded to a domain for which the SIP intermediary is not responsibl= e"

17. In the same sentence:
"a Privacy Service at the boundary of the domain applies"
Where is "Privacy Service" defined (for priv-value "history&= quot;)? Presumably the following paragraphs specify the Privacy Service, bu= t this is not clear.
[MB] Privacy service is a logical= role as defined in RFC 3323 and the next paragraphs define the behavior fo= r the entity serving in that logical role. [/MB]=A0

18. In the same sentence:
"at the boundary of the domain"
How do we ensure the presence of a Privacy Service at a domain boundary? Fo= r example, a proxy inserts an hi-entry marked with privacy and sends it to = the next node in its domain. But that node doesn't support H-I, so just= passes H-I on transparently, perhaps outside the domain. There needs to be= an element of trust here, similar to RFC 3325, where information subject t= o privacy is sent only to trusted entities within the domain, but furthermo= re, to be trusted an entity needs to support H-I. See also my last comment = (on section 12).

[MB] =A0=A0=A0The protocol itself can'= t ensure the presence of a privacy service, however, if whomever wants priv= acy applied needs to ensure that the entities within its domain are capable= of applying the required privacy when the request leaves the domain. The p= rivacy won't work unless all entities in the domain have implemented th= is RFC (or 4244 for that matter. =A0 I don't see that adding the RFC 33= 25 trust domain model helps. We have also discussed the latter in the past = and we add ed clarification in section 2 that this document is dealing with= the definition of a domain as per RFC 3261 and we aren't describing th= e use in the context of RFC 3325. [/MB]

19. Section 10.1.2:
"If there is a Privacy header field in the request with a priv-value =A0 of "header" or "history","
I think this is talking about a Privacy header field in the message header,= as opposed to a Privacy header field in the "headers" component = of an hi-targeted-to-uri. This should be made clear, although there is no o= bvious terminology we can call on. Perhaps:
"If there is a Privacy header field in the request, other than in the = "headers" component of an hi-targeted-to-uri, with a priv-value =A0 of "header" or "history","

20. The same quoted text talks about requests, but don't we need simila= r procedures for responses?
[MB] Yes. [/MB]=A0

21. In the same sentence:
"then the hi-targeted-to-uris in the hi-
=A0 entries, associated with the domain for which a SIP intermediary is =A0 responsible, are anonymized."
I think this is trying to say "a SIP intermediary =A0anonymizes any hi= -targeted-to-uris associated with its own domain". But I am rather con= fused that this sentence talks about "a SIP intermediary" and the= next sentence, which seems to repeat things in normative language, talks a= bout "The Privacy Service". We could do with some rationalization= of the two sentences.
[MB] The Privacy Service is a logical role as described i= n my response to 17 above. The usage of domain and SIP intermediary is used= as described in section 2. =A0I'll change the last part of that first = sentence to "are anonymized by the Privacy Service". [/MB]

22. Section 10.1.2:
"If there is not a Privacy header field in the request or response
=A0 that is being forwarded"
Again I think we need to qualify this by adding "other than in the &qu= ot;headers" component of an hi-targeted-to-uri".

23. Concerning the same sentence, again I have trouble with this sentence a= nd the next sentence covering essentially the same thing with different ter= minology.

24. Section 10.2:
"If the retargeting is due to receipt of an explicit SIP response and<= br> =A0 the response contains any Reason header fields (see [RFC3326]), then =A0 the SIP entity MUST include the Reason header fields in the hi-
=A0 targeted-to-uri containing the URI of the request that was
=A0 retargeted"
According to 9.3 step 2, we add Reason to the cached hi-entries, and indepe= ndently of whether the request then gets retargeted. I think it should say = something like: =A0"To add Reason header fields to a cached hi-entry a= s a result of receiving a response to the request sent to the hi-entry'= s hi-targeted-to-uri, a SIP entity MUST use any Reason header fields receiv= ed in the response"
[MB] See response to 25. [/MB]=A0

25. Section 10.2:
"MUST
=A0 include a Reason header field, containing the SIP Response Code"<= br> What if it is a 2xx response - does this make sense?
[= MB] If it was a 2xx response, then we are not retargeting, which is the sub= ject of that sentence. =A0So, we should update 9.3 to read "other than= a 100 or 2xx". =A0[/MB]

26. In the same sentence:
"that
=A0 triggered the retargeting, in the hi-targeted-to-uri containing the =A0 URI of the request that was retargeted"
Delete these words, because it gets added to the cached hi-entry independen= tly of whether it is then retargeted.
[MB] Per my resp= onse above, it only gets added when it is retargeted. So, we need to clarif= y this in section 9.3 which is caching. =A0However, there are times when we= need to cache an hi-entry so it gets sent in a response AND it doesn't= need to have a Reason header added. I think we introduced a bug when the c= ache concept was introduced. [/MB]=A0

27. Section 10.2:
"containing a SIP
=A0 error response code of 408 "Request Timeout" in hi-targeted-= to-uri
=A0 containing the URI of the request that was retargeted. "
Again, delete "in hi-targeted-to-uri
=A0 containing the URI of the request that was retargeted. "
because we are just talking about adding to the cache.

28. Section 10.2:
"The SIP
=A0 entity MAY also include a Reason header field in the hi-targeted-to- =A0 uri containing the URI of the request that was retargeted as a result<= br> =A0 of internal retargeting."
Change "the request" to "a request".

29. Section 10.2:
"If additional Reason headers are defined in the future "
Does this mean "additional protocol values"? However, no specific= protocol values are mentioned above, so why to we need to mention "ad= ditional" protocol values?
[MB] This is saying th= at if there are new Reason header field values defined, then they also MUST= be added to the hi-entry as described in that section. =A0So, perhaps rath= er than "described above" we say "as described in this secti= on". =A0This is intended to mean that you don't need to =A0update = HI if you add new Reason header field values since this document references= the ones defined in RFC 3326.[/MB]

30. Section 10.3:
"Basic Forwarding: "
What is "Basic Forwarding"?
[MB] We'll r= emove "basic". It's referring to=A0when a request is sent from one entity to= another entity across=A0different intermediary without changing the target.[/MB]=A0

31. Section 10.3, item 1:
"In the case of a request that is being
=A0 =A0 =A0 forwarded"
Any request can be forwarded eventually, even it has been retargeted, redir= ected, etc.. So how exactly does this case 1 differ from some of the other = cases?
[MB] =A0See 30. [/MB]

32. Also in item 1:
"MUST
=A0 =A0 =A0 add another level of indexing by appending the dot delimiter =A0 =A0 =A0 followed by an initial hi-index for the new level of 1."<= br> The new level is not, in general, level 1. I think this should say "An= initial value of 1 for the new level." Unfortunately the ABNF fails t= o give a name to a single component of hi-index, so I have just called it &= quot;value".

33. "a proxy would add an hi-entry with
=A0 =A0 =A0 an hi-index to 1.1.1 "
Change "to" to "of".

34. In item 3:
"Retargeting within a processing entity - subsequent instance: For
=A0 =A0 =A0 each subsequent retargeting of a request by the same SIP entit= y,
=A0 =A0 =A0 the SIP entity MUST add another branch."
What exactly is "another branch"? RFC 3261 already talks about cr= eating branches, so why do we need a normative statement here to tell us to= do something that is normatively specified in RFC 3261? We should only be = making normative statements that are specific to H-I.

[MB] =A0We meant to represent the additional branch by setti= ng=A0a hi-entry with value incrementing the hi-entry of previous branch by 1.= =A0

Initial branch= =3D 1.1.1
Second branch =3D 1.1.2=A0

I guess we can remove the M= UST add and change the following sentence=A0
as follows.=A0

"The SIP entity MUST calculate and add the hi-in= dex for each new branch.."
[= /MB]

35. Also in item 3:
"The SIP entity MUST
=A0 =A0 =A0 calculate the hi-index for each new branch by incrementing the=
=A0 =A0 =A0 value from the hi-index in the last hi-entry at the current =A0 =A0 =A0 level."
It is unclear what "value" means. I think it is the value of the = rightmost level.

36. In item 4:
"That is, the lowest/last
=A0 =A0 =A0 digit of the hi-index MUST be incremented"
Since a value for a particular level within hi-index can comprise more than= one digit, the word "digit" here is not correct. It is the integ= er that should be incremented.
[MB] It's not an in= teger. =A0We could say the lowest/last "value".[/MB]=A0

37. In the same sentence:
"MUST be incremented (i.e., a new branch is
=A0 =A0 =A0 created), with the increment of 1"
I think "with the increment of 1" can be deleted.

38. In item 5:
"Note that for each individual fork, only the
=A0 =A0 =A0 hi-entry corresponding to that fork is included (e.g., the hi-=
=A0 =A0 =A0 entry for fork 1.1.1 is not included in the request sent to fo= rk
=A0 =A0 =A0 1.1.2, and vice-versa)."
I don't think this is true. For example, I receive hi-entry 1.2, I fork= first of all with hi-entry 1.2.1. This receives a response 4xx, so I then = fork again, this time with hi-entry 1.2.2. I thought in this case hi-entry = 1.2.1, as well as 1.2.2, =A0would be included in the new forwarded request = (since 1.2.1 will be in the cache at this stage).
[MB] That just applies to parallel forking. =A0Will chang= e to "Note, that in the case of parallel forking, only the hi-entry co= rresponding to the fork =A0is included in the request.[/MB]=A0

39. "10.4. =A0Mechanism for Target Determination in the History-Info H= eader
=A0 =A0 =A0 Field"
Wrong title - the section is to do with indicating how the target was deter= mined, not with the determination mechanism itself. Perhaps "10.4 Indi= cating the mechanism by which the target was determined..."

40. Section 10.4:
" =A0 This specification defines two header field parameters, "rc= " and
=A0 "mp", indicating two non-inclusive mechanisms by which a new= target
=A0 for a request is determined."
I am not sure what "non-inclusive" means here.
[MB] Meaning that those are not the only mechanisms by which a target is= determined - this goes back to when we had others identified and was added= when we changed it to not tag each hi-entry with something. =A0We can just= delete the "non-inclusive". [/MB]=A0

41. Section 10.4:
"in the case of 3xx responses"
I think this should say "in the case of retargeting to a contact URI r= eceived in a 3xx response".

42. Section 10.4:
"If the Contact header field
=A0 does not contain an "rc" or "mp" header field para= meter, then the SIP
=A0 entity MUST NOT include an "rc" or "mp" in the hi-= entry when the
=A0 request is retargeted."
I think this sentence is still talking about the 3xx case, but it is not cl= ear. Should say:
"....when the request is retargeted to a contact URI received in a 3xx= response".

43. Section 10.4:
""rc": The target was determined based on a contact that is = bound
=A0 =A0 =A0to an AOR in an abstract location service for the Request-URI =A0 =A0 =A0being retargeted."
This doesn't make it clear that the Request-URI is the AOR. However, fo= r both this and the "mp" bullet point, we should perhaps refer to= section 5, where those are defined, rather than reproducing the definition= here with the risk of it being different.

44. Section 10.4:
"The mapping was done due to receiving a 3xx response, in which
=A0 =A0 =A0case the mp-value is an earlier sibling of the hi-entry's i= ndex,
=A0 =A0 =A0that of the downstream request which received the 3xx response.= "
I don't think this is right, since the issuer of the 3xx will build the= rc or mp parameter, and therefore it will reference the index received by = that entity. This could indeed be a sibling, but it could also be a child o= f a sibling, a child of a child of a sibling, and so on.
[MB]

45. Section 11:
"Thus, if gaps are detected,
=A0 the SIP entity MUST NOT treat this as an error, but rather indicate =A0 to any applications that there are gaps."
I think changing "rather indicate" to "MUST indicate" w= ould be clearer, if we do indeed intend it normatively.
[MB] =A0=A0This is bascially saying that the SIP entity is the one that ca= n interpret the information and if there are gaps, it MUST NOT generate an = error but it just needs to provide an indication to the application that th= ere are gaps. =A0 We added this MUST NOT generate an error based on a comme= nt from Hadriel a while back.=A0= I don't know what we can anticipate by saying MUST indicate, as we aren= 't providing a protocol mechanism for the indication.=A0=A0There being a gap is an indication that there is a = gap and that is that.=A0


46. Section 11:
"The most complete
=A0 information available to the application is the History-Info entries =A0 starting with the last hi-entry with an index of "1"."<= br> This is not true. The most complete is the complete set of hi-entries. Even= if there are gaps, the information subsequent to the last gap will not be = as complete as the total information.
[MB] We can just= strike that sentence [/MB]=A0

47. Section 11:
"The following summarizes the categories of =A0information that
=A0 applications can use:"
I thinks these are only examples, rather than a summary of everything an ap= plication could used. Change "summarizes" to "examples"= .
[MB] I would prefer "describes some categories&= quot; [/MB]=A0

48. Section 11, item 2:
"the index that matches the value of =A0the last hi-
=A0 =A0 =A0 entry with ..."
An index cannot match an entire hi-entry. I think this should say "the= index that matches the value of the "rc" parameter in the last h= i-
=A0 =A0 =A0 entry with ..."
A similar correction should be applied to items 3, 4 and 5 too.

49. Section 11, item 2:
"rc" header parameter"
I am not sure that "header parameter" is the right way to describ= e "rc". It might be more accurate to say "hi-entry parameter= " or, to use the ABNF name, "hi-target-parameter", or simply= "parameter". Whatever is chosen, it needs to be consistent throu= ghout the document.
A similar correction should be applied to items 3, 4 and 5 too.
[MB] "rc" is a header field parameter that is in an hi-= entry. [/MB]=A0

50. Section 11, item 2:
"i.e., the Request URI associated with the destination of
=A0 =A0 =A0 the request was determined based on an AOR-to-contact binding = in
=A0 =A0 =A0 an abstract location service."
This is confusing, because the Request-URI changes during retargeting, and = it is not clear to which Request-URI and to which request we refer. Perhaps= it means the final target, but that is not necessarily true - I am sure th= ere must be some corner cases where there is a non-"rc" retarget = after the last "rc" retarget. I think all we can say for certain = is something like: "i.e., the last AOR that was retargeted to a contac= t based on an AOR-to-contact binding in an abstract location service."= Note that a formulation like this would better match the style of the form= ulation in item 3.

51. Section 11, item 4:
"thus the
=A0 =A0 =A0 first hi-entry with an "rc" header parameter =A0with= in the domain
=A0 =A0 =A0 associated with the target URI at the destination is more like= ly
=A0 =A0 =A0 to be useful."
I think this should say:
"thus the hi-entry that matches the value of the "rc" = parameter of the first hi-entry with an "rc" parameter within the= domain..."
A similar correction should be applied to item 5 too.

52. Section 11:
"hi-entry who =A0index "
Change to:
"hi-entry whose =A0index "

53. Section 11:
"matches the index =A0of the first"
I think this should say:
"matches value of the "mp" parameter of the first"= ;

54. Section 11:
"History-Info entry"
Why not "hi-entry" as elsewhere?
Similarly "History-Info entries" later in sentence.

55. Section 11:
"with an hi-target value of "mp" "
Whatever terminology we end up with from comment 49, we should align here t= oo, e.g., "with an "mp" parameter".
Similarly for "rc" later in sentence.

56. Section 11:
"Since support for History-info header field is optional, a service =A0 MUST define default behavior for requests and responses not
=A0 containing History-Info headers."
Change "History-Info headers" to "a History-Info header fiel= d".

57. Section 11:
"For example, an entity may receive
=A0 only partial History-Info entries =A0or entries"
Surely each hi-entry will be a complete entry, but an entity might receive = an incomplete set of hi-entries. Also correct the terminology. Change to: "For example, an entity may receive an incomplete set of hi-entries&qu= ot;

58. Section 12:
If an entity forwards a request containing an hi-entry marked as private to= another entity within the same domain, it expects that other entity to ano= nymize the hi-entry before forwarding outside the domain. However, what hap= pens if that other entity doesn't support H-I? Presumably the RFC 3325 = concept of Trust Domain needs to be extended somehow to RFC4424bis, such th= at for an entity to be considered in the same Trust Domain it must support = RFC4424bis. There should be some discussion around this. See also comment 1= 8.
[MB] See response to 18 above. =A0[/MB]=A0

John

> -----Original Message-----
> From: si= pcore-bounces@ietf.org
> [mailto:= sipcore-bounces@ietf.org] On Behalf Of Mary Barnes
> Sent: 15 March 2011 18:46
> To: SIPCORE
> Subject: [sipcore] Fwd: I-D
> ACTION:draft-ietf-sipcore-rfc4244bis-04.txt
>
> Hi folks,
>
> I have updated the document to incorporate the feedback on
> the -03 as follows:
>
> 1) The biggest change was the reformating =A0inline with John's > suggestion:
> http://www.ietf.org/mail-archive/web/sipcore/cur= rent/msg04010.html
> It is not verbatim, but rather I included some of the past
> text in the relevant sections and I included a bullet list in
> some cases rather than just a paragraph as that was one of
> the formatting changes we made between RFC4244 and 4244bis in
> that the text in paragraph form can be rather dense. =A0I
> believe the spirit and intent of John's proposal has been
> accomodated (I don't know that as many words were saved).
> Also, I just noticed some of the bullet lists don't have the
> "o" - I'll have to fix that. =A0I think one of the most<= br> > important aspects of John's proposal was introducing the
> "caching" of the hi-entries as that wasn't clearly spell= ed
> out previously and that really did help to clarify the
> processing. =A0I do think the breakdown in the
> sending/receiving of the request and sending/receiving of a
> response into common processing is quite helpful.
>
> 2) Removed the term "escape" with regards to the Privacy and=
> Reason header fields and just stated that those header fields
> were included in the hi-targeted-to-uri. =A0I think this also
> improves readbility.
>
> 3) Additional clarification around the Tel-URI.
>
> I think the doc should be ready for another WGLC.
>
> Thanks,
> Mary.
>
>
> ---------- Forwarded message ----------
> From: <Internet-Drafts@ietf.org>
> Date: Tue, Mar 15, 2011 at 1:30 PM
> Subject: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt
> To: i-d-ann= ounce@ietf.org
> Cc: sipcore@ietf= .org
>
>
> A new Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Session Initiation Protocol
> Core Working Group of the IETF.
>
> =A0 =A0Title =A0 =A0 =A0 =A0 : An Extension to the Session Initiation<= br> > Protocol (SIP) for Request History Information
> =A0 =A0Author(s) =A0 =A0 : M. Barnes, et al
> =A0 =A0Filename =A0 =A0 =A0: draft-ietf-sipcore-rfc4244bis-04.txt
> =A0 =A0Pages =A0 =A0 =A0 =A0 : 32
> =A0 =A0Date =A0 =A0 =A0 =A0 =A0: 2011-03-15
>
> =A0 This document defines a standard mechanism for capturing the histo= ry
> =A0 information associated with a Session Initiation Protocol (SIP) > =A0 request. =A0This capability enables many enhanced services by
> providing
> =A0 the information as to how and why a SIP request arrives at
> a specific
> =A0 application or user. =A0This document defines an optional SIP head= er
> =A0 field, History-Info, for capturing the history information in
> =A0 requests. =A0The document also defines SIP header field parameters= for
> =A0 the History-Info and Contact header fields to tag the
> method by which
> =A0 the target of a request is determined. =A0In addition, this docume= nt
> =A0 defines a value for the Privacy header field specific to
> the History-
> =A0 Info header field.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sipco= re-rfc4244
> bis-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft
> <https://www.ietf.org/mailman/listinfo/i-d-announc= eInternet-Dr
> aft> =A0directories: http://www.ietf.org/shadow.html

--bcaec53f95ef3f762b049fac2e8e-- From adam@nostrum.com Wed Mar 30 00:32:53 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250A23A6B23 for ; Wed, 30 Mar 2011 00:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YebAhkxLz1Gz for ; Wed, 30 Mar 2011 00:32:52 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3D83F3A6B15 for ; Wed, 30 Mar 2011 00:32:50 -0700 (PDT) Received: from dhcp-17a6.meeting.ietf.org (dhcp-17a6.meeting.ietf.org [130.129.23.166]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p2U7YREk057774 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 30 Mar 2011 02:34:28 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4D92DD03.2090902@nostrum.com> Date: Wed, 30 Mar 2011 09:34:27 +0200 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.166 is authenticated by a trusted mechanism) Subject: [sipcore] Getting Prepared: History-Info Call Flows X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 07:32:53 -0000 [as chair] As we discussed at the SIPCORE meeting today, the SIPCORE WG chairs will be calling for consensus around adoption of the History-Info call flows shortly. Please take some time in the next two weeks to read the document in preparation for this decision: http://tools.ietf.org/html/draft-barnes-sipcore-rfc4244bis-callflows-01 Thank you. /a From john.elwell@siemens-enterprise.com Wed Mar 30 01:00:48 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933E13A6B37 for ; Wed, 30 Mar 2011 01:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mw9ZXBuHZDr for ; Wed, 30 Mar 2011 01:00:47 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id F38153A6B31 for ; Wed, 30 Mar 2011 01:00:46 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3937394 for sipcore@ietf.org; Wed, 30 Mar 2011 10:02:24 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id DA37E1EB82B4 for ; Wed, 30 Mar 2011 10:02:24 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 30 Mar 2011 10:02:25 +0200 From: "Elwell, John" To: SIPCORE Date: Wed, 30 Mar 2011 10:02:22 +0200 Thread-Topic: Rough notes Thread-Index: AcvusMy0qoa77F8fRFWNLiL9ZUw4Iw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Rough notes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:00:48 -0000 RFC 3265 bis. Adam Roach: Event header field parameters issue has arisen - what is the sc= ope of the parameters. Event-rate-control Robert Sparks: Some minor corrections needed. Location conveyance (James Polk) No issues raised. History-Info (Mary Barnes) Issue of when to add Reason header field. Proposal to add for all responses= except 100 and 2xx responses. No objection to this. Need additional reviewers. John Elwell: I did not review all sections, so some sections have not been = reviewed. Hadriel Kaplan, Andrew Allen and Dale Worley volunteered. Cullen Jennings. It does not tell me how to USE the information. Mary Barnes. The call flows document. Cullen Jennings. I will review it carefully. Reviews required within next few weeks. Keith Drage: Asked about compatibility with RFC 4244. Mary Barnes: That is needed (there are some existing implementations) and t= here is some text, but I will look to improving it. Andrew Allen: Asked what would be impact on 3GPP specifications that refere= nce RFC 4244. Mary Barnes: It should be possible just to change the reference to 4244bis,= although the specifications and any implementations might want to take adv= antage of the new features in 4244bis. On call flows document. Cullen Jennings: I think we should adopt it as WG item now. But there is co= nfusion between the two documents, and the two documents don't tell me how = to use the information. Mary Barnes: 4244bis provides a building block and does not define the serv= ices. Cullen Jennings: Somewhere we should write down how we solve the problems t= his document is meant to solve. Mary Barnes: It is in 4244bis. Cullen Jennings: I will read it. Keith Drage: Keep the call flows fully informative. Mary Barnes: They are not normative. Keith Drage: Yes, but if anything does need to be normative, it should be i= n 4244bis. Martin Dolly: Agree with Mary this is a base capability and how to use it d= oes not need to be defined any further. Dale Worley: Comparison with REFER, we don't need to specify how you used H= -I, but should specify what it means when you receive it. Mary Barnes: Yes, and it is indeed clearly defined in terms of SIP terminol= ogy. Dale Worley: So the approach we are taken does seem to be OK. Only a few people have read the flows document. Will take consensus call on adoption of flows document to list, to give mor= e people chance to read it. Proxy feature tags (Christer Holmberg) Christer is only asking do we want to work on this problem, not about speci= fic solution. Andrew Allen: This is useful. Christer Holmberg: In reply to a question from John Elwell, clarified that = the entities concerned really are proxies, using Record-Route, and not B2BU= As. Not in a position to be able to overwrite the contact. Cullen Jennings: Thinks Christer makes a compelling argument and would be u= seful also outside 3GPP context. Chair: Does Cullen see any specific non-3GPP use cases. Cullen Jennings: Let me go try and find some of those - there were some. Dale Worley: Don't want to enforce the use of B2BUAs. But it would be good = if a proxy could signal its capabilities differently in the two directions. Christer Holmberg: Yes, this is something we need to be able to deal with. Keith Drage: Fine to go and look for old use cases, but make sure they are = still current. Andrew Allen: Mentioned BLISS work where a UA might want to identify capabi= lities of a proxy. Hum: those who want to add this to charter. Strong hum in favour, and nobod= y opposed. Chair declared consensus for adopting milestone for solving this= problem. A reasonable number of people have read the document. Chair: Can we adopt this document? John Elwell: We haven't discussed the technical solution. Andrew Allen: There may be some issues that need to be addressed. Chair: Just asking if this is roughly the right direction. Keith Drage: Just ask on list, and give people the option of saying if ther= e are any sections not suitable for adoption. Andrew Allen: Happy to adopt the draft, because feature tags will be part o= f the solution, but not the whole solution. Hum: Those in support of using this document as the basis for the milestone= , if created. Good support, none against. Chair declared consensus in room = - will be taken to list. John From john.elwell@siemens-enterprise.com Wed Mar 30 01:46:12 2011 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061C93A6AC1 for ; Wed, 30 Mar 2011 01:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF6anHTzdQT4 for ; Wed, 30 Mar 2011 01:46:09 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A8FB43A6909 for ; Wed, 30 Mar 2011 01:46:08 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3928260; Wed, 30 Mar 2011 10:47:46 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 57A641EB82B5; Wed, 30 Mar 2011 10:47:46 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 30 Mar 2011 10:47:46 +0200 From: "Elwell, John" To: Mary Barnes Date: Wed, 30 Mar 2011 10:47:44 +0200 Thread-Topic: [sipcore] Fwd: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt Thread-Index: AcvumKXR7RqA5XA8Q3CeqWkwHL0QeAAG4Vag Message-ID: References: <20110315183001.24369.74903.idtracker@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] Fwd: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:46:12 -0000 Mary, Thanks for your responses. Sorry I did not see this before the meeting. The= re are a few points where I am not entirely happy with your response, but n= othing that really needed to be raised at the meeting - see below. > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: 30 March 2011 06:09 > To: Elwell, John > Cc: SIPCORE > Subject: Re: [sipcore] Fwd: I-D > ACTION:draft-ietf-sipcore-rfc4244bis-04.txt > > John, > > Thanks for the additional comments. Per my other response, I > agree with your suggestions for the most part, with just a > few responses inline below [MB]. > > Thanks, > Mary. > > On Fri, Mar 25, 2011 at 9:46 AM, Elwell, John > wrote: > > > Mary, > > I already sent you my comments on sections 6 to 9. Now > I finally got round to reading much of the rest of the > document (up to section 12). Sorry, my energy ran out after > that - I will leave it to others to check the rest. I have to > say that these sections are not yet ready to go - quite a few > inaccuracies and inconsistent use of terminology. Here goes: > > 1. Section 1: > "Many services that SIP is anticipated to support > require the ability > to determine why and how a SIP requests arrived at a specific > application." > Change "requests" to "request". > > 2. Section 5: > "By adding the new > entries in order (i.e., following existing entries > per the details > in Section 10.3), including the index and securing > the header, the > ordering of the History-info header fields in the > request is > assured." > What is meant by "securing the header"? Why just the > header and not the body? Surely the only means we are > suggesting is TLS, which secures the body as well as the header. > > > [MB] The intent is that if the SIP header fields are > protected, then you have confidence that the values are real. > That's not necessarily saying that the bodies aren't also > protected by TLS - it's just not mentioned since the bodies > aren't relevant to History-Info header fields. I could > change that to "sending the messages using a secure transport". [/MB] > > > 3. Section 5: > "hi-target-param: An optional parameter reflecting the > mechanism by > which the Request URI captured in the > hi-targeted-to-uri in the > hi-entry was determined." > The term "hi-entry" has not been introduced yet. > > 4. Section 5: > ""rc": The hi-targeted-to-URI is a contact for the Request-URI, > in the incoming request, that is bound to an > AOR in an abstract > location service." > What is bound? Presumably the contact, not the > Request-URI, and not the request. Wording is ambiguous, > because "that is bound" is too separated from "contact". Also > "Request-URI is ambiguous - the Request-URI before or after > retargeting. I think it should say something like "...is a > contact bound to an AOR in an abstract location service, that > AOR being the Request-URI that was retargeted." > > 5. Section 5: > "This occurs when a request is to > statically or dynamically retargeted " > Delete "to". > > 6. Section 5: > "The > value of the index in the "mp" header field parameter > represents the value of the hi-index in the > hi-entry with an > hi-targeted-to- uri that reflects the > Request-URI that was > retargeted, thus identifying the "mapped from" target." > What is meant by "the value of the index" at the start > of the sentence? Isn't this simply the value of the "mp" > parameter? In any case, shouldn't we use a similar > formulation to that used in the corresponding sentence in the > definition of "rc"? > > > [MB] The "value of the index" refers the value of the "mp" > header field parameter which contains an "index" as defined > by the ABNF. However, I'll make the change as you suggest. [/MB] > > > 7. Section 5: > "hi-param =3D hi-index / hi-target / hi-extension" > There is no definition of hi-target - I think it should > be "hi-target-param". However, there are other places in the > document where "hi-target" is referred to. I think > hi-target-param is better - please align all instances. > > 8. Section5: > "addition to the parameters defined by the ABNF, an hi-entry may > also include a Reason header field and a Privacy header field" > I think it should say "...and/or a Privacy header > field. We can have one without the other. > > 9. Section 5: > "which > are both included in the hi-targeted-to-uri as > described below:" > To make it clear where in the hi-targeted-to-uri, I > think it should say "...included in the "headers" component > of the hi-targeted-to-uri". > > 10. Section 5: > "A reason is > included for the hi-targeted-to-uri that was > retargeted as opposed > to the hi-targeted-to-uri to which it was retargeted." > Ambiguous. Does it mean it appears in the hi-entry for > that URI, or does it mean it relates to that URI even though > it appears in the URI resulting from retargeting? In > addition, a reason can be included (and will appear in the > response) even if there is no retargeting as a result of that > reason. I would suggest: "A reason is included in the > hi-targeted-to-uri of an hi-entry to reflect information > received in a response to the request sent to that URI." > > 11. Section 5.1: > "and > the headers in the URI are not shown properly > formatted for escaping." > I am not sure what this is talking about - if it is > talking about "headers" component in a URI, I don't see any > in the example. Delete this part of the sentence? > > > [MB] That's a hangover from the improper usage of "escape" in > prior versions. So, yes, I will delete. [/MB] > > > 12. Section 10.1: > "Section 10.1.1 describes the use of the Privacy header > field defined in [RFC3323] to indicate the privacy to > be applied to > the History-Info header field entries." > I think 10.1.1 only describes insertion - it doesn't > describe use on receipt. Change "the use of" to "the insertion of". > > 13. Section 10.1: > "Section 10.1.2 describes the > processing of the priv-values in the Privacy header > field to privacy > protect the History-Info header field entries in the > request or > response that is being forwarded." > I think this would be clearer if it said "Section > 10.1.2 describes how to apply privacy to a request or > response that is being forwarded, based on the presence of > the Privacy header field." > > 14. Section 10.1.1: > "The Privacy header field is > used by the UAC to indicate the privacy to be applied > to all the hi- > entries in the request as follows:" > This seems to suggest it is used to indicate whether > privacy is to be applied or not, but the bullets below are > specific to the case where privacy IS to be applied. I would > suggest "...to indicate that privacy is to be applied" > > 15. Section 10.1.1: > "for each hi-entry added by intermediary, as the request is > retargeted within the domain for which the SIP entity > is responsible." > Does "each hi-entry added by intermediary" include any > hi-entries that have been received in responses from > downstream entities, these hi-entries then being added to any > additional branches? > > > [MB] No, it does not include the hi-entries added by the > branches as the entity that is doing the retargeting applies > the privacy as appropriate. If the entities are in the same > domain one would expect that the entity doing the retargeting > would indicate and apply privacy as appropriate. [/MB] [JRE] Perhaps you could add some words to clarify that. > > > 16. Section 10.1.2: > "When a request is retargeted to a URI associated with > a domain for > which the SIP intermediary is not responsible or a response is > forwarded" > I think the words "to ... a domain for which the SIP > intermediary is not responsible" applies also when forwarding > a response. Should it say: > "When a request is retargeted to a URI associated with > a domain for > which the SIP intermediary is not responsible or a response is > forwarded to a domain for which the SIP intermediary > is not responsible" > > 17. In the same sentence: > "a Privacy Service at the boundary of the domain applies" > Where is "Privacy Service" defined (for priv-value > "history")? Presumably the following paragraphs specify the > Privacy Service, but this is not clear. > > > [MB] Privacy service is a logical role as defined in RFC 3323 > and the next paragraphs define the behavior for the entity > serving in that logical role. [/MB] [JRE] My problem was that Privacy Service as defined in RFC 3323 does inclu= de H-I - but if others are comfortable with the existing text I can live wi= th it. > > > 18. In the same sentence: > "at the boundary of the domain" > How do we ensure the presence of a Privacy Service at a > domain boundary? For example, a proxy inserts an hi-entry > marked with privacy and sends it to the next node in its > domain. But that node doesn't support H-I, so just passes H-I > on transparently, perhaps outside the domain. There needs to > be an element of trust here, similar to RFC 3325, where > information subject to privacy is sent only to trusted > entities within the domain, but furthermore, to be trusted an > entity needs to support H-I. See also my last comment (on section 12). > > > > [MB] The protocol itself can't ensure the presence of a > privacy service, however, if whomever wants privacy applied > needs to ensure that the entities within its domain are > capable of applying the required privacy when the request > leaves the domain. The privacy won't work unless all entities > in the domain have implemented this RFC (or 4244 for that > matter. I don't see that adding the RFC 3325 trust domain > model helps. We have also discussed the latter in the past > and we add ed clarification in section 2 that this document > is dealing with the definition of a domain as per RFC 3261 > and we aren't describing the use in the context of RFC 3325. [/MB] [JRE] Perhaps this is something that can be address in Security Considerati= ons - see my later comment. > > > 19. Section 10.1.2: > "If there is a Privacy header field in the request with > a priv-value > of "header" or "history"," > I think this is talking about a Privacy header field in > the message header, as opposed to a Privacy header field in > the "headers" component of an hi-targeted-to-uri. This should > be made clear, although there is no obvious terminology we > can call on. Perhaps: > "If there is a Privacy header field in the request, > other than in the "headers" component of an > hi-targeted-to-uri, with a priv-value > of "header" or "history"," > > 20. The same quoted text talks about requests, but > don't we need similar procedures for responses? > > > [MB] Yes. [/MB] > > > 21. In the same sentence: > "then the hi-targeted-to-uris in the hi- > entries, associated with the domain for which a SIP > intermediary is > responsible, are anonymized." > I think this is trying to say "a SIP intermediary > anonymizes any hi-targeted-to-uris associated with its own > domain". But I am rather confused that this sentence talks > about "a SIP intermediary" and the next sentence, which seems > to repeat things in normative language, talks about "The > Privacy Service". We could do with some rationalization of > the two sentences. > > > [MB] The Privacy Service is a logical role as described in my > response to 17 above. The usage of domain and SIP > intermediary is used as described in section 2. I'll change > the last part of that first sentence to "are anonymized by > the Privacy Service". [/MB] > > > 22. Section 10.1.2: > "If there is not a Privacy header field in the request > or response > that is being forwarded" > Again I think we need to qualify this by adding "other > than in the "headers" component of an hi-targeted-to-uri". > > 23. Concerning the same sentence, again I have trouble > with this sentence and the next sentence covering essentially > the same thing with different terminology. > > 24. Section 10.2: > "If the retargeting is due to receipt of an explicit > SIP response and > the response contains any Reason header fields (see > [RFC3326]), then > the SIP entity MUST include the Reason header fields > in the hi- > targeted-to-uri containing the URI of the request that was > retargeted" > According to 9.3 step 2, we add Reason to the cached > hi-entries, and independently of whether the request then > gets retargeted. I think it should say something like: "To > add Reason header fields to a cached hi-entry as a result of > receiving a response to the request sent to the hi-entry's > hi-targeted-to-uri, a SIP entity MUST use any Reason header > fields received in the response" > > > [MB] See response to 25. [/MB] [JRE] I don't see the relevance of 25 - 24 and 25 are quite different comme= nts. > > > 25. Section 10.2: > "MUST > include a Reason header field, containing the SIP > Response Code" > What if it is a 2xx response - does this make sense? > > > [MB] If it was a 2xx response, then we are not retargeting, > which is the subject of that sentence. So, we should update > 9.3 to read "other than a 100 or 2xx". [/MB] > > > 26. In the same sentence: > "that > triggered the retargeting, in the hi-targeted-to-uri > containing the > URI of the request that was retargeted" > Delete these words, because it gets added to the cached > hi-entry independently of whether it is then retargeted. > > > [MB] Per my response above, it only gets added when it is > retargeted. So, we need to clarify this in section 9.3 which > is caching. However, there are times when we need to cache > an hi-entry so it gets sent in a response AND it doesn't need > to have a Reason header added. I think we introduced a bug > when the cache concept was introduced. [/MB] > > > 27. Section 10.2: > "containing a SIP > error response code of 408 "Request Timeout" in > hi-targeted-to-uri > containing the URI of the request that was retargeted. " > Again, delete "in hi-targeted-to-uri > containing the URI of the request that was retargeted. " > because we are just talking about adding to the cache. > > 28. Section 10.2: > "The SIP > entity MAY also include a Reason header field in the > hi-targeted-to- > uri containing the URI of the request that was > retargeted as a result > of internal retargeting." > Change "the request" to "a request". > > 29. Section 10.2: > "If additional Reason headers are defined in the future " > Does this mean "additional protocol values"? However, > no specific protocol values are mentioned above, so why to we > need to mention "additional" protocol values? > > > [MB] This is saying that if there are new Reason header field > values defined, then they also MUST be added to the hi-entry > as described in that section. So, perhaps rather than > "described above" we say "as described in this section". > This is intended to mean that you don't need to update HI if > you add new Reason header field values since this document > references the ones defined in RFC 3326.[/MB] [JRE] So "additional" means additional to those currently specified in RFCs= , or "new protocol values specified in the future". > > > 30. Section 10.3: > "Basic Forwarding: " > What is "Basic Forwarding"? > > > [MB] We'll remove "basic". It's referring to when a request > is sent from one entity to another entity across different > intermediary without changing the target.[/MB] [JRE] so make it clear that we are not changing the target, e.g., "Forwardi= ng a request without changing the target". > > > 31. Section 10.3, item 1: > "In the case of a request that is being > forwarded" > Any request can be forwarded eventually, even it has > been retargeted, redirected, etc.. So how exactly does this > case 1 differ from some of the other cases? > > > [MB] See 30. [/MB] > > > 32. Also in item 1: > "MUST > add another level of indexing by appending the > dot delimiter > followed by an initial hi-index for the new level of 1." > The new level is not, in general, level 1. I think this > should say "An initial value of 1 for the new level." > Unfortunately the ABNF fails to give a name to a single > component of hi-index, so I have just called it "value". > > 33. "a proxy would add an hi-entry with > an hi-index to 1.1.1 " > Change "to" to "of". > > 34. In item 3: > "Retargeting within a processing entity - subsequent > instance: For > each subsequent retargeting of a request by the > same SIP entity, > the SIP entity MUST add another branch." > What exactly is "another branch"? RFC 3261 already > talks about creating branches, so why do we need a normative > statement here to tell us to do something that is normatively > specified in RFC 3261? We should only be making normative > statements that are specific to H-I. > > > > [MB] We meant to represent the additional branch by setting > a hi-entry with value incrementing the hi-entry of previous > branch by 1. > > Initial branch =3D 1.1.1 > Second branch =3D 1.1.2 > > I guess we can remove the MUST add and change the following sentence > as follows. > > "The SIP entity MUST calculate and add the hi-index for each > new branch.." > [/MB] > > > > 35. Also in item 3: > "The SIP entity MUST > calculate the hi-index for each new branch by > incrementing the > value from the hi-index in the last hi-entry at > the current > level." > It is unclear what "value" means. I think it is the > value of the rightmost level. > > 36. In item 4: > "That is, the lowest/last > digit of the hi-index MUST be incremented" > Since a value for a particular level within hi-index > can comprise more than one digit, the word "digit" here is > not correct. It is the integer that should be incremented. > > > [MB] It's not an integer. We could say the lowest/last "value".[/MB] > > > 37. In the same sentence: > "MUST be incremented (i.e., a new branch is > created), with the increment of 1" > I think "with the increment of 1" can be deleted. > > 38. In item 5: > "Note that for each individual fork, only the > hi-entry corresponding to that fork is included > (e.g., the hi- > entry for fork 1.1.1 is not included in the > request sent to fork > 1.1.2, and vice-versa)." > I don't think this is true. For example, I receive > hi-entry 1.2, I fork first of all with hi-entry 1.2.1. This > receives a response 4xx, so I then fork again, this time with > hi-entry 1.2.2. I thought in this case hi-entry 1.2.1, as > well as 1.2.2, would be included in the new forwarded > request (since 1.2.1 will be in the cache at this stage). > > > [MB] That just applies to parallel forking. Will change to > "Note, that in the case of parallel forking, only the > hi-entry corresponding to the fork is included in the request.[/MB] > > > 39. "10.4. Mechanism for Target Determination in the > History-Info Header > Field" > Wrong title - the section is to do with indicating how > the target was determined, not with the determination > mechanism itself. Perhaps "10.4 Indicating the mechanism by > which the target was determined..." > > 40. Section 10.4: > " This specification defines two header field > parameters, "rc" and > "mp", indicating two non-inclusive mechanisms by > which a new target > for a request is determined." > I am not sure what "non-inclusive" means here. > > > [MB] Meaning that those are not the only mechanisms by which > a target is determined - this goes back to when we had others > identified and was added when we changed it to not tag each > hi-entry with something. We can just delete the > "non-inclusive". [/MB] [JRE] I would have thought we would use "non-exclusive", i.e., we are not e= xcluding other mechanisms. Anyway, I am happy with deletion. > > > 41. Section 10.4: > "in the case of 3xx responses" > I think this should say "in the case of retargeting to > a contact URI received in a 3xx response". > > 42. Section 10.4: > "If the Contact header field > does not contain an "rc" or "mp" header field > parameter, then the SIP > entity MUST NOT include an "rc" or "mp" in the > hi-entry when the > request is retargeted." > I think this sentence is still talking about the 3xx > case, but it is not clear. Should say: > "....when the request is retargeted to a contact URI > received in a 3xx response". > > 43. Section 10.4: > ""rc": The target was determined based on a contact > that is bound > to an AOR in an abstract location service for the > Request-URI > being retargeted." > This doesn't make it clear that the Request-URI is the > AOR. However, for both this and the "mp" bullet point, we > should perhaps refer to section 5, where those are defined, > rather than reproducing the definition here with the risk of > it being different. > > 44. Section 10.4: > "The mapping was done due to receiving a 3xx response, in which > case the mp-value is an earlier sibling of the > hi-entry's index, > that of the downstream request which received the > 3xx response." > I don't think this is right, since the issuer of the > 3xx will build the rc or mp parameter, and therefore it will > reference the index received by that entity. This could > indeed be a sibling, but it could also be a child of a > sibling, a child of a child of a sibling, and so on. > > > [MB] [JRE] Were you attempting to add a remark here? > > > 45. Section 11: > "Thus, if gaps are detected, > the SIP entity MUST NOT treat this as an error, but > rather indicate > to any applications that there are gaps." > I think changing "rather indicate" to "MUST indicate" > would be clearer, if we do indeed intend it normatively. > > > [MB] This is bascially saying that the SIP entity is the > one that can interpret the information and if there are gaps, > it MUST NOT generate an error but it just needs to provide an > indication to the application that there are gaps. We added > this MUST NOT generate an error based on a comment from > Hadriel a while back. I don't know what we can anticipate by > saying MUST indicate, as we aren't providing a protocol > mechanism for the indication. There being a gap is an > indication that there is a gap and that is that. [JRE] So I would say "should indicate". > > > > 46. Section 11: > "The most complete > information available to the application is the > History-Info entries > starting with the last hi-entry with an index of "1"." > This is not true. The most complete is the complete set > of hi-entries. Even if there are gaps, the information > subsequent to the last gap will not be as complete as the > total information. > > > [MB] We can just strike that sentence [/MB] > > > 47. Section 11: > "The following summarizes the categories of information that > applications can use:" > I thinks these are only examples, rather than a summary > of everything an application could used. Change "summarizes" > to "examples". > > > [MB] I would prefer "describes some categories" [/MB] > > > 48. Section 11, item 2: > "the index that matches the value of the last hi- > entry with ..." > An index cannot match an entire hi-entry. I think this > should say "the index that matches the value of the "rc" > parameter in the last hi- > entry with ..." > A similar correction should be applied to items 3, 4 and 5 too. > > 49. Section 11, item 2: > "rc" header parameter" > I am not sure that "header parameter" is the right way > to describe "rc". It might be more accurate to say "hi-entry > parameter" or, to use the ABNF name, "hi-target-parameter", > or simply "parameter". Whatever is chosen, it needs to be > consistent throughout the document. > A similar correction should be applied to items 3, 4 and 5 too. > > > [MB] "rc" is a header field parameter that is in an hi-entry. [/MB] > > > 50. Section 11, item 2: > "i.e., the Request URI associated with the destination of > the request was determined based on an > AOR-to-contact binding in > an abstract location service." > This is confusing, because the Request-URI changes > during retargeting, and it is not clear to which Request-URI > and to which request we refer. Perhaps it means the final > target, but that is not necessarily true - I am sure there > must be some corner cases where there is a non-"rc" retarget > after the last "rc" retarget. I think all we can say for > certain is something like: "i.e., the last AOR that was > retargeted to a contact based on an AOR-to-contact binding in > an abstract location service." Note that a formulation like > this would better match the style of the formulation in item 3. > > 51. Section 11, item 4: > "thus the > first hi-entry with an "rc" header parameter > within the domain > associated with the target URI at the destination > is more likely > to be useful." > > I think this should say: > > "thus the hi-entry that matches the value of the "rc" > parameter of the first hi-entry with an "rc" parameter within > the domain..." > A similar correction should be applied to item 5 too. > > 52. Section 11: > "hi-entry who index " > Change to: > "hi-entry whose index " > > 53. Section 11: > "matches the index of the first" > > I think this should say: > > "matches value of the "mp" parameter of the first" > > 54. Section 11: > "History-Info entry" > Why not "hi-entry" as elsewhere? > Similarly "History-Info entries" later in sentence. > > 55. Section 11: > "with an hi-target value of "mp" " > Whatever terminology we end up with from comment 49, we > should align here too, e.g., "with an "mp" parameter". > Similarly for "rc" later in sentence. > > 56. Section 11: > "Since support for History-info header field is > optional, a service > MUST define default behavior for requests and responses not > containing History-Info headers." > Change "History-Info headers" to "a History-Info header field". > > 57. Section 11: > "For example, an entity may receive > only partial History-Info entries or entries" > Surely each hi-entry will be a complete entry, but an > entity might receive an incomplete set of hi-entries. Also > correct the terminology. Change to: > "For example, an entity may receive an incomplete set > of hi-entries" > > 58. Section 12: > If an entity forwards a request containing an hi-entry > marked as private to another entity within the same domain, > it expects that other entity to anonymize the hi-entry before > forwarding outside the domain. However, what happens if that > other entity doesn't support H-I? Presumably the RFC 3325 > concept of Trust Domain needs to be extended somehow to > RFC4424bis, such that for an entity to be considered in the > same Trust Domain it must support RFC4424bis. There should be > some discussion around this. See also comment 18. > > > [MB] See response to 18 above. [/MB] [JRE] I really think this is something that should be described in Security= Considerations. John > > > John > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > Sent: 15 March 2011 18:46 > > To: SIPCORE > > > Subject: [sipcore] Fwd: I-D > > ACTION:draft-ietf-sipcore-rfc4244bis-04.txt > > > > Hi folks, > > > > I have updated the document to incorporate the feedback on > > the -03 as follows: > > > > 1) The biggest change was the reformating inline with John's > > suggestion: > > > http://www.ietf.org/mail-archive/web/sipcore/current/msg04010.html > > It is not verbatim, but rather I included some of the past > > text in the relevant sections and I included a bullet list in > > some cases rather than just a paragraph as that was one of > > the formatting changes we made between RFC4244 and 4244bis in > > that the text in paragraph form can be rather dense. I > > believe the spirit and intent of John's proposal has been > > accomodated (I don't know that as many words were saved). > > Also, I just noticed some of the bullet lists don't have the > > "o" - I'll have to fix that. I think one of the most > > important aspects of John's proposal was introducing the > > "caching" of the hi-entries as that wasn't clearly spelled > > out previously and that really did help to clarify the > > processing. I do think the breakdown in the > > sending/receiving of the request and sending/receiving of a > > response into common processing is quite helpful. > > > > 2) Removed the term "escape" with regards to the Privacy and > > Reason header fields and just stated that those header fields > > were included in the hi-targeted-to-uri. I think this also > > improves readbility. > > > > 3) Additional clarification around the Tel-URI. > > > > I think the doc should be ready for another WGLC. > > > > Thanks, > > Mary. > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Tue, Mar 15, 2011 at 1:30 PM > > Subject: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt > > To: i-d-announce@ietf.org > > Cc: sipcore@ietf.org > > > > > > A new Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Session Initiation Protocol > > Core Working Group of the IETF. > > > > Title : An Extension to the Session Initiation > > Protocol (SIP) for Request History Information > > Author(s) : M. Barnes, et al > > Filename : draft-ietf-sipcore-rfc4244bis-04.txt > > Pages : 32 > > Date : 2011-03-15 > > > > This document defines a standard mechanism for > capturing the history > > information associated with a Session Initiation > Protocol (SIP) > > request. This capability enables many enhanced services by > > providing > > the information as to how and why a SIP request arrives at > > a specific > > application or user. This document defines an > optional SIP header > > field, History-Info, for capturing the history > information in > > requests. The document also defines SIP header > field parameters for > > the History-Info and Contact header fields to tag the > > method by which > > the target of a request is determined. In > addition, this document > > defines a value for the Privacy header field specific to > > the History- > > Info header field. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244 > > bis-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant > mail reader > > implementation to automatically retrieve the ASCII > version of the > > Internet-Draft. > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft > > > > aft> directories: http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > >