From shida@ntt-at.com Wed Jul 1 06:00:44 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6B83A6964 for ; Wed, 1 Jul 2009 06:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ4Nkyh8Q88b for ; Wed, 1 Jul 2009 06:00:44 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.44.10]) by core3.amsl.com (Postfix) with SMTP id EC4403A67A8 for ; Wed, 1 Jul 2009 06:00:43 -0700 (PDT) Received: (qmail 11888 invoked from network); 1 Jul 2009 13:03:14 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway14.websitewelcome.com with SMTP; 1 Jul 2009 13:03:14 -0000 Received: from flh1acl028.tky.mesh.ad.jp ([221.170.63.28]:59156 helo=[192.168.1.6]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MLzJV-0000Ra-9t for bliss@ietf.org; Wed, 01 Jul 2009 07:53:25 -0500 Message-Id: <47F3CDC6-F167-4160-8028-99A69D172BD1@ntt-at.com> From: Shida Schubert To: bliss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 21:53:24 +0900 X-Mailer: Apple Mail (2.935.3) 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 Subject: [BLISS] Agenda Requests for IETF 75 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 13:00:44 -0000 All; I'm putting together a first-draft agenda for BLISS at IETF 75. Please send me a note if you want some agenda time. If you feel strongly about spending time on a particular topic, feel free to send me a note about that too. Regards Shida From shida@ntt-at.com Sun Jul 5 21:24:12 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8407328C1A2 for ; Sun, 5 Jul 2009 21:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIA33855QXoX for ; Sun, 5 Jul 2009 21:24:11 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.212.17]) by core3.amsl.com (Postfix) with SMTP id D633028C190 for ; Sun, 5 Jul 2009 21:23:48 -0700 (PDT) Received: (qmail 12245 invoked from network); 6 Jul 2009 04:31:06 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway08.websitewelcome.com with SMTP; 6 Jul 2009 04:31:06 -0000 Received: from flh1acl028.tky.mesh.ad.jp ([221.170.63.28]:49206 helo=[192.168.1.6]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MNfkP-0000nv-Ae; Sun, 05 Jul 2009 23:24:10 -0500 Message-Id: <78C4BAA2-5D0B-4765-9703-949AB8670028@ntt-at.com> From: Shida Schubert To: Alan Johnston In-Reply-To: <4A4A8324.8000902@sipstation.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 6 Jul 2009 13:24:07 +0900 References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <719F9BBB3E7E71428A2D13F3D76C768F01D5BB14@GBNTHT12009MSX.gb002.siemens.net> <4A4A8324.8000902@sipstation.com> X-Mailer: Apple Mail (2.935.3) 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: bliss@ietf.org Subject: Re: [BLISS] Expert Review requests on Shared Line Appearance X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 04:24:12 -0000 Alan; We are going to be talking to ADs this coming Tuesday, I will inquire about the question on the appearance number and extension of alert-info during the call. As for Appendix B, if people are happy with removing the text and example call-flows that's fine. Appendix B is needed during the process to ensure we evaluate pre-existing implementations and options before coming up with best current practice. If we are to remove the entire Appendix B, I would recommend we make a note that pre-existing implementations were indeed evaluated during the process. Regards Shida On Jul 1, 2009, at 6:27 AM, Alan Johnston wrote: > Andy, > > Thanks for this detailed review. See my comments below. > > I also have a few questions for the chairs, which are summarized here: > > 1. How to proceed with Appendix A which defines a new Alert-Info > header field parameter? > 2. Should we remove Appendix B on alternative approaches? > > Thanks, > Alan > > > Hutton, Andrew wrote: >> Hi All, >> >> These are my review comments on draft-ietf-bliss-shared- >> appearances-02. >> >> Overall I think the draft covers most of the requirements but needs >> some >> editorial work to remove some of the unnecessary sections and text. I >> also think that it is necessary to explore some scenarios in more >> detail >> especially the glare conditions. For example in 10.7 (appearance >> pickup) >> what happens if the pickup fails and the already published state >> needs >> to be cancelled. > > If the INVITE with Replaces fails (presumably because the dialog has > gone away or been marked exclusive), then the UQ will need to > PUBLISH again this failure. I agree a call flow showing this would > be useful. This would apply equally well to the INVITE Join case as > well. > >> It is the glare and recover scenarios that make this >> feature so hard to implement and the draft says very little about >> failure scenarios. >> > > Yes, we need to include more failure and race conditions in the call > flows. Your INVITE Replaces suggestion will be included - other > suggestions? > >> The inclusion of the appearance number in the incoming INVITE >> (appendix >> A) is I believe a must have to make this work and should be a >> mandatory >> part of the main specification. >> > > I agree it is also very important. I'd like to hear from the chairs > how we should proceed on this - I doubt that BLISS is chartered to > do a SIP extension such as a header field parameter. Will we need > to discuss this in DISPATCH? If so, it would be good to get started > on this now. > >> My detailed comments are as follows. >> >> >> Section 1 >> >> 3rd Para. >> "Different approaches will be discussed including the use of URI >> parameters....". Can we now remove the discussion on different >> approaches. >> > > This text is currently in Appendix B of the document. I agree it is > not critical to an implementor, however, it is the kind of thing > that BLISS is chartered to do. I'd like to hear the opinions of the > chairs and others on this. I'm fine with either including or > removing Appendix B. > >> 4th Para. >> "...gives this feature its" - Should this be "..its name" ? >> >> > > Yes. > >> Section 3.1 >> "An assistant can make outgoing calls using the identity of either >> the >> executive or their own". This should be removed as making calls with >> the different identities is not part of this feature. >> > > Agreed. > > >> Section 3.2. >> >> Replace "SIP Telephony devices" with "SIP UA's" for consistency with >> other sections. >> > > Agreed. > >> Possibly replace "Another phone can request to be added to an >> appearance >> resulting in a conference call" with "Another phone can request to be >> added joined or bridged in with the existing appearance". Again >> this is >> for consistency with section 3.3. >> > > Yes. > >> Section 4.1. >> >> REQ-4 contains the statement "UAs registering against the group AOR >> should be able to learn about each other and join the appearance >> group". >> I don't think it is a requirement that the UA's "learn about each >> other". >> > > We were trying to say that UAs should not have to be configured with > information about other UAs in the group - I'll restate this > requirement. > >> Section 4.2. >> >> 4th Para. Contains the statement "The next section discusses normal >> SIP >> operations used to implement parts of the shared appearance feature". >> This refers to the bulleted list below which appears to contain many >> statements that I would not include in "normal SIP operations" and >> should be part of the normative section. >> > > You are correct that this should not be described as "normal SIP > operations", so I'll get rid of that. The steps in this list are > already repeated in normative language starting in Section 5.3. > >> Bullet 4 contains the statement "UAs receive a notification from the >> Appearance Agent indicating the appearance number to use in rendering >> the incoming call". I think it is a must that the incoming INVITE >> contains the appearance number otherwise the UA cannot render the >> incoming call until it receives this leading to all kind of race and >> glare conditions. >> > > This bullet should also mention the Alert-Info parameter as well. > If we make it mandatory, we will need to address which one has > precedence over the other, i.e. if Alert-Info says appearance 1 > while the NOTIFY for the same early dialog says appearance 2. I'd > vote for the NOTIFY having precedence. > > >> Bullet 7. What does the UA publish in this scenario? >> > > It is described in Section 5.3: > > A UA wanting to place a call but not have an appearance number > assigned publishes before sending the INVITE without an 'appearance' > element but with the 'shared' event package parameter present. > Perhaps a forward reference to this section would make this clearer. > >> Section 5.2.1. >> The statement "When sent in a notification in state Trying to the >> Appearance Agent" is incorrect because it is actually a publish >> which is >> used. >> > > You are correct. > >> Section 5.2.4 >> >> Replace "convey" with "to convey". >> > > Right. > >> Section 5.3. >> >> 1st Para. "defined in this draft". Please add a reference to the >> section >> that defines this. >> > > I will reference Section 11.1. > >> 3rd Para. "Upon initialization and at regular intervals, the UA >> SHOULD >> subscribe" should replace the statement about regular intervals >> with a >> reference to RFC 3265. >> > > How about: > > Upon initialization, the UA SHOULD subscribe to the dialog event > package of the AOR and refresh the subscription per RFC 3265. > > >> 3rd Para. "or returns a 482 Loop Detected" why is this singled out >> is it >> just one of many possible failure cases. >> > > I thought it was a likely error case. We don't want an > implementation that gets an error at this stage to give up on the > entire shared appearances feature. > > >> 4th Para. "User Agents MUST support sending an INVITE with a Join >> [RFC3911] header field to initiate bridging". Why is this a MUST >> strength requirement it should be optional for the UA to support >> bridging so a MAY would seem to be appropriate. >> > > I'm worried that if we made it less than a MUST, implementors will > just skip it and the resulting feature will be very weak. I think > that only UAs that do line appearance monitoring don't need to > support Join. > > >> 4th Para Note. "Note that the Join operation can be implemented >> outside >> the UA, for example, in a B2BUA. This is why UAs must support >> sending >> Join header fields even if they do not necessarily support receiving >> them". I think this can be removed and as previous comment I don't >> think >> this is a reason for mandating that a UA can initiate bridging. >> > > This is badly worded. What is meant is that a UA can request to be > joined to another call even though it is not necessarily capable of > doing the mixing if another UA requests it. Handling this kind of > asymmetric feature is something we've done very very badly in SIP, > I'm afraid. I'll try to reword this text. > > >> Section 7 (User Interface Considerations). I don't think we need this >> section the purpose of the draft is to promote interoperability >> between >> SA implementations. Those implementing this will be well aware of >> the UI >> considerations that may be different depending on their particular >> type >> of UA. >> > > I think this section is useful. Perhaps it would tie in better if > we had introduced these phones in Section 3.1. What do others think > about this section? > >> Section 8.3. >> >> 1st Para. "This type of UA will be detected by the Appearance Agent >> by >> the absence of the ma event parameter in SUBSCRIBE or PUBLISH >> messages" >> I think the event type is "shared" not "ma" also if the UA does not >> support SA then I assume it will not PUBLISH to the appearance agent. >> >> > > Yes, ma is from an older draft. A non SA UA would not likely > PUBLISH but it may still SUBSCRIBE. > > >> Section 10.1. >> I think the REGISTER from bob needs to be shown. >> > > OK. >> Section 10.2 >> >> 2nd Para. "then the Appearance Agent will need to resolve the >> situation >> by moving either Alice or Bob's dialog to a different appearance". >> This >> is one glare condition that I worry about what would happen if all >> other >> appearances are busy ?. >> > > Hmm. This would imply an upper limit to the number of appearances > in the group. We once had a requirement and scenarios for this but > they were removed as people thought they didn't fit the feature. Of > course, a hard phone with lamps and buttons might run out of button > and lamp positions, but this should be addressed in Section 7. > > >> The diagram seems to imply that the INVITE (F7/F8) is not sent to Bob >> until after the NOTIFY's have been sent but I don't think this is the >> case and it would therefore seem better to move the sending of the >> INVITE to before the NOTIFY (F2/F4). > > Why? The INVITE can not be forwarded with the appearance number > until the appearance agent knows about it and processes it. In > processing the appearance number allocation, I would expect it to > immediately send NOTIFYs - for it to delay would not give a good > user experience for this feature. As such, I prefer showing the > NOTIFYs arrriving first. They are effectively happening in > parallel, although we have no way of showing that on the figure. > Some text perhaps could explain this. > >> >> Section 10.7. >> The PUBLISH (F32) indicating the dialog to be replaced is sent before >> the INVITE/replaces (F38) is this the correct order and if so it >> introduces some glare conditions that we need to explain how to get >> out >> of. >> > > Yes, this order is critical, otherwise the Appearance Agent will > probably reject the INVITE. I agree we should show the case where > the PUBLISH succeeds but the INVITE Replace or Join fails. > >> Section 10.9. >> It is not explained how Bob indicates in the PUBLISH that he does not >> want an appearance number assigned. >> > > How about adding this: > > He indicates this in his PUBLISH F32 by the inclusion of the > 'shared' event parameter with no element. This PUBLISH > is sent before the INVITE to Alice to ensure no appearance number is > assigned by the Appearance Agent. > >> The NOTIFY (F32) contains the dialog identifiers for the dialog with >> alice but since the INVITE (F34) has not yet been generated it is >> likely >> that Bob's UA will not know this information so it cannot be >> included in >> the NOTIFY with state "trying". >> > > This is the same thing we are doing in 10.4 and other places in this > specification. If any dialog information is available, it should be > included in the publish. This is described in Section 5.3: > > Note that when a UA selects an appearance prior to establishment of a > dialog (#1 and #2 in above list), not all dialog information will be > available. In particular, when a UA publishes an attempt to select > an appearance prior to knowing the destination URI, minimal or no > dialog information may be available. For example, in some cases, > only the local target URI for the call will be known and no dialog > information. If no dialog identification information is present in > the initial PUBLISH, the UA MUST PUBLISH again after receiving the > 100 Trying response. > >> Section 12 Appendix A. >> I think this should become part of the main specification and >> included >> in the normative section. >> > > Unless I am mistaken, I don't think that the BLISS WG can do this > work, so we will likely have to spin this off into a separate > document and reference it normatively in this document. > >> Section 13 Appendix B. >> >> I think this should be removed to reduce the size of the document. >> >> > > I am sympathetic to reducing the size. > >> Regards >> Andy >> >> >> >> >> > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss From R.Jesske@telekom.de Mon Jul 6 04:55:31 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909FA28C27F for ; Mon, 6 Jul 2009 04:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, HELO_EQ_DE=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 d2oq29KkZA-t for ; Mon, 6 Jul 2009 04:55:30 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 67EA73A6863 for ; Mon, 6 Jul 2009 04:55:28 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 06 Jul 2009 13:54:57 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 13:54:57 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9FE30.9544F43C" Date: Mon, 6 Jul 2009 13:54:56 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD40498CFC9@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: Acn7EgmFHY5NLHSnTdacRdukHKWXGADHHJngAACB/QA= From: To: X-OriginalArrivalTime: 06 Jul 2009 11:54:57.0466 (UTC) FILETIME=[955E99A0:01C9FE30] Subject: [BLISS] WG: draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 11:55:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FE30.9544F43C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Dear all, > After getting no response to my question from the dispatch. I assume = that there is no interest on this draft within dispatch. >=20 > So now I would like to ask the people from SIPCORE and BILSS where do = they see the work. >=20 > The below mentioned draft describes the use of the Reason Header = within Resoponses for interoperability with the existing PSTN/ISDN = networks. >=20 > Best Regards >=20 > Roland >=20 > _____________________________________________=20 > Von: Jesske, Roland =20 > Gesendet: Donnerstag, 2. Juli 2009 14:39 > An: dispatch@ietf.org > Betreff: draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Dear all, > At the moment I'm preparing a new version of = draft-jesske-sipping-etsi-ngn-reason-04 ( = http://tools.ietf.org/html/draft-jesske-sipping-etsi-ngn-reason-04 ) to = be submitted. > There were some comments which were stating that this is the wrong = group for the draft. > I would like to know what the feeling of the group is to which group = (BLISS, DISPATCH or SIPCORE) this draft should belong. >=20 > Thank you and Best Regards >=20 > Roland >=20 > Deutsche Telekom Netzproduktion GmbH=20 > Zentrum Technik Einf=FChrung=20 > Roland Jesske=20 > Gateways, Protokolle, Konvergenz, TE32-1 > Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,=20 > Postfach, 64307 Darmstadt (Postanschrift)=20 > +496151 628 2766 (Tel) > +491718618445 (Mobile)=20 > E-Mail: r.jesske@telekom.de=20 > http://www.telekom.de =20 >=20 >=20 >=20 > Registerrechtliche Unternehmensangaben:=20 > Deutsche Telekom Netzproduktion GmbH=20 > Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=20 > Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren=20 > Handelsregister: Amtsgericht Bonn HRB 14190=20 > Sitz der Gesellschaft: Bonn=20 > USt-IdNr.: DE 814645262 >=20 >=20 ------_=_NextPart_001_01C9FE30.9544F43C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG: draft-jesske-sipping-etsi-ngn-reason-04

Dear all,
After getting no = response to my question from the dispatch. I assume that there is no = interest on this draft within dispatch.

So now I would like = to ask the people from SIPCORE and BILSS where do they see the = work.

The below mentioned = draft describes the use of the Reason Header within Resoponses for = interoperability with the existing PSTN/ISDN networks.

Best Regards

Roland

_____________________________________________
Von:    Jesske, Roland 
Gesendet:       = Donnerstag, 2. Juli 2009 14:39
An:     dispatch@ietf.org
Betreff:       = draft-jesske-sipping-etsi-ngn-reason-04

Dear all,
At the moment I'm preparing a new = version of draft-jesske-sipping-etsi-ngn-reason-04 ( http://tools.ietf.org/html/draft-jesske-sipping-etsi-ngn-r= eason-04 ) to be = submitted.

There were some comments which were = stating that this is the wrong group for the draft.
I would like to know what the feeling = of the group is to which group (BLISS, DISPATCH or SIPCORE) this draft = should belong.

Thank you and Best Regards

Roland

Deutsche Telekom = Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Roland Jesske
Gateways, Protokolle, Konvergenz, = TE32-1
Heinrich-Hertz-Str. 3-7, 64295 = Darmstadt,
Postfach, 64307 Darmstadt = (Postanschrift)
+496151 628 2766 (Tel)
+491718618445 (Mobile)
E-Mail: r.jesske@telekom.de=20
http://www.telekom.de=20



Registerrechtliche = Unternehmensangaben:=20
Deutsche Telekom Netzproduktion = GmbH
Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)
Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262


------_=_NextPart_001_01C9FE30.9544F43C-- From root@core3.amsl.com Tue Jul 7 03:45:01 2009 Return-Path: X-Original-To: bliss@ietf.org Delivered-To: bliss@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 846C83A6E43; Tue, 7 Jul 2009 03:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090707104501.846C83A6E43@core3.amsl.com> Date: Tue, 7 Jul 2009 03:45:01 -0700 (PDT) Cc: bliss@ietf.org Subject: [BLISS] I-D Action:draft-ietf-bliss-call-park-extension-00.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 10:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. Title : Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP) Author(s) : M. Procter Filename : draft-ietf-bliss-call-park-extension-00.txt Pages : 19 Date : 2009-06-28 Call Park and Call Retrieve are useful telephony services that are familiar to many users. Existing implementations using the Session Initiation Protocol (SIP) show that a variety of approaches can be Taken, with varying degrees of interoperability. This draft discusses a number of feature variations, and how they may be implemented using existing techniques. An additional URI parameter is also described, which enables further common use-cases to be implemented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bliss-call-park-extension-00.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-bliss-call-park-extension-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-07034217.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 13 12:15:02 2009 Return-Path: X-Original-To: bliss@ietf.org Delivered-To: bliss@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 052D23A6A55; Mon, 13 Jul 2009 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713191502.052D23A6A55@core3.amsl.com> Date: Mon, 13 Jul 2009 12:15:02 -0700 (PDT) Cc: bliss@ietf.org Subject: [BLISS] I-D Action:draft-ietf-bliss-call-completion-04.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 19:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. Title : Call Completion for Session Initiation Protocol (SIP) Author(s) : D. Worley, et al. Filename : draft-ietf-bliss-call-completion-04.txt Pages : 28 Date : 2009-07-13 The call completion features allow the calling user of a failed call to be notified when the called user becomes available to receive a call. For the realization of a basic solution without queueing call- completion requests this document references the usage of the the dialog event package [RFC4235] as described as 'automatic redial' in [RFC5359]. For the realization of a more comprehensive solution with queueing call-completion requests this document introduces an architecture for implementing these features in the Session Initiation Protocol: "Call completion" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for call completion into a queue at the callee's endpoint, and, when a caller's request is ready to be serviced, re-attempt the original, failed call. The deployment of a certain SIP call-completion solution is also dependent on the needed level of interoperability with existing call- completion solutions in other networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bliss-call-completion-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-bliss-call-completion-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13120105.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 13 15:15:02 2009 Return-Path: X-Original-To: bliss@ietf.org Delivered-To: bliss@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2695C3A68E0; Mon, 13 Jul 2009 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713221502.2695C3A68E0@core3.amsl.com> Date: Mon, 13 Jul 2009 15:15:02 -0700 (PDT) Cc: bliss@ietf.org Subject: [BLISS] I-D Action:draft-ietf-bliss-shared-appearances-03.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 22:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. Title : Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) Author(s) : A. Johnston, et al. Filename : draft-ietf-bliss-shared-appearances-03.txt Pages : 64 Date : 2009-07-13 This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This document discusses use cases, lists requirements and defines SIP extensions to implement this feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-03.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-bliss-shared-appearances-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13151328.I-D@ietf.org> --NextPart-- From L.Liess@telekom.de Tue Jul 14 06:56:10 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7638A3A6EA3 for ; Tue, 14 Jul 2009 06:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBL8KNrnsX6Q for ; Tue, 14 Jul 2009 06:56:09 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 158F23A6926 for ; Tue, 14 Jul 2009 06:56:08 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 14 Jul 2009 15:55:44 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 15:55:44 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA048A.C7DDC8CA" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 14 Jul 2009 15:55:43 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003300944@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-alexeitsev-bliss-alert-info-urns-02.txt thread-index: AcoD6TE9z8zM1GOAQOa0Bua0Ic9kggAiKD4w From: To: X-OriginalArrivalTime: 14 Jul 2009 13:55:44.0196 (UTC) FILETIME=[C80FD840:01CA048A] Subject: [BLISS] FW: I-D Action:draft-alexeitsev-bliss-alert-info-urns-02.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 13:56:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA048A.C7DDC8CA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi,=20 We submitted a new version of the draft-alexeitsev-bliss-alert-info-urns. Kind regards Laura=20 =20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Monday, July 13, 2009 8:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-alexeitsev-bliss-alert-info-urns-02.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Alert-Info URNs for the Session=20 > Initiation Protocol (SIP) > Author(s) : D. Alexeitsev, et al. > Filename : draft-alexeitsev-bliss-alert-info-urns-02.txt > Pages : 16 > Date : 2009-07-13 >=20 > The Session Initiation Protocol (SIP) supports the capability to > provide a reference to the alternative ringback tone (RBT) for > caller, or ring tone (RT) for callee using the Alert-Info header. > However, the reference addresses only the network resources with > specific rendering properties. There is currently no support for > predefined standard identifiers for ringback tones or semantic > indications without tied rendering. To overcome this limitations and > support new applications a family of the URNs is defined in this > specification. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-alexeitsev-bliss-ale > rt-info-urns-02.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 ------_=_NextPart_001_01CA048A.C7DDC8CA Content-Type: application/octet-stream; name="draft-alexeitsev-bliss-alert-info-urns-02.URL" Content-Transfer-Encoding: base64 Content-Description: draft-alexeitsev-bliss-alert-info-urns-02.URL Content-Disposition: attachment; filename="draft-alexeitsev-bliss-alert-info-urns-02.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1hbGV4ZWl0c2V2LWJsaXNzLWFsZXJ0LWluZm8tdXJucy0wMi50eHQNCg== ------_=_NextPart_001_01CA048A.C7DDC8CA Content-Type: text/plain; name="ATT53982.txt" Content-Transfer-Encoding: base64 Content-Description: ATT53982.txt Content-Disposition: attachment; filename="ATT53982.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01CA048A.C7DDC8CA-- From alan@sipstation.com Tue Jul 14 07:48:25 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8F128C117 for ; Tue, 14 Jul 2009 07:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 7SRDtLop7XHD for ; Tue, 14 Jul 2009 07:48:24 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 91ED73A6E7C for ; Tue, 14 Jul 2009 07:48:24 -0700 (PDT) Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MQjII-000KXU-GE for bliss@ietf.org; Tue, 14 Jul 2009 14:47:46 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.193.18 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+ykX9b0tOBDF95itn2MZR0/m1BlktU/mY= Message-ID: <4A5C9A8F.6000907@sipstation.com> Date: Tue, 14 Jul 2009 09:47:43 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: bliss@ietf.org References: <20090713221502.2695C3A68E0@core3.amsl.com> In-Reply-To: <20090713221502.2695C3A68E0@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BLISS] I-D Action:draft-ietf-bliss-shared-appearances-03.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 14:48:25 -0000 All, I have revised the draft based the three reviews received. There are four open issues in the draft - if we can close them, I think it is ready for WGLC. They are: Section 5.3: "Upon initialization, the UA SHOULD subscribe to the dialog event package of the AOR and refresh the subscription per RFC 3265. If the SUBSCRIBE request fails, loops back to itself, or returns a 482 Loop Detected, then no Appearance Agent is present and this feature is not active for this AOR. The UA MAY periodically retry the subscription to see if conditions have changed. OPEN ISSUE: Do we need to specifically call out the 482 response, or is just saying if the request fails or loops, to give up?" and "User Agents SHOULD support sending and receiving an INVITE with a Replaces [RFC3891] header to allow the Call Pickup operation. User Agents SHOULD support sending an INVITE with a Join [RFC3911] header field to initiate bridging. UAs SHOULD either support receiving a Join header field or be configured to use a conference server or B2BUA which supports the Join header field. OPEN ISSUE: Replaces and Join support is a SHOULD. This means that taking and bridging/joining calls could fail if the UA does not support them. Can we make these a MUST so that we can avoid these failures?" Section 7.1.3 "This UA is the typical 'business-class' hard-phone. A number of appearances are typically configured statically and labeled on buttons, and calls may be managed using these configured appearances. Any calls outside this range should be ignored, and not mapped to a free button. Users of these devices often select/seize specific appearance numbers for outgoing calls, and the UA will need to select/seize the appearance number and wait for confirmation from the Appearance Agent before proceeding with calls. OPEN ISSUE: We currently have no upper limit on the appearance number in the specification. Do we need a way for an Appearance Agent to indicate to a UA that no more appearances are available?" Section 10.13 "In this scenario, the Appearance Agent does not have any way of knowing Bob's dialog state information, except through Bob. This could be because the Appearance Agent is not part of a B2BUA, or perhaps Bob is remotely registering. When Bob registers, the Appearance Agent receives a registration event package notification from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's dialog event state. Whenever Bob's dialog state changes, a NOTIFY is sent to the Appearance Agent who then notifies the other other UAs in the group. OPEN ISSUE: Does Bob PUBLISH to select/seize an appearance, or does he just NOTIFY the Appearance Agent?" Comments on the document and these open issues are most welcome. Thanks, Alan Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. > > > Title : Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) > Author(s) : A. Johnston, et al. > Filename : draft-ietf-bliss-shared-appearances-03.txt > Pages : 64 > Date : 2009-07-13 > > This document describes the requirements and implementation of a > group telephony feature commonly known as Bridged Line Appearance > (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line > Appearance (SCA). When implemented using the Session Initiation > Protocol (SIP), it is referred to as shared appearances of an Address > of Record (AOR) since SIP does not have the concept of lines. This > feature is commonly offered in IP Centrex services and IP-PBX > offerings and is likely to be implemented on SIP IP telephones and > SIP feature servers used in a business environment. This document > discusses use cases, lists requirements and defines SIP extensions to > implement this feature. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-03.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. > > ------------------------------------------------------------------------ > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss > From alan@sipstation.com Tue Jul 14 08:04:37 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FB928C21C for ; Tue, 14 Jul 2009 08:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 ALtP-b6wdQlO for ; Tue, 14 Jul 2009 08:04:35 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id D732B28C284 for ; Tue, 14 Jul 2009 08:04:32 -0700 (PDT) Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MQjYG-0000iz-Lh; Tue, 14 Jul 2009 15:04:17 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.193.18 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/W2aDTovBDoefpy4pGceVLuE3FZZsaulQ= Message-ID: <4A5C9E6E.6030001@sipstation.com> Date: Tue, 14 Jul 2009 10:04:14 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bliss@ietf.org Subject: Re: [BLISS] Expert Review requests on Shared Line Appearance X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 15:04:37 -0000 Francois, Thanks for the review - I somehow lost track of it. I think I have addressed nearly all of your comments in the latest revision. See my comments below. Thanks, Alan Francois Audet wrote: > This is my expert review on draft-ietf-bliss-shared-appearances-02. > > Overall, document is in good shape and has no major issue. It would benefit > from removing a lot of the "historical" or "discussion" material that is > not relevant anymore. > > Also, I make some recommendation on how to make the Call flow examples clearer. > > This review also highlights the need for up-issuing draft-alexeitsev-bliss-alert-infor-urns > (which is also needed by external standards bodies). > > --------------------- > > > Section 1: > > 4th paragraph. > NIT: incomplete sentence "...what gives this feature its.". > NIT: s/lamp that can change color or blink/e.g.. a lamp that can change color or blink, or > an screen icon > Done. > > Section 4.2: > > p. 9, 2nd full paragraph: s/not discussed in this draft but instead is left as a > research project for future standardization/outside the scope of this draft > Done. > p. 10, bullet 5: Reword as follows: > 5. For outgoing calls, the operation depends on the implementation. > If line seizing is supported, the UA publishes this information and > waits for a 200 OK before sending the INVITE. > (In other words, some implentations may allow for the user to "select" the appearance > by pressing the button, but not seize the line. For that same reason, I'm changing "select" > to "seize" in a few places in the document). > I changed "select" to "select/seize" globally in the document. I'm not sure it helps readability, but I think we need both terms. > > Section 5.3: > > p. 13, bullet 1: Reword as follows (this is same as previous point): > > 1. When the user selects a particular appearance number for an outgoing > and wishes to seize the apperance and appearing "off-hook" (if the UA's > user interface uses this methaphor). > Done. > 2nd paragraph after numbered items: s/UA selects/UA seizes > > This section needs to describe that either a PUBLISH model or a SUBSCRIBE model can > be used for the state/appearance information to be sent to the Appearance Agent. > Currently, it appears written for the PUBLISH model only. The SUBSCRIBE model, as > illustrated in section 10.13, is very useful for cases where the Appearance Agent > is a stand-alone UA that does not share state/appearance information with the > Proxy/B2BUA. This section also needs to describe that when the SUBSCRIBE model is used, > the NOTIFY message is sent to "seize" a line (there is no need for a PUBLISH in this case). > (I'm assuming I'm right: let's discuss if not). > Good catch. The draft is silent on this right now, so I've marked it as an open issue. One one hand, I'd prefer to have only one mechanism (PUBLISH) for selection/seizure. On the other hand, if the Appearance Agent has subscribed, and the UA is sending NOTIFYs, it hardly makes sense to mix PUBLISH into it. > > > Section 8: > > Remove Editor's note. > Done. > > Section 9: > > Delete first paragraph. > > Clarify the UA also REGISTERs to the AOR. Discuss the security implications, i.e., > you either use the same shared username/password, or you use a different username/password > for HTTP digest, per user. Perhaps the security considerations can be described in section 15. > > I added text about authorization for third party registrations and publication. A little more text on this would be helpful. > Section 10: > > General: > > The call flows are confusing because Alice is both the end user AOR, as well as the > shared apperance AOR. This makes it very difficult to follow the call flows. > > I would like all the call flows to use Alice and Bob as the Endpoint, and the shared > AOR to be, say, sharedline@example.com (or something similar). See below for details. > I agree 100%. I have changed the shared AOR to be sip:HelpDesk@example.com and I think this makes things clearer. We need to make sure I've made all the correct substitutions in the call flows. > > Section 10.1: > > p. 22, 2nd paragraph: delete "or Appearance Agent" at end of paragraph. > Actually, this is correct, as I am talking about registrations refresh with the Registrar and subscription refresh with the Appearance Agent. Here's the sentence: "Also note that registrations and subscriptions must all be refreshed by Alice at intervals determined by the expiration intervals returned by the Registrar or Appearance Agent." Maybe it should say Registrar and Appearance Agent? > Figure 1 and Call Flow: I would like to also see Bob's registration, to > illustrate the idea that Alice and Bob share the same AOR for both > registration and subscription. > Done. > Something like this: > > Registrar Appearance Agent Alice Bob > | | | | > | | | | > |<--------------------------- REGISTER F1<| | > | | | | > |>F2 200 OK ----------------------------->| | > | | | | > | |<----- SUBSCRIBE F3<| | > | | | | > | |>F4 202 Accepted -->| | > | | | | > | |>F5 NOTIFY -------->| | > | | | | > | |<-------- 200 OK F6<| | > | | | | > |<--------------------------- REGISTER F7---------------<| > | | | | > |>F8 200 OK -------------------------------------------->| > | | | | > | |<----- SUBSCRIBE F9---------------<| > | | | | > | |>---------F10 202 Accepted ------->| > | | | | > | |>--------F11 NOTIFY -------------->| > | | | | > | |<-------- 200 OK F12--------------<| > > The, in the call flows, all the To headers for REGISTER > and SUBSCRIBE are instead of > . > > I REALLY think this will make the spec much more readable. > > Question: Why is "202" used for responding to SUBSCRIBE instead of "200"? If > 202 is used, I think it deserves an explanation in the document. > Isn't 202 commonly immediately returned, and then the NOTIFY confirms the subscription state (i.e. active instead of pending)? I can change it to 200 if this is more common behavior. > > Section 10.2 > > Again, all the AOR in "To" headers should be > (e.g., F7 & F8). This will help reader's understanding. > > Alert-Info in F7 should not use a example. > Preferably, we need to use a urn, like in draft-alexeitsev-bliss-alert-infor-urns. > For example: > Alert-Info: ;alert=normal;appearances=1 > This is done as well, thanks to Laura for being the editor of this draft! > > Section 10.3 > > In first paragraph, s/selecting/seizing. > > It would be useful to show the content of the NOTIFY messages going to Alice > (e.g., F4). > Done. > I'm a bit confused by this example. It shows Bob making a call NOT using an > appearance (i.e., From: Bob instead of From: sharedline). And then both Alice > and Bob are notified of Bob's state instead of the sharedline? Why is that > a shared appearance scenario??? > Good catch! This was a mistake - it now uses the shared AOR. > > Section 10.4 > > Title: s/Pre-Selection/Seizing > > Again, use sip:sharedline@example.com when appropriate. > It would be nice to see the content of message 7. > Done. > > Section 10.5 > > Again, use sip:sharedline@example.com when appropriate. > It would be nice to see the content of message 7. > > It is the same as the previous message F7 - I put in a note saying that. > Section 10.7 > > Are messages F32-F35 necessary when line seizing is NOT used? > I think the answer is "no, they would not be used if there is no > line seizing". If so, I'd like to see a note explaining it. > They are necessary for the Replaces and Join cases. I added this text: "Alice must PUBLISH F32 to indicate that the INVITE F38 will be an attempt to pickup the dialog between Carol and Bob, and hence may use the same appearance number." > > Section 10.9 > > Are messages F32-F33 necessary when line seizing is NOT used? > I think the answer is "no, they would not be used if there is no > line seizing". If so, I'd like to see a note explaining it. > Again, they are necessary (this flow is now 10.10). > > Section 10.10 > > Are messages F22-F23 necessary when line seizing is NOT used? > I think the answer is "no, they would not be used if there is no > line seizing". If so, I'd like to see a note explaining it. > > > Section 10.13 > > If the Appearance Agent subscribes to Bob's dialog-event package (as > in this example), is the expectation that Bob would never really use > PUBLISH, and rather, would always use NOTIFY? I am assuming that the > answer is yes. > We do need to resolve this and document the right answer. > I am also assuming that it would even be the case for the line > seizing mechanism. Is this correct? > > If this is the case, it would be useful to section 10 (before the > individual call flows) that all the sections expect 1.13 use a model > where the Appearance agent does NOT use a subscription model, but a > publish model instead. And then add a note that if a subscription model > was used instead, there would be NOTIFYs instead of PUBLISHes, as per > section 10.13. > OK, I meant to include this text but left it out. I think it is a good idea. > > Section 11.1 > > First line: delete "also". > Done. > > Section 12 Appendix A > > This whole section should not be an Appendix and should be moved to the core > document; it seems this section is necessary for REQ-9. > > Alert-Info should not use a example. > Preferably, we need to use a urn, like in draft-alexeitsev-bliss-alert-infor-urns. > For example: > Alert-Info: ;alert=normal;appearances=1 > > (I think that "tone" one is the default, so we can get rid of the OPEN issue. > Need to add draft-alexeitsev-bliss-alert-infor-urns to References. Also need > to up-issue that draft and move it forward). > Right, done. > > Section 13: Appendix B > > I think it is time to remove this whole Appendix B. This whole section was useful > reference when we were discussing various options, but now, it is totally out of > place since the choices have been made. > > Done. > Section 15: Security Considerations > > See comment on section 9. > > From AUDET@nortel.com Tue Jul 14 13:47:43 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314483A6A60 for ; Tue, 14 Jul 2009 13:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 AmIfn+KFj4aS for ; Tue, 14 Jul 2009 13:47:42 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 457D63A6A3F for ; Tue, 14 Jul 2009 13:47:42 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6EKiYk04799; Tue, 14 Jul 2009 20:44:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2009 15:45:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA1716@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5C9E6E.6030001@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Expert Review requests on Shared Line Appearance thread-index: AcoElF38JzjscuxfTa2jLS1ru6gFAwAL4mMA References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> From: "Francois Audet" To: "Alan Johnston" Cc: bliss@ietf.org Subject: Re: [BLISS] Expert Review requests on Shared Line Appearance X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 20:47:43 -0000 Thanks Alan. Looks good. Since the vast majority of my comments are addressed by this new draft, I'll do individual replies for the ones requiring more discussion/ clarification. Cheers. > -----Original Message----- > From: Alan Johnston [mailto:alan@sipstation.com]=20 > Sent: Tuesday, July 14, 2009 08:04 > To: Audet, Francois (SC100:3055) > Cc: bliss@ietf.org > Subject: Re: Expert Review requests on Shared Line Appearance >=20 > Francois, >=20 > Thanks for the review - I somehow lost track of it. I think=20 > I have addressed nearly all of your comments in the latest=20 > revision. See my comments below. >=20 > Thanks, > Alan From AUDET@nortel.com Tue Jul 14 14:33:15 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5DC3A69CE for ; Tue, 14 Jul 2009 14:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 cH9DlpUVDg0O for ; Tue, 14 Jul 2009 14:33:14 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 7D7093A6852 for ; Tue, 14 Jul 2009 14:33:14 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6ELSCJ22538; Tue, 14 Jul 2009 21:28:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2009 16:27:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA1837@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5C9E6E.6030001@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-bliss-shared-appearances: Seize vs Select thread-index: AcoElF38JzjscuxfTa2jLS1ru6gFAwAMArnA References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> From: "Francois Audet" To: "Alan Johnston" Cc: bliss@ietf.org Subject: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 21:33:15 -0000 > I changed "select" to "select/seize" globally in the=20 > document. I'm not sure it helps readability, but I think we=20 > need both terms. Here is an explanation what I meant with "seize" versus "select". I might have been using a definition of "selection" that is different from what you had in mind. In my mind, I was equating "seizing" with the concept of actually reserving the AOR for ones self by PUBLISHing (or NOTIFYing) the Appearance agent of the call state "premptively". In contrast, I was using the term "selection" to mean the local action (on the phone) of choosing which "line" to use (i.e., the "From" header). This is local because it does not require any publication of state to the appearance agent. The user presses a line key, no signalling comes out immediately (and user probably hears dial tone). When the call is eventually made, it uses that=20 line that was "selected" as the originator (i.e., the From header). I am proposing that if we use these definitions, then it makes it much clearer throughout the document what we are talking about. There are lots of cases where we mean "selection or seizing" (because the PUBLISH/ SUBSCRIBE is optional), and in other cases, we really mean the "seizing". So, for example, in 10.4, messages F1-F2 are actually a "seizing", not=20 merely a "selection". Anyways, just think about it.=20 I think there are people who would want to implement the "line seizure"=20 concept, and people who would NOT want to implement it. If it's clear what "seizure" means, then it makes it obvious in the text what is the optional part. From AUDET@nortel.com Tue Jul 14 15:08:03 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDF43A694F for ; Tue, 14 Jul 2009 15:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 9aleLGEz25JN for ; Tue, 14 Jul 2009 15:08:02 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A13983A682E for ; Tue, 14 Jul 2009 15:08:02 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6ELUik13207; Tue, 14 Jul 2009 21:30:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2009 16:32:21 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA184D@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5C9E6E.6030001@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-bliss-shared-appearance: Call state update in SUBSCRIBE mode thread-index: AcoElF38JzjscuxfTa2jLS1ru6gFAwANZIIQ References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> From: "Francois Audet" To: "Alan Johnston" Cc: bliss@ietf.org Subject: [BLISS] draft-bliss-shared-appearance: Call state update in SUBSCRIBE mode X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 22:08:03 -0000 =20 > Good catch. The draft is silent on this right now, so I've=20 > marked it as=20 > an open issue. One one hand, I'd prefer to have only one mechanism=20 > (PUBLISH) for selection/seizure. On the other hand, if the=20 > Appearance=20 > Agent has subscribed, and the UA is sending NOTIFYs, it hardly makes=20 > sense to mix PUBLISH into it. I believe the approach of using SUBSCRIBE instead of PUBLISH in this = case makes much more sense. From AUDET@nortel.com Tue Jul 14 15:29:58 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26063A6A1D for ; Tue, 14 Jul 2009 15:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 AKptp5PbxxBd for ; Tue, 14 Jul 2009 15:29:57 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id CD3BD3A69F4 for ; Tue, 14 Jul 2009 15:29:56 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6EMSEk19927; Tue, 14 Jul 2009 22:28:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2009 17:29:30 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA1950@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5C9E6E.6030001@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-bliss-shared-appearances: Provisioning considerations thread-index: AcoElF38JzjscuxfTa2jLS1ru6gFAwANkNXQ References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> From: "Francois Audet" To: "Alan Johnston" Cc: bliss@ietf.org Subject: [BLISS] draft-ietf-bliss-shared-appearances: Provisioning considerations X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 22:29:58 -0000 > > Section 9: > > > > Delete first paragraph. > > > > Clarify the UA also REGISTERs to the AOR. Discuss the=20 > security implications, i.e., > > you either use the same shared username/password, or you=20 > use a different username/password > > for HTTP digest, per user. Perhaps the security=20 > considerations can be described in section 15. > > > > =20 >=20 > I added text about authorization for third party registrations and=20 > publication. A little more text on this would be helpful. Ah-ah... Now we are getting down to business. I am now looking at new section 10.1 on registration, and I see that you are using indeed third-party registration (with To=3DHelpDesk,=20 From=3DAlice). So, this would be one way to to it. Another way would be to NOT use third-party registration at all. In=20 other words, Alice would send a first party registration on behalf of HelpDesk (ie.., To=3DHelpDesk, From=3DAlice). Wouldn't that work? Then there is the whole issue of authentication with HTTP-Digest. I guess one could use username=3D"HelpDesk". In this case, the idea is = that Alice would need to know the credentials for HelpDesk.=20 Another way would be to use username=3D"alice" instead (i.e., her own = credentials). The decisions on which authentication you use would depend on need of = the=20 administrator. Have you tought about this? Am I off based? From AUDET@nortel.com Tue Jul 14 16:17:56 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E773C3A68F3 for ; Tue, 14 Jul 2009 16:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 XKpvAJKC7LEU for ; Tue, 14 Jul 2009 16:17:56 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id CB6473A6898 for ; Tue, 14 Jul 2009 16:17:55 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6ENFQk24546; Tue, 14 Jul 2009 23:15:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2009 18:16:17 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA19BE@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5C9E6E.6030001@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-bliss-shared-appearances: Final Nits thread-index: AcoElF38JzjscuxfTa2jLS1ru6gFAwAPqziw References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> From: "Francois Audet" To: "Alan Johnston" Cc: bliss@ietf.org Subject: [BLISS] draft-ietf-bliss-shared-appearances: Final Nits X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 23:17:57 -0000 Ok, these are the final nits.=20 --------------------- > > Section 10.1: > > > > p. 22, 2nd paragraph: delete "or Appearance Agent" at end=20 > of paragraph. > > =20 >=20 > Actually, this is correct, as I am talking about=20 > registrations refresh=20 > with the Registrar and subscription refresh with the=20 > Appearance Agent. =20 > Here's the sentence: >=20 > "Also note that registrations and subscriptions must all be refreshed > by Alice at intervals determined by the expiration=20 > intervals returned > by the Registrar or Appearance Agent." >=20 > Maybe it should say Registrar and Appearance Agent? Ah, I get it now. What about this: Also note that both registrations and subscriptions must all be=20 refreshed by Alice at intervals determined by the expiration=20 intervals returned respectively by the Registrar and the=20 Appearance Agent. --------------------- > > Question: Why is "202" used for responding to SUBSCRIBE=20 > instead of "200"? If > > 202 is used, I think it deserves an explanation in the document. > > =20 >=20 > Isn't 202 commonly immediately returned, and then the NOTIFY confirms=20 > the subscription state (i.e. active instead of pending)? I=20 > can change=20 Not exactly. >From 3265: A 200 response indicates that the subscription has been accepted=20 and that the user is authorized to subscribe to the requested=20 resource. A 202 response merely indicates that the subscription=20 has been understood, and that authorization may or may not have=20 been granted. Now, in draft-roach-sipcore-rfc3265bis-00 Appendix B, I see this: B.2. Remove 202 Response Code? In practice, the 202 response code defined in RFC 3265 has proven to be nearly useless, due to its redundancy with the "pending" state, and its interaction with the HERFP problem. Given that 202 must be treated as 200 if an implementation does not understand it: would removing the 202 response code cause any issues for current implementations? I know it's not a done deal yet (this is not even a WG document), but unless you see a really good reason why this spec would use 202 instead=20 of 200 in the examples, I'd rather we play it safe and use 200... ------------- Section 10 Add note after first paragraph: Note: All the examples in this section, except Section 10.13, show a model where the Appearance Agent has access to dialog state = information and therefore does not explicitly subscribe to the dialog-event = package. All these examples would be different if an explicit subscription was = used instead. For simplicity, only one example of subscription is shown (see Section 13): but the same idea could be applied throughout all the = examples. Or something like that. You get the idea. What I found is that if you are designing your implementation using the = subscription model, then it takes a while to figure out that the spec is still = applicable to you. And section 10.13 is burried quite deep at the end. =09 From andrew.hutton@siemens-enterprise.com Wed Jul 15 01:00:23 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3FCA3A6B12 for ; Wed, 15 Jul 2009 01:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tutaaEwEYVg1 for ; Wed, 15 Jul 2009 01:00:23 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id E80733A6AD4 for ; Wed, 15 Jul 2009 01:00:22 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMT0090JCOA76@siemenscomms.co.uk> for bliss@ietf.org; Wed, 15 Jul 2009 08:55:22 +0100 (BST) Date: Wed, 15 Jul 2009 08:55:22 +0100 From: "Hutton, Andrew" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1EFA1837@zrc2hxm0.corp.nortel.com> To: Francois Audet , Alan Johnston Message-id: <719F9BBB3E7E71428A2D13F3D76C768F01E11835@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select Thread-Index: AcoElF38JzjscuxfTa2jLS1ru6gFAwAMArnAABcP9gA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1837@zrc2hxm0.corp.nortel.com> Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 08:00:24 -0000 Hi, If "select" is a local action in the UA to choose a "line" to use and this determines the what is in the from header then this is I believe out of scope for this draft which should not mention selecting lines or AOR's as this is a different feature. The SA draft is limited to sharing appearances of the same AOR. Also if "select" is a local action at the UA that is just UI behaviour then probably no need to mention it at all. Regards Andy =20 >-----Original Message----- >From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 >On Behalf Of Francois Audet >Sent: 14 July 2009 22:28 >To: Alan Johnston >Cc: bliss@ietf.org >Subject: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select > > >> I changed "select" to "select/seize" globally in the=20 >> document. I'm not sure it helps readability, but I think we=20 >> need both terms. > >Here is an explanation what I meant with "seize" versus "select". >I might have been using a definition of "selection" that is different >from what you had in mind. > >In my mind, I was equating "seizing" with the concept of actually >reserving the AOR for ones self by PUBLISHing (or NOTIFYing) the >Appearance agent of the call state "premptively". > >In contrast, I was using the term "selection" to mean the local >action (on the phone) of choosing which "line" to use (i.e., the >"From" header). This is local because it does not require any >publication of state to the appearance agent. The user presses >a line key, no signalling comes out immediately (and user probably >hears dial tone). When the call is eventually made, it uses that=20 >line that was "selected" as the originator (i.e., the From header). > >I am proposing that if we use these definitions, then it makes it much >clearer throughout the document what we are talking about. There are >lots of cases where we mean "selection or seizing" (because=20 >the PUBLISH/ >SUBSCRIBE is optional), and in other cases, we really mean the >"seizing". > >So, for example, in 10.4, messages F1-F2 are actually a "seizing", not=20 >merely a "selection". > >Anyways, just think about it.=20 > >I think there are people who would want to implement the "line=20 >seizure"=20 >concept, and people who would NOT want to implement it. If it's clear >what "seizure" means, then it makes it obvious in the text what is the >optional part. >_______________________________________________ >BLISS mailing list >BLISS@ietf.org >https://www.ietf.org/mailman/listinfo/bliss > From andrew.hutton@siemens-enterprise.com Wed Jul 15 03:54:44 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645BD3A6BE1 for ; Wed, 15 Jul 2009 03:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5PQF2pcez6R for ; Wed, 15 Jul 2009 03:54:43 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 4811E3A6B25 for ; Wed, 15 Jul 2009 03:54:41 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMT00K02KY080@siemenscomms.co.uk> for bliss@ietf.org; Wed, 15 Jul 2009 11:54:00 +0100 (BST) Date: Wed, 15 Jul 2009 11:53:57 +0100 From: "Hutton, Andrew" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1EFA1950@zrc2hxm0.corp.nortel.com> To: Francois Audet , Alan Johnston Message-id: <719F9BBB3E7E71428A2D13F3D76C768F01E4D90B@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations Thread-Index: AcoElF38JzjscuxfTa2jLS1ru6gFAwANkNXQABuI/5A= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1950@zrc2hxm0.corp.nortel.com> Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 10:54:44 -0000 Indeed this getting interesting. In version -02 the REGISTER in section 10.1 showed a normal 1st party registration by alice but -03 shows a third party registration which is a significant change. I must admit I missed the text in -02 which stated "Bob and Alice are in an appearance group identified by Alice's AOR. Bob REGISTERs using contact sip:bob@ua2.example.com" and I should have commented on that earlier. As the draft is about sharing appearances of a single AOR then surely third party registration is not necessary as it could be that there is simply two helpdesk phones using a single AOR and there is no "alice" or "bob" AOR's. So in the simplest case the REGISTER would be: REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=3Dz9hG4bK527b54da8ACC7B09 From: ;tag=3DCDF9A668-909E2BDD To: CSeq: 2 REGISTER Call-ID: d3281184-518783de-cc23d6bb Contact: Regards Andy =20 >-----Original Message----- >From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 >On Behalf Of Francois Audet >Sent: 14 July 2009 23:30 >To: Alan Johnston >Cc: bliss@ietf.org >Subject: [BLISS] draft-ietf-bliss-shared-appearances:=20 >Provisioningconsiderations > > >> > Section 9: >> > >> > Delete first paragraph. >> > >> > Clarify the UA also REGISTERs to the AOR. Discuss the=20 >> security implications, i.e., >> > you either use the same shared username/password, or you=20 >> use a different username/password >> > for HTTP digest, per user. Perhaps the security=20 >> considerations can be described in section 15. >> > >> > =20 >>=20 >> I added text about authorization for third party registrations and=20 >> publication. A little more text on this would be helpful. > >Ah-ah... Now we are getting down to business. > >I am now looking at new section 10.1 on registration, and I see that >you are using indeed third-party registration (with To=3DHelpDesk,=20 >From=3DAlice). > >So, this would be one way to to it. > >Another way would be to NOT use third-party registration at all. In=20 >other words, Alice would send a first party registration on behalf >of HelpDesk (ie.., To=3DHelpDesk, From=3DAlice). > >Wouldn't that work? > >Then there is the whole issue of authentication with HTTP-Digest. >I guess one could use username=3D"HelpDesk". In this case, the=20 >idea is that >Alice would need to know the credentials for HelpDesk.=20 >Another way would be to use username=3D"alice" instead (i.e.,=20 >her own credentials). >The decisions on which authentication you use would depend on=20 >need of the=20 >administrator. > >Have you tought about this? Am I off based? >_______________________________________________ >BLISS mailing list >BLISS@ietf.org >https://www.ietf.org/mailman/listinfo/bliss > From sgarg@cedarpointcom.com Wed Jul 15 07:08:34 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC91B3A6AAB for ; Wed, 15 Jul 2009 07:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7Vc2HEh4vQS for ; Wed, 15 Jul 2009 07:08:34 -0700 (PDT) Received: from web65616.mail.ac4.yahoo.com (web65616.mail.ac4.yahoo.com [76.13.9.84]) by core3.amsl.com (Postfix) with SMTP id CD7723A68AB for ; Wed, 15 Jul 2009 07:08:33 -0700 (PDT) Received: (qmail 2534 invoked by uid 60001); 15 Jul 2009 14:07:49 -0000 Message-ID: <108654.2415.qm@web65616.mail.ac4.yahoo.com> X-YMail-OSG: eC4Ow8kVM1kPlssxDSX7fjDXrfKBFPhJvMcc.hyFIzAJnyfQDYB0reTpsfad_gRgksbymC.pGrY.bR_eN_5xS.fILmkXvWQOYCz3MWJ7n69hmKruIMice_2lXqMEiXS8sWyeXG5P74tPqmZ8xtWIb9pS9nZSBFAbDhMl_T9TizZEuKqAn.dH9c15QS.2A8YyT2tc.S1GwlF_0MW3G5X2bEhr3DQp_BgH6yXYBzaGyOeLnzTorFXlKq4ecYPzfLPnjsdNG0iQmLpI53oKRdCj08l2n7xVplCgbegkzsc- Received: from [67.151.79.74] by web65616.mail.ac4.yahoo.com via HTTP; Wed, 15 Jul 2009 07:07:48 PDT X-RocketYMMF: emailsumitgarg X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Wed, 15 Jul 2009 07:07:48 -0700 (PDT) From: Sumit Garg To: bliss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [BLISS] draft-ietf-bliss-shared-appearances X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sgarg@cedarpointcom.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 14:08:34 -0000 I prefer 3PCC registrations as makes it easier for somebody with admin privileges to add/remove another user to the shared line without having to change the credentials for everybody at removal of user... Even though it looks complex..in practice it is simpler.. Forever, Sumit "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From vvenkatar@gmail.com Wed Jul 15 08:46:44 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6C33A6B2D for ; Wed, 15 Jul 2009 08:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dHfMDHEnwMp for ; Wed, 15 Jul 2009 08:46:43 -0700 (PDT) Received: from mail-vw0-f184.google.com (mail-vw0-f184.google.com [209.85.212.184]) by core3.amsl.com (Postfix) with ESMTP id 5D0F33A69B2 for ; Wed, 15 Jul 2009 08:46:43 -0700 (PDT) Received: by vwj14 with SMTP id 14so3586647vwj.29 for ; Wed, 15 Jul 2009 08:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Dv68joUVlPwov4XE26bwEjcFGpjAYoHx02DaDmhiaYk=; b=nvaOiSUhUlP/DvBiIesfs/0AAE4EoqdgI5pL4lk0IgKI8CDfo/HVFCGzVNjBS9wtYl LgKiXP+PFBZq9GB+0OMm9voE40phTWUGPVzihzJT/T8SGH7exHaHgq3o+7R06kO/xpuc dPdTgfRDjjeXLHo5fHUx/ztt9HD68qIQ/02XQ= 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=oZk9EGTX8oQLFKUh1RCSe3mYmsQ4R7dfYvmdh24CDs7mSsLZ2j0QiREUfXZkFKRV+Y Vt/+zkXpPuj2Kd2wQgXQYcqBAYKkUSPh0ZQzGWwYLgTCspcvTvkWY3KEciJv79tErMxT pJhwfjKUdCBCKvThFUuvhose7teXwtCLnXNKc= MIME-Version: 1.0 Received: by 10.150.50.16 with SMTP id x16mr12804306ybx.246.1247672733166; Wed, 15 Jul 2009 08:45:33 -0700 (PDT) In-Reply-To: <719F9BBB3E7E71428A2D13F3D76C768F01E4D90B@GBNTHT12009MSX.gb002.siemens.net> References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1950@zrc2hxm0.corp.nortel.com> <719F9BBB3E7E71428A2D13F3D76C768F01E4D90B@GBNTHT12009MSX.gb002.siemens.net> Date: Wed, 15 Jul 2009 08:45:33 -0700 Message-ID: <4ff4e7370907150845j22311aa1u876039de3ea058e6@mail.gmail.com> From: Venkatesh To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=000e0cd6ad1a0e6c28046ec0726a Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 15:46:45 -0000 --000e0cd6ad1a0e6c28046ec0726a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Andrew: Thanks for pointing it out. I missed the change as well. Honestly, one of the main use cases for BLA/SLA was to address a boss/secretary scenario. In these cases, the secretary is really monitoring a "Boss" extension; so from a "ownership" purpose, the AoR is really that of the boss and not a "common" address. Venkatesh On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andrew < andrew.hutton@siemens-enterprise.com> wrote: > > Indeed this getting interesting. > > In version -02 the REGISTER in section 10.1 showed a normal 1st party > registration by alice but -03 shows a third party registration which is > a significant change. > > I must admit I missed the text in -02 which stated "Bob and Alice are in > an appearance group identified by Alice's AOR. Bob REGISTERs using > contact sip:bob@ua2.example.com " and I should > have commented on that > earlier. > > As the draft is about sharing appearances of a single AOR then surely > third party registration is not necessary as it could be that there is > simply two helpdesk phones using a single AOR and there is no "alice" or > "bob" AOR's. So in the simplest case the REGISTER would be: > > REGISTER sip:registrar.example.com SIP/2.0 > Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 > From: > >;tag=CDF9A668-909E2BDD > To: > > CSeq: 2 REGISTER > Call-ID: d3281184-518783de-cc23d6bb > Contact: > > > Regards > Andy > > > >-----Original Message----- > >From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] > >On Behalf Of Francois Audet > >Sent: 14 July 2009 23:30 > >To: Alan Johnston > >Cc: bliss@ietf.org > >Subject: [BLISS] draft-ietf-bliss-shared-appearances: > >Provisioningconsiderations > > > > > >> > Section 9: > >> > > >> > Delete first paragraph. > >> > > >> > Clarify the UA also REGISTERs to the AOR. Discuss the > >> security implications, i.e., > >> > you either use the same shared username/password, or you > >> use a different username/password > >> > for HTTP digest, per user. Perhaps the security > >> considerations can be described in section 15. > >> > > >> > > >> > >> I added text about authorization for third party registrations and > >> publication. A little more text on this would be helpful. > > > >Ah-ah... Now we are getting down to business. > > > >I am now looking at new section 10.1 on registration, and I see that > >you are using indeed third-party registration (with To=HelpDesk, > >From=Alice). > > > >So, this would be one way to to it. > > > >Another way would be to NOT use third-party registration at all. In > >other words, Alice would send a first party registration on behalf > >of HelpDesk (ie.., To=HelpDesk, From=Alice). > > > >Wouldn't that work? > > > >Then there is the whole issue of authentication with HTTP-Digest. > >I guess one could use username="HelpDesk". In this case, the > >idea is that > >Alice would need to know the credentials for HelpDesk. > >Another way would be to use username="alice" instead (i.e., > >her own credentials). > >The decisions on which authentication you use would depend on > >need of the > >administrator. > > > >Have you tought about this? Am I off based? > >_______________________________________________ > >BLISS mailing list > >BLISS@ietf.org > >https://www.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss > --000e0cd6ad1a0e6c28046ec0726a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew:

Thanks for pointing it out. I missed the change = as well. Honestly, one of the main use cases for BLA/SLA was to address a b= oss/secretary scenario. In these cases, the secretary is really monitoring = a "Boss" extension; so from a "ownership" purpose, the = AoR is really that of the boss and not a "common" address.

Venkatesh

On Wed, Jul= 15, 2009 at 3:53 AM, Hutton, Andrew <andrew.hutton@siemens-enterprise.co= m> wrote:

Indeed this getting interesting.

In version -02 the REGISTER in section 10.1 showed a normal 1st party
registration by alice but -03 shows a third party registration which is
a significant change.

I must admit I missed the text in -02 which stated "Bob and Alice are = in
an appearance group identified by Alice's AOR. Bob REGISTERs using
contact sip:bob@ua2.example.co= m" and I should have commented on that
earlier.

As the draft is about sharing appearances of a single AOR then surely
third party registration is not necessary as it could be that there is
simply two helpdesk phones using a single AOR and there is no "alice&q= uot; or
"bob" AOR's. So in the simplest case the REGISTER would be:
=A0 REGISTER sip:registrar.example.com SIP/2.0
=A0 Via: SIP/2.0/UDP = ua1.example.com;branch=3Dz9hG4bK527b54da8ACC7B09
=A0 From: <sip:HelpDesk@e= xample.com>;tag=3DCDF9A668-909E2BDD
=A0 To: <sip:HelpDesk@exa= mple.com>
=A0 CSeq: 2 REGISTER
=A0 Call-ID: d3281184-518783de-cc23d6bb
=A0 Contact: <sip:Hel= pDesk@ua1.example.com>

Regards
Andy


>-----Original Message-----
>From: bliss-bounces@ietf.org<= /a> [mailto:bliss-bounces@ietf.or= g]
>On Behalf Of Francois Audet
>Sent: 14 July 2009 23:30
>To: Alan Johnston
>Cc: bliss@ietf.org
>Subject: [BLISS] draft-ietf-bliss-shared-appearances:
>Provisioningconsiderations
>
>
>> > Section 9:
>> >
>> > Delete first paragraph.
>> >
>> > Clarify the UA also REGISTERs to the AOR. Discuss the
>> security implications, i.e.,
>> > you either use the same shared username/password, or you
>> use a different username/password
>> > for HTTP digest, per user. Perhaps the security
>> considerations can be described in section 15.
>> >
>> >
>>
>> I added text about authorization for third party registrations and=
>> publication. =A0A little more text on this would be helpful.
>
>Ah-ah... Now we are getting down to business.
>
>I am now looking at new section 10.1 on registration, and I see that >you are using indeed third-party registration (with To=3DHelpDesk,
>From=3DAlice).
>
>So, this would be one way to to it.
>
>Another way would be to NOT use third-party registration at all. In
>other words, Alice would send a first party registration on behalf
>of HelpDesk (ie.., To=3DHelpDesk, From=3DAlice).
>
>Wouldn't that work?
>
>Then there is the whole issue of authentication with HTTP-Digest.
>I guess one could use username=3D"HelpDesk". In this case, th= e
>idea is that
>Alice would need to know the credentials for HelpDesk.
>Another way would be to use username=3D"alice" instead (i.e.,=
>her own credentials).
>The decisions on which authentication you use would depend on
>need of the
>administrator.
>
>Have you tought about this? Am I off based?
>_______________________________________________
>BLISS mailing list
>BLISS@ietf.org
>https://www.ietf.org/mailman/listinfo/bliss
>
_______________________________________________
BLISS mailing list
BLISS@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/bliss

--000e0cd6ad1a0e6c28046ec0726a-- From AUDET@nortel.com Wed Jul 15 09:04:50 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8453A6947 for ; Wed, 15 Jul 2009 09:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 GxO22nJzlzIT for ; Wed, 15 Jul 2009 09:04:49 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 112793A6A08 for ; Wed, 15 Jul 2009 09:04:48 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6FG2ZF24964; Wed, 15 Jul 2009 16:02:36 GMT 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, 15 Jul 2009 11:02:12 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFE0BF0@zrc2hxm0.corp.nortel.com> In-Reply-To: A<719F9BBB3E7E71428A2D13F3D76C768F01E4D90B@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations thread-index: AcoElF38JzjscuxfTa2jLS1ru6gFAwANkNXQABuI/5AACwQL4A== References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1950@zrc2hxm0.corp.nortel.com> A<719F9BBB3E7E71428A2D13F3D76C768F01E4D90B@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Hutton, Andrew" , "Alan Johnston" Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 16:04:50 -0000 Hi Andrew, That's what I was thinking too for the two fields of importance here, i.e., the To and the From. I will point out that the Contact is completely up to the UA to=20 decide (as long as it routes). Specifically, in this case, Bob could use: Contact: =20 Or even: Contact: Or Contact: ...you get the idea. The reason why you may need to use something else than HelpDesk as the contact is for cases where you need to associate the signalling to a specific user. For example, many phones allow for multiple=20 users to be logged in simultaneaously (i.e.,=20 multiple accounts). Think of a phone, for example, that happens to have both Alice and Bob logged in on the same phone, and each one having a shared appearance of HelpDesk./ > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 > Sent: Wednesday, July 15, 2009 03:54 > To: Audet, Francois (SC100:3055); Alan Johnston > Cc: bliss@ietf.org > Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances:=20 > Provisioningconsiderations >=20 >=20 > Indeed this getting interesting. >=20 > In version -02 the REGISTER in section 10.1 showed a normal=20 > 1st party registration by alice but -03 shows a third party=20 > registration which is a significant change. >=20 > I must admit I missed the text in -02 which stated "Bob and=20 > Alice are in an appearance group identified by Alice's AOR.=20 > Bob REGISTERs using contact sip:bob@ua2.example.com" and I=20 > should have commented on that earlier. >=20 > As the draft is about sharing appearances of a single AOR=20 > then surely third party registration is not necessary as it=20 > could be that there is simply two helpdesk phones using a=20 > single AOR and there is no "alice" or "bob" AOR's. So in the=20 > simplest case the REGISTER would be: >=20 > REGISTER sip:registrar.example.com SIP/2.0 > Via: SIP/2.0/UDP ua1.example.com;branch=3Dz9hG4bK527b54da8ACC7B09 > From: ;tag=3DCDF9A668-909E2BDD > To: > CSeq: 2 REGISTER > Call-ID: d3281184-518783de-cc23d6bb > Contact: >=20 > Regards > Andy > =20 >=20 > >-----Original Message----- > >From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > On Behalf=20 > >Of Francois Audet > >Sent: 14 July 2009 23:30 > >To: Alan Johnston > >Cc: bliss@ietf.org > >Subject: [BLISS] draft-ietf-bliss-shared-appearances:=20 > >Provisioningconsiderations > > > > > >> > Section 9: > >> > > >> > Delete first paragraph. > >> > > >> > Clarify the UA also REGISTERs to the AOR. Discuss the > >> security implications, i.e., > >> > you either use the same shared username/password, or you > >> use a different username/password > >> > for HTTP digest, per user. Perhaps the security > >> considerations can be described in section 15. > >> > > >> > =20 > >>=20 > >> I added text about authorization for third party registrations and=20 > >> publication. A little more text on this would be helpful. > > > >Ah-ah... Now we are getting down to business. > > > >I am now looking at new section 10.1 on registration, and I see that=20 > >you are using indeed third-party registration (with To=3DHelpDesk,=20 > >From=3DAlice). > > > >So, this would be one way to to it. > > > >Another way would be to NOT use third-party registration at all. In=20 > >other words, Alice would send a first party registration on=20 > behalf of=20 > >HelpDesk (ie.., To=3DHelpDesk, From=3DAlice). > > > >Wouldn't that work? > > > >Then there is the whole issue of authentication with HTTP-Digest. > >I guess one could use username=3D"HelpDesk". In this case, the idea = is=20 > >that Alice would need to know the credentials for HelpDesk. > >Another way would be to use username=3D"alice" instead (i.e., her own = > >credentials). > >The decisions on which authentication you use would depend=20 > on need of=20 > >the administrator. > > > >Have you tought about this? Am I off based? > >_______________________________________________ > >BLISS mailing list > >BLISS@ietf.org > >https://www.ietf.org/mailman/listinfo/bliss > > >=20 From AUDET@nortel.com Wed Jul 15 09:30:25 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C858A3A6B9D for ; Wed, 15 Jul 2009 09:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDhS0-kKOlfT for ; Wed, 15 Jul 2009 09:30:24 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 54D123A6A3C for ; Wed, 15 Jul 2009 09:30:24 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6FGThF02046; Wed, 15 Jul 2009 16:29:43 GMT 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_01CA0569.692DE362" Date: Wed, 15 Jul 2009 11:29:22 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFE0CCD@zrc2hxm0.corp.nortel.com> In-Reply-To: <4ff4e7370907150845j22311aa1u876039de3ea058e6@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations thread-index: AcoFY0uIgugGqoUVRuWzoNI+An3FQwABhHjw References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1950@zrc2hxm0.corp.nortel.com> <719F9BBB3E7E71428A2D13F3D76C768F01E4D90B@GBNTHT12009MSX.gb002.siemens.net> <4ff4e7370907150845j22311aa1u876039de3ea058e6@mail.gmail.com> From: "Francois Audet" To: "Venkatesh" , "Hutton, Andrew" Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 16:30:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0569.692DE362 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, of course HelpDesk could be the Boss instead. ________________________________ From: Venkatesh [mailto:vvenkatar@gmail.com]=20 Sent: Wednesday, July 15, 2009 08:46 To: Hutton, Andrew Cc: Audet, Francois (SC100:3055); Alan Johnston; bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: = Provisioningconsiderations =09 =09 Andrew:=20 Thanks for pointing it out. I missed the change as well. Honestly, one = of the main use cases for BLA/SLA was to address a boss/secretary = scenario. In these cases, the secretary is really monitoring a "Boss" = extension; so from a "ownership" purpose, the AoR is really that of the = boss and not a "common" address. Venkatesh =09 =09 On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andrew = wrote: =09 Indeed this getting interesting. =09 In version -02 the REGISTER in section 10.1 showed a normal 1st party registration by alice but -03 shows a third party registration which = is a significant change. =09 I must admit I missed the text in -02 which stated "Bob and Alice are = in an appearance group identified by Alice's AOR. Bob REGISTERs using contact sip:bob@ua2.example.com " = and I should have commented on that earlier. =09 As the draft is about sharing appearances of a single AOR then surely third party registration is not necessary as it could be that there is simply two helpdesk phones using a single AOR and there is no "alice" = or "bob" AOR's. So in the simplest case the REGISTER would be: =09 REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=3Dz9hG4bK527b54da8ACC7B09 From: = >;tag=3DCDF9A668-909E2BDD To: > CSeq: 2 REGISTER Call-ID: d3281184-518783de-cc23d6bb Contact: > =09 Regards Andy =09 >-----Original Message----- >From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] >On Behalf Of Francois Audet >Sent: 14 July 2009 23:30 >To: Alan Johnston >Cc: bliss@ietf.org >Subject: [BLISS] draft-ietf-bliss-shared-appearances: >Provisioningconsiderations > > >> > Section 9: >> > >> > Delete first paragraph. >> > >> > Clarify the UA also REGISTERs to the AOR. Discuss the >> security implications, i.e., >> > you either use the same shared username/password, or you >> use a different username/password >> > for HTTP digest, per user. Perhaps the security >> considerations can be described in section 15. >> > >> > >> >> I added text about authorization for third party registrations and >> publication. A little more text on this would be helpful. > >Ah-ah... Now we are getting down to business. > >I am now looking at new section 10.1 on registration, and I see that >you are using indeed third-party registration (with To=3DHelpDesk, >From=3DAlice). > >So, this would be one way to to it. > >Another way would be to NOT use third-party registration at all. In >other words, Alice would send a first party registration on behalf >of HelpDesk (ie.., To=3DHelpDesk, From=3DAlice). > >Wouldn't that work? > >Then there is the whole issue of authentication with HTTP-Digest. >I guess one could use username=3D"HelpDesk". In this case, the >idea is that >Alice would need to know the credentials for HelpDesk. >Another way would be to use username=3D"alice" instead (i.e., >her own credentials). >The decisions on which authentication you use would depend on >need of the >administrator. > >Have you tought about this? Am I off based? >_______________________________________________ >BLISS mailing list >BLISS@ietf.org >https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss =09 ------_=_NextPart_001_01CA0569.692DE362 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes,=20 of course HelpDesk could be the Boss instead.

From: Venkatesh = [mailto:vvenkatar@gmail.com]=20
Sent: Wednesday, July 15, 2009 08:46
To: Hutton,=20 Andrew
Cc: Audet, Francois (SC100:3055); Alan Johnston;=20 bliss@ietf.org
Subject: Re: [BLISS]=20 draft-ietf-bliss-shared-appearances:=20 Provisioningconsiderations

Andrew:

Thanks for pointing it out. I missed the change as well. = Honestly, one of=20 the main use cases for BLA/SLA was to address a boss/secretary = scenario. In=20 these cases, the secretary is really monitoring a "Boss" extension; so = from a=20 "ownership" purpose, the AoR is really that of the boss and not a = "common"=20 address.

Venkatesh

On Wed, Jul 15, 2009 at 3:53 AM, Hutton, = Andrew <andrew.hutton@siemen= s-enterprise.com>=20 wrote:

Indeed=20 this getting interesting.

In version -02 the REGISTER in = section 10.1=20 showed a normal 1st party
registration by alice but -03 shows a = third=20 party registration which is
a significant change.

I must = admit I=20 missed the text in -02 which stated "Bob and Alice are in
an = appearance=20 group identified by Alice's AOR. Bob REGISTERs using
contact sip:bob@ua2.example.com" = and I=20 should have commented on that
earlier.

As the draft is = about=20 sharing appearances of a single AOR then surely
third party = registration=20 is not necessary as it could be that there is
simply two helpdesk = phones=20 using a single AOR and there is no "alice" or
"bob" AOR's. So in = the=20 simplest case the REGISTER would be:

  REGISTER sip:registrar.example.com=20 SIP/2.0
  Via: SIP/2.0/UDP ua1.example.com;branch=3Dz9hG4bK527b54da8ACC7B09
&= nbsp;=20 From: <sip:HelpDesk@example.com&g= t;;tag=3DCDF9A668-909E2BDD
 =20 To: <sip:HelpDesk@example.com&g= t;
 =20 CSeq: 2 REGISTER
  Call-ID: = d3281184-518783de-cc23d6bb
 =20 Contact: <sip:HelpDesk@ua1.example.c= om>

Regards
Andy


>-----Original Message-----
>From: = bliss-bounces@ietf.org = [mailto:bliss-bounces@ietf.org]
>= ;On=20 Behalf Of Francois Audet
>Sent: 14 July 2009 23:30
>To: = Alan=20 Johnston
>Cc: bliss@ietf.org
>Subject: = [BLISS]=20 = draft-ietf-bliss-shared-appearances:
>Provisioningconsiderations>
>
>>=20 > Section 9:
>> >
>> > Delete first=20 paragraph.
>> >
>> > Clarify the UA also = REGISTERs=20 to the AOR. Discuss the
>> security implications, = i.e.,
>>=20 > you either use the same shared username/password, or = you
>>=20 use a different username/password
>> > for HTTP digest, = per=20 user. Perhaps the security
>> considerations can be = described in=20 section 15.
>> >
>> = >
>>
>> I=20 added text about authorization for third party registrations = and
>>=20 publication.  A little more text on this would be=20 helpful.
>
>Ah-ah... Now we are getting down to=20 business.
>
>I am now looking at new section 10.1 on=20 registration, and I see that
>you are using indeed third-party = registration (with = To=3DHelpDesk,
>From=3DAlice).
>
>So, this=20 would be one way to to it.
>
>Another way would be to = NOT use=20 third-party registration at all. In
>other words, Alice would = send a=20 first party registration on behalf
>of HelpDesk (ie.., = To=3DHelpDesk,=20 From=3DAlice).
>
>Wouldn't that = work?
>
>Then there is=20 the whole issue of authentication with HTTP-Digest.
>I guess = one could=20 use username=3D"HelpDesk". In this case, the
>idea is = that
>Alice=20 would need to know the credentials for HelpDesk.
>Another way = would be=20 to use username=3D"alice" instead (i.e.,
>her own=20 credentials).
>The decisions on which authentication you use = would=20 depend on
>need of = the
>administrator.
>
>Have you=20 tought about this? Am I off=20 = based?
>_______________________________________________
>BLIS= S=20 mailing list
>BLISS@ietf.org
>https://www.ietf.org/mailman/listinfo/bliss
>_______________________________________________
BLISS=20 mailing list
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss
=

------_=_NextPart_001_01CA0569.692DE362-- From vvenkatar@gmail.com Wed Jul 15 09:41:50 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66673A6F16 for ; Wed, 15 Jul 2009 09:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2PBkooZKLB8 for ; Wed, 15 Jul 2009 09:41:49 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id 6C3E83A6D56 for ; Wed, 15 Jul 2009 09:41:49 -0700 (PDT) Received: by yxe34 with SMTP id 34so4410016yxe.29 for ; Wed, 15 Jul 2009 09:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pP4QcvV65OIj4rU3E7zh21j3wYVdr6YCh1FGDuhink8=; b=QOQtsYRc8fAO1Bokkio6pZCHdJXyEZrH2N42bJ4Jzjp21uT3TF+KFz1y/+IQYYptvo u642o6IA4E0Qd1KF3CdTFqR3qykJaLjkzg21hijrgBbgrppdT8Sv5fr/ux7lRMHS9JEP b3VvWrgSYSsUYnr2DwVvty0aAlH4VhW6QVKB4= 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=QzLb6IE88ujPre7QOv+zOvGeWR6mHfOea3BPKI5wP4JeQqaWKs3zk4HnxGF5MbM+Hw Gz7IaxZQu0AJFqg4XQZu6EqphCynAV3Yu1CZznYQ9aaNLnRHswT7PQKmQiYDXRyytZFG dThicCiLJ1LqClblIfnTPwvoNGVPAxF3CDVxI= MIME-Version: 1.0 Received: by 10.151.110.21 with SMTP id n21mr12929840ybm.63.1247675765366; Wed, 15 Jul 2009 09:36:05 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFE0CCD@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1950@zrc2hxm0.corp.nortel.com> <719F9BBB3E7E71428A2D13F3D76C768F01E4D90B@GBNTHT12009MSX.gb002.siemens.net> <4ff4e7370907150845j22311aa1u876039de3ea058e6@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1EFE0CCD@zrc2hxm0.corp.nortel.com> Date: Wed, 15 Jul 2009 09:36:05 -0700 Message-ID: <4ff4e7370907150936m73455773jc4107e1031a0c0ab@mail.gmail.com> From: Venkatesh To: Francois Audet Content-Type: multipart/alternative; boundary=00151750e57cca1f17046ec12636 Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 16:41:51 -0000 --00151750e57cca1f17046ec12636 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sure, but it means the secretary is now using HelpDesk (or "boss" in the example) credentials to register if you didn't have 3rd party registration semantics? Venkatesh On Wed, Jul 15, 2009 at 9:29 AM, Francois Audet wrote: > Yes, of course HelpDesk could be the Boss instead. > > ------------------------------ > *From:* Venkatesh [mailto:vvenkatar@gmail.com] > *Sent:* Wednesday, July 15, 2009 08:46 > *To:* Hutton, Andrew > *Cc:* Audet, Francois (SC100:3055); Alan Johnston; bliss@ietf.org > *Subject:* Re: [BLISS] draft-ietf-bliss-shared-appearances: > Provisioningconsiderations > > Andrew: > Thanks for pointing it out. I missed the change as well. Honestly, one of > the main use cases for BLA/SLA was to address a boss/secretary scenario. In > these cases, the secretary is really monitoring a "Boss" extension; so from > a "ownership" purpose, the AoR is really that of the boss and not a "common" > address. > > Venkatesh > > On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andrew < > andrew.hutton@siemens-enterprise.com> wrote: > >> >> Indeed this getting interesting. >> >> In version -02 the REGISTER in section 10.1 showed a normal 1st party >> registration by alice but -03 shows a third party registration which is >> a significant change. >> >> I must admit I missed the text in -02 which stated "Bob and Alice are in >> an appearance group identified by Alice's AOR. Bob REGISTERs using >> contact sip:bob@ua2.example.com " and I should >> have commented on that >> earlier. >> >> As the draft is about sharing appearances of a single AOR then surely >> third party registration is not necessary as it could be that there is >> simply two helpdesk phones using a single AOR and there is no "alice" or >> "bob" AOR's. So in the simplest case the REGISTER would be: >> >> REGISTER sip:registrar.example.com SIP/2.0 >> Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 >> From: >> >;tag=CDF9A668-909E2BDD >> To: > >> CSeq: 2 REGISTER >> Call-ID: d3281184-518783de-cc23d6bb >> Contact: >> > >> >> Regards >> Andy >> >> >> >-----Original Message----- >> >From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] >> >On Behalf Of Francois Audet >> >Sent: 14 July 2009 23:30 >> >To: Alan Johnston >> >Cc: bliss@ietf.org >> >Subject: [BLISS] draft-ietf-bliss-shared-appearances: >> >Provisioningconsiderations >> > >> > >> >> > Section 9: >> >> > >> >> > Delete first paragraph. >> >> > >> >> > Clarify the UA also REGISTERs to the AOR. Discuss the >> >> security implications, i.e., >> >> > you either use the same shared username/password, or you >> >> use a different username/password >> >> > for HTTP digest, per user. Perhaps the security >> >> considerations can be described in section 15. >> >> > >> >> > >> >> >> >> I added text about authorization for third party registrations and >> >> publication. A little more text on this would be helpful. >> > >> >Ah-ah... Now we are getting down to business. >> > >> >I am now looking at new section 10.1 on registration, and I see that >> >you are using indeed third-party registration (with To=HelpDesk, >> >From=Alice). >> > >> >So, this would be one way to to it. >> > >> >Another way would be to NOT use third-party registration at all. In >> >other words, Alice would send a first party registration on behalf >> >of HelpDesk (ie.., To=HelpDesk, From=Alice). >> > >> >Wouldn't that work? >> > >> >Then there is the whole issue of authentication with HTTP-Digest. >> >I guess one could use username="HelpDesk". In this case, the >> >idea is that >> >Alice would need to know the credentials for HelpDesk. >> >Another way would be to use username="alice" instead (i.e., >> >her own credentials). >> >The decisions on which authentication you use would depend on >> >need of the >> >administrator. >> > >> >Have you tought about this? Am I off based? >> >_______________________________________________ >> >BLISS mailing list >> >BLISS@ietf.org >> >https://www.ietf.org/mailman/listinfo/bliss >> > >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www.ietf.org/mailman/listinfo/bliss >> > > --00151750e57cca1f17046ec12636 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sure, but it means the secretary is now using HelpDesk (or "boss"= in the example) credentials to register if you didn't have 3rd party r= egistration semantics?

Venkatesh

On Wed, Jul 15, 2009 at 9:29 AM, Francois Audet <audet@nortel.com> wrote:
Yes,=20 of course HelpDesk could be the Boss instead.

From: Venkatesh [mailto:vvenkatar@gmail.com]= =20
Sent: Wednesday, July 15, 2009 08:46
To: Hutton,=20 Andrew
Cc: Audet, Francois (SC100:3055); Alan Johnston;=20 bliss@ietf.orgSubject: Re: [BLISS]=20 draft-ietf-bliss-shared-appearances:=20 Provisioningconsiderations

Andrew:

Thanks for pointing it out. I missed the change as well. Honestly, o= ne of=20 the main use cases for BLA/SLA was to address a boss/secretary scenario. = In=20 these cases, the secretary is really monitoring a "Boss" extens= ion; so from a=20 "ownership" purpose, the AoR is really that of the boss and not= a "common"=20 address.

Venkatesh

On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andre= w <andrew.hutton@siemens-enterprise.com>= =20 wrote:

Indeed=20 this getting interesting.

In version -02 the REGISTER in section= 10.1=20 showed a normal 1st party
registration by alice but -03 shows a thir= d=20 party registration which is
a significant change.

I must admi= t I=20 missed the text in -02 which stated "Bob and Alice are in
an ap= pearance=20 group identified by Alice's AOR. Bob REGISTERs using
contact sip:bob@ua2.exa= mple.com" and I=20 should have commented on that
earlier.

As the draft is about= =20 sharing appearances of a single AOR then surely
third party registra= tion=20 is not necessary as it could be that there is
simply two helpdesk ph= ones=20 using a single AOR and there is no "alice" or
"bob&qu= ot; AOR's. So in the=20 simplest case the REGISTER would be:

=A0 REGISTER sip:registrar.example.com= =20 SIP/2.0
=A0 Via: SIP/2.0/UDP ua1.example.com;branch=3Dz9hG4bK527b54da8ACC7B09
=A0= =20 From: <sip:HelpDesk@example.com>;tag=3DCDF9A668-909E2BDD
=A0=20 To: <sip:HelpDesk@example.com>
=A0=20 CSeq: 2 REGISTER
=A0 Call-ID: d3281184-518783de-cc23d6bb
=A0=20 Contact: <sip:HelpDesk@ua1.example.com>

Regards
Andy


>-----Original Message-----
>From: bliss-bounces@ietf.org [m= ailto:bliss-bou= nces@ietf.org]
>On=20 Behalf Of Francois Audet
>Sent: 14 July 2009 23:30
>To: Ala= n=20 Johnston
>Cc: bliss@ietf.org
>Subject: [BLISS]=20 draft-ietf-bliss-shared-appearances:
>Provisioningconsiderations<= br>>
>
>>=20 > Section 9:
>> >
>> > Delete first=20 paragraph.
>> >
>> > Clarify the UA also REGIST= ERs=20 to the AOR. Discuss the
>> security implications, i.e.,
>= ;>=20 > you either use the same shared username/password, or you
>&g= t;=20 use a different username/password
>> > for HTTP digest, per= =20 user. Perhaps the security
>> considerations can be described = in=20 section 15.
>> >
>> >
>>
>> I= =20 added text about authorization for third party registrations and
>= ;>=20 publication. =A0A little more text on this would be=20 helpful.
>
>Ah-ah... Now we are getting down to=20 business.
>
>I am now looking at new section 10.1 on=20 registration, and I see that
>you are using indeed third-party=20 registration (with To=3DHelpDesk,
>From=3DAlice).
>
>= So, this=20 would be one way to to it.
>
>Another way would be to NOT u= se=20 third-party registration at all. In
>other words, Alice would sen= d a=20 first party registration on behalf
>of HelpDesk (ie.., To=3DHelpD= esk,=20 From=3DAlice).
>
>Wouldn't that work?
>
>Th= en there is=20 the whole issue of authentication with HTTP-Digest.
>I guess one = could=20 use username=3D"HelpDesk". In this case, the
>idea is t= hat
>Alice=20 would need to know the credentials for HelpDesk.
>Another way wou= ld be=20 to use username=3D"alice" instead (i.e.,
>her own=20 credentials).
>The decisions on which authentication you use woul= d=20 depend on
>need of the
>administrator.
>
>Have = you=20 tought about this? Am I off=20 based?
>_______________________________________________
>BL= ISS=20 mailing list
>BLISS@ietf.org
>https://www.ietf.org/mailman/listinfo/bliss>
_______________________________________________
BLISS=20 mailing list
BLI= SS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss
=


--00151750e57cca1f17046ec12636-- From AUDET@nortel.com Wed Jul 15 09:56:51 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C979C3A6F30 for ; Wed, 15 Jul 2009 09:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9D3Os3ZFEsN for ; Wed, 15 Jul 2009 09:56:50 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 27C663A6EB9 for ; Wed, 15 Jul 2009 09:56:50 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6FGtHF01933; Wed, 15 Jul 2009 16:55:17 GMT 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_01CA056D.3C5CCC50" Date: Wed, 15 Jul 2009 11:56:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFE0D71@zrc2hxm0.corp.nortel.com> In-Reply-To: <4ff4e7370907150936m73455773jc4107e1031a0c0ab@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations thread-index: AcoFaovCkrtrxTJBSveBWXmT6IxGSAAAdDcA References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1950@zrc2hxm0.corp.nortel.com> <719F9BBB3E7E71428A2D13F3D76C768F01E4D90B@GBNTHT12009MSX.gb002.siemens.net> <4ff4e7370907150845j22311aa1u876039de3ea058e6@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1EFE0CCD@zrc2hxm0.corp.nortel.com> <4ff4e7370907150936m73455773jc4107e1031a0c0ab@mail.gmail.com> From: "Francois Audet" To: "Venkatesh" Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 16:56:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA056D.3C5CCC50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, yes. =20 However, as per my email, that's not the only alternative. =20 You could use "user=3Dalice" for authentication in HTTP digest if, for = whatever reason, you prefer to have users authenticating as themselves = instead of using the shared appearance. That advantage is that users = don't need to know 2 username/passwords. The disadvantage is that you = need more infrastructure in the back-end to allow Alice to log in as = Boss with her own credential.=20 =20 I was thinking that both model should be allowed. Like in most SIP = client today, you can put a different HTTP credential (if required). Otherwise, it would default to the one used for registering (i.e., the = From). =20 So in both cases, there is no 3rd party registration per se (as per the = definition in 3261). =20 That was my thought ________________________________ From: Venkatesh [mailto:vvenkatar@gmail.com]=20 Sent: Wednesday, July 15, 2009 09:36 To: Audet, Francois (SC100:3055) Cc: Hutton, Andrew; Alan Johnston; bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: = Provisioningconsiderations =09 =09 Sure, but it means the secretary is now using HelpDesk (or "boss" in = the example) credentials to register if you didn't have 3rd party = registration semantics?=20 Venkatesh =09 =09 On Wed, Jul 15, 2009 at 9:29 AM, Francois Audet = wrote: =09 Yes, of course HelpDesk could be the Boss instead. ________________________________ From: Venkatesh [mailto:vvenkatar@gmail.com]=20 Sent: Wednesday, July 15, 2009 08:46 To: Hutton, Andrew Cc: Audet, Francois (SC100:3055); Alan Johnston; bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: = Provisioningconsiderations =09 =09 Andrew:=20 Thanks for pointing it out. I missed the change as well. Honestly, = one of the main use cases for BLA/SLA was to address a boss/secretary = scenario. In these cases, the secretary is really monitoring a "Boss" = extension; so from a "ownership" purpose, the AoR is really that of the = boss and not a "common" address. Venkatesh =09 =09 On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andrew = wrote: =09 Indeed this getting interesting. =09 In version -02 the REGISTER in section 10.1 showed a normal 1st = party registration by alice but -03 shows a third party registration which = is a significant change. =09 I must admit I missed the text in -02 which stated "Bob and Alice = are in an appearance group identified by Alice's AOR. Bob REGISTERs using contact sip:bob@ua2.example.com " = and I should have commented on that earlier. =09 As the draft is about sharing appearances of a single AOR then = surely third party registration is not necessary as it could be that there = is simply two helpdesk phones using a single AOR and there is no = "alice" or "bob" AOR's. So in the simplest case the REGISTER would be: =09 REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=3Dz9hG4bK527b54da8ACC7B09 From: >;tag=3DCDF9A668-909E2BDD To: = > CSeq: 2 REGISTER Call-ID: d3281184-518783de-cc23d6bb Contact: > =09 Regards Andy =09 >-----Original Message----- >From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] >On Behalf Of Francois Audet >Sent: 14 July 2009 23:30 >To: Alan Johnston >Cc: bliss@ietf.org >Subject: [BLISS] draft-ietf-bliss-shared-appearances: >Provisioningconsiderations > > >> > Section 9: >> > >> > Delete first paragraph. >> > >> > Clarify the UA also REGISTERs to the AOR. Discuss the >> security implications, i.e., >> > you either use the same shared username/password, or you >> use a different username/password >> > for HTTP digest, per user. Perhaps the security >> considerations can be described in section 15. >> > >> > >> >> I added text about authorization for third party registrations = and >> publication. A little more text on this would be helpful. > >Ah-ah... Now we are getting down to business. > >I am now looking at new section 10.1 on registration, and I see = that >you are using indeed third-party registration (with To=3DHelpDesk, >From=3DAlice). > >So, this would be one way to to it. > >Another way would be to NOT use third-party registration at all. In >other words, Alice would send a first party registration on behalf >of HelpDesk (ie.., To=3DHelpDesk, From=3DAlice). > >Wouldn't that work? > >Then there is the whole issue of authentication with HTTP-Digest. >I guess one could use username=3D"HelpDesk". In this case, the >idea is that >Alice would need to know the credentials for HelpDesk. >Another way would be to use username=3D"alice" instead (i.e., >her own credentials). >The decisions on which authentication you use would depend on >need of the >administrator. > >Have you tought about this? Am I off based? >_______________________________________________ >BLISS mailing list >BLISS@ietf.org >https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss =09 ------_=_NextPart_001_01CA056D.3C5CCC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Well,=20 yes.
 
However, as per my email, that's not the only=20 alternative.
 
You=20 could use "user=3Dalice" for authentication in HTTP digest if, for = whatever=20 reason, you prefer to have users authenticating as themselves instead of = using=20 the shared appearance. That advantage is that users don't need to know 2 = username/passwords. The disadvantage is that you need more = infrastructure in the=20 back-end to allow Alice to log in as Boss with her own credential.=20
 
I was=20 thinking that both model should be allowed. Like in most SIP client = today, you=20 can put a different HTTP credential (if = required).
Otherwise, it would default to the one used for registering = (i.e., the=20 From).
 
So in=20 both cases, there is no 3rd party registration per se (as per the = definition in=20 3261).
 
That=20 was my thought

From: Venkatesh = [mailto:vvenkatar@gmail.com]=20
Sent: Wednesday, July 15, 2009 09:36
To: Audet, = Francois=20 (SC100:3055)
Cc: Hutton, Andrew; Alan Johnston;=20 bliss@ietf.org
Subject: Re: [BLISS]=20 draft-ietf-bliss-shared-appearances:=20 Provisioningconsiderations

Sure, but it means the secretary is now using HelpDesk (or = "boss"=20 in the example) credentials to register if you didn't have 3rd party=20 registration semantics?

Venkatesh

On Wed, Jul 15, 2009 at 9:29 AM, Francois = Audet <audet@nortel.com>=20 wrote:
Yes, of = course HelpDesk=20 could be the Boss instead.

From: Venkatesh [mailto:vvenkatar@gmail.com]=20
Sent: Wednesday, July 15, 2009 08:46
To: = Hutton,=20 Andrew
Cc: Audet, Francois (SC100:3055); Alan Johnston; = bliss@ietf.org
Subject: Re: [BLISS]=20 draft-ietf-bliss-shared-appearances:=20 Provisioningconsiderations

Andrew:=20

Thanks for pointing it out. I missed the change as well. = Honestly,=20 one of the main use cases for BLA/SLA was to address a = boss/secretary=20 scenario. In these cases, the secretary is really monitoring a = "Boss"=20 extension; so from a "ownership" purpose, the AoR is really that = of the=20 boss and not a "common" address.

Venkatesh

On Wed, Jul 15, 2009 at 3:53 AM, Hutton, = Andrew=20 <andrew.hutton@siemens-enterprise.com>=20 wrote:

Indeed=20 this getting interesting.

In version -02 the REGISTER in = section=20 10.1 showed a normal 1st party
registration by alice but -03 = shows a=20 third party registration which is
a significant = change.

I must=20 admit I missed the text in -02 which stated "Bob and Alice are = in
an=20 appearance group identified by Alice's AOR. Bob REGISTERs=20 using
contact sip:bob@ua2.example.com" and I should have = commented=20 on that
earlier.

As the draft is about sharing = appearances of=20 a single AOR then surely
third party registration is not = necessary as=20 it could be that there is
simply two helpdesk phones using a = single=20 AOR and there is no "alice" or
"bob" AOR's. So in the = simplest case=20 the REGISTER would be:

  REGISTER sip:registrar.example.com SIP/2.0
  Via: = SIP/2.0/UDP ua1.example.com;branch=3Dz9hG4bK527b54da8ACC7B09
&= nbsp;=20 From: <sip:HelpDesk@example.com>;tag=3DCDF9A668-909E2BDD<= BR> =20 To: <sip:HelpDesk@example.com>
  CSeq: = 2=20 REGISTER
  Call-ID: d3281184-518783de-cc23d6bb
  = Contact: <sip:HelpDesk@ua1.example.com>

Regards
An= dy


>-----Original Message-----
>From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]
>On Behalf Of = Francois=20 Audet
>Sent: 14 July 2009 23:30
>To: Alan=20 Johnston
>Cc: bliss@ietf.org
>Subject: [BLISS]=20 = draft-ietf-bliss-shared-appearances:
>Provisioningconsiderations>
>
>>=20 > Section 9:
>> >
>> > Delete first=20 paragraph.
>> >
>> > Clarify the UA also = REGISTERs to the AOR. Discuss the
>> security = implications,=20 i.e.,
>> > you either use the same shared = username/password,=20 or you
>> use a different username/password
>> = >=20 for HTTP digest, per user. Perhaps the security
>>=20 considerations can be described in section 15.
>>=20 >
>> >
>>
>> I added text about = authorization for third party registrations and
>> = publication.=20  A little more text on this would be=20 helpful.
>
>Ah-ah... Now we are getting down to=20 business.
>
>I am now looking at new section 10.1 on = registration, and I see that
>you are using indeed = third-party=20 registration (with = To=3DHelpDesk,
>From=3DAlice).
>
>So,=20 this would be one way to to it.
>
>Another way would = be to=20 NOT use third-party registration at all. In
>other words, = Alice=20 would send a first party registration on behalf
>of = HelpDesk=20 (ie.., To=3DHelpDesk, From=3DAlice).
>
>Wouldn't = that=20 work?
>
>Then there is the whole issue of = authentication=20 with HTTP-Digest.
>I guess one could use = username=3D"HelpDesk". In=20 this case, the
>idea is that
>Alice would need to = know the=20 credentials for HelpDesk.
>Another way would be to use=20 username=3D"alice" instead (i.e.,
>her own = credentials).
>The=20 decisions on which authentication you use would depend = on
>need of=20 the
>administrator.
>
>Have you tought about = this? Am=20 I off=20 = based?
>_______________________________________________
>BLIS= S=20 mailing list
>BLISS@ietf.org
>https://www.ietf.org/mailman/listinfo/bliss
>_______________________________________________
BLISS=20 mailing list
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss
=


------_=_NextPart_001_01CA056D.3C5CCC50-- From AUDET@nortel.com Wed Jul 15 10:22:05 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45CB73A6F1A for ; Wed, 15 Jul 2009 10:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 ScBjkAjhfc4M for ; Wed, 15 Jul 2009 10:22:04 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 130143A6999 for ; Wed, 15 Jul 2009 10:22:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6FGIXF26950; Wed, 15 Jul 2009 16:18:33 GMT 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, 15 Jul 2009 11:19:08 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFE0C7E@zrc2hxm0.corp.nortel.com> In-Reply-To: A<719F9BBB3E7E71428A2D13F3D76C768F01E11835@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select thread-index: AcoElF38JzjscuxfTa2jLS1ru6gFAwAMArnAABcP9gAAENAFIA== References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1837@zrc2hxm0.corp.nortel.com> A<719F9BBB3E7E71428A2D13F3D76C768F01E11835@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Hutton, Andrew" , "Alan Johnston" Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 17:22:05 -0000 I disagree. I think we need some clarification. We have decided already that the act of "fake publishing" a "trying" = state is OPTIONAL in this draft. This feature is really when a vendor=20 wants to mimic traditional behavior of a key system. Other people view this as an archaic limitation instead. Even in "pre-sip" implementations, many TDM PBXs have given up already on "seizing" lines when you press the button (the "seizing" only occurs when the call is actually made). So, we wisely opted to make this optional in the spec. The problem is that we have a bit of lack of clarity in a few places about what that means. Getting to specifics, if you look at example 10.4 of the spec. If you use a "selection model" instead of a "seizing" model, then messages F1-F6 do not occur. And neigther would messages F10-F11.=20 (Note that if the Appearance agent had subscribed to HelpDeksk's dialog state, then there would be NOTIFY instead of F10: that is the subject of another discussion). If we agree on this, I can volunteer to provide text if Alan wants it. But I'm not sure if "selection" is the proper term. An alternative would be to say the line is "Seized" or "Not Seized". > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 > Sent: Wednesday, July 15, 2009 00:55 > To: Audet, Francois (SC100:3055); Alan Johnston > Cc: bliss@ietf.org > Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances:=20 > Seize vs Select >=20 > Hi, >=20 > If "select" is a local action in the UA to choose a "line" to=20 > use and this determines the what is in the from header then=20 > this is I believe out of scope for this draft which should=20 > not mention selecting lines or AOR's as this is a different=20 > feature. The SA draft is limited to sharing appearances of=20 > the same AOR. >=20 > Also if "select" is a local action at the UA that is just UI=20 > behaviour then probably no need to mention it at all. >=20 > Regards > Andy >=20 > =20 >=20 > >-----Original Message----- > >From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > On Behalf=20 > >Of Francois Audet > >Sent: 14 July 2009 22:28 > >To: Alan Johnston > >Cc: bliss@ietf.org > >Subject: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select > > > > > >> I changed "select" to "select/seize" globally in the=20 > document. I'm=20 > >> not sure it helps readability, but I think we need both terms. > > > >Here is an explanation what I meant with "seize" versus "select". > >I might have been using a definition of "selection" that is=20 > different=20 > >from what you had in mind. > > > >In my mind, I was equating "seizing" with the concept of actually=20 > >reserving the AOR for ones self by PUBLISHing (or NOTIFYing) the=20 > >Appearance agent of the call state "premptively". > > > >In contrast, I was using the term "selection" to mean the=20 > local action=20 > >(on the phone) of choosing which "line" to use (i.e., the "From"=20 > >header). This is local because it does not require any=20 > publication of=20 > >state to the appearance agent. The user presses a line key, no=20 > >signalling comes out immediately (and user probably hears=20 > dial tone).=20 > >When the call is eventually made, it uses that line that was=20 > "selected"=20 > >as the originator (i.e., the From header). > > > >I am proposing that if we use these definitions, then it=20 > makes it much=20 > >clearer throughout the document what we are talking about. There are=20 > >lots of cases where we mean "selection or seizing" (because the=20 > >PUBLISH/ SUBSCRIBE is optional), and in other cases, we=20 > really mean the=20 > >"seizing". > > > >So, for example, in 10.4, messages F1-F2 are actually a=20 > "seizing", not=20 > >merely a "selection". > > > >Anyways, just think about it.=20 > > > >I think there are people who would want to implement the=20 > "line seizure" > >concept, and people who would NOT want to implement it. If=20 > it's clear=20 > >what "seizure" means, then it makes it obvious in the text=20 > what is the=20 > >optional part. > >_______________________________________________ > >BLISS mailing list > >BLISS@ietf.org > >https://www.ietf.org/mailman/listinfo/bliss > > >=20 From sgarg@cedarpointcom.com Wed Jul 15 12:43:10 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75293A6AA4 for ; Wed, 15 Jul 2009 12:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 UJLjPv8Xbmil for ; Wed, 15 Jul 2009 12:43:10 -0700 (PDT) Received: from web65614.mail.ac4.yahoo.com (web65614.mail.ac4.yahoo.com [76.13.9.82]) by core3.amsl.com (Postfix) with SMTP id E25D33A6A6C for ; Wed, 15 Jul 2009 12:43:09 -0700 (PDT) Received: (qmail 58872 invoked by uid 60001); 15 Jul 2009 19:41:41 -0000 Message-ID: <13092.58223.qm@web65614.mail.ac4.yahoo.com> X-YMail-OSG: 4Orb5SsVM1nYwPWX7tFKMvdO_qjRsbjh6XyHkPDif3nKo9AcGueyYNdDZ3.qsgVblyxB31NlXdyZw0s2HbuqB5I.Or4czTZHCsKgogfvVVkLlOjB8Ed8NLgIvoj3PPqvHbMmYzgr6uKJxB.44HmdRnQbquY1OiQ3hRYreHJIz0XpXNBPs.UvUpROXIrG_UuLuceGqKte7z6rvBZ.gjiPKNJfMqudcaAPJ6OKaFttVCIcScZ5ASscqWEgpDaAjprnm5vQYhF_hIdLt97wKo1XpkucyWUxC.HE9KNS_UvB5.0FuE5c_lNgAOOxgfMhrXRTTdw- Received: from [67.151.79.74] by web65614.mail.ac4.yahoo.com via HTTP; Wed, 15 Jul 2009 12:41:40 PDT X-RocketYMMF: emailsumitgarg X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Wed, 15 Jul 2009 12:41:40 -0700 (PDT) From: Sumit Garg To: bliss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [BLISS] draft-ietf-bliss-shared-appearances X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sgarg@cedarpointcom.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 19:43:10 -0000 I prefer 3PCC registrations as makes it easier for somebody with admin privileges to add/remove another user to the shared line without having to change the credentials for everybody at removal of user... Even though it looks complex..in practice it is simpler.. Forever, Sumit "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From shida@ntt-at.com Thu Jul 16 03:42:12 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E1B3A6904 for ; Thu, 16 Jul 2009 03:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhFhMAqK0l+X for ; Thu, 16 Jul 2009 03:42:11 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.144.11]) by core3.amsl.com (Postfix) with SMTP id 9BC493A67EB for ; Thu, 16 Jul 2009 03:42:11 -0700 (PDT) Received: (qmail 15393 invoked from network); 16 Jul 2009 10:42:47 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway04.websitewelcome.com with SMTP; 16 Jul 2009 10:42:47 -0000 Received: from softbank219005131054.bbtec.net ([219.5.131.54]:47914 helo=[10.0.1.5]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MROIv-0002RE-WE for bliss@ietf.org; Thu, 16 Jul 2009 05:35:10 -0500 Message-Id: From: Shida Schubert To: bliss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 16 Jul 2009 19:35:07 +0900 X-Mailer: Apple Mail (2.935.3) 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 Subject: [BLISS] Draft Agenda X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 10:42:12 -0000 All; I uploaded a draft agenda for our meeting in Minneapolis. http://www.ietf.org/proceedings/09jul/agenda/bliss.html Please let Jason and I know if we missed any requests and/or if you have any comments on the agenda. Thanks & Regards Shida From AUDET@nortel.com Thu Jul 16 09:31:19 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030C73A68F7 for ; Thu, 16 Jul 2009 09:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZHqFQqEtJCT for ; Thu, 16 Jul 2009 09:31:17 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id AAFC13A6918 for ; Thu, 16 Jul 2009 09:31:17 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6GGUAw05248; Thu, 16 Jul 2009 16:30:10 GMT 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, 16 Jul 2009 11:29:54 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F0503FD@zrc2hxm0.corp.nortel.com> In-Reply-To: A<719F9BBB3E7E71428A2D13F3D76C768F01E4E075@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select thread-index: AcoElF38JzjscuxfTa2jLS1ru6gFAwAMArnAABcP9gAAENAFIAAy94AwAABXyPA= References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1837@zrc2hxm0.corp.nortel.com> A <719F9BBB3E7E71428A2D13F3D76C768F01E11835@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1EFE0C7E@zrc2hxm0.corp.nortel.com> A<719F9BBB3E7E71428A2D13F3D76C768F01E4E075@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Hutton, Andrew" , "Alan Johnston" Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 16:31:19 -0000 Ok, I think we are on the same page then.=20 I was thinking something along the lines of having a "terminology section" (like most drafts) including something like: Seizing: An appearance can be seized by communicating an artificial state of "trying" prior to actually initiating a dialog, in order to appear as it was already initiating a dialog.=20 Selecting(or Not-Seizing): An appearance is merely selected (i.e., not seized) if there is no such communication of=20 artificial state of "trying" prior to initiating a dialog: i.e., the state is communicted when the dialog is actually initiated.=20 I'm not attached to using the term "selected". I would just like the distinction to be clear so when developpers read the procedures (and more importantly the example), they know which parts are optional. It's perfectly fine with me if at the end of the day, a phone can be described as "Support Appearance Seizure: yes or no" instead of "Appearance: Seizure vs Selection". > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 > Sent: Thursday, July 16, 2009 09:18 > To: Audet, Francois (SC100:3055); Alan Johnston > Cc: bliss@ietf.org > Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances:=20 > Seize vs Select >=20 > Hi All, >=20 > See below. >=20 > Regards > Andy >=20 > >-----Original Message----- > >From: Francois Audet [mailto:audet@nortel.com] > >Sent: 15 July 2009 17:19 > >To: Hutton, Andrew; Alan Johnston > >Cc: bliss@ietf.org > >Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances:=20 > >Seize vs Select > > > >I disagree. I think we need some clarification. >=20 >=20 > [Andy H] OK Clarification is always a good thing. >=20 >=20 > >We have decided already that the act of "fake publishing" a "trying"=20 > >state is OPTIONAL in this draft. This feature is really when=20 > a vendor=20 > >wants to mimic traditional behavior of a key system. > > >=20 > [Andy H] I Agree. >=20 > >Other people view this as an archaic limitation instead. Even in > >"pre-sip" implementations, many TDM PBXs have given up already > >on "seizing" lines when you press the button (the "seizing" only > >occurs when the call is actually made). > > >=20 > [Andy H] I Agree. >=20 > >So, we wisely opted to make this optional in the spec. The problem > >is that we have a bit of lack of clarity in a few places about what > >that means. > > > >Getting to specifics, if you look at example 10.4 of the spec. > >If you use a "selection model" instead of a "seizing" model, then > >messages F1-F6 do not occur. And neigther would messages F10-F11.=20 >=20 > [Andy H] I Agree. >=20 > > > >(Note that if the Appearance agent had subscribed to HelpDeksk's > >dialog state, then there would be NOTIFY instead of F10: that is > >the subject of another discussion). > > > >If we agree on this, I can volunteer to provide text if Alan wants > >it. But I'm not sure if "selection" is the proper term. An=20 > alternative > >would be to say the line is "Seized" or "Not Seized". > > >=20 > [Andy H] I agree except that I object to is any discussion about line > selection as we will not be able to agree on what is meant by a "line" > we went over this many times already it is an an appearance=20 > index which > is "seized" or "not siezed" and not a line which many people relate to > an AOR. >=20 >=20 >=20 >=20 > > > > > >> -----Original Message----- > >> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 > >> Sent: Wednesday, July 15, 2009 00:55 > >> To: Audet, Francois (SC100:3055); Alan Johnston > >> Cc: bliss@ietf.org > >> Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances:=20 > >> Seize vs Select > >>=20 > >> Hi, > >>=20 > >> If "select" is a local action in the UA to choose a "line" to=20 > >> use and this determines the what is in the from header then=20 > >> this is I believe out of scope for this draft which should=20 > >> not mention selecting lines or AOR's as this is a different=20 > >> feature. The SA draft is limited to sharing appearances of=20 > >> the same AOR. > >>=20 > >> Also if "select" is a local action at the UA that is just UI=20 > >> behaviour then probably no need to mention it at all. > >>=20 > >> Regards > >> Andy > >>=20 > >> =20 > >>=20 > >> >-----Original Message----- > >> >From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > >> On Behalf=20 > >> >Of Francois Audet > >> >Sent: 14 July 2009 22:28 > >> >To: Alan Johnston > >> >Cc: bliss@ietf.org > >> >Subject: [BLISS] draft-ietf-bliss-shared-appearances: Seize=20 > >vs Select > >> > > >> > > >> >> I changed "select" to "select/seize" globally in the=20 > >> document. I'm=20 > >> >> not sure it helps readability, but I think we need both terms. > >> > > >> >Here is an explanation what I meant with "seize" versus "select". > >> >I might have been using a definition of "selection" that is=20 > >> different=20 > >> >from what you had in mind. > >> > > >> >In my mind, I was equating "seizing" with the concept of actually=20 > >> >reserving the AOR for ones self by PUBLISHing (or NOTIFYing) the=20 > >> >Appearance agent of the call state "premptively". > >> > > >> >In contrast, I was using the term "selection" to mean the=20 > >> local action=20 > >> >(on the phone) of choosing which "line" to use (i.e., the "From"=20 > >> >header). This is local because it does not require any=20 > >> publication of=20 > >> >state to the appearance agent. The user presses a line key, no=20 > >> >signalling comes out immediately (and user probably hears=20 > >> dial tone).=20 > >> >When the call is eventually made, it uses that line that was=20 > >> "selected"=20 > >> >as the originator (i.e., the From header). > >> > > >> >I am proposing that if we use these definitions, then it=20 > >> makes it much=20 > >> >clearer throughout the document what we are talking about.=20 > >There are=20 > >> >lots of cases where we mean "selection or seizing" (because the=20 > >> >PUBLISH/ SUBSCRIBE is optional), and in other cases, we=20 > >> really mean the=20 > >> >"seizing". > >> > > >> >So, for example, in 10.4, messages F1-F2 are actually a=20 > >> "seizing", not=20 > >> >merely a "selection". > >> > > >> >Anyways, just think about it.=20 > >> > > >> >I think there are people who would want to implement the=20 > >> "line seizure" > >> >concept, and people who would NOT want to implement it. If=20 > >> it's clear=20 > >> >what "seizure" means, then it makes it obvious in the text=20 > >> what is the=20 > >> >optional part. > >> >_______________________________________________ > >> >BLISS mailing list > >> >BLISS@ietf.org > >> >https://www.ietf.org/mailman/listinfo/bliss > >> > > >>=20 > > >=20 From andrew.hutton@siemens-enterprise.com Thu Jul 16 09:31:44 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91E8A3A6D2D for ; Thu, 16 Jul 2009 09:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyHY+BLTjcmo for ; Thu, 16 Jul 2009 09:31:43 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id F18433A6891 for ; Thu, 16 Jul 2009 09:31:38 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMV00AA3UM2HL@siemenscomms.co.uk> for bliss@ietf.org; Thu, 16 Jul 2009 17:18:02 +0100 (BST) Date: Thu, 16 Jul 2009 17:17:58 +0100 From: "Hutton, Andrew" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1EFE0C7E@zrc2hxm0.corp.nortel.com> To: Francois Audet , Alan Johnston Message-id: <719F9BBB3E7E71428A2D13F3D76C768F01E4E075@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select Thread-Index: AcoElF38JzjscuxfTa2jLS1ru6gFAwAMArnAABcP9gAAENAFIAAy94Aw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1837@zrc2hxm0.corp.nortel.com> A <719F9BBB3E7E71428A2D13F3D76C768F01E11835@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1EFE0C7E@zrc2hxm0.corp.nortel.com> Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 16:31:44 -0000 Hi All, See below. Regards Andy >-----Original Message----- >From: Francois Audet [mailto:audet@nortel.com]=20 >Sent: 15 July 2009 17:19 >To: Hutton, Andrew; Alan Johnston >Cc: bliss@ietf.org >Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances:=20 >Seize vs Select > >I disagree. I think we need some clarification. [Andy H] OK Clarification is always a good thing. >We have decided already that the act of "fake publishing" a=20 >"trying" state >is OPTIONAL in this draft. This feature is really when a vendor=20 >wants to mimic traditional behavior of a key system. > [Andy H] I Agree. >Other people view this as an archaic limitation instead. Even in >"pre-sip" implementations, many TDM PBXs have given up already >on "seizing" lines when you press the button (the "seizing" only >occurs when the call is actually made). > [Andy H] I Agree. >So, we wisely opted to make this optional in the spec. The problem >is that we have a bit of lack of clarity in a few places about what >that means. > >Getting to specifics, if you look at example 10.4 of the spec. >If you use a "selection model" instead of a "seizing" model, then >messages F1-F6 do not occur. And neigther would messages F10-F11.=20 [Andy H] I Agree. > >(Note that if the Appearance agent had subscribed to HelpDeksk's >dialog state, then there would be NOTIFY instead of F10: that is >the subject of another discussion). > >If we agree on this, I can volunteer to provide text if Alan wants >it. But I'm not sure if "selection" is the proper term. An alternative >would be to say the line is "Seized" or "Not Seized". > [Andy H] I agree except that I object to is any discussion about line selection as we will not be able to agree on what is meant by a "line" we went over this many times already it is an an appearance index which is "seized" or "not siezed" and not a line which many people relate to an AOR. > > >> -----Original Message----- >> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 >> Sent: Wednesday, July 15, 2009 00:55 >> To: Audet, Francois (SC100:3055); Alan Johnston >> Cc: bliss@ietf.org >> Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances:=20 >> Seize vs Select >>=20 >> Hi, >>=20 >> If "select" is a local action in the UA to choose a "line" to=20 >> use and this determines the what is in the from header then=20 >> this is I believe out of scope for this draft which should=20 >> not mention selecting lines or AOR's as this is a different=20 >> feature. The SA draft is limited to sharing appearances of=20 >> the same AOR. >>=20 >> Also if "select" is a local action at the UA that is just UI=20 >> behaviour then probably no need to mention it at all. >>=20 >> Regards >> Andy >>=20 >> =20 >>=20 >> >-----Original Message----- >> >From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 >> On Behalf=20 >> >Of Francois Audet >> >Sent: 14 July 2009 22:28 >> >To: Alan Johnston >> >Cc: bliss@ietf.org >> >Subject: [BLISS] draft-ietf-bliss-shared-appearances: Seize=20 >vs Select >> > >> > >> >> I changed "select" to "select/seize" globally in the=20 >> document. I'm=20 >> >> not sure it helps readability, but I think we need both terms. >> > >> >Here is an explanation what I meant with "seize" versus "select". >> >I might have been using a definition of "selection" that is=20 >> different=20 >> >from what you had in mind. >> > >> >In my mind, I was equating "seizing" with the concept of actually=20 >> >reserving the AOR for ones self by PUBLISHing (or NOTIFYing) the=20 >> >Appearance agent of the call state "premptively". >> > >> >In contrast, I was using the term "selection" to mean the=20 >> local action=20 >> >(on the phone) of choosing which "line" to use (i.e., the "From"=20 >> >header). This is local because it does not require any=20 >> publication of=20 >> >state to the appearance agent. The user presses a line key, no=20 >> >signalling comes out immediately (and user probably hears=20 >> dial tone).=20 >> >When the call is eventually made, it uses that line that was=20 >> "selected"=20 >> >as the originator (i.e., the From header). >> > >> >I am proposing that if we use these definitions, then it=20 >> makes it much=20 >> >clearer throughout the document what we are talking about.=20 >There are=20 >> >lots of cases where we mean "selection or seizing" (because the=20 >> >PUBLISH/ SUBSCRIBE is optional), and in other cases, we=20 >> really mean the=20 >> >"seizing". >> > >> >So, for example, in 10.4, messages F1-F2 are actually a=20 >> "seizing", not=20 >> >merely a "selection". >> > >> >Anyways, just think about it.=20 >> > >> >I think there are people who would want to implement the=20 >> "line seizure" >> >concept, and people who would NOT want to implement it. If=20 >> it's clear=20 >> >what "seizure" means, then it makes it obvious in the text=20 >> what is the=20 >> >optional part. >> >_______________________________________________ >> >BLISS mailing list >> >BLISS@ietf.org >> >https://www.ietf.org/mailman/listinfo/bliss >> > >>=20 > From alan@sipstation.com Thu Jul 16 11:42:05 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD91A28C195 for ; Thu, 16 Jul 2009 11:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1c68-MnONeQ0 for ; Thu, 16 Jul 2009 11:42:04 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 8894D3A6DD2 for ; Thu, 16 Jul 2009 11:42:04 -0700 (PDT) Received: from 24-107-145-55.dhcp.stls.mo.charter.com ([24.107.145.55] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MRVuc-000AJv-CM; Thu, 16 Jul 2009 18:42:34 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.55 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+N1bQaO0TSjMvHJq3bnYIFSUC6I/IbEcI= Message-ID: <4A5F7496.6030401@sipstation.com> Date: Thu, 16 Jul 2009 13:42:30 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1837@zrc2hxm0.corp.nortel.com> A <719F9BBB3E7E71428A2D13F3D76C768F01E11835@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1EFE0C7E@zrc2hxm0.corp.nortel.com> A<719F9BBB3E7E71428A2D13F3D76C768F01E4E075@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F0503FD@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F0503FD@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 18:42:05 -0000 So it sounds like we are all on the same page, that we are talking about only one AOR, the shared appearances AOR. So lines or alternative AORs are not mentioned in this document. See my comments below. Thanks, Alan Francois Audet wrote: > Ok, I think we are on the same page then. > > I was thinking something along the lines of having a "terminology > section" (like most drafts) including something like: > > Seizing: An appearance can be seized by communicating an > artificial state of "trying" prior to actually initiating a dialog, > in order to appear as it was already initiating a dialog. > > Selecting(or Not-Seizing): An appearance is merely selected > (i.e., not seized) if there is no such communication of > artificial state of "trying" prior to initiating a dialog: > i.e., the state is communicted when the dialog is actually > initiated. > So, using this terminology, selecting is a UI operation that has no protocol implications on the wire. I think we already cover this in the draft, but don't talk about the UI. From the protocol perspective, there are four options when it comes to appearances: 1. The UA seizes the appearance prior to sending the INVITE - this is the old fashioned mechanism and requires the PUBLISH prior to the INVITE. 2. The UA just sends the INVITE and the Appearance Agent assigns the appearance number for it. The UA will update its UI once it knows the appearance number. 3. The UA does not want to assign an appearance number for a call using the shared AOR. This is the consultation call case. The PUBLISH must be sent before the INVITE so the Appearance Agent does not assign a new appearance number by mistake. 4. The UA is going to take or join another appearance, so it wants to reuse the existing appearance number. Again, a PUBLISH must be sent before the INVITE so the Appearance Agent does not assign a new appearance number by mistake. Also, the joined-dialog or replaced-dialog elements tell the Appearance Agent that a take or join is in progress, so it does not reject the PUBLISH with a 409 due to the appearance number already being in use. > I'm not attached to using the term "selected". I would just > like the distinction to be clear so when developpers read > the procedures (and more importantly the example), they > know which parts are optional. > > It's perfectly fine with me if at the end of the day, > a phone can be described as "Support Appearance Seizure: yes or no" > instead of "Appearance: Seizure vs Selection". > OK, but even UAs that do no seize appearances must be able to handle scenarios 2-4 above, some of which involve sending the PUBLISH prior to the INVITE. > >> -----Original Message----- >> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >> Sent: Thursday, July 16, 2009 09:18 >> To: Audet, Francois (SC100:3055); Alan Johnston >> Cc: bliss@ietf.org >> Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances: >> Seize vs Select >> >> Hi All, >> >> See below. >> >> Regards >> Andy >> >> >>> -----Original Message----- >>> From: Francois Audet [mailto:audet@nortel.com] >>> Sent: 15 July 2009 17:19 >>> To: Hutton, Andrew; Alan Johnston >>> Cc: bliss@ietf.org >>> Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances: >>> Seize vs Select >>> >>> I disagree. I think we need some clarification. >>> >> [Andy H] OK Clarification is always a good thing. >> >> >> >>> We have decided already that the act of "fake publishing" a "trying" >>> state is OPTIONAL in this draft. This feature is really when >>> >> a vendor >> >>> wants to mimic traditional behavior of a key system. >>> >>> >> [Andy H] I Agree. >> >> >>> Other people view this as an archaic limitation instead. Even in >>> "pre-sip" implementations, many TDM PBXs have given up already >>> on "seizing" lines when you press the button (the "seizing" only >>> occurs when the call is actually made). >>> >>> >> [Andy H] I Agree. >> >> >>> So, we wisely opted to make this optional in the spec. The problem >>> is that we have a bit of lack of clarity in a few places about what >>> that means. >>> >>> Getting to specifics, if you look at example 10.4 of the spec. >>> If you use a "selection model" instead of a "seizing" model, then >>> messages F1-F6 do not occur. And neigther would messages F10-F11. >>> >> [Andy H] I Agree. >> >> >>> (Note that if the Appearance agent had subscribed to HelpDeksk's >>> dialog state, then there would be NOTIFY instead of F10: that is >>> the subject of another discussion). >>> >>> If we agree on this, I can volunteer to provide text if Alan wants >>> it. But I'm not sure if "selection" is the proper term. An >>> >> alternative >> >>> would be to say the line is "Seized" or "Not Seized". >>> >>> >> [Andy H] I agree except that I object to is any discussion about line >> selection as we will not be able to agree on what is meant by a "line" >> we went over this many times already it is an an appearance >> index which >> is "seized" or "not siezed" and not a line which many people relate to >> an AOR. >> >> >> >> >> >>> >>>> -----Original Message----- >>>> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >>>> Sent: Wednesday, July 15, 2009 00:55 >>>> To: Audet, Francois (SC100:3055); Alan Johnston >>>> Cc: bliss@ietf.org >>>> Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances: >>>> Seize vs Select >>>> >>>> Hi, >>>> >>>> If "select" is a local action in the UA to choose a "line" to >>>> use and this determines the what is in the from header then >>>> this is I believe out of scope for this draft which should >>>> not mention selecting lines or AOR's as this is a different >>>> feature. The SA draft is limited to sharing appearances of >>>> the same AOR. >>>> >>>> Also if "select" is a local action at the UA that is just UI >>>> behaviour then probably no need to mention it at all. >>>> >>>> Regards >>>> Andy >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] >>>>> >>>> On Behalf >>>> >>>>> Of Francois Audet >>>>> Sent: 14 July 2009 22:28 >>>>> To: Alan Johnston >>>>> Cc: bliss@ietf.org >>>>> Subject: [BLISS] draft-ietf-bliss-shared-appearances: Seize >>>>> >>> vs Select >>> >>>>> >>>>>> I changed "select" to "select/seize" globally in the >>>>>> >>>> document. I'm >>>> >>>>>> not sure it helps readability, but I think we need both terms. >>>>>> >>>>> Here is an explanation what I meant with "seize" versus "select". >>>>> I might have been using a definition of "selection" that is >>>>> >>>> different >>>> >from what you had in mind. >>>> >>>>> In my mind, I was equating "seizing" with the concept of actually >>>>> reserving the AOR for ones self by PUBLISHing (or NOTIFYing) the >>>>> Appearance agent of the call state "premptively". >>>>> >>>>> In contrast, I was using the term "selection" to mean the >>>>> >>>> local action >>>> >>>>> (on the phone) of choosing which "line" to use (i.e., the "From" >>>>> header). This is local because it does not require any >>>>> >>>> publication of >>>> >>>>> state to the appearance agent. The user presses a line key, no >>>>> signalling comes out immediately (and user probably hears >>>>> >>>> dial tone). >>>> >>>>> When the call is eventually made, it uses that line that was >>>>> >>>> "selected" >>>> >>>>> as the originator (i.e., the From header). >>>>> >>>>> I am proposing that if we use these definitions, then it >>>>> >>>> makes it much >>>> >>>>> clearer throughout the document what we are talking about. >>>>> >>> There are >>> >>>>> lots of cases where we mean "selection or seizing" (because the >>>>> PUBLISH/ SUBSCRIBE is optional), and in other cases, we >>>>> >>>> really mean the >>>> >>>>> "seizing". >>>>> >>>>> So, for example, in 10.4, messages F1-F2 are actually a >>>>> >>>> "seizing", not >>>> >>>>> merely a "selection". >>>>> >>>>> Anyways, just think about it. >>>>> >>>>> I think there are people who would want to implement the >>>>> >>>> "line seizure" >>>> >>>>> concept, and people who would NOT want to implement it. If >>>>> >>>> it's clear >>>> >>>>> what "seizure" means, then it makes it obvious in the text >>>>> >>>> what is the >>>> >>>>> optional part. >>>>> _______________________________________________ >>>>> BLISS mailing list >>>>> BLISS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/bliss >>>>> >>>>> > > From alan@sipstation.com Thu Jul 16 11:47:12 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59493A6DD2 for ; Thu, 16 Jul 2009 11:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 esmiqJ7sopg1 for ; Thu, 16 Jul 2009 11:47:11 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 426A13A68B8 for ; Thu, 16 Jul 2009 11:47:11 -0700 (PDT) Received: from 24-107-145-55.dhcp.stls.mo.charter.com ([24.107.145.55] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MRVzZ-000D20-S3; Thu, 16 Jul 2009 18:47:42 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.55 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18+E8FWbt1yfNpng7oUPjQhH2e4NfVzub4= Message-ID: <4A5F75CA.6010102@sipstation.com> Date: Thu, 16 Jul 2009 13:47:38 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1950@zrc2hxm0.corp.nortel.com> <719F9BBB3E7E71428A2D13F3D76C768F01E4D90B@GBNTHT12009MSX.gb002.siemens.net> <4ff4e7370907150845j22311aa1u876039de3ea058e6@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1EFE0CCD@zrc2hxm0.corp.nortel.com> <4ff4e7370907150936m73455773jc4107e1031a0c0ab@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1EFE0D71@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFE0D71@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 18:47:12 -0000 So you are proposing that Bob would register like this: REGISTER To: From: but when challenged, provide the credentials for user Bob instead of the HelpDesk? This seems like a bad idea to me. Why isn't this 3rd party registration: REGISTER To: From: And when challenged, Bob provides his credentials. The Registrar is provisioned to allow Bob to register against HelpDesk and everything works. Alternatively, you could have Bob register using: REGISTER To: From: But he will need to have the credentials for HelpDesk when challenged. Anyway, we and other vendors already implement this feature this way, so the draft must support it. A given system can choose not to use it. Thanks, Alan Francois Audet wrote: > Well, yes. > > However, as per my email, that's not the only alternative. > > You could use "user=alice" for authentication in HTTP digest if, for > whatever reason, you prefer to have users authenticating as themselves > instead of using the shared appearance. That advantage is that users > don't need to know 2 username/passwords. The disadvantage is that you > need more infrastructure in the back-end to allow Alice to log in as > Boss with her own credential. > > I was thinking that both model should be allowed. Like in most SIP > client today, you can put a different HTTP credential (if required). > Otherwise, it would default to the one used for registering (i.e., the > From). > > So in both cases, there is no 3rd party registration per se (as per > the definition in 3261). > > That was my thought > > ------------------------------------------------------------------------ > *From:* Venkatesh [mailto:vvenkatar@gmail.com] > *Sent:* Wednesday, July 15, 2009 09:36 > *To:* Audet, Francois (SC100:3055) > *Cc:* Hutton, Andrew; Alan Johnston; bliss@ietf.org > *Subject:* Re: [BLISS] draft-ietf-bliss-shared-appearances: > Provisioningconsiderations > > Sure, but it means the secretary is now using HelpDesk (or "boss" > in the example) credentials to register if you didn't have 3rd > party registration semantics? > > Venkatesh > > On Wed, Jul 15, 2009 at 9:29 AM, Francois Audet > wrote: > > Yes, of course HelpDesk could be the Boss instead. > > ------------------------------------------------------------------------ > *From:* Venkatesh [mailto:vvenkatar@gmail.com > ] > *Sent:* Wednesday, July 15, 2009 08:46 > *To:* Hutton, Andrew > *Cc:* Audet, Francois (SC100:3055); Alan Johnston; > bliss@ietf.org > *Subject:* Re: [BLISS] > draft-ietf-bliss-shared-appearances: > Provisioningconsiderations > > Andrew: > > Thanks for pointing it out. I missed the change as well. > Honestly, one of the main use cases for BLA/SLA was to > address a boss/secretary scenario. In these cases, the > secretary is really monitoring a "Boss" extension; so from > a "ownership" purpose, the AoR is really that of the boss > and not a "common" address. > > Venkatesh > > On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andrew > > wrote: > > > Indeed this getting interesting. > > In version -02 the REGISTER in section 10.1 showed a > normal 1st party > registration by alice but -03 shows a third party > registration which is > a significant change. > > I must admit I missed the text in -02 which stated > "Bob and Alice are in > an appearance group identified by Alice's AOR. Bob > REGISTERs using > contact sip:bob@ua2.example.com > " and I should have > commented on that > earlier. > > As the draft is about sharing appearances of a single > AOR then surely > third party registration is not necessary as it could > be that there is > simply two helpdesk phones using a single AOR and > there is no "alice" or > "bob" AOR's. So in the simplest case the REGISTER > would be: > > REGISTER sip:registrar.example.com > SIP/2.0 > Via: SIP/2.0/UDP ua1.example.com > ;branch=z9hG4bK527b54da8ACC7B09 > From: >;tag=CDF9A668-909E2BDD > To: > > CSeq: 2 REGISTER > Call-ID: d3281184-518783de-cc23d6bb > Contact: > > > Regards > Andy > > > >-----Original Message----- > >From: bliss-bounces@ietf.org > > [mailto:bliss-bounces@ietf.org > ] > >On Behalf Of Francois Audet > >Sent: 14 July 2009 23:30 > >To: Alan Johnston > >Cc: bliss@ietf.org > >Subject: [BLISS] draft-ietf-bliss-shared-appearances: > >Provisioningconsiderations > > > > > >> > Section 9: > >> > > >> > Delete first paragraph. > >> > > >> > Clarify the UA also REGISTERs to the AOR. Discuss the > >> security implications, i.e., > >> > you either use the same shared username/password, > or you > >> use a different username/password > >> > for HTTP digest, per user. Perhaps the security > >> considerations can be described in section 15. > >> > > >> > > >> > >> I added text about authorization for third party > registrations and > >> publication. A little more text on this would be > helpful. > > > >Ah-ah... Now we are getting down to business. > > > >I am now looking at new section 10.1 on registration, > and I see that > >you are using indeed third-party registration (with > To=HelpDesk, > >From=Alice). > > > >So, this would be one way to to it. > > > >Another way would be to NOT use third-party > registration at all. In > >other words, Alice would send a first party > registration on behalf > >of HelpDesk (ie.., To=HelpDesk, From=Alice). > > > >Wouldn't that work? > > > >Then there is the whole issue of authentication with > HTTP-Digest. > >I guess one could use username="HelpDesk". In this > case, the > >idea is that > >Alice would need to know the credentials for HelpDesk. > >Another way would be to use username="alice" instead > (i.e., > >her own credentials). > >The decisions on which authentication you use would > depend on > >need of the > >administrator. > > > >Have you tought about this? Am I off based? > >_______________________________________________ > >BLISS mailing list > >BLISS@ietf.org > >https://www.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss > > > From alan@sipstation.com Thu Jul 16 11:47:48 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055AA3A6DD2 for ; Thu, 16 Jul 2009 11:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 LXgLVPcsLNRj for ; Thu, 16 Jul 2009 11:47:47 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 4FE0E3A6DC3 for ; Thu, 16 Jul 2009 11:47:47 -0700 (PDT) Received: from 24-107-145-55.dhcp.stls.mo.charter.com ([24.107.145.55] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MRW09-000DHO-MK; Thu, 16 Jul 2009 18:48:19 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.55 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+sUIFRgB7cvA2VUSbM28n13usieYnPQ44= Message-ID: <4A5F75EF.3040801@sipstation.com> Date: Thu, 16 Jul 2009 13:48:15 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: sgarg@cedarpointcom.com References: <108654.2415.qm@web65616.mail.ac4.yahoo.com> In-Reply-To: <108654.2415.qm@web65616.mail.ac4.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 18:47:48 -0000 Agree 100%. Flexibility like this is important. Thanks, Alan Sumit Garg wrote: > I prefer 3PCC registrations as makes it easier for somebody with admin privileges to add/remove another user to the shared line without having to change the credentials for everybody at removal of user... > Even though it looks complex..in practice it is simpler.. > > > Forever, > Sumit > "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." > -- George Bernard Shaw > > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss > > From alan@sipstation.com Thu Jul 16 12:09:35 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8D828C21E for ; Thu, 16 Jul 2009 12:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 hzZpN26VUQAY for ; Thu, 16 Jul 2009 12:09:33 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 7ABF43A6894 for ; Thu, 16 Jul 2009 12:09:19 -0700 (PDT) Received: from 24-107-145-55.dhcp.stls.mo.charter.com ([24.107.145.55] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MRWL0-000PRA-DN for bliss@ietf.org; Thu, 16 Jul 2009 19:09:51 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.55 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18hEvulrDl1nCwpGCEimOprqb18Zw5mX30= Message-ID: <4A5F7AFC.90602@sipstation.com> Date: Thu, 16 Jul 2009 14:09:48 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: BLISS Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [BLISS] Fwd: Review of draft-bliss-shared-appearances X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 19:09:35 -0000 Tim, Raji, & Harsh, Thanks for doing this review. See my comments below. Thanks, Alan > *From: *"Ross, Timothy I (Tim)" > > *Date: *July 3, 2009 12:47:20 AM JST > *To: *>, > > > *Cc: *"Chinnappa, Raji (Raji)" >, "Mendiratta, Harsh V (Harsh)" > > > *Subject: **Review of draft-bliss-shared-appearances* > > Hi Jason and Shida, > > Alan asked if I would like to review the shared appearance draft. > Three of us got together and came up with these comments. Hope they help. > > > Generally the shared appearance looks good. We spent a couple of > weeks seeing how we would adopt it into our system, and it is a pretty > natural fit. There were a few places where we struggled a bit, and in > all but one (comment 3) we found solutions. The comments under “Main > Comments” address these struggles. > > > Main Comments: > > 1) The draft does not discuss Alice and Bob being on separate Proxies > (SIP trapezoid). This has a few subtleties: > a) If Bob is using TLS and his UA only accepts connections > from his own Proxy, then his UA will need to use a gruu (obtained from > Bob’s Proxy) when registering to Alice's Appearance Group. This means > that Bob's UA would need to register twice, once with his own proxy to > get a gruu, then again with Alice's proxy, passing the gruu as the > contact. The gruu would also be needed if Bob’s UA is non-routable. > b) Sip Messages to Bob's Bridged Appearance of Alice' > Appearance Group need to go through Alice's Proxy, so that Alice's > Proxy can see these calls and report their state to the Appearance > Agent. Separate Proxies need to be considered. Some cases: > i) INVITEs to Alice's AOR – no problem here > ii) INVITEwJoin from Alice to Bob -- This message is to Bob’s Contact > so would not normally go through Alice’s Proxy. This looks ok at > first, because this scenario requires that Alice’s UA PUBLISHes to the > Appearance Group before sending the INVITEwJoin. But this runs in to > trouble in later stages of the call where the Appearance Agent will > not receive a DSE PUBLISH ( 180 Ringing, 200 OK, BYE). In these later > stages, the Appearance Agent needs to get call state from the Alice’s > Proxy so it can send the DSE NOTIFYs to the appearance group UAs. This > can be solved with Bob obtaining a gruu from Alice’s Proxy, or by > Alice’s UA inserting a route header to route the call through Alice’s > Proxy. > iii) INVITEwReplaces from Alice to Carol – this is pretty much the > same problem as INVITEwJoin except here if Carol was on a separate > Proxy, her UA would not obtain a gruu from Alice’s Proxy, so a gruu > won’t make the INVITE traverse Alice’s Proxy. This has to use a route > header (at least that is all we can see) > iv) INVITE sent from Carol to Bob’s contact that was discovered > through Reg Event Package Subscription for Alice’s AOR -- Again the > same sort of problem, but this time, Carol’s UA would not know to add > a route header for Alice’s Proxy. Carol is not part of the Appearance > Group. Here if Bob’s Contact is a gruu from Alice’s Proxy, then > Alice’s Proxy would see the INVITE. > > > > > If Bob’s UA needs a gruu from Alice’s Proxy to solve 1.a.iv above, and > if Bob's UA is using TLS, then Bob’s UA will need to nest the gruus so > that an INVITE to his contact/gruu would go through both Alice's Proxy > and Bob's Proxy. This looks ok in the gruu draft. Bob would get a > gruu from his own Proxy, and then register with that gruu to Alice's > Proxy, asking for another gruu. The gruus should then nest. Then all > INVITES that end up on Bob’s Shared Appearance for Alice will traverse > Alice’s then Bob’s Proxy. > > c) With separate proxies, we assume that when Bob's UA > registers with Alice's Appearance Group, Bob's proxy will authenticate > Bob's credentials, not Alice's, so that the REGISTER should traverse > Bob's proxy first. The REGISTER message can add a route header to > Bob's Proxy, but is this enough to ensure that Bob's Proxy does the > authentication, and that Alice's Proxy trusts it? Does authentication > on a trapezoidal REGISTER work the same way as a trapezoidal INVITE? > d) When Bob sends an INVITE on his shared appearance for > Alice’s Appearance Group the INVITE needs to go through Bob’s Proxy, > then Alice’s. Bob’s Proxy is needed to challenge Bob’s credentials, > and Alice’s Proxy is needed to report Call events to the Appearance > Agent. Bob’s Proxy can be traversed with a route header. Alice’s > Proxy is a bit trickier, and Bob’s Proxy would have to route the call > to Alice’s Proxy based on the “From” header or Contact (if a contact > parameter is defined to identify the contact as a Shared Appearance to > Alice (see end of comment 2)) I think that this all does work as long as Alice and Bob use GRUUs and they use their GRUU from the initial registration as the Contact for their 3rd party registration. We should probably include some text in the draft about this. > 2) The draft does not discuss (or we missed it) how Bob's > UA distinguishes its own calls from Alice's Appearance Group's calls. > We assume the "To" header is used, but this may lead to trouble. > Consider a call to "Sales@example.com " > that is forwarded to Alice. When Bob's UA gets the call, the "To" > header will be "Sales@example.com ", and not > "Alice@example.com ". Bob's UA may then > need then to rely on history-info. > > If it is legitimate for Carol to INVITE Bob's contact discovered > through a Registration Event Package Subscription to Alice’s AOR, then > it is difficult for Bob's UA to know that this is an INVITE to the > Shared Appearance, and not his regular appearance. The "To" header > would be for Bob's contact, and history-info would not mention Alice's > AOR. > > A gruu could solve this problem because it contains Alice’s AOR, but > only if it is a public gruu. > > Instead of relying on a combination of “To” header, history-info and > public gruu, Bob's UA could tag his Contact with a contact parameter > distinguishing the Contact as an "Alice Appearance Group" Contact (ex. > Contact: ;appearnacegroup=alice@example.com > ). This would put Bob's UA > in control of distinguishing incoming INVITES and not have it rely on > the rest of system. Adding an Appearance Group parameter to the > Contact does not have same problems that adding an appearance number > parameter has. I think that either the From or the use of a different Contact URI (or GRUU) should solve this. > > > 3) The draft leverages the Dialog State Event ESC but restricts the > DSE PUBLISHes sent by the UAs. This terse PUBLISHing seems to > conflict with the ESC/PUBLISH RFC (3903). The Shared Appearance draft > states that "In some cases, the Appearance Agent may not have full > access to the complete dialog state of some or all of the UAs in the > group. If this is the case, the Appearance Agent will subscribe to the > dialog state of individual UAs in the group to obtain this > information." This seems to require that the appearance agent (an > extended DSE ESC) subscribe to the group UAs, while our reading of > 3903 for DSEs would have the UAs publish all these events by default. This is not the normal mode for this feature. The normal mode is that UAs PUBLISH, but not for every dialog state event. > > Reducing the PUBLISH traffic is a great idea, but I think it belongs > within the definition of DSE ESCs and not just in the shared > appearance draft. All DSE ESC’s have this same traffic problem. > There also may need to be some sort of query to allow UAs and > Appearance Agents to go into this terse mode, allowing default DSE > ESCs/UAs to work. Does it help to think of this feature as having an implied filter for dialog state events? This filter is such that most PUBLISHes don't get sent, just the ones we are interested in. > > This is really the only part of the draft that is giving us trouble. > We have already defined a DSE Event State Compositor, and all UAs > PUBLISH DSE events to it. Extending our DSE ECS to be an Appearance > Agent is a very natural fit, except that the terse PULISING in the > Shared Appearance draft seems to conflict with our interpretation of > what a DSE ESC and supporting UAs should be. We don’t know how to > resolve this while still following both RFC 3903 and the shared > appearance draft. > > > > Less Main Comments: > > 4) Starting Appearance numbers with 0 confused me. When first seeing > this, I thought “0” may have special meaning like "no appearance". It > became clear that this was not so after further reading. I think > starting appearance numbers with “1” would be clearer. I don't know - this draft has been around for many years, starting at 0. It might cause backwards compatibility problems if we change it now. > > > 5) Example 10.1 > > In example 10.1, it would have been more interesting to > see Bob's registration/subscriptions to the Appearance Group > identified with Alice's AOR instead of seeing Alice’s > registrations/subscriptions. Bob’s registration (I think) would look > like a third party registration. And I assume it should challenge for > Bob's credentials, and not Alice's. Yes, I have made this change, and it has created a discussion about 3rd party registration. > > 6) Example 10.2 > > What happens if some one else, maybe another proxy adds an > alert-info to the message. Does the "Proxy" then add the "appearance" > parameter to that alert-info? Does it remove the previous alert-info > and add its own? I added some text to cover this case. I think the proxy applies normal Alert-Info policies - that is, keeps ones it trusts, strips ones it does not. > > 6a) Example 10.2 > "However, if Carol answers both Alice and Bob and keeps > both dialogs active, then the Appearance Agent will need to resolve > the situation by moving either Alice or Bob's dialog to a different > appearance." --> Shouldn't this end up being a joined call between > Alice, Bob and Carol?. Same as if Bob answered the call, the Alice > sent and INVITEwJoin? This would be true if the media were mixed. However, if Carol does not mix the media but keeps the two calls separate (i.e. one on hold, one active), then this is different from the Join case. > > 7) Several of the examples are missing the dashed special > communications line between the proxy and the appearance agent > (<------>: like the dashed line between F1 and F2 in example 10.2). > Putting these in would clarify the examples. When reading it at > first, I was not sure if this special communication was missing, or > the PUBLISHes were missing. These are missing in Examples 10.3, 10.4, > 10.5?, 10.6, 10.7, 10.9, 10.10, 10.11?, 10.13. I tried to add them all in - let me know if I missed any. > > 8) Example 10.6 > "Bob and Carol are in a dialog, created in one of the > previous two call flows" --> Previous example (10.5, one of the > “previous two call flows”) does not allocate appearance number, but > 10.6 de-allocates it. Right - fixed the reference. > > 9) Example 10.8. > I think this call from Bob is from a regular appearance, > not his shared appearance to Alice. I think this should be made > clear. I wasn't sure if it was from Bob’s shared appearance, or Bob’s > regular appearance. Good catch - this was a mistake which has been fixed. > > 9a) Example 10.8 > Shouldn't the DSE NOTIFY F16 be from Alice@example.com > and not Bob@example.com > ? > I'm not sure if this is fixed or not with the renumbering of the examples. Can you check? > 10) Example 10.12 discusses outgoing/outgoing race condition. > Examples for the other two race conditions would be good. > Outgoing/Incoming and Incoming/Incoming. Depending on the > Proxy<--->Appearance agent link, outgoing/incoming may have problems Good idea - I added the Incoming/Outgoing. The Incoming/Incoming one I think would only happen if the Alert-Info appearance didn't match the NOTIFY appearance, and this is mentioned in the text. > > 11) Appendix A > "For example, the proxy could fetch this information by > initiating a > SUBSCRIBE request with Expires: 0 to the Appearance Agent > for the AOR > to fetch the list of lines that are in use. > Alternatively, it could > act like a UA that is a part of the appearance group and > SUBSCRIBE to > the State-Agent like any other UA. " --> This has a small > outgoing/incoming race condition. Just after the proxy polls for a > free appearance number on an incoming INVITE, another UA could request > an appearance number with a DSE PUBLISH. That UA could pick and get > the same appearance number as the Proxy chooses from the DSE poll. We got rid of this section. > > 12) Example 10.7 > When Carol hangs up F48, does NOTIFY 52 show "terminated" > but strip out the appearance number? The appearance number is now in > use between Alice and Carol. I worry that if NOTIFY F52 shows > terminated with the same used appearance number, UAs may mistakenly > think the number is free. I think we dealt with this race condition using the joined-dialog and replaced-dialog elements. Let me know if you still think this is a problem. > > > Questions > > Q1) Example 10.2 > > Can the Notifies F2 - F4 come after the INVITE F7? I > assume both ways work, and both are possible. > > Yes, I included text saying this. > > > > Trivial Comments > > T1) Section 13.1 refers to 5.1.1 and 5.1.2. Neither one exists. Think > they actually mean 13.1.1 and 13.1.2 > > T2) page 5 (wording) > > "The sharing or appearance of these lines between a number > of phones is what gives this feature its." -> its name. > > T3) page 9 (wording) > > "The Appearance Agent learns the group state > either dialog state publications from members." -> missing words > Thanks for the nits. > Harsh, Raji, Tim > > > Tim Ross > 1-732-852-2104 > tiross@avaya.com > From AUDET@nortel.com Thu Jul 16 12:14:16 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2373A6D94 for ; Thu, 16 Jul 2009 12:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 GJRGbmXIdes9 for ; Thu, 16 Jul 2009 12:14:15 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6FB3E3A69C1 for ; Thu, 16 Jul 2009 12:14:14 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6GJD0D06870; Thu, 16 Jul 2009 19:13:00 GMT 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, 16 Jul 2009 14:13:51 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F050809@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5F75CA.6010102@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations thread-index: AcoGRe0lXBxaYQOcQF2l0AXfkHEDMgAAFSeA References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <4A5C9E6E.6030001@sipstation.com> <1ECE0EB50388174790F9694F77522CCF1EFA1950@zrc2hxm0.corp.nortel.com> <719F9BBB3E7E71428A2D13F3D76C768F01E4D90B@GBNTHT12009MSX.gb002.siemens.net> <4ff4e7370907150845j22311aa1u876039de3ea058e6@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1EFE0CCD@zrc2hxm0.corp.nortel.com> <4ff4e7370907150936m73455773jc4107e1031a0c0ab@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1EFE0D71@zrc2hxm0.corp.nortel.com> <4A5F75CA.6010102@sipstation.com> From: "Francois Audet" To: "Alan Johnston" Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 19:14:16 -0000 I don't have a strong opinion one way or another, but I think=20 the point is that we decide, and document it. It's not clear to me why the first method (3rd party authentication) is "a bad idea" and the second one (3rd party registration) is a good one. Can you clarify why it's bad? I *think* (I could be wrong) the 3rd party authentication would be = supported by any UA today that supports a separate "Authorization name" (or "realm = auth" or whatever it is called). In contast, I haven't seen many UAs supporting = 3rd=20 party registration. Furthermore, in 3261, your would assume that the username in the = credentials be the same as the userinfo part of the To header (3261/26.3.2.1). In = what you are describing here for 3rd party registration, in contast, you are using = for the username,=20 the userinfo of the From header.=20 In other words, any way we choose to go, we are changing the way you'd = normally expect=20 authentication to work. Anyways, to summarize: I don't have a strong opinion. Just pick one, and = document it in the draft. I think leaving it open to interpretation will cause = interoperability issues. ---- PS: Finally, for the last case in your email, i.e., = From/To/Http-digest-credentials =3D HelpDesk, we are in 100% agreement. That's also what we have done. We should = describe it in the text. > -----Original Message----- > From: Alan Johnston [mailto:alan@sipstation.com]=20 > Sent: Thursday, July 16, 2009 11:48 > To: Audet, Francois (SC100:3055) > Cc: Venkatesh; Hutton, Andrew; bliss@ietf.org > Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances:=20 > Provisioningconsiderations >=20 > So you are proposing that Bob would register like this: >=20 > REGISTER > To: > From: >=20 > but when challenged, provide the credentials for user Bob=20 > instead of the HelpDesk? This seems like a bad idea to me. =20 > Why isn't this 3rd party > registration: >=20 > REGISTER > To: > From: >=20 > And when challenged, Bob provides his credentials. The=20 > Registrar is provisioned to allow Bob to register against=20 > HelpDesk and everything works. Alternatively, you could have=20 > Bob register using: >=20 > REGISTER > To: > From: >=20 > But he will need to have the credentials for HelpDesk when challenged. >=20 > Anyway, we and other vendors already implement this feature=20 > this way, so the draft must support it. A given system can=20 > choose not to use it. >=20 > Thanks, > Alan >=20 > Francois Audet wrote: > > Well, yes. > > =20 > > However, as per my email, that's not the only alternative. > > =20 > > You could use "user=3Dalice" for authentication in HTTP=20 > digest if, for=20 > > whatever reason, you prefer to have users authenticating as=20 > themselves=20 > > instead of using the shared appearance. That advantage is=20 > that users=20 > > don't need to know 2 username/passwords. The disadvantage=20 > is that you=20 > > need more infrastructure in the back-end to allow Alice to=20 > log in as=20 > > Boss with her own credential. > > =20 > > I was thinking that both model should be allowed. Like in most SIP=20 > > client today, you can put a different HTTP credential (if required). > > Otherwise, it would default to the one used for registering=20 > (i.e., the=20 > > From). > > =20 > > So in both cases, there is no 3rd party registration per se (as per=20 > > the definition in 3261). > > =20 > > That was my thought > > > > =20 > -------------------------------------------------------------- > ---------- > > *From:* Venkatesh [mailto:vvenkatar@gmail.com] > > *Sent:* Wednesday, July 15, 2009 09:36 > > *To:* Audet, Francois (SC100:3055) > > *Cc:* Hutton, Andrew; Alan Johnston; bliss@ietf.org > > *Subject:* Re: [BLISS] draft-ietf-bliss-shared-appearances: > > Provisioningconsiderations > > > > Sure, but it means the secretary is now using HelpDesk=20 > (or "boss" > > in the example) credentials to register if you didn't have 3rd > > party registration semantics? > > > > Venkatesh > > > > On Wed, Jul 15, 2009 at 9:29 AM, Francois Audet=20 > > > wrote: > > > > Yes, of course HelpDesk could be the Boss instead. > > > > =20 > -------------------------------------------------------------- > ---------- > > *From:* Venkatesh [mailto:vvenkatar@gmail.com > > ] > > *Sent:* Wednesday, July 15, 2009 08:46 > > *To:* Hutton, Andrew > > *Cc:* Audet, Francois (SC100:3055); Alan Johnston; > > bliss@ietf.org > > *Subject:* Re: [BLISS] > > draft-ietf-bliss-shared-appearances: > > Provisioningconsiderations > > > > Andrew: > > > > Thanks for pointing it out. I missed the change as well. > > Honestly, one of the main use cases for BLA/SLA was to > > address a boss/secretary scenario. In these cases, the > > secretary is really monitoring a "Boss"=20 > extension; so from > > a "ownership" purpose, the AoR is really that=20 > of the boss > > and not a "common" address. > > > > Venkatesh > > > > On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andrew > > > > wrote: > > > > > > Indeed this getting interesting. > > > > In version -02 the REGISTER in section 10.1 showed a > > normal 1st party > > registration by alice but -03 shows a third party > > registration which is > > a significant change. > > > > I must admit I missed the text in -02 which stated > > "Bob and Alice are in > > an appearance group identified by Alice's AOR. Bob > > REGISTERs using > > contact sip:bob@ua2.example.com > > " and I=20 > should have > > commented on that > > earlier. > > > > As the draft is about sharing appearances=20 > of a single > > AOR then surely > > third party registration is not necessary=20 > as it could > > be that there is > > simply two helpdesk phones using a single AOR and > > there is no "alice" or > > "bob" AOR's. So in the simplest case the REGISTER > > would be: > > > > REGISTER sip:registrar.example.com > > SIP/2.0 > > Via: SIP/2.0/UDP ua1.example.com > > =20 > ;branch=3Dz9hG4bK527b54da8ACC7B09 > > From: > =20 > >;tag=3DCDF9A668-909E2BDD > > To: > > > > CSeq: 2 REGISTER > > Call-ID: d3281184-518783de-cc23d6bb > > Contact: > > > > > > Regards > > Andy > > > > > > >-----Original Message----- > > >From: bliss-bounces@ietf.org > > > > [mailto:bliss-bounces@ietf.org > > ] > > >On Behalf Of Francois Audet > > >Sent: 14 July 2009 23:30 > > >To: Alan Johnston > > >Cc: bliss@ietf.org > > >Subject: [BLISS]=20 > draft-ietf-bliss-shared-appearances: > > >Provisioningconsiderations > > > > > > > > >> > Section 9: > > >> > > > >> > Delete first paragraph. > > >> > > > >> > Clarify the UA also REGISTERs to the=20 > AOR. Discuss the > > >> security implications, i.e., > > >> > you either use the same shared=20 > username/password, > > or you > > >> use a different username/password > > >> > for HTTP digest, per user. Perhaps the security > > >> considerations can be described in section 15. > > >> > > > >> > > > >> > > >> I added text about authorization for third party > > registrations and > > >> publication. A little more text on this would be > > helpful. > > > > > >Ah-ah... Now we are getting down to business. > > > > > >I am now looking at new section 10.1 on=20 > registration, > > and I see that > > >you are using indeed third-party registration (with > > To=3DHelpDesk, > > >From=3DAlice). > > > > > >So, this would be one way to to it. > > > > > >Another way would be to NOT use third-party > > registration at all. In > > >other words, Alice would send a first party > > registration on behalf > > >of HelpDesk (ie.., To=3DHelpDesk, From=3DAlice). > > > > > >Wouldn't that work? > > > > > >Then there is the whole issue of=20 > authentication with > > HTTP-Digest. > > >I guess one could use username=3D"HelpDesk". In = this > > case, the > > >idea is that > > >Alice would need to know the credentials=20 > for HelpDesk. > > >Another way would be to use=20 > username=3D"alice" instead > > (i.e., > > >her own credentials). > > >The decisions on which authentication you use would > > depend on > > >need of the > > >administrator. > > > > > >Have you tought about this? Am I off based? > > >_______________________________________________ > > >BLISS mailing list > > >BLISS@ietf.org > > >https://www.ietf.org/mailman/listinfo/bliss > > > > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www.ietf.org/mailman/listinfo/bliss > > > > > > >=20 >=20 From shida@ntt-at.com Thu Jul 16 16:47:34 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0083A69EA for ; Thu, 16 Jul 2009 16:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsZPiwdl1yUX for ; Thu, 16 Jul 2009 16:47:33 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.142.25]) by core3.amsl.com (Postfix) with SMTP id A9A3A3A6A71 for ; Thu, 16 Jul 2009 16:47:33 -0700 (PDT) Received: (qmail 19564 invoked from network); 16 Jul 2009 23:47:20 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway07.websitewelcome.com with SMTP; 16 Jul 2009 23:47:20 -0000 Received: from flh1acl028.tky.mesh.ad.jp ([221.170.63.28]:52233 helo=[192.168.1.6]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MRaZG-0007Iu-8n for bliss@ietf.org; Thu, 16 Jul 2009 18:40:50 -0500 Message-Id: From: Shida Schubert To: bliss@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 17 Jul 2009 08:40:49 +0900 References: X-Mailer: Apple Mail (2.935.3) 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 Subject: Re: [BLISS] Draft Agenda X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 23:47:34 -0000 I meant in Stockholm and not Minneapolis. On Jul 16, 2009, at 7:35 PM, Shida Schubert wrote: > > All; > > I uploaded a draft agenda for our meeting in Minneapolis. > > http://www.ietf.org/proceedings/09jul/agenda/bliss.html > > Please let Jason and I know if we missed any requests > and/or if you have any comments on the agenda. > > Thanks & Regards > Shida > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss From tiross@avaya.com Mon Jul 20 07:39:29 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A55F3A6C34 for ; Mon, 20 Jul 2009 07:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3kU6eWvuGGF for ; Mon, 20 Jul 2009 07:39:27 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 9921F3A68F0 for ; Mon, 20 Jul 2009 07:39:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,234,1246852800"; d="scan'208";a="167666208" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 20 Jul 2009 10:39:25 -0400 Received: from unknown (HELO 300815ANEX4.global.avaya.com) ([198.152.6.140]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 20 Jul 2009 10:39:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jul 2009 10:39:24 -0400 Message-ID: <56A930946AFE054393BD0FFCBCA9823B01296108@300815ANEX4.global.avaya.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: BLISS Digest, Vol 31, Issue 31 thread-index: AcoGSR35egQ6wueOTPSPeuweH+3CeAAy0JDg References: From: "Ross, Timothy I (Tim)" To: Cc: "Raji Chinnappa \(Raji\) \(Chinnappa, Raji \(Raji\)\)" Subject: Re: [BLISS] BLISS Digest, Vol 31, Issue 31 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 14:39:29 -0000 Alan, Thanks for the reply. I still worry about small incompatiblities between DSE ESC specs and shared appearance specs. And we still would like to see suggested techniques UAs can used to differentiate INVITE to shared appearances from other INVITEs. Maybe these techniques are out of scope. Also example 10.8 still has some details that aren't quite right. I added these comments inline below. Thanks, Tim > -----Original Message----- >=20 > Message: 1 > Date: Thu, 16 Jul 2009 14:09:48 -0500 > From: Alan Johnston > Subject: [BLISS] Fwd: Review of draft-bliss-shared-appearances > To: BLISS > Message-ID: <4A5F7AFC.90602@sipstation.com> > Content-Type: text/plain; charset=3DWINDOWS-1252; format=3Dflowed >=20 > Tim, Raji, & Harsh, >=20 > Thanks for doing this review. See my comments below. >=20 > Thanks, > Alan >=20 >=20 > > *From: *"Ross, Timothy I (Tim)" > > > > *Date: *July 3, 2009 12:47:20 AM JST > > *To: *>,=20 > > > > > *Cc: *"Chinnappa, Raji (Raji)" > >, "Mendiratta, Harsh V (Harsh)" > > > > > *Subject: **Review of draft-bliss-shared-appearances* > > > > Hi Jason and Shida, > > =20 > > Alan asked if I would like to review the shared appearance draft. =20 > > Three of us got together and came up with these comments. =20 > Hope they help. > > =20 > > =20 > > Generally the shared appearance looks good. We spent a couple of=20 > > weeks seeing how we would adopt it into our system, and it=20 > is a pretty=20 > > natural fit. There were a few places where we struggled a=20 > bit, and in=20 > > all but one (comment 3) we found solutions. The comments=20 > under ?Main=20 > > Comments? address these struggles. > > =20 > > =20 > > Main Comments: > > =20 > > 1) The draft does not discuss Alice and Bob being on=20 > separate Proxies=20 > > (SIP trapezoid). This has a few subtleties: > > a) If Bob is using TLS and his UA only accepts=20 > connections=20 > > from his own Proxy, then his UA will need to use a gruu=20 > (obtained from=20 > > Bob?s Proxy) when registering to Alice's Appearance Group.=20 > This means=20 > > that Bob's UA would need to register twice, once with his=20 > own proxy to=20 > > get a gruu, then again with Alice's proxy, passing the gruu as the=20 > > contact. The gruu would also be needed if Bob?s UA is non-routable. > > b) Sip Messages to Bob's Bridged Appearance of Alice'=20 > > Appearance Group need to go through Alice's Proxy, so that Alice's=20 > > Proxy can see these calls and report their state to the Appearance=20 > > Agent. Separate Proxies need to be considered. Some cases: > > i) INVITEs to Alice's AOR ? no problem here > > ii) INVITEwJoin from Alice to Bob -- This message is to=20 > Bob?s Contact=20 > > so would not normally go through Alice?s Proxy. This looks ok at=20 > > first, because this scenario requires that Alice?s UA=20 > PUBLISHes to the=20 > > Appearance Group before sending the INVITEwJoin. But this=20 > runs in to=20 > > trouble in later stages of the call where the Appearance Agent will=20 > > not receive a DSE PUBLISH ( 180 Ringing, 200 OK, BYE). In=20 > these later=20 > > stages, the Appearance Agent needs to get call state from=20 > the Alice?s=20 > > Proxy so it can send the DSE NOTIFYs to the appearance=20 > group UAs. This=20 > > can be solved with Bob obtaining a gruu from Alice?s Proxy, or by=20 > > Alice?s UA inserting a route header to route the call=20 > through Alice?s=20 > > Proxy. > > iii) INVITEwReplaces from Alice to Carol ? this is pretty much the=20 > > same problem as INVITEwJoin except here if Carol was on a separate=20 > > Proxy, her UA would not obtain a gruu from Alice?s Proxy, so a gruu=20 > > won?t make the INVITE traverse Alice?s Proxy. This has to=20 > use a route=20 > > header (at least that is all we can see) > > iv) INVITE sent from Carol to Bob?s contact that was discovered=20 > > through Reg Event Package Subscription for Alice?s AOR -- =20 > Again the=20 > > same sort of problem, but this time, Carol?s UA would not=20 > know to add=20 > > a route header for Alice?s Proxy. Carol is not part of the=20 > Appearance=20 > > Group. Here if Bob?s Contact is a gruu from Alice?s Proxy, then=20 > > Alice?s Proxy would see the INVITE. > > =20 > > > > =20 > > > > If Bob?s UA needs a gruu from Alice?s Proxy to solve 1.a.iv=20 > above, and=20 > > if Bob's UA is using TLS, then Bob?s UA will need to nest=20 > the gruus so=20 > > that an INVITE to his contact/gruu would go through both=20 > Alice's Proxy=20 > > and Bob's Proxy. This looks ok in the gruu draft. Bob would get a=20 > > gruu from his own Proxy, and then register with that gruu=20 > to Alice's=20 > > Proxy, asking for another gruu. The gruus should then nest.=20 > Then all=20 > > INVITES that end up on Bob?s Shared Appearance for Alice=20 > will traverse=20 > > Alice?s then Bob?s Proxy. > > =20 > > c) With separate proxies, we assume that when Bob's UA=20 > > registers with Alice's Appearance Group, Bob's proxy will=20 > authenticate=20 > > Bob's credentials, not Alice's, so that the REGISTER should=20 > traverse=20 > > Bob's proxy first. The REGISTER message can add a route header to=20 > > Bob's Proxy, but is this enough to ensure that Bob's Proxy does the=20 > > authentication, and that Alice's Proxy trusts it? Does=20 > authentication=20 > > on a trapezoidal REGISTER work the same way as a trapezoidal INVITE? > > d) When Bob sends an INVITE on his shared=20 > appearance for=20 > > Alice?s Appearance Group the INVITE needs to go through=20 > Bob?s Proxy,=20 > > then Alice?s. Bob?s Proxy is needed to challenge Bob?s=20 > credentials,=20 > > and Alice?s Proxy is needed to report Call events to the Appearance=20 > > Agent. Bob?s Proxy can be traversed with a route header. Alice?s=20 > > Proxy is a bit trickier, and Bob?s Proxy would have to=20 > route the call=20 > > to Alice?s Proxy based on the ?From? header or Contact (if=20 > a contact=20 > > parameter is defined to identify the contact as a Shared=20 > Appearance to=20 > > Alice (see end of comment 2)) >=20 >=20 > I think that this all does work as long as Alice and Bob use=20 > GRUUs and they use their GRUU from the initial registration=20 > as the Contact for their 3rd party registration. >=20 > We should probably include some text in the draft about this. >=20 > > 2) The draft does not discuss (or we missed it)=20 > how Bob's=20 > > UA distinguishes its own calls from Alice's Appearance=20 > Group's calls. > > We assume the "To" header is used, but this may lead to trouble.=20 > > Consider a call to "Sales@example.com "=20 > > that is forwarded to Alice. When Bob's UA gets the call, the "To"=20 > > header will be "Sales@example.com=20 > ", and not=20 > > "Alice@example.com ". Bob's UA may then=20 > > need then to rely on history-info. > > =20 > > If it is legitimate for Carol to INVITE Bob's contact discovered=20 > > through a Registration Event Package Subscription to=20 > Alice?s AOR, then=20 > > it is difficult for Bob's UA to know that this is an INVITE to the=20 > > Shared Appearance, and not his regular appearance. The "To" header=20 > > would be for Bob's contact, and history-info would not=20 > mention Alice's=20 > > AOR. > > =20 > > A gruu could solve this problem because it contains Alice?s=20 > AOR, but=20 > > only if it is a public gruu. > > =20 > > Instead of relying on a combination of ?To? header,=20 > history-info and=20 > > public gruu, Bob's UA could tag his Contact with a contact=20 > parameter=20 > > distinguishing the Contact as an "Alice Appearance Group"=20 > Contact (ex. > > Contact: > ;appearnacegroup=3Dalice@example.com > > ). This would=20 > put Bob's UA=20 > > in control of distinguishing incoming INVITES and not have=20 > it rely on=20 > > the rest of system. Adding an Appearance Group parameter to the=20 > > Contact does not have same problems that adding an=20 > appearance number > > parameter has. =20 >=20 > I think that either the From or the use of a different Contact URI (or > GRUU) should solve this. Shouldn't these alternatives be mentioned in the spec? Maybe in an appendix? True it is up to the UA which way it wants to differentiate shared appearance INVITES for other INVITES, but there are tradeoffs between the alternatives. Some relying more heavily on the rest of the sip infrastructure than others. >=20 > > =20 > > =20 > > 3) The draft leverages the Dialog State Event ESC but restricts the=20 > > DSE PUBLISHes sent by the UAs. This terse PUBLISHing seems to=20 > > conflict with the ESC/PUBLISH RFC (3903). The Shared=20 > Appearance draft=20 > > states that "In some cases, the Appearance Agent may not have full=20 > > access to the complete dialog state of some or all of the=20 > UAs in the=20 > > group. If this is the case, the Appearance Agent will=20 > subscribe to the=20 > > dialog state of individual UAs in the group to obtain this=20 > > information." This seems to require that the appearance agent (an=20 > > extended DSE ESC) subscribe to the group UAs, while our reading of > > 3903 for DSEs would have the UAs publish all these events=20 > by default. >=20 > This is not the normal mode for this feature. The normal=20 > mode is that UAs PUBLISH, but not for every dialog state event. >=20 > > =20 > > Reducing the PUBLISH traffic is a great idea, but I think=20 > it belongs=20 > > within the definition of DSE ESCs and not just in the shared=20 > > appearance draft. All DSE ESC?s have this same traffic problem. > > There also may need to be some sort of query to allow UAs and=20 > > Appearance Agents to go into this terse mode, allowing default DSE=20 > > ESCs/UAs to work. >=20 > Does it help to think of this feature as having an implied=20 > filter for dialog state events? This filter is such that=20 > most PUBLISHes don't get sent, just the ones we are interested in. >=20 I am not sure it helps. When a shared appearance UA PUBLISHes to the appearance agent/DSE ESC (say Alice's as in version 02 of the draft), how does it know what the PUBLISH is for? If could be for the Alice's appearance agent, or it could be for Alice's DSE ESC that other UAs are subscribing to. When does it apply the filter? This is the problem we see. A system has UAs that publish dialog state events to an event state compositor, following RFC 3903 and RFC 4235. These RFC's (at least as I read them) have the UAs publish all states to the ESC. Now we add an appearance agent. The natural way to do this is, as the shared appearance draft suggests, extend the DSE ESC to be an appearance agent. This would be pretty simple, except that the appearance agent does not expect all events to be published, and the DSE ESC does. =20 If the appearance agent does not sniff call states from the proxy (the simpliest way to extend the DSE ESC to an appearance agent), then it needs to SUBSCRIBE to the UAs for the DSEs that the UAs are already sending. When this happens, do the UAs send both PUBLISH and NOTIFY for DSEs not normally published in the shared appearance draft? Or do the UAs just send PUBLISHes, and the appearance agent/DSE ESC is smart enough to treat them as NOTIFYs? Is it possible to have the UAs respond to the SUBSCRIBE with some 4xx if it already PUBLISHes all the DSEs? Or can the UA respond with a 3xx redirect, redirecting the SUBSCRIBE to the ESC? This tells the subscriber to use the ESC for DSEs, instead of the UA, and since the ESC is the appearance agent, then the appearance agent knows that the ESC has complete state, and therefore the PUBLISHes are already complete. (this would when any UA tries to SUBSCRIBE for DSEs directly to a UA instead of an ESC) > > =20 > > This is really the only part of the draft that is giving us=20 > trouble. =20 > > We have already defined a DSE Event State Compositor, and all UAs=20 > > PUBLISH DSE events to it. Extending our DSE ECS to be an=20 > Appearance=20 > > Agent is a very natural fit, except that the terse PULISING in the=20 > > Shared Appearance draft seems to conflict with our=20 > interpretation of=20 > > what a DSE ESC and supporting UAs should be. We don?t know how to=20 > > resolve this while still following both RFC 3903 and the shared=20 > > appearance draft. > > =20 > > =20 > > =20 > > Less Main Comments: > > =20 > > 4) Starting Appearance numbers with 0 confused me. When=20 > first seeing=20 > > this, I thought ?0? may have special meaning like "no=20 > appearance". It=20 > > became clear that this was not so after further reading. I think=20 > > starting appearance numbers with ?1? would be clearer. >=20 > I don't know - this draft has been around for many years,=20 > starting at 0. It might cause backwards compatibility=20 > problems if we change it now. >=20 >=20 > > =20 > > =20 > > 5) Example 10.1 > > =20 > > In example 10.1, it would have been more interesting to=20 > > see Bob's registration/subscriptions to the Appearance Group=20 > > identified with Alice's AOR instead of seeing Alice?s=20 > > registrations/subscriptions. Bob?s registration (I think)=20 > would look=20 > > like a third party registration. And I assume it should=20 > challenge for=20 > > Bob's credentials, and not Alice's. >=20 > Yes, I have made this change, and it has created a discussion=20 > about 3rd=20 > party registration. >=20 >=20 > > =20 > > 6) Example 10.2 > > =20 > > What happens if some one else, maybe another=20 > proxy adds an=20 > > alert-info to the message. Does the "Proxy" then add the=20 > "appearance"=20 > > parameter to that alert-info? Does it remove the previous=20 > alert-info=20 > > and add its own? >=20 > I added some text to cover this case. I think the proxy=20 > applies normal=20 > Alert-Info policies - that is, keeps ones it trusts, strips=20 > ones it does=20 > not. >=20 >=20 > > =20 > > 6a) Example 10.2 > > "However, if Carol answers both Alice and Bob and keeps=20 > > both dialogs active, then the Appearance Agent will need to resolve=20 > > the situation by moving either Alice or Bob's dialog to a different=20 > > appearance." --> Shouldn't this end up being a joined=20 > call between=20 > > Alice, Bob and Carol?. Same as if Bob answered the call, the Alice=20 > > sent and INVITEwJoin? >=20 >=20 > This would be true if the media were mixed. However, if=20 > Carol does not=20 > mix the media but keeps the two calls separate (i.e. one on hold, one=20 > active), then this is different from the Join case. >=20 > > =20 > > 7) Several of the examples are missing the dashed special=20 > > communications line between the proxy and the appearance agent=20 > > (<------>: like the dashed line between F1 and F2 in=20 > example 10.2). =20 > > Putting these in would clarify the examples. When reading it at=20 > > first, I was not sure if this special communication was missing, or=20 > > the PUBLISHes were missing. These are missing in Examples=20 > 10.3, 10.4,=20 > > 10.5?, 10.6, 10.7, 10.9, 10.10, 10.11?, 10.13. >=20 > I tried to add them all in - let me know if I missed any. I can't see any more missing ones >=20 >=20 > > =20 > > 8) Example 10.6 > > "Bob and Carol are in a dialog, created in one of the=20 > > previous two call flows" --> Previous example (10.5, one of the=20 > > ?previous two call flows?) does not allocate appearance number, but=20 > > 10.6 de-allocates it. >=20 >=20 > Right - fixed the reference. >=20 > > =20 > > 9) Example 10.8.=20 > > I think this call from Bob is from a regular=20 > appearance,=20 > > not his shared appearance to Alice. I think this should be made=20 > > clear. I wasn't sure if it was from Bob?s shared=20 > appearance, or Bob?s=20 > > regular appearance. >=20 > Good catch - this was a mistake which has been fixed. >=20 > > =20 > > 9a) Example 10.8 > > Shouldn't the DSE NOTIFY F16 be from Alice@example.com=20 > > and not Bob@example.com=20 > > ? > > =20 >=20 > I'm not sure if this is fixed or not with the renumbering of the=20 > examples. Can you check? The From header looks correct now. But it is now F19, and not F16 (the sequence diagram shows F19 while the detail shows F16) Also the DSE body looks incorrect. I think the local and remote elements are reversed. Local should be alice, and remote should be bob (unless I am confused) and the direction should be "recipient" not "initiator" >=20 >=20 > > 10) Example 10.12 discusses outgoing/outgoing race condition. =20 > > Examples for the other two race conditions would be good. =20 > > Outgoing/Incoming and Incoming/Incoming. Depending on the=20 > > Proxy<--->Appearance agent link, outgoing/incoming may have problems >=20 > Good idea - I added the Incoming/Outgoing. The=20 > Incoming/Incoming one I=20 > think would only happen if the Alert-Info appearance didn't match the=20 > NOTIFY appearance, and this is mentioned in the text. >=20 >=20 > > =20 > > 11) Appendix A > > "For example, the proxy could fetch this information by=20 > > initiating a > > SUBSCRIBE request with Expires: 0 to the=20 > Appearance Agent=20 > > for the AOR > > to fetch the list of lines that are in use. =20 > > Alternatively, it could > > act like a UA that is a part of the appearance=20 > group and=20 > > SUBSCRIBE to > > the State-Agent like any other UA. " --> This=20 > has a small=20 > > outgoing/incoming race condition. Just after the proxy polls for a=20 > > free appearance number on an incoming INVITE, another UA=20 > could request=20 > > an appearance number with a DSE PUBLISH. That UA could=20 > pick and get=20 > > the same appearance number as the Proxy chooses from the DSE poll. >=20 >=20 > We got rid of this section. >=20 > > =20 > > 12) Example 10.7 > > When Carol hangs up F48, does NOTIFY 52 show=20 > "terminated"=20 > > but strip out the appearance number? The appearance number=20 > is now in=20 > > use between Alice and Carol. I worry that if NOTIFY F52 shows=20 > > terminated with the same used appearance number, UAs may mistakenly=20 > > think the number is free. >=20 > I think we dealt with this race condition using the joined-dialog and=20 > replaced-dialog elements. Let me know if you still think=20 > this is a problem. >=20 >=20 > > =20 > > =20 > > Questions > > =20 > > Q1) Example 10.2 > > =20 > > Can the Notifies F2 - F4 come after the INVITE F7? I=20 > > assume both ways work, and both are possible.=20 > > =20 > > =20 >=20 > Yes, I included text saying this. >=20 >=20 > > =20 > > =20 > > =20 > > Trivial Comments > > =20 > > T1) Section 13.1 refers to 5.1.1 and 5.1.2. Neither one=20 > exists. Think=20 > > they actually mean 13.1.1 and 13.1.2 > > =20 > > T2) page 5 (wording) > > =20 > > "The sharing or appearance of these lines=20 > between a number=20 > > of phones is what gives this feature its." -> its name. > > =20 > > T3) page 9 (wording) > > =20 > > "The Appearance Agent learns the=20 > group state=20 > > either dialog state publications from members." -> missing words > > =20 >=20 > Thanks for the nits. >=20 > > Harsh, Raji, Tim =20 > > =20 > > =20 > > Tim Ross > > 1-732-852-2104 > > tiross@avaya.com > > =20 >=20 >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss >=20 >=20 > End of BLISS Digest, Vol 31, Issue 31 > ************************************* >=20 From sgarg@cedarpointcom.com Tue Jul 21 14:10:13 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24FF3A6EA1 for ; Tue, 21 Jul 2009 14:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es8zfaG995iz for ; Tue, 21 Jul 2009 14:10:13 -0700 (PDT) Received: from web65613.mail.ac4.yahoo.com (web65613.mail.ac4.yahoo.com [76.13.9.81]) by core3.amsl.com (Postfix) with SMTP id CE7F13A6E9B for ; Tue, 21 Jul 2009 14:10:12 -0700 (PDT) Received: (qmail 88569 invoked by uid 60001); 21 Jul 2009 21:09:01 -0000 Message-ID: <937688.88540.qm@web65613.mail.ac4.yahoo.com> X-YMail-OSG: kZvZ3GgVM1mkE_bSDdk_oMaTDdwKKvRsitAoZ0.j8AwQu279PmlP3P_HDqF8PYk0UWVI7WMOh1kK8VK.Q9Nh1rDG5CoIgR92mxBLoj4XSimGpKkNDdw2rVWv24k1saEsWWSINB4td20RLd.JhxR6pxYdGQILmEhSZY5_C1DdYY33Z8aEeAZ6k7CzB3.rsQLv6tJFnqitsQLI0sCjO4a6PPL_RWAw9ybiGw5iI8ynKePa0ssf5i2pkr3xyD4SOZPmxRjV1iCH7CC..UW1205aJMOVsjsmdHuB4iQgRCQR6M1kSe4oB6nQoCpJW.tgYjXSxjoZuixNjcqDlFIsIxoRswWzKDiiMm0XiQ-- Received: from [67.151.79.74] by web65613.mail.ac4.yahoo.com via HTTP; Tue, 21 Jul 2009 14:09:00 PDT X-RocketYMMF: emailsumitgarg X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Tue, 21 Jul 2009 14:09:00 -0700 (PDT) From: Sumit Garg To: bliss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances:Provisioningconsiderations X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sgarg@cedarpointcom.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 21:10:13 -0000 It appears to me that the section 26.3.2.1 does not agree with section 10.3 of the same spec...as that(10.3) implies the asserted identity is derived from the From header (without challenge)but section 26.3.2.1 implies that the asserted identity is derived from the To header (with challenge)... Anyways, below implies (from 10.3)that the user should be authenticated and then the permissions for the AOR should be checked... Section 26.3.2.1 implies authentication based on info in the AoR to be registered against... 3.A registrar SHOULD authenticate the UAC. Mechanisms for the authentication of SIP user agents are described in Section 22. Registration behavior in no way overrides the generic authentication framework for SIP. If no authentication mechanism is available, the registrar MAY take the From address as the asserted identity of the originator of the request. 4. The registrar SHOULD determine if the authenticated user is authorized to modify registrations for this address-of-record. For example, a registrar might consult an authorization database that maps user names to a list of addresses-of-record for which that user has authorization to modify bindings. If the authenticated user is not authorized to modify bindings, the registrar MUST return a 403 (Forbidden) and skip the remaining steps. In architectures that support third-party registration, one entity may be responsible for updating the registrations associated with multiple addresses-of-record. From: bliss-bounces@ietf.org on behalf of Francois Audet Sent: Thu 7/16/2009 3:13 PM To: Alan Johnston Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances:Provisioningconsiderations I don't have a strong opinion one way or another, but I think the point is that we decide, and document it. It's not clear to me why the first method (3rd party authentication) is "a bad idea" and the second one (3rd party registration) is a good one. Can you clarify why it's bad? I *think* (I could be wrong) the 3rd party authentication would be supported by any UA today that supports a separate "Authorization name" (or "realm auth" or whatever it is called). In contast, I haven't seen many UAs supporting 3rd party registration. Furthermore, in 3261, your would assume that the username in the credentials be the same as the userinfo part of the To header (3261/26.3.2.1). In what you are describing here for 3rd party registration, in contast, you are using for the username, the userinfo of the From header. In other words, any way we choose to go, we are changing the way you'd normally expect authentication to work. Anyways, to summarize: I don't have a strong opinion. Just pick one, and document it in the draft. I think leaving it open to interpretation will cause interoperability issues. ---- PS: Finally, for the last case in your email, i.e., From/To/Http-digest-credentials = HelpDesk, we are in 100% agreement. That's also what we have done. We should describe it in the text. Forever, Sumit "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From alan@sipstation.com Wed Jul 22 13:29:51 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9923A6900 for ; Wed, 22 Jul 2009 13:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECz2lYjOGtyk for ; Wed, 22 Jul 2009 13:29:50 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id CCBFF3A67E9 for ; Wed, 22 Jul 2009 13:29:50 -0700 (PDT) Received: from 24-107-145-55.dhcp.stls.mo.charter.com ([24.107.145.55] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MTiOY-0005Jm-86; Wed, 22 Jul 2009 20:26:34 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.55 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18r/ic0IkXpeIYsIwjryT5LK2m5Wpx5Z5o= Message-ID: <4A6775F8.7000802@sipstation.com> Date: Wed, 22 Jul 2009 15:26:32 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: sgarg@cedarpointcom.com References: <937688.88540.qm@web65613.mail.ac4.yahoo.com> In-Reply-To: <937688.88540.qm@web65613.mail.ac4.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances:Provisioningconsiderations X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 20:29:51 -0000 Hi Sumit, Yes, RFC 3261 is a bit confusing in this regard. We should get some opinions from other SIP experts and registrars that have implemented 3rd party registrations before deciding exactly how we should do it in this case. I have always assumed that authentication in SIP is based on the From URI. In SIP registration, the AOR being registered is the To URI. However, text in Section 10 does say that the authenticated identity is the To, which is confusing. For a standard first party registration will have both the To and From URIs the same, so it doesn't matter, but for a 3rd party registration, it does matter. It seems to me requiring the authentication credentials of the To URI for 3rd party registration defeats the whole purpose of 3rd party registrations. Thanks, Alan Sumit Garg wrote: > It appears to me that the section 26.3.2.1 does not agree with section 10.3 of the same spec...as that(10.3) implies the asserted identity is derived from the From header (without challenge)but section 26.3.2.1 implies that the asserted identity is derived from the To header (with challenge)... > Anyways, below implies (from 10.3)that the user should be authenticated and then the permissions for the AOR should be checked... > Section 26.3.2.1 implies authentication based on info in the AoR to be registered against... > > 3.A registrar SHOULD authenticate the UAC. Mechanisms for the > authentication of SIP user agents are described in Section 22. > Registration behavior in no way overrides the generic > authentication framework for SIP. If no authentication > mechanism is available, the registrar MAY take the From address > as the asserted identity of the originator of the request. > > 4. The registrar SHOULD determine if the authenticated user is > authorized to modify registrations for this address-of-record. > For example, a registrar might consult an authorization > database that maps user names to a list of addresses-of-record > for which that user has authorization to modify bindings. If > the authenticated user is not authorized to modify bindings, > the registrar MUST return a 403 (Forbidden) and skip the > remaining steps. > > In architectures that support third-party registration, one > entity may be responsible for updating the registrations > associated with multiple addresses-of-record. > > From: bliss-bounces@ietf.org on behalf of Francois Audet > Sent: Thu 7/16/2009 3:13 PM > To: Alan Johnston > Cc: bliss@ietf.org > Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances:Provisioningconsiderations > > > I don't have a strong opinion one way or another, but I think > the point is that we decide, and document it. > > It's not clear to me why the first method (3rd party authentication) is > "a bad idea" and the second one (3rd party registration) is a good one. > Can you clarify why it's bad? > > I *think* (I could be wrong) the 3rd party authentication would be supported > by any UA today that supports a separate "Authorization name" (or "realm auth" or > whatever it is called). In contast, I haven't seen many UAs supporting 3rd > party registration. > > Furthermore, in 3261, your would assume that the username in the credentials > be the same as the userinfo part of the To header (3261/26.3.2.1). In what you are > describing here for 3rd party registration, in contast, you are using for the username, > the userinfo of the From header. > > In other words, any way we choose to go, we are changing the way you'd normally expect > authentication to work. > > Anyways, to summarize: I don't have a strong opinion. Just pick one, and document > it in the draft. I think leaving it open to interpretation will cause interoperability > issues. > > ---- > > PS: > > Finally, for the last case in your email, i.e., From/To/Http-digest-credentials = HelpDesk, > we are in 100% agreement. That's also what we have done. We should describe it in the text. > > > Forever, > Sumit > "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." > -- George Bernard Shaw > > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss > > From jason.fischl@gmail.com Tue Jul 28 01:11:21 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997833A6ABC for ; Tue, 28 Jul 2009 01:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsSHQ5lhIXeC for ; Tue, 28 Jul 2009 01:11:20 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id 7A9503A6D38 for ; Tue, 28 Jul 2009 01:11:20 -0700 (PDT) Received: by gxk9 with SMTP id 9so52767gxk.13 for ; Tue, 28 Jul 2009 01:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=/KTNG8ege0FFnrNIFJZXVyBb4iScwPgmR/BIUT8H3O8=; b=fKL2HL0KC5N0GZo/CnnII8dRKzfSgzn50hG0UdhPmp57dvCntJ/AaHGrAB9MlRqu/6 Auh9EdNlsa0vrOF/2QR7kxT4g9Qk5Yf9jbmIEsjsWofqSoV07uQuohNmCKsS8Cb8sPrY qjodLvK2ySCstdxXnZfxYTeAnDTfhBpOcvDDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=r3YMhRwKRUKstfhpCk/jdDKMBT4U+WmjU1uo8S+Xup/n9ENLrKdS8P2SZUqeVMK5jj QzWXEVgh78YwjfTJSbeeIrA2iefCOyBQy53czKkpThKQs2hsOjmvxmsobuK0Ox91obIq CZD4hZhg+tzY1OQ3guSCDL1XyOyV1E2i2pVQc= MIME-Version: 1.0 Received: by 10.150.134.11 with SMTP id h11mr12917348ybd.29.1248768309074; Tue, 28 Jul 2009 01:05:09 -0700 (PDT) In-Reply-To: <4A6775F8.7000802@sipstation.com> References: <937688.88540.qm@web65613.mail.ac4.yahoo.com> <4A6775F8.7000802@sipstation.com> From: Jason Fischl Date: Tue, 28 Jul 2009 10:04:49 +0200 Message-ID: To: Alan Johnston Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bliss@ietf.org, Robert Sparks Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances:Provisioningconsiderations X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:11:21 -0000 On Wed, Jul 22, 2009 at 10:26 PM, Alan Johnston wrote: > Hi Sumit, > > Yes, RFC 3261 is a bit confusing in this regard. =A0We should get some > opinions from other SIP experts and registrars that have implemented 3rd > party registrations before deciding exactly how we should do it in this > case. > > I have always assumed that authentication in SIP is based on the From URI= . > =A0In SIP registration, the AOR being registered is the To URI. =A0 Howev= er, This has always been my assumption as well. Robert, could you weigh in on this topic? > text in Section 10 does say that the authenticated identity is the To, wh= ich > is confusing. =A0For a standard first party registration will have both t= he To > and From URIs the same, so it doesn't matter, but for a 3rd party > registration, it does matter. It seems to me requiring the authentication > credentials of the To URI for 3rd party registration defeats the whole > purpose of 3rd party registrations. > > Thanks, > Alan > > Sumit Garg wrote: >> >> It appears to me that the section 26.3.2.1 does not agree with section >> 10.3 of the same spec...as that(10.3) implies the asserted identity is >> derived from the From header (without challenge)but section 26.3.2.1 imp= lies >> that the asserted identity is derived from the To header (with challenge= )... >> Anyways, below implies (from 10.3)that the user should be authenticated >> and then the permissions for the AOR should be checked... >> Section 26.3.2.1 implies authentication based on info in the AoR to be >> registered against... >> >> =A0 =A0 =A03.A registrar SHOULD authenticate the UAC. =A0Mechanisms for = the >> =A0 =A0 =A0 =A0 authentication of SIP user agents are described in Secti= on 22. >> =A0 =A0 =A0 =A0 Registration behavior in no way overrides the generic >> =A0 =A0 =A0 =A0 authentication framework for SIP. =A0If no authenticatio= n >> =A0 =A0 =A0 =A0 mechanism is available, the registrar MAY take the From = address >> =A0 =A0 =A0 =A0 as the asserted identity of the originator of the reques= t. >> >> =A0 =A0 =A04. The registrar SHOULD determine if the authenticated user i= s >> =A0 =A0 =A0 =A0 authorized to modify registrations for this address-of-r= ecord. >> =A0 =A0 =A0 =A0 For example, a registrar might consult an authorization >> =A0 =A0 =A0 =A0 database that maps user names to a list of addresses-of-= record >> =A0 =A0 =A0 =A0 for which that user has authorization to modify bindings= . =A0If >> =A0 =A0 =A0 =A0 the authenticated user is not authorized to modify bindi= ngs, >> =A0 =A0 =A0 =A0 the registrar MUST return a 403 (Forbidden) and skip the >> =A0 =A0 =A0 =A0 remaining steps. >> >> =A0 =A0 =A0 =A0 In architectures that support third-party registration, = one >> =A0 =A0 =A0 =A0 entity may be responsible for updating the registrations >> =A0 =A0 =A0 =A0 associated with multiple addresses-of-record. >> >> From: bliss-bounces@ietf.org on behalf of Francois Audet >> Sent: Thu 7/16/2009 3:13 PM >> To: Alan Johnston >> Cc: bliss@ietf.org >> Subject: Re: [BLISS] >> draft-ietf-bliss-shared-appearances:Provisioningconsiderations >> >> >> I don't have a strong opinion one way or another, but I think >> the point is that we decide, and document it. >> >> It's not clear to me why the first method (3rd party authentication) is >> "a bad idea" and the second one (3rd party registration) is a good one. >> Can you clarify why it's bad? >> >> I *think* (I could be wrong) the 3rd party authentication would be >> supported >> by any UA today that supports a separate "Authorization name" (or "realm >> auth" or >> whatever it is called). In contast, I haven't seen many UAs supporting 3= rd >> party registration. >> >> Furthermore, in 3261, your would assume that the username in the >> credentials >> be the same as the userinfo part of the To header (3261/26.3.2.1). In wh= at >> you are >> describing here for 3rd party registration, in contast, you are using fo= r >> the username, >> the userinfo of the From header. >> >> In other words, any way we choose to go, we are changing the way you'd >> normally expect >> authentication to work. >> >> Anyways, to summarize: I don't have a strong opinion. Just pick one, and >> document >> it in the draft. I think leaving it open to interpretation will cause >> interoperability >> issues. >> >> ---- >> >> PS: >> >> Finally, for the last case in your email, i.e., >> From/To/Http-digest-credentials =3D HelpDesk, >> we are in 100% agreement. That's also what we have done. We should >> describe it in the text. >> >> >> Forever, >> Sumit >> "The reasonable man adapts himself to the world; the unreasonable one >> persists in trying to adapt the world to himself. Therefore all progress >> depends on the unreasonable man." >> -- George Bernard Shaw >> >> >> =A0 =A0 =A0_______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www.ietf.org/mailman/listinfo/bliss >> >> > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss > --=20 Jason From john.elwell@siemens-enterprise.com Tue Jul 28 04:34:12 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465BE3A6E56 for ; Tue, 28 Jul 2009 04:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 kujlZiO0EB9o for ; Tue, 28 Jul 2009 04:34:11 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 13A373A6DC4 for ; Tue, 28 Jul 2009 04:33:57 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KNH00E29PFGH2@siemenscomms.co.uk> for bliss@ietf.org; Tue, 28 Jul 2009 12:33:17 +0100 (BST) Date: Tue, 28 Jul 2009 12:33:10 +0100 From: "Elwell, John" To: bliss@ietf.org, Alan Johnston Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022EA7A4@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Text for seize Thread-Index: AcoPdy+bKn3aMZuBTM2/Hqq3mleyyg== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [BLISS] Text for seize X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 11:34:12 -0000 I think seize means reserve? I think the definition should start: "The act of reserving an appearance by communicating ..." Similarly for selecting: "The act of choosing an appearance for communication without reserving the appearance ...." John From alan@sipstation.com Tue Jul 28 04:52:02 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693873A6D38 for ; Tue, 28 Jul 2009 04:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-ru0alxkoyF for ; Tue, 28 Jul 2009 04:51:58 -0700 (PDT) Received: from outbound-mail-350.bluehost.com (outbound-mail-350.bluehost.com [66.147.249.11]) by core3.amsl.com (Postfix) with SMTP id 464C23A6CF0 for ; Tue, 28 Jul 2009 04:51:58 -0700 (PDT) Received: (qmail 19628 invoked by uid 0); 28 Jul 2009 11:51:59 -0000 Received: from unknown (HELO host350.hostmonster.com) (66.147.240.150) by outboundproxy7.bluehost.com.bluehost.com with SMTP; 28 Jul 2009 11:51:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=sipstation.com; h=Received:References:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Mailer:Mime-Version:Subject:Date:Cc:X-Identified-User; b=YGcxahcwuizFyggWgUZmay2F9dzhkvc993F28NU3GeX+xPctIUNJFBdu7q1oeSyFEbILuCASdAGyZpmnDE1vvK15evpExew/hWJLeiL4yI/GEBecsdc1FlCfJOERn9f1; Received: from dhcp-13b6.meeting.ietf.org ([130.129.19.182]) by host350.hostmonster.com with esmtpa (Exim 4.69) (envelope-from ) id 1MVlDr-0000lr-Ac; Tue, 28 Jul 2009 05:51:59 -0600 References: <0D5F89FAC29E2C41B98A6A762007F5D0022EA7A4@GBNTHT12009MSX.gb002.siemens.net> Message-Id: <47F63C63-D42D-47FC-BE1D-9F5F559D5D75@sipstation.com> From: Alan Johnston To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0022EA7A4@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Date: Tue, 28 Jul 2009 13:51:57 +0200 X-Identified-User: {2451:host350.hostmonster.com:aeternus:sipstation.com} {sentby:smtp auth 130.129.19.182 authed with alan+sipstation.com} Cc: "bliss@ietf.org" Subject: Re: [BLISS] Text for seize X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 11:52:02 -0000 John, Thanks for sending this - I will use this text. Thanks, Alan On Jul 28, 2009, at 1:33 PM, "Elwell, John" wrote: > I think seize means reserve? I think the definition should start: > > "The act of reserving an appearance by communicating ..." > > Similarly for selecting: > "The act of choosing an appearance for communication without reserving > the appearance ...." > > John From adam@nostrum.com Tue Jul 28 05:30:24 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96E8E3A6BBE for ; Tue, 28 Jul 2009 05:30:24 -0700 (PDT) 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 YVP099iNrnuh for ; Tue, 28 Jul 2009 05:30:23 -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 52B1F3A67D8 for ; Tue, 28 Jul 2009 05:30:23 -0700 (PDT) Received: from dhcp-17f4.meeting.ietf.org (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6SCUKjB019506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Jul 2009 07:30:22 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A6EEF5C.1060107@nostrum.com> Date: Tue, 28 Jul 2009 14:30:20 +0200 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) Subject: [BLISS] Initial ringtones for draft-alexeitsev-bliss-alert-info-urns X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 12:30:24 -0000 There are a number of additional tones that are probably worth considering as part of the initial set of symbols. If you look at TIA/EIA-41-D and 3GPP2 A.S0014, you'll find quite a few tone designations that are used in other standards. A.S0014 defines: 1. Normal Alerting 2. Inter-group Alerting 3. Special/Priority Alerting 4. Ping Ring (abbreviated alert) 5. Abbreviated intercept 6. Abbreviated reorder I think #1 and #4 are covered in the current document, but the others aren't clearly represented. If you throw in the TIA/EIA values, you also have things like: 1. Long (Normal) 2. Short-Short 3. Short-Short-Long 4. Short-Short2 5. Short-Long-Short 6. Short-Short-Short-Short 7. PBX Long (Normal) 8. PBX Short-Short 9. PBX Short-Short-Long 10. PBX Short-Long-Short 11. PBX Short-Short-Short-Short Additionally, A.S0014 allows indication of pitch (high, normal, low) as part of the ringtone designation. It would be nice if we could tack this pitch data on to the end of the existing tokens (e.g., "normal.short.low"). I note that this points to a combinatorial explosion of IANA values -- perhaps we need to re-think how we're representing the registry. /a From L.Liess@telekom.de Tue Jul 28 08:59:32 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C1A3A6EB8 for ; Tue, 28 Jul 2009 08:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpFk0vNtQZ9y for ; Tue, 28 Jul 2009 08:59:30 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 6F3D03A6DA9 for ; Tue, 28 Jul 2009 08:59:30 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 28 Jul 2009 17:59:25 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:59:24 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jul 2009 17:59:22 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4A6EEF5C.1060107@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [BLISS] Initial ringtones for draft-alexeitsev-bliss-alert-info-urns Thread-index: AcoPfzVjfWOKe69nRiyST8drYni1LQAHP6pw References: <4A6EEF5C.1060107@nostrum.com> From: To: , X-OriginalArrivalTime: 28 Jul 2009 15:59:24.0735 (UTC) FILETIME=[60D4BCF0:01CA0F9C] Subject: Re: [BLISS] Initial ringtones for draft-alexeitsev-bliss-alert-info-urns X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:59:32 -0000 Adam, The intent of the draft is to provide a general mechanism, to register = the template and to do initial registration for tones and service tones = which we know that people intend to use now and have interoperability = problems. I don't think we should now register every tone in every = national specification, which possible nobbody intends to use. =20 If, over time, people need additional tones or service tones, they can = use the general mechanism and template are free to register their own = tones. =20 Or do you see a problem with this approach? Thanks a lot Laura Mit freundlichen Gr=FC=DFen Laura Liess Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Laura Liess=20 Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 +49 6151 628-2761 (Tel.)=20 +49 6151 628-3395 (Fax)=20 +49 175 2961015 (Mobil)=20 l.liess@telekom.de (E-mail) http://www.telekom.com=20 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 =20 > -----Original Message----- > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > On Behalf Of Adam Roach > Sent: Tuesday, July 28, 2009 2:30 PM > To: bliss@ietf.org > Subject: [BLISS] Initial ringtones for=20 > draft-alexeitsev-bliss-alert-info-urns >=20 > There are a number of additional tones that are probably worth > considering as part of the initial set of symbols. If you look at > TIA/EIA-41-D and 3GPP2 A.S0014, you'll find quite a few tone > designations that are used in other standards. >=20 > A.S0014 defines: >=20 > 1. Normal Alerting > 2. Inter-group Alerting > 3. Special/Priority Alerting > 4. Ping Ring (abbreviated alert) > 5. Abbreviated intercept > 6. Abbreviated reorder >=20 > I think #1 and #4 are covered in the current document, but the others > aren't clearly represented. >=20 > If you throw in the TIA/EIA values, you also have things like: >=20 > 1. Long (Normal) > 2. Short-Short > 3. Short-Short-Long > 4. Short-Short2 > 5. Short-Long-Short > 6. Short-Short-Short-Short > 7. PBX Long (Normal) > 8. PBX Short-Short > 9. PBX Short-Short-Long > 10. PBX Short-Long-Short > 11. PBX Short-Short-Short-Short >=20 >=20 > Additionally, A.S0014 allows indication of pitch (high,=20 > normal, low) as > part of the ringtone designation. It would be nice if we=20 > could tack this > pitch data on to the end of the existing tokens (e.g., > "normal.short.low"). I note that this points to a combinatorial > explosion of IANA values -- perhaps we need to re-think how we're > representing the registry. >=20 > /a >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss >=20 From AUDET@nortel.com Wed Jul 29 04:51:13 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0B93A7011 for ; Wed, 29 Jul 2009 04:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 GG+oLf0amjaW for ; Wed, 29 Jul 2009 04:51:11 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 546853A6F5F for ; Wed, 29 Jul 2009 04:51:11 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6TBmXS23216; Wed, 29 Jul 2009 11:48:33 GMT 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, 29 Jul 2009 06:49:59 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F36370E@zrc2hxm0.corp.nortel.com> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Initial ringtones fordraft-alexeitsev-bliss-alert-info-urns thread-index: AcoPfzVjfWOKe69nRiyST8drYni1LQAHP6pwACmVU9A= References: <4A6EEF5C.1060107@nostrum.com> <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> From: "Francois Audet" To: , , Subject: Re: [BLISS] Initial ringtones fordraft-alexeitsev-bliss-alert-info-urns X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 11:51:13 -0000 It seems to me that if a specific national body requires the use of national-specific ringback tones, they would then have to register their own URN space for it. Hopefully we wouldn't go that route, but the option is definitively there if required.=20 > -----Original Message----- > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > On Behalf Of L.Liess@telekom.de > Sent: Tuesday, July 28, 2009 08:59 > To: adam@nostrum.com; bliss@ietf.org > Subject: Re: [BLISS] Initial ringtones=20 > fordraft-alexeitsev-bliss-alert-info-urns >=20 > Adam, >=20 > The intent of the draft is to provide a general mechanism, to=20 > register the template and to do initial registration for=20 > tones and service tones which we know that people intend to=20 > use now and have interoperability problems. I don't think we=20 > should now register every tone in every national=20 > specification, which possible nobbody intends to use. =20 > If, over time, people need additional tones or service tones,=20 > they can use the general mechanism and template are free to=20 > register their own tones. =20 >=20 > Or do you see a problem with this approach? >=20 > Thanks a lot > Laura >=20 >=20 > Mit freundlichen Gr=FC=DFen > Laura Liess >=20 > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Laura Liess > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 > +49 6151 628-2761 (Tel.) > +49 6151 628-3395 (Fax) > +49 175 2961015 (Mobil) > l.liess@telekom.de (E-mail) > http://www.telekom.com=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > Albert Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der=20 > Gesellschaft: Bonn > USt-IdNr.: DE 814645262 >=20 > =20 >=20 > > -----Original Message----- > > From: bliss-bounces@ietf.org=20 > [mailto:bliss-bounces@ietf.org] On Behalf=20 > > Of Adam Roach > > Sent: Tuesday, July 28, 2009 2:30 PM > > To: bliss@ietf.org > > Subject: [BLISS] Initial ringtones for=20 > > draft-alexeitsev-bliss-alert-info-urns > >=20 > > There are a number of additional tones that are probably worth=20 > > considering as part of the initial set of symbols. If you look at=20 > > TIA/EIA-41-D and 3GPP2 A.S0014, you'll find quite a few tone=20 > > designations that are used in other standards. > >=20 > > A.S0014 defines: > >=20 > > 1. Normal Alerting > > 2. Inter-group Alerting > > 3. Special/Priority Alerting > > 4. Ping Ring (abbreviated alert) > > 5. Abbreviated intercept > > 6. Abbreviated reorder > >=20 > > I think #1 and #4 are covered in the current document, but=20 > the others=20 > > aren't clearly represented. > >=20 > > If you throw in the TIA/EIA values, you also have things like: > >=20 > > 1. Long (Normal) > > 2. Short-Short > > 3. Short-Short-Long > > 4. Short-Short2 > > 5. Short-Long-Short > > 6. Short-Short-Short-Short > > 7. PBX Long (Normal) > > 8. PBX Short-Short > > 9. PBX Short-Short-Long > > 10. PBX Short-Long-Short > > 11. PBX Short-Short-Short-Short > >=20 > >=20 > > Additionally, A.S0014 allows indication of pitch (high,=20 > normal, low)=20 > > as part of the ringtone designation. It would be nice if we=20 > could tack=20 > > this pitch data on to the end of the existing tokens (e.g.,=20 > > "normal.short.low"). I note that this points to a combinatorial=20 > > explosion of IANA values -- perhaps we need to re-think how we're=20 > > representing the registry. > >=20 > > /a > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www.ietf.org/mailman/listinfo/bliss > >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss >=20 From wwwrun@core3.amsl.com Wed Jul 29 11:57:12 2009 Return-Path: X-Original-To: bliss@ietf.org Delivered-To: bliss@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9D2793A6923; Wed, 29 Jul 2009 11:57:12 -0700 (PDT) To: alan@sipstation.com,mohsen.soroush@sylantro.com,vvenkatar@gmail.com From: IETF Secretariat Message-Id: <20090729185712.9D2793A6923@core3.amsl.com> Date: Wed, 29 Jul 2009 11:57:12 -0700 (PDT) Cc: bliss@ietf.org, ipr-announce@ietf.org, rjsparks@nostrum.com Subject: [BLISS] Posting of IPR Disclosure related to Verizon Patent and Licensing Inc.'s Statement about IPR related to draft-ietf-bliss-shared-appearances-03 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 18:57:12 -0000 Dear Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan: An IPR disclosure that pertains to your Internet-Draft entitled "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)" (draft-ietf-bliss-shared-appearances) was submitted to the IETF Secretariat on 2009-07-16 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1175/). The title of the IPR disclosure is "Verizon Patent and Licensing Inc.'s Statement about IPR related to draft-ietf-bliss-shared-appearances-03." The IETF Secretariat From L.Liess@telekom.de Thu Jul 30 02:25:59 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53FEC3A69E5 for ; Thu, 30 Jul 2009 02:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKy8biKQUZAa for ; Thu, 30 Jul 2009 02:25:58 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 9C1723A68C2 for ; Thu, 30 Jul 2009 02:25:57 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 30 Jul 2009 11:25:57 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 11:25:57 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jul 2009 11:25:56 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0033EB69F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F36370E@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [BLISS] Initial ringtones fordraft-alexeitsev-bliss-alert-info-urns Thread-index: AcoPfzVjfWOKe69nRiyST8drYni1LQAHP6pwACmVU9AALA5p8A== References: <4A6EEF5C.1060107@nostrum.com> <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F36370E@zrc2hxm0.corp.nortel.com> From: To: , , X-OriginalArrivalTime: 30 Jul 2009 09:25:57.0173 (UTC) FILETIME=[BE742650:01CA10F7] Subject: Re: [BLISS] Initial ringtones fordraft-alexeitsev-bliss-alert-info-urns X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 09:25:59 -0000 Francois, They would have to use the alredy registered alert urn template and to = register new alert-URN indications for "tone" or "service" , e.g. = internal.short-short-short. It's a similar process as for the Emergency = Service URN (5031).=20 My personal opinion is that many of the tones defined in national = documents will be not longer used when PSTN moves to VoIP.=20 Regards Laura > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Wednesday, July 29, 2009 1:50 PM > To: Liess, Laura; adam@nostrum.com; bliss@ietf.org > Subject: RE: [BLISS] Initial ringtones=20 > fordraft-alexeitsev-bliss-alert-info-urns >=20 > It seems to me that if a specific national body requires the use > of national-specific ringback tones, they would then have to register > their own URN space for it. >=20 > Hopefully we wouldn't go that route, but the option is definitively > there if required.=20 >=20 > > -----Original Message----- > > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > > On Behalf Of L.Liess@telekom.de > > Sent: Tuesday, July 28, 2009 08:59 > > To: adam@nostrum.com; bliss@ietf.org > > Subject: Re: [BLISS] Initial ringtones=20 > > fordraft-alexeitsev-bliss-alert-info-urns > >=20 > > Adam, > >=20 > > The intent of the draft is to provide a general mechanism, to=20 > > register the template and to do initial registration for=20 > > tones and service tones which we know that people intend to=20 > > use now and have interoperability problems. I don't think we=20 > > should now register every tone in every national=20 > > specification, which possible nobbody intends to use. =20 > > If, over time, people need additional tones or service tones,=20 > > they can use the general mechanism and template are free to=20 > > register their own tones. =20 > >=20 > > Or do you see a problem with this approach? > >=20 > > Thanks a lot > > Laura > >=20 > >=20 > > Mit freundlichen Gr=FC=DFen > > Laura Liess > >=20 > > Deutsche Telekom Netzproduktion GmbH > > Zentrum Technik Einf=FChrung > > Laura Liess > > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 > > +49 6151 628-2761 (Tel.) > > +49 6151 628-3395 (Fax) > > +49 175 2961015 (Mobil) > > l.liess@telekom.de (E-mail) > > http://www.telekom.com=20 > >=20 > > Deutsche Telekom Netzproduktion GmbH > > Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) > > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > > Albert Matheis, Klaus Peren > > Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der=20 > > Gesellschaft: Bonn > > USt-IdNr.: DE 814645262 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: bliss-bounces@ietf.org=20 > > [mailto:bliss-bounces@ietf.org] On Behalf=20 > > > Of Adam Roach > > > Sent: Tuesday, July 28, 2009 2:30 PM > > > To: bliss@ietf.org > > > Subject: [BLISS] Initial ringtones for=20 > > > draft-alexeitsev-bliss-alert-info-urns > > >=20 > > > There are a number of additional tones that are probably worth=20 > > > considering as part of the initial set of symbols. If you look at=20 > > > TIA/EIA-41-D and 3GPP2 A.S0014, you'll find quite a few tone=20 > > > designations that are used in other standards. > > >=20 > > > A.S0014 defines: > > >=20 > > > 1. Normal Alerting > > > 2. Inter-group Alerting > > > 3. Special/Priority Alerting > > > 4. Ping Ring (abbreviated alert) > > > 5. Abbreviated intercept > > > 6. Abbreviated reorder > > >=20 > > > I think #1 and #4 are covered in the current document, but=20 > > the others=20 > > > aren't clearly represented. > > >=20 > > > If you throw in the TIA/EIA values, you also have things like: > > >=20 > > > 1. Long (Normal) > > > 2. Short-Short > > > 3. Short-Short-Long > > > 4. Short-Short2 > > > 5. Short-Long-Short > > > 6. Short-Short-Short-Short > > > 7. PBX Long (Normal) > > > 8. PBX Short-Short > > > 9. PBX Short-Short-Long > > > 10. PBX Short-Long-Short > > > 11. PBX Short-Short-Short-Short > > >=20 > > >=20 > > > Additionally, A.S0014 allows indication of pitch (high,=20 > > normal, low)=20 > > > as part of the ringtone designation. It would be nice if we=20 > > could tack=20 > > > this pitch data on to the end of the existing tokens (e.g.,=20 > > > "normal.short.low"). I note that this points to a combinatorial=20 > > > explosion of IANA values -- perhaps we need to re-think how we're=20 > > > representing the registry. > > >=20 > > > /a > > >=20 > > > _______________________________________________ > > > BLISS mailing list > > > BLISS@ietf.org > > > https://www.ietf.org/mailman/listinfo/bliss > > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www.ietf.org/mailman/listinfo/bliss > >=20 >=20 From john.elwell@siemens-enterprise.com Thu Jul 30 06:49:25 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540413A69E8 for ; Thu, 30 Jul 2009 06:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 t3T97ZHYD-HL for ; Thu, 30 Jul 2009 06:49:23 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 887373A67D4 for ; Thu, 30 Jul 2009 06:49:23 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KNL00B4KL296U@siemenscomms.co.uk> for bliss@ietf.org; Thu, 30 Jul 2009 14:49:21 +0100 (BST) Date: Thu, 30 Jul 2009 14:49:17 +0100 From: "Elwell, John" In-reply-to: <40FB0FFB97588246A1BEFB05759DC8A0033EB69F@S4DE9JSAANI.ost.t-com.de> To: L.Liess@telekom.de, audet@nortel.com, adam@nostrum.com, bliss@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00233D2D7@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [BLISS] Initial ringtonesfordraft-alexeitsev-bliss-alert-info-urns Thread-Index: AcoPfzVjfWOKe69nRiyST8drYni1LQAHP6pwACmVU9AALA5p8AAEuvxA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A6EEF5C.1060107@nostrum.com> <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F36370E@zrc2hxm0.corp.nortel.com> <40FB0FFB97588246A1BEFB05759DC8A0033EB69F@S4DE9JSAANI.ost.t-com.de> Subject: Re: [BLISS] Initial ringtonesfordraft-alexeitsev-bliss-alert-info-urns X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 13:49:25 -0000 We should at least try to avoid having two or more URNs with the same = semantics, coming from different countries. Furthermore, we should try = to register names that reflect the meaning, rather than the = representation, of a tone, so that it can be rendered in the appropriate = way for the locale concerned. For example "internal.short-short-short" = tells me nothing about the meaning (other than that it is internal). If = it is intended to denote three short bursts of tone, this could convey = different meanings (or confusion) to a user outside the locale where it = originated. John > -----Original Message----- > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > On Behalf Of L.Liess@telekom.de > Sent: 30 July 2009 10:26 > To: audet@nortel.com; adam@nostrum.com; bliss@ietf.org > Subject: Re: [BLISS] Initial=20 > ringtonesfordraft-alexeitsev-bliss-alert-info-urns >=20 >=20 > Francois, >=20 > They would have to use the alredy registered alert urn=20 > template and to register new alert-URN indications for "tone"=20 > or "service" , e.g. internal.short-short-short. It's a=20 > similar process as for the Emergency Service URN (5031).=20 >=20 > My personal opinion is that many of the tones defined in=20 > national documents will be not longer used when PSTN moves to VoIP.=20 >=20 > Regards > Laura >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com]=20 > > Sent: Wednesday, July 29, 2009 1:50 PM > > To: Liess, Laura; adam@nostrum.com; bliss@ietf.org > > Subject: RE: [BLISS] Initial ringtones=20 > > fordraft-alexeitsev-bliss-alert-info-urns > >=20 > > It seems to me that if a specific national body requires the use > > of national-specific ringback tones, they would then have=20 > to register > > their own URN space for it. > >=20 > > Hopefully we wouldn't go that route, but the option is definitively > > there if required.=20 > >=20 > > > -----Original Message----- > > > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > > > On Behalf Of L.Liess@telekom.de > > > Sent: Tuesday, July 28, 2009 08:59 > > > To: adam@nostrum.com; bliss@ietf.org > > > Subject: Re: [BLISS] Initial ringtones=20 > > > fordraft-alexeitsev-bliss-alert-info-urns > > >=20 > > > Adam, > > >=20 > > > The intent of the draft is to provide a general mechanism, to=20 > > > register the template and to do initial registration for=20 > > > tones and service tones which we know that people intend to=20 > > > use now and have interoperability problems. I don't think we=20 > > > should now register every tone in every national=20 > > > specification, which possible nobbody intends to use. =20 > > > If, over time, people need additional tones or service tones,=20 > > > they can use the general mechanism and template are free to=20 > > > register their own tones. =20 > > >=20 > > > Or do you see a problem with this approach? > > >=20 > > > Thanks a lot > > > Laura > > >=20 > > >=20 > > > Mit freundlichen Gr=FC=DFen > > > Laura Liess > > >=20 > > > Deutsche Telekom Netzproduktion GmbH > > > Zentrum Technik Einf=FChrung > > > Laura Liess > > > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 > > > +49 6151 628-2761 (Tel.) > > > +49 6151 628-3395 (Fax) > > > +49 175 2961015 (Mobil) > > > l.liess@telekom.de (E-mail) > > > http://www.telekom.com=20 > > >=20 > > > Deutsche Telekom Netzproduktion GmbH > > > Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) > > > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > > > Albert Matheis, Klaus Peren > > > Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der=20 > > > Gesellschaft: Bonn > > > USt-IdNr.: DE 814645262 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: bliss-bounces@ietf.org=20 > > > [mailto:bliss-bounces@ietf.org] On Behalf=20 > > > > Of Adam Roach > > > > Sent: Tuesday, July 28, 2009 2:30 PM > > > > To: bliss@ietf.org > > > > Subject: [BLISS] Initial ringtones for=20 > > > > draft-alexeitsev-bliss-alert-info-urns > > > >=20 > > > > There are a number of additional tones that are probably worth=20 > > > > considering as part of the initial set of symbols. If=20 > you look at=20 > > > > TIA/EIA-41-D and 3GPP2 A.S0014, you'll find quite a few tone=20 > > > > designations that are used in other standards. > > > >=20 > > > > A.S0014 defines: > > > >=20 > > > > 1. Normal Alerting > > > > 2. Inter-group Alerting > > > > 3. Special/Priority Alerting > > > > 4. Ping Ring (abbreviated alert) > > > > 5. Abbreviated intercept > > > > 6. Abbreviated reorder > > > >=20 > > > > I think #1 and #4 are covered in the current document, but=20 > > > the others=20 > > > > aren't clearly represented. > > > >=20 > > > > If you throw in the TIA/EIA values, you also have things like: > > > >=20 > > > > 1. Long (Normal) > > > > 2. Short-Short > > > > 3. Short-Short-Long > > > > 4. Short-Short2 > > > > 5. Short-Long-Short > > > > 6. Short-Short-Short-Short > > > > 7. PBX Long (Normal) > > > > 8. PBX Short-Short > > > > 9. PBX Short-Short-Long > > > > 10. PBX Short-Long-Short > > > > 11. PBX Short-Short-Short-Short > > > >=20 > > > >=20 > > > > Additionally, A.S0014 allows indication of pitch (high,=20 > > > normal, low)=20 > > > > as part of the ringtone designation. It would be nice if we=20 > > > could tack=20 > > > > this pitch data on to the end of the existing tokens (e.g.,=20 > > > > "normal.short.low"). I note that this points to a combinatorial=20 > > > > explosion of IANA values -- perhaps we need to re-think=20 > how we're=20 > > > > representing the registry. > > > >=20 > > > > /a > > > >=20 > > > > _______________________________________________ > > > > BLISS mailing list > > > > BLISS@ietf.org > > > > https://www.ietf.org/mailman/listinfo/bliss > > > >=20 > > > _______________________________________________ > > > BLISS mailing list > > > BLISS@ietf.org > > > https://www.ietf.org/mailman/listinfo/bliss > > >=20 > >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss >=20