From pkyzivat@cisco.com Mon Nov 2 05:50:31 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECBE03A68FB for ; Mon, 2 Nov 2009 05:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 e0-K5qpTm+s4 for ; Mon, 2 Nov 2009 05:50:30 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 756EF3A6885 for ; Mon, 2 Nov 2009 05:50:30 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANBy7kqtJV2Z/2dsb2JhbADFDZZZhDkE X-IronPort-AV: E=Sophos;i="4.44,667,1249257600"; d="scan'208";a="65964114" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 02 Nov 2009 13:50:49 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id nA2DonZC003708; Mon, 2 Nov 2009 13:50:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 08:50:49 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 08:50:48 -0500 Message-ID: <4AEEE3B9.7040506@cisco.com> Date: Mon, 02 Nov 2009 08:50:49 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alan Johnston References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> <4AE99CFE.9030205@sipstation.com> In-Reply-To: <4AE99CFE.9030205@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2009 13:50:48.0567 (UTC) FILETIME=[7BB4B070:01CA5BC3] Cc: dispatch@ietf.org, R.Jesske@telekom.de, L.Liess@telekom.de, anwars@avaya.com Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 13:50:32 -0000 Alan, Sorry to be slow in responding. Comments inline. Thanks, Paul Alan Johnston wrote: > Paul, > > Thanks for your comments on the draft. See mine below. > > Thanks, > Alan > > > Paul Kyzivat wrote: >> responses inline >> >> L.Liess@telekom.de wrote: >>> Paul, >>> Thank you very much for taking the time to look and comment the draft. >>> After the changes we did shortly before the submission deadline, there >>> are some inconsistecies and open items. We are aware of some of them and >>> probably there are some we are not aware of. For the problems we are >>> aware of, there are alternative solutions. In some cases, we did not >>> have a clear opinion which way to go and we would like to hear others >>> opinions. >>> >>> >>> Please find comments inline: >>> > > This seems to be shaping up well. I think the >>> requirements are >>> quite > clear now. >>> >>> It's good to hear that we have achieved at least a smal stepp in the >>> right direction :-). > > I don't fully understand what is >>> intended regarding >>> combination of > multiple alert URNs for a specific situation. >>> Section 4.5 >>> states: >>> > > > finally, a short Albanian auto-callback tone could be >>> indicated >>> > > Alert-Info: , >>> > > , . >>> > > while section 7.3.6 states: >>> > > > Alert URN Indications from the same group should not be >>> combined. >>> >>> >>> >>> To avoid the combinatorial explosion of IANA values as Adam pointed out >>> in his comment >>> http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html , we >>> decided to abandon the usage of sub-indications for the use cases we >>> have in the draft and to register only discrete tokens as top-level >>> registrations. (With county-specidfic ring and busy tones, we almost >>> got the problem Adam talked about.) The sub-indications are no longer >>> used in the current version of the draft. >> >> So, maybe that is the confusion. I didn't understand that from reading >> the text. >> >>> We thougt about changing the template in chapter 3 from >>> alert-indication = top-level *("." sub-indication) >>> top-level = let-dig [ *25let-dig-hyp let-dig ] >>> sub-indication = let-dig [ *let-dig-hyp let-dig ] >>> >>> to just >>> alert-indication= let-dig [ *let-dig-hyp let-dig ] >>> >>> But we are not sure if everyone would agree with this, so we would like >>> to have feedback from the WG on this issue. >> >> I don't know yet. The alternative is apparently to have multiple URNs >> and interpret the combination. I'm having difficulty imagining how >> that would work. I have always assumed that in the end a URN would be >> "looked up" locally by the UA and resolved to *something* that it >> could render. >> >> I will keep an open mind, but I'll need a better explanation of how >> multiple URNs are to be combined into *something* that can be looked up. >> >>> There is an inconcistency concerning the alert indications "priority", >>> "short" and "delayed": In chapter 4, they are now top-level indications >>> in the alert-category "service", therefore in the same group eith >>> "auto-callback". In chapter 7 there is a dedicated group for them >>> "Additional Indications for PBX-tones" in the "tones" alert-category. >>> We must have to decide which alternative to take. If we decide for the >>> chapter 4 alternative, we must change either the combination rule or the >>> example you complained about. >>> >>> > I could find no definition of what constitutes a "group". The >>> first > thing that comes to mind is "service" vs. "tone", but the >>> > above example > violates that. It seems to me that you need >>> some notion of >>> orthogonal > properties in order to define what can/cannot be >>> combined. >>> >>> It's true, it's quite impossible to guess from the text what I meant >>> here. A group consists of the indications in one sub-chapter 7.3.1 to >>> 7.3.5. I just looked for a way to avoid combinations of contradictory >>> URNs, e.g. that is combined with >>> or is combined with >>> . If we agree that this kind of groups makes sense >>> and we keep it, some definition needs to be added. But maybe there are >>> better proposals in the WG about how to avoid combinations of >>> contradictory indications? >> >> It seems like what you must be doing is replacing a hierarchy with an >> N-dimensional matrix which is sparsely populated. That seems harder to >> deal with. >> > > Perhaps, or perhaps not. When I said "seems harder" that's what I meant. I'm not *sure* its harder. Mostly I'm trying to understand the implications. > Remember that this is just a suggestion, > rather than a command about a ring or ringback. It is perfectly > reasonable for UAs to simply ignore the Alert-Info. So, the sparse > scenario, where a server puts in as much information as possible, > possibly via multiple URNs, and the UA uses the ones it knows and > ignores the rest. Yup. But there really isn't much point if everybody just ignores the info. So what is important is to make clear what the *intended* behavior is, when not overridden by policy. I think that intended behavior isn't very clear if there is just a bunch of values for multiple "dimensions" and no notion of how they might then be turned into something perceptible by a person. >> I have a sip pbx phone on my desk. I don't have any distinction for >> internal vs. external, and have no clue how "normal" would be >> different from one or the other of those. I don't really desire any >> distinction on any of those terms. > > Remember, the use case for normal is driven by shared appearances - we > want to insert an appearance number parameter into the Alert-Info but we > do not want to convey any particular Alert, so we use normal as a no-op. Ah. So maybe its just a matter of my not understanding what connotation you meant me to get from the name. You mean it to be like "unspecified". >>> I would keep the two worlds disjunct. E.g. , I have a sip handy which is >>> attached sometimes to the pbx and sometimes to my public carrier at >>> home, I may want the pbx ringing tone to be different from the ringing >>> tone at home. >> >> I don't really have any objection to a bunch of "names" for extra >> arbitrary ring types. The real issue is deciding when to use one or >> another. Is the assumption here that these will typically be inserted >> by some agent acting on behalf of the phone acting on them, rather >> than being inserted by "the other" party? IOW, *my* pbx decides that >> an incoming call from you is "internal" or "external" and inserts a >> suitable value by its policy, rather than *your* phone deciding the >> call is internal or external and inserting the value that I then render. > > I wonder if some of the confusion we are having is because we are not > cleanly separating ring tones from ringback tones. I'm going to think a > bit how we would structure this if we had separate registries or trees > for these. For instance, the country specification would only make > sense for ringback tones. Also, things like priority would only apply > to ring tones, etc. My original thinking was that there need not be any difference. But maybe there is, at least in common practice. While it isn't common practice, I can imagine it might be interesting to have the ring tone match the country of origin of the caller. But of course many would not like that, and would insist that their choice of ring tone(s) be honored. I agree its worth considering splitting up the namespace into separate sections for ring alerts and ringback alerts. Thanks, Paul From gonzalo.camarillo@ericsson.com Mon Nov 2 10:22:56 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77283A68D0 for ; Mon, 2 Nov 2009 10:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.131 X-Spam-Level: X-Spam-Status: No, score=-6.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BnWJDu8gEPN for ; Mon, 2 Nov 2009 10:22:56 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 992733A63D3 for ; Mon, 2 Nov 2009 10:22:55 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-49-4aef239223e5 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id A3.D4.31706.2932FEA4; Mon, 2 Nov 2009 19:23:14 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 19:23:14 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 19:23:13 +0100 Received: from [131.160.126.140] (rvi2-126-140.lmf.ericsson.se [131.160.126.140]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1EAB82507; Mon, 2 Nov 2009 20:23:13 +0200 (EET) Message-ID: <4AEF2390.1090409@ericsson.com> Date: Mon, 02 Nov 2009 20:23:12 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2009 18:23:13.0587 (UTC) FILETIME=[8A18D030:01CA5BE9] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Liaison from OMA on SIP Push X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 18:22:56 -0000 Folks, here you have an LS we have received from OMA: https://datatracker.ietf.org/documents/LIAISON/file726.doc It relates to the following draft: http://tools.ietf.org/html/draft-mdolly-dispatch-oma-push-00 Cheers, Gonzalo DISPATCH co-chair From R.Jesske@telekom.de Tue Nov 3 00:51:02 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485963A6997 for ; Tue, 3 Nov 2009 00:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 udlYC1CoauAE for ; Tue, 3 Nov 2009 00:51:00 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 092463A6999 for ; Tue, 3 Nov 2009 00:50:56 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 03 Nov 2009 09:51:12 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 09:51:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5C62.CB6C682A" Date: Tue, 3 Nov 2009 09:51:12 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD4052C0F99@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-jesske-dispatch-reason-in-responses-00, provisional Responses 18x Thread-Index: AcpcYsreYidyKluXQ6CnDKcv8mayow== From: To: X-OriginalArrivalTime: 03 Nov 2009 08:51:12.0489 (UTC) FILETIME=[CB8A9D90:01CA5C62] Subject: [dispatch] draft-jesske-dispatch-reason-in-responses-00, provisional Responses 18x X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 08:51:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5C62.CB6C682A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, Due to some comments I have extended the = draft-jesske-dispatch-reason-in-responses-00 for the next planned = version. It was asked also to allow the inclusion of the Reason header within 18x = Responses. So I plan to incorporate the following text within the next 01 Version = as follows: 4. Overall Applicability The SIP procedures specified in this document are foreseen for networks providing simulation services and/or interworking to the PSTN/ISDN. The document is describing the use of the Reason header in SIP responses. These procedures are only valuable if the reason contained in the element "protocol" is "Q.850". A inclusion of a SIP reason (protocol=3D"SIP") is not helpful due to the fact that the response already provides the SIP reason. The Release Causes are described within [Q.850]. (Note: The ETSI specifications can be downloaded under http://pda.etsi.org/pda/queryform.asp free of charge.) The appearance of the Reason header is applicable to final responses 4xx, 5xx and 6xx and in addition for 199 Responses as defined within [I-D.ietf-sipcore-199]. Also the Reason header is applicable to provisional responses 18x which are generated by an interworking gateway from ISUP to SIP. Comments?=20 Mit freundlichen Gr=FC=DFen; With Best Regards=20 Roland Jesske Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Roland Jesske Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 +49 6151628-2766 (Tel.)=20 +49 521 9210-3753 (Fax)=20 +49 171 8618-445 (Mobil)=20 http://www.telekom.com=20 Erleben, was verbindet. Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Dr. Steffen Roehn (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 ------_=_NextPart_001_01CA5C62.CB6C682A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-jesske-dispatch-reason-in-responses-00, provisional = Responses 18x

Dear all,
Due to some comments I have extended = the draft-jesske-dispatch-reason-in-responses-00 for the next planned = version.
It was asked also to allow the = inclusion of the Reason header within 18x Responses.
So I plan to incorporate the following = text within the next 01 Version as follows:


4.  Overall = Applicability

   The SIP procedures = specified in this document are foreseen for
   networks providing = simulation services and/or interworking to the
   PSTN/ISDN.

   The document is = describing the use of the Reason header in SIP
   responses.  = These procedures are only valuable if the reason
   contained in the = element "protocol" is "Q.850".  A inclusion of = a SIP
   reason = (protocol=3D"SIP") is not helpful due to the fact that = the
   response already = provides the SIP reason.  The Release Causes are
   described within = [Q.850].  (Note: The ETSI specifications can be
   downloaded under = http://pda.etsi.org/pda/queryform.asp free of
   charge.)

   The appearance of = the Reason header is applicable to final responses
   4xx, 5xx and 6xx = and in addition for 199 Responses as defined within
   = [I-D.ietf-sipcore-199].  Also the Reason header is applicable = to
   provisional = responses 18x which are generated by an interworking
   gateway from ISUP = to SIP.

Comments?


Mit freundlichen Gr=FC=DFen; With Best = Regards
Roland Jesske


Deutsche Telekom = Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151628-2766 (Tel.)
+49 521 9210-3753 (Fax)
+49 171 8618-445 (Mobil)
http://www.telekom.com

Erleben, was = verbindet.

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

------_=_NextPart_001_01CA5C62.CB6C682A-- From alan@sipstation.com Tue Nov 3 13:08:53 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2EC23A691C for ; Tue, 3 Nov 2009 13:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 JspcisjmZnHz for ; Tue, 3 Nov 2009 13:08:53 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id E0AE33A6802 for ; Tue, 3 Nov 2009 13:08:52 -0800 (PST) Received: from 24-107-145-15.dhcp.stls.mo.charter.com ([24.107.145.15] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1N5Qcr-000Fcx-7M for dispatch@ietf.org; Tue, 03 Nov 2009 21:09:13 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.15 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+eUo7mgCEvvQC05/cMIXB8jl2kzmLSb24= Message-ID: <4AF09BF6.9010902@sipstation.com> Date: Tue, 03 Nov 2009 15:09:10 -0600 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:08:54 -0000 All, Here is some updated charter text for CCUS. Comments are most welcome. Thanks, Alan - - - - - The Call Control UUI for SIP (CCUS) working group is chartered to define a SIP mechanism for transporting call control related user-to-user (UUI) information between User Agents. The mechanism developed in this working group is generally appropriate in the following situations: 1. The information is generated and consumed by an application using SIP during session setup but the application is not necessarily even SIP aware. 2. SIP behavior is unchanged. 3. Generally only the UAC and UAS are interested in the information. 4. The information is expected to survive retargeting, redirection, and retargeting. 5. SIP elements may need to apply policy about passing and screening the information. 6. Multi-vendor interoperability is important. This mechanism is not appropriate in the following situations: 1. SIP behavior is changed. 2. The information is generated and consumed at the SIP layer by SIP elements. 3. SIP elements besides the UAC and UAS might be interested and consume the information. 4. There are specific privacy or cross-RAI issues involved with the information being transported. User data of the mechanism will be clearly marked with the application, encoding, semantics, and contents of the data, allowing policy to be applied by UAs. The working group will define the information which each application must specify in a standards-track document to utilize the mechanism. One important application of this mechanism is interworking with the ISDN User to User Information Service. This application defined by ITU-T Q.931, is extensively deployed in the PSTN today, supporting such applications as contact centers, call centers, and automatic call distributors (ACDs). A major barrier to the movement of these applications to SIP is the lack of a standard mechanism to transport this information in SIP. For interworking with ISDN, minimal information about the content of the UUI is available. In this case only, the content will just indicate ISDN UUI Service 1 interworking rather than the actual content. Call control UUI is user information conveyed between user agents during call control operations. As a result, the information must be conveyed with the INVITE transaction, and must survive proxy retargeting, redirection, and transfers. The mechanism must utilize a minimum of SIP extensions as it will need to be supported by many simple SIP user agents such as PSTN gateways. The mechanism must interwork with the existing ISDN service but should also be extensible for use by other applications and non-ISDN protocols. While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI can be generated by a number of protocols that are not ISUP, and as such it is architecturally unreasonable to interwork these protocols at the SIP / ISUP gateway. That is, existing SIP-T approaches defined in RFC3372 do not meet the requirements. Mechanisms based on the SIP INFO method, RFC2976, will not be considered by the working group since the UUI contents carry information that must be conveyed during session setup at the user agent - the information must be conveyed with the INVITE transaction. The information must be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases. The group will produce: - A problem statement and requirements document for implementing a SIP call control UUI mechanism - A specification of the SIP extension to best meet those requirements. Goals and Milestones ==================== Mar 10 - Problem statement and requirements document to IESG (Informational) Aug 10 - SIP call control UUI specification to IESG (PS) From Leon.Portman@nice.com Tue Nov 3 23:58:41 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296053A67C0 for ; Tue, 3 Nov 2009 23:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 AFmeiBg7ZCAO for ; Tue, 3 Nov 2009 23:58:40 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id AEB183A68B0 for ; Tue, 3 Nov 2009 23:58:39 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 4 Nov 2009 09:58:58 +0200 From: Leon Portman To: Alan Johnston , "dispatch@ietf.org" Date: Wed, 4 Nov 2009 09:58:56 +0200 Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Thread-Index: Acpcyf9cQc7Gv/u7RAyfnE5VWPs2QQAWmnAQ Message-ID: <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> References: <4AF09BF6.9010902@sipstation.com> In-Reply-To: <4AF09BF6.9010902@sipstation.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 07:58:41 -0000 Only one comment, does it also supposed to support re-invite (for SRTP re-k= eying or media updates) scenarios as well? Thanks Leon -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Alan Johnston Sent: Tuesday, November 03, 2009 11:09 PM To: dispatch@ietf.org Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP All, Here is some updated charter text for CCUS. Comments are most welcome. Thanks, Alan - - - - - The Call Control UUI for SIP (CCUS) working group is chartered to=20 define a SIP mechanism for transporting call control related=20 user-to-user (UUI) information between User Agents. The mechanism developed in this working group is generally appropriate=20 in the following situations: 1. The information is generated and consumed by an application using SIP=20 during session setup but the application is not necessarily even SIP aware. 2. SIP behavior is unchanged. 3. Generally only the UAC and UAS are interested in the information. 4. The information is expected to survive retargeting, redirection, and=20 retargeting. 5. SIP elements may need to apply policy about passing and screening the=20 information. 6. Multi-vendor interoperability is important. This mechanism is not appropriate in the following situations: 1. SIP behavior is changed. 2. The information is generated and consumed at the SIP layer by SIP=20 elements. 3. SIP elements besides the UAC and UAS might be interested and consume=20 the information. 4. There are specific privacy or cross-RAI issues involved with the=20 information being transported. User data of the mechanism will be clearly marked with the application,=20 encoding, semantics, and contents of the data, allowing policy to be=20 applied by UAs. The working group will define the information which=20 each application must specify in a standards-track document to utilize=20 the mechanism. One important application of this mechanism is interworking with the=20 ISDN User to User Information Service. This application defined by=20 ITU-T Q.931, is extensively deployed in the PSTN today, supporting such=20 applications as contact centers, call centers, and automatic call=20 distributors (ACDs). A major barrier to the movement of these=20 applications to SIP is the lack of a standard mechanism to transport=20 this information in SIP. For interworking with ISDN, minimal=20 information about the content of the UUI is available. In this case=20 only, the content will just indicate ISDN UUI Service 1 interworking=20 rather than the actual content. Call control UUI is user information conveyed between user agents during=20 call control operations. As a result, the information must be conveyed=20 with the INVITE transaction, and must survive proxy retargeting,=20 redirection, and transfers. The mechanism must utilize a minimum of SIP=20 extensions as it will need to be supported by many simple SIP user=20 agents such as PSTN gateways. The mechanism must interwork with the=20 existing ISDN service but should also be extensible for use by other=20 applications and non-ISDN protocols. While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI=20 can be generated by a number of protocols that are not ISUP, and as such=20 it is architecturally unreasonable to interwork these protocols at the=20 SIP / ISUP gateway. That is, existing SIP-T approaches defined in=20 RFC3372 do not meet the requirements. Mechanisms based on the SIP INFO method, RFC2976, will not be considered=20 by the working group since the UUI contents carry information that must=20 be conveyed during session setup at the user agent - the information=20 must be conveyed with the INVITE transaction. The information must be=20 passed with the session setup request (INVITE), responses to that=20 INVITE, or session termination requests. As a result, it is not=20 possible to use INFO in these cases. The group will produce: - A problem statement and requirements document for implementing a SIP=20 call control UUI mechanism - A specification of the SIP extension to best meet those requirements. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mar 10 - Problem statement and requirements document to IESG=20 (Informational) Aug 10 - SIP call control UUI specification to IESG (PS) _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From sanjsinh@cisco.com Wed Nov 4 01:18:14 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56FE728C162 for ; Wed, 4 Nov 2009 01:18:14 -0800 (PST) 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.151, 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 fPjgTPy--ocM for ; Wed, 4 Nov 2009 01:18:13 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D276428C161 for ; Wed, 4 Nov 2009 01:18:12 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANPV8EqtJV2Y/2dsb2JhbADFDJg4hD0E X-IronPort-AV: E=Sophos;i="4.44,679,1249257600"; d="scan'208";a="66339050" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 04 Nov 2009 09:18:33 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id nA49IX6V011740; Wed, 4 Nov 2009 09:18:33 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 03:18:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Nov 2009 03:18:29 -0600 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Thread-Index: Acpcyf9cQc7Gv/u7RAyfnE5VWPs2QQAWmnAQAALE5EA= References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> From: "Sanjay Sinha (sanjsinh)" To: "Leon Portman" , "Alan Johnston" , X-OriginalArrivalTime: 04 Nov 2009 09:18:33.0269 (UTC) FILETIME=[C7EF8650:01CA5D2F] Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 09:18:14 -0000 I think UUI is carried during session setup and teardown, and hence re-Invite scenario may not be applicable here. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Leon Portman Sent: Wednesday, November 04, 2009 1:29 PM To: Alan Johnston; dispatch@ietf.org Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Only one comment, does it also supposed to support re-invite (for SRTP re-keying or media updates) scenarios as well? Thanks Leon -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Tuesday, November 03, 2009 11:09 PM To: dispatch@ietf.org Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP All, Here is some updated charter text for CCUS. Comments are most welcome. Thanks, Alan - - - - - The Call Control UUI for SIP (CCUS) working group is chartered to=20 define a SIP mechanism for transporting call control related=20 user-to-user (UUI) information between User Agents. The mechanism developed in this working group is generally appropriate=20 in the following situations: 1. The information is generated and consumed by an application using SIP during session setup but the application is not necessarily even SIP aware. 2. SIP behavior is unchanged. 3. Generally only the UAC and UAS are interested in the information. 4. The information is expected to survive retargeting, redirection, and=20 retargeting. 5. SIP elements may need to apply policy about passing and screening the information. 6. Multi-vendor interoperability is important. This mechanism is not appropriate in the following situations: 1. SIP behavior is changed. 2. The information is generated and consumed at the SIP layer by SIP=20 elements. 3. SIP elements besides the UAC and UAS might be interested and consume=20 the information. 4. There are specific privacy or cross-RAI issues involved with the=20 information being transported. User data of the mechanism will be clearly marked with the application,=20 encoding, semantics, and contents of the data, allowing policy to be=20 applied by UAs. The working group will define the information which=20 each application must specify in a standards-track document to utilize=20 the mechanism. One important application of this mechanism is interworking with the=20 ISDN User to User Information Service. This application defined by=20 ITU-T Q.931, is extensively deployed in the PSTN today, supporting such=20 applications as contact centers, call centers, and automatic call=20 distributors (ACDs). A major barrier to the movement of these=20 applications to SIP is the lack of a standard mechanism to transport=20 this information in SIP. For interworking with ISDN, minimal=20 information about the content of the UUI is available. In this case=20 only, the content will just indicate ISDN UUI Service 1 interworking=20 rather than the actual content. Call control UUI is user information conveyed between user agents during call control operations. As a result, the information must be conveyed=20 with the INVITE transaction, and must survive proxy retargeting,=20 redirection, and transfers. The mechanism must utilize a minimum of SIP extensions as it will need to be supported by many simple SIP user=20 agents such as PSTN gateways. The mechanism must interwork with the=20 existing ISDN service but should also be extensible for use by other=20 applications and non-ISDN protocols. While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI can be generated by a number of protocols that are not ISUP, and as such it is architecturally unreasonable to interwork these protocols at the=20 SIP / ISUP gateway. That is, existing SIP-T approaches defined in=20 RFC3372 do not meet the requirements. Mechanisms based on the SIP INFO method, RFC2976, will not be considered by the working group since the UUI contents carry information that must=20 be conveyed during session setup at the user agent - the information=20 must be conveyed with the INVITE transaction. The information must be=20 passed with the session setup request (INVITE), responses to that=20 INVITE, or session termination requests. As a result, it is not=20 possible to use INFO in these cases. The group will produce: - A problem statement and requirements document for implementing a SIP=20 call control UUI mechanism - A specification of the SIP extension to best meet those requirements. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mar 10 - Problem statement and requirements document to IESG=20 (Informational) Aug 10 - SIP call control UUI specification to IESG (PS) _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From Leon.Portman@nice.com Wed Nov 4 01:31:29 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D633A68B8 for ; Wed, 4 Nov 2009 01:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 U6DZATYcQBTo for ; Wed, 4 Nov 2009 01:31:28 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 60CF83A683B for ; Wed, 4 Nov 2009 01:31:27 -0800 (PST) Received: from tlvcas02.nice.com (172.18.253.6) by tlvcas01.nice.com (192.168.253.111) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 4 Nov 2009 11:31:47 +0200 Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Wed, 4 Nov 2009 11:31:47 +0200 From: Leon Portman To: "Sanjay Sinha (sanjsinh)" , Alan Johnston , "dispatch@ietf.org" Date: Wed, 4 Nov 2009 11:31:45 +0200 Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Thread-Index: Acpcyf9cQc7Gv/u7RAyfnE5VWPs2QQAWmnAQAALE5EAAAHpdwA== Message-ID: <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> In-Reply-To: <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 09:31:29 -0000 Actually I was thinking that if UUI was presented during the original INVIT= E, if it is going to be required to be presented during RE_INVITES as well,= especially if it represents some client state information Leon -----Original Message----- From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com]=20 Sent: Wednesday, November 04, 2009 11:18 AM To: Leon Portman; Alan Johnston; dispatch@ietf.org Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for SI= P I think UUI is carried during session setup and teardown, and hence re-Invite scenario may not be applicable here. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Leon Portman Sent: Wednesday, November 04, 2009 1:29 PM To: Alan Johnston; dispatch@ietf.org Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Only one comment, does it also supposed to support re-invite (for SRTP re-keying or media updates) scenarios as well? Thanks Leon -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Tuesday, November 03, 2009 11:09 PM To: dispatch@ietf.org Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP All, Here is some updated charter text for CCUS. Comments are most welcome. Thanks, Alan - - - - - The Call Control UUI for SIP (CCUS) working group is chartered to=20 define a SIP mechanism for transporting call control related=20 user-to-user (UUI) information between User Agents. The mechanism developed in this working group is generally appropriate=20 in the following situations: 1. The information is generated and consumed by an application using SIP during session setup but the application is not necessarily even SIP aware. 2. SIP behavior is unchanged. 3. Generally only the UAC and UAS are interested in the information. 4. The information is expected to survive retargeting, redirection, and=20 retargeting. 5. SIP elements may need to apply policy about passing and screening the information. 6. Multi-vendor interoperability is important. This mechanism is not appropriate in the following situations: 1. SIP behavior is changed. 2. The information is generated and consumed at the SIP layer by SIP=20 elements. 3. SIP elements besides the UAC and UAS might be interested and consume=20 the information. 4. There are specific privacy or cross-RAI issues involved with the=20 information being transported. User data of the mechanism will be clearly marked with the application,=20 encoding, semantics, and contents of the data, allowing policy to be=20 applied by UAs. The working group will define the information which=20 each application must specify in a standards-track document to utilize=20 the mechanism. One important application of this mechanism is interworking with the=20 ISDN User to User Information Service. This application defined by=20 ITU-T Q.931, is extensively deployed in the PSTN today, supporting such=20 applications as contact centers, call centers, and automatic call=20 distributors (ACDs). A major barrier to the movement of these=20 applications to SIP is the lack of a standard mechanism to transport=20 this information in SIP. For interworking with ISDN, minimal=20 information about the content of the UUI is available. In this case=20 only, the content will just indicate ISDN UUI Service 1 interworking=20 rather than the actual content. Call control UUI is user information conveyed between user agents during call control operations. As a result, the information must be conveyed=20 with the INVITE transaction, and must survive proxy retargeting,=20 redirection, and transfers. The mechanism must utilize a minimum of SIP extensions as it will need to be supported by many simple SIP user=20 agents such as PSTN gateways. The mechanism must interwork with the=20 existing ISDN service but should also be extensible for use by other=20 applications and non-ISDN protocols. While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI can be generated by a number of protocols that are not ISUP, and as such it is architecturally unreasonable to interwork these protocols at the=20 SIP / ISUP gateway. That is, existing SIP-T approaches defined in=20 RFC3372 do not meet the requirements. Mechanisms based on the SIP INFO method, RFC2976, will not be considered by the working group since the UUI contents carry information that must=20 be conveyed during session setup at the user agent - the information=20 must be conveyed with the INVITE transaction. The information must be=20 passed with the session setup request (INVITE), responses to that=20 INVITE, or session termination requests. As a result, it is not=20 possible to use INFO in these cases. The group will produce: - A problem statement and requirements document for implementing a SIP=20 call control UUI mechanism - A specification of the SIP extension to best meet those requirements. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mar 10 - Problem statement and requirements document to IESG=20 (Informational) Aug 10 - SIP call control UUI specification to IESG (PS) _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Wed Nov 4 03:43:07 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C893A6979 for ; Wed, 4 Nov 2009 03:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.075 X-Spam-Level: X-Spam-Status: No, score=-6.075 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9wAxxhb5wVF for ; Wed, 4 Nov 2009 03:43:05 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 4753D3A63C9 for ; Wed, 4 Nov 2009 03:43:05 -0800 (PST) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id nA4BhPwc005543; Wed, 4 Nov 2009 12:43:25 +0100 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA4BhPqn007279; Wed, 4 Nov 2009 12:43:25 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.3.83]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Wed, 4 Nov 2009 12:43:24 +0100 From: "Elwell, John" To: Alan Johnston , "dispatch@ietf.org" Date: Wed, 4 Nov 2009 12:43:41 +0100 Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Thread-Index: AcpcyefBSZqpwJq4TPKel/GSGPLY8gAecttA Message-ID: <7402509E63C5A145A6095D46C179A5B7058468FBC1@DEMCHP99E35MSX.ww902.siemens.net> References: <4AF09BF6.9010902@sipstation.com> In-Reply-To: <4AF09BF6.9010902@sipstation.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 11:43:07 -0000 Alan, Do we need to make any statement about applicability of the mechanism to 3P= CC situations? For example, UA A has exchanged UUI with UA B, but then is 3= PCC-transferred to UA C - does UA A need to exchange UUI with UA C? From UA= A's perspective it would be mid-call. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston > Sent: 03 November 2009 21:09 > To: dispatch@ietf.org > Subject: [dispatch] Updated CCUS Charter Text - Call Control=20 > UUI for SIP >=20 > All, >=20 > Here is some updated charter text for CCUS. Comments are=20 > most welcome. >=20 > Thanks, > Alan >=20 > - - - - - >=20 > The Call Control UUI for SIP (CCUS) working group is chartered to=20 > define a SIP mechanism for transporting call control related=20 > user-to-user (UUI) information between User Agents. >=20 > The mechanism developed in this working group is generally=20 > appropriate=20 > in the following situations: > 1. The information is generated and consumed by an=20 > application using SIP=20 > during session setup but the application is not necessarily=20 > even SIP aware. > 2. SIP behavior is unchanged. > 3. Generally only the UAC and UAS are interested in the information. > 4. The information is expected to survive retargeting,=20 > redirection, and=20 > retargeting. > 5. SIP elements may need to apply policy about passing and=20 > screening the=20 > information. > 6. Multi-vendor interoperability is important. >=20 > This mechanism is not appropriate in the following situations: > 1. SIP behavior is changed. > 2. The information is generated and consumed at the SIP layer by SIP=20 > elements. > 3. SIP elements besides the UAC and UAS might be interested=20 > and consume=20 > the information. > 4. There are specific privacy or cross-RAI issues involved with the=20 > information being transported. >=20 > User data of the mechanism will be clearly marked with the=20 > application,=20 > encoding, semantics, and contents of the data, allowing policy to be=20 > applied by UAs. The working group will define the information which=20 > each application must specify in a standards-track document=20 > to utilize=20 > the mechanism. >=20 > One important application of this mechanism is interworking with the=20 > ISDN User to User Information Service. This application defined by=20 > ITU-T Q.931, is extensively deployed in the PSTN today,=20 > supporting such=20 > applications as contact centers, call centers, and automatic call=20 > distributors (ACDs). A major barrier to the movement of these=20 > applications to SIP is the lack of a standard mechanism to transport=20 > this information in SIP. For interworking with ISDN, minimal=20 > information about the content of the UUI is available. In this case=20 > only, the content will just indicate ISDN UUI Service 1 interworking=20 > rather than the actual content. >=20 > Call control UUI is user information conveyed between user=20 > agents during=20 > call control operations. As a result, the information must=20 > be conveyed=20 > with the INVITE transaction, and must survive proxy retargeting,=20 > redirection, and transfers. The mechanism must utilize a=20 > minimum of SIP=20 > extensions as it will need to be supported by many simple SIP user=20 > agents such as PSTN gateways. The mechanism must interwork with the=20 > existing ISDN service but should also be extensible for use by other=20 > applications and non-ISDN protocols. >=20 > While PSTN UUI is carried in ISUP (ISDN User Part), SIP call=20 > control UUI=20 > can be generated by a number of protocols that are not ISUP,=20 > and as such=20 > it is architecturally unreasonable to interwork these=20 > protocols at the=20 > SIP / ISUP gateway. That is, existing SIP-T approaches defined in=20 > RFC3372 do not meet the requirements. >=20 > Mechanisms based on the SIP INFO method, RFC2976, will not be=20 > considered=20 > by the working group since the UUI contents carry information=20 > that must=20 > be conveyed during session setup at the user agent - the information=20 > must be conveyed with the INVITE transaction. The=20 > information must be=20 > passed with the session setup request (INVITE), responses to that=20 > INVITE, or session termination requests. As a result, it is not=20 > possible to use INFO in these cases. >=20 > The group will produce: >=20 > - A problem statement and requirements document for=20 > implementing a SIP=20 > call control UUI mechanism >=20 > - A specification of the SIP extension to best meet those=20 > requirements. >=20 > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Mar 10 - Problem statement and requirements document to IESG=20 > (Informational) > Aug 10 - SIP call control UUI specification to IESG (PS) >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From sanjsinh@cisco.com Wed Nov 4 03:44:29 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2170D3A68BB for ; Wed, 4 Nov 2009 03:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 HaNfXWPmCjM8 for ; Wed, 4 Nov 2009 03:44:14 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A30543A6966 for ; Wed, 4 Nov 2009 03:44:14 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJP38EqrR7H+/2dsb2JhbADEfJg+hD0E X-IronPort-AV: E=Sophos;i="4.44,679,1249257600"; d="scan'208";a="266010018" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 04 Nov 2009 11:44:35 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA4BianK024940; Wed, 4 Nov 2009 11:44:36 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 05:44:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Nov 2009 05:44:33 -0600 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA0C00A1@XMB-RCD-101.cisco.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Thread-Index: Acpcyf9cQc7Gv/u7RAyfnE5VWPs2QQAWmnAQAALE5EAAAHpdwAAEirDQ References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> From: "Sanjay Sinha (sanjsinh)" To: "Leon Portman" , "Alan Johnston" , X-OriginalArrivalTime: 04 Nov 2009 11:44:35.0575 (UTC) FILETIME=[2EAD5070:01CA5D44] Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 11:44:30 -0000 Do you mean same IE that was present in initial INVITE needs to be presented in Re-Invite as well?=20 If the information does not change, then I do not see any value in carrying the same payload in re-Invite. But if there is a new IE, then yeah it can be presented in re-Invite. I am not sure if there can be a new UU IE after the call is setup and before call termination. Sanjay -----Original Message----- From: Leon Portman [mailto:Leon.Portman@nice.com]=20 Sent: Wednesday, November 04, 2009 3:02 PM To: Sanjay Sinha (sanjsinh); Alan Johnston; dispatch@ietf.org Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Actually I was thinking that if UUI was presented during the original INVITE, if it is going to be required to be presented during RE_INVITES as well, especially if it represents some client state information Leon -----Original Message----- From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com]=20 Sent: Wednesday, November 04, 2009 11:18 AM To: Leon Portman; Alan Johnston; dispatch@ietf.org Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP I think UUI is carried during session setup and teardown, and hence re-Invite scenario may not be applicable here. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Leon Portman Sent: Wednesday, November 04, 2009 1:29 PM To: Alan Johnston; dispatch@ietf.org Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Only one comment, does it also supposed to support re-invite (for SRTP re-keying or media updates) scenarios as well? Thanks Leon -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Tuesday, November 03, 2009 11:09 PM To: dispatch@ietf.org Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP All, Here is some updated charter text for CCUS. Comments are most welcome. Thanks, Alan - - - - - The Call Control UUI for SIP (CCUS) working group is chartered to=20 define a SIP mechanism for transporting call control related=20 user-to-user (UUI) information between User Agents. The mechanism developed in this working group is generally appropriate=20 in the following situations: 1. The information is generated and consumed by an application using SIP during session setup but the application is not necessarily even SIP aware. 2. SIP behavior is unchanged. 3. Generally only the UAC and UAS are interested in the information. 4. The information is expected to survive retargeting, redirection, and=20 retargeting. 5. SIP elements may need to apply policy about passing and screening the information. 6. Multi-vendor interoperability is important. This mechanism is not appropriate in the following situations: 1. SIP behavior is changed. 2. The information is generated and consumed at the SIP layer by SIP=20 elements. 3. SIP elements besides the UAC and UAS might be interested and consume=20 the information. 4. There are specific privacy or cross-RAI issues involved with the=20 information being transported. User data of the mechanism will be clearly marked with the application,=20 encoding, semantics, and contents of the data, allowing policy to be=20 applied by UAs. The working group will define the information which=20 each application must specify in a standards-track document to utilize=20 the mechanism. One important application of this mechanism is interworking with the=20 ISDN User to User Information Service. This application defined by=20 ITU-T Q.931, is extensively deployed in the PSTN today, supporting such=20 applications as contact centers, call centers, and automatic call=20 distributors (ACDs). A major barrier to the movement of these=20 applications to SIP is the lack of a standard mechanism to transport=20 this information in SIP. For interworking with ISDN, minimal=20 information about the content of the UUI is available. In this case=20 only, the content will just indicate ISDN UUI Service 1 interworking=20 rather than the actual content. Call control UUI is user information conveyed between user agents during call control operations. As a result, the information must be conveyed=20 with the INVITE transaction, and must survive proxy retargeting,=20 redirection, and transfers. The mechanism must utilize a minimum of SIP extensions as it will need to be supported by many simple SIP user=20 agents such as PSTN gateways. The mechanism must interwork with the=20 existing ISDN service but should also be extensible for use by other=20 applications and non-ISDN protocols. While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI can be generated by a number of protocols that are not ISUP, and as such it is architecturally unreasonable to interwork these protocols at the=20 SIP / ISUP gateway. That is, existing SIP-T approaches defined in=20 RFC3372 do not meet the requirements. Mechanisms based on the SIP INFO method, RFC2976, will not be considered by the working group since the UUI contents carry information that must=20 be conveyed during session setup at the user agent - the information=20 must be conveyed with the INVITE transaction. The information must be=20 passed with the session setup request (INVITE), responses to that=20 INVITE, or session termination requests. As a result, it is not=20 possible to use INFO in these cases. The group will produce: - A problem statement and requirements document for implementing a SIP=20 call control UUI mechanism - A specification of the SIP extension to best meet those requirements. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mar 10 - Problem statement and requirements document to IESG=20 (Informational) Aug 10 - SIP call control UUI specification to IESG (PS) _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Wed Nov 4 05:56:31 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C933A68E2 for ; Wed, 4 Nov 2009 05:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 q23BsWrSgSUw for ; Wed, 4 Nov 2009 05:56:30 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7A8CF3A68AE for ; Wed, 4 Nov 2009 05:56:30 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHMX8UqrR7Ht/2dsb2JhbADFU5gehD0E X-IronPort-AV: E=Sophos;i="4.44,680,1249257600"; d="scan'208";a="221101610" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2009 13:56:52 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA4DupQq021047; Wed, 4 Nov 2009 13:56:52 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 08:56:51 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 08:56:51 -0500 Message-ID: <4AF18822.4070603@cisco.com> Date: Wed, 04 Nov 2009 08:56:50 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Leon Portman References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2009 13:56:51.0208 (UTC) FILETIME=[A8AED080:01CA5D56] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 13:56:31 -0000 Leon Portman wrote: > Actually I was thinking that if UUI was presented during the original INVITE, if it is going to be required to be presented during RE_INVITES as well, especially if it represents some client state information Can you explain more about this? The charter seems to spend its time explaining that this is governed by the needs for session setup. If this is a mechanism that is also intended for use after the session is established, then I think more explanation is required. As described, this is just plain tunneling, pure and simple. And INFO (expecially with the new Info-Package work) is yet another mechanism for tunneling. The rationale for not using INFO for UUI is that it is needed during session establishment. Clearly that doesn't apply after the session is established. Of course its a mess to have two mechanisms with overlapping purposes. It would be silly to use two mechanisms to transport the same information, depending on when in the lifetime of the session the info was being transported. But I'm having difficulty drawing a clear distinction between the applicability of the two mechanisms. Thanks, Paul > Leon > > -----Original Message----- > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > Sent: Wednesday, November 04, 2009 11:18 AM > To: Leon Portman; Alan Johnston; dispatch@ietf.org > Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP > > I think UUI is carried during session setup and teardown, and hence > re-Invite scenario may not be applicable here. > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Wednesday, November 04, 2009 1:29 PM > To: Alan Johnston; dispatch@ietf.org > Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for > SIP > > Only one comment, does it also supposed to support re-invite (for SRTP > re-keying or media updates) scenarios as well? > > Thanks > > Leon > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Alan Johnston > Sent: Tuesday, November 03, 2009 11:09 PM > To: dispatch@ietf.org > Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP > > All, > > Here is some updated charter text for CCUS. Comments are most welcome. > > Thanks, > Alan > > - - - - - > > The Call Control UUI for SIP (CCUS) working group is chartered to > define a SIP mechanism for transporting call control related > user-to-user (UUI) information between User Agents. > > The mechanism developed in this working group is generally appropriate > in the following situations: > 1. The information is generated and consumed by an application using SIP > > during session setup but the application is not necessarily even SIP > aware. > 2. SIP behavior is unchanged. > 3. Generally only the UAC and UAS are interested in the information. > 4. The information is expected to survive retargeting, redirection, and > retargeting. > 5. SIP elements may need to apply policy about passing and screening the > > information. > 6. Multi-vendor interoperability is important. > > This mechanism is not appropriate in the following situations: > 1. SIP behavior is changed. > 2. The information is generated and consumed at the SIP layer by SIP > elements. > 3. SIP elements besides the UAC and UAS might be interested and consume > the information. > 4. There are specific privacy or cross-RAI issues involved with the > information being transported. > > User data of the mechanism will be clearly marked with the application, > encoding, semantics, and contents of the data, allowing policy to be > applied by UAs. The working group will define the information which > each application must specify in a standards-track document to utilize > the mechanism. > > One important application of this mechanism is interworking with the > ISDN User to User Information Service. This application defined by > ITU-T Q.931, is extensively deployed in the PSTN today, supporting such > applications as contact centers, call centers, and automatic call > distributors (ACDs). A major barrier to the movement of these > applications to SIP is the lack of a standard mechanism to transport > this information in SIP. For interworking with ISDN, minimal > information about the content of the UUI is available. In this case > only, the content will just indicate ISDN UUI Service 1 interworking > rather than the actual content. > > Call control UUI is user information conveyed between user agents during > > call control operations. As a result, the information must be conveyed > with the INVITE transaction, and must survive proxy retargeting, > redirection, and transfers. The mechanism must utilize a minimum of SIP > > extensions as it will need to be supported by many simple SIP user > agents such as PSTN gateways. The mechanism must interwork with the > existing ISDN service but should also be extensible for use by other > applications and non-ISDN protocols. > > While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI > > can be generated by a number of protocols that are not ISUP, and as such > > it is architecturally unreasonable to interwork these protocols at the > SIP / ISUP gateway. That is, existing SIP-T approaches defined in > RFC3372 do not meet the requirements. > > Mechanisms based on the SIP INFO method, RFC2976, will not be considered > > by the working group since the UUI contents carry information that must > be conveyed during session setup at the user agent - the information > must be conveyed with the INVITE transaction. The information must be > passed with the session setup request (INVITE), responses to that > INVITE, or session termination requests. As a result, it is not > possible to use INFO in these cases. > > The group will produce: > > - A problem statement and requirements document for implementing a SIP > call control UUI mechanism > > - A specification of the SIP extension to best meet those requirements. > > Goals and Milestones > ==================== > > Mar 10 - Problem statement and requirements document to IESG > (Informational) > Aug 10 - SIP call control UUI specification to IESG (PS) > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From john.elwell@siemens-enterprise.com Wed Nov 4 05:57:14 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5918C3A68F1 for ; Wed, 4 Nov 2009 05:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.079 X-Spam-Level: X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeIlMAgeihAg for ; Wed, 4 Nov 2009 05:57:13 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 1BB343A68E2 for ; Wed, 4 Nov 2009 05:57:12 -0800 (PST) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id nA4DvW6o026914 for ; Wed, 4 Nov 2009 14:57:32 +0100 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA4DvWUv012678 for ; Wed, 4 Nov 2009 14:57:32 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.3.83]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Wed, 4 Nov 2009 14:57:31 +0100 From: "Elwell, John" To: "dispatch@ietf.org" Date: Wed, 4 Nov 2009 14:57:31 +0100 Thread-Topic: Draft charter for domain registration work Thread-Index: AcpdVsB1/PYZJl+nREaLZTuG1cswWQ== Message-ID: <7402509E63C5A145A6095D46C179A5B7058468FC4B@DEMCHP99E35MSX.ww902.siemens.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Draft charter for domain registration work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 13:57:14 -0000 Below is an initial proposal for chartering this work: John Domain REGistration for SIP (DREGS) Description of Working Group The Domain REGistration for SIP (DREGS) working group is chartered to speci= fy a means by which an entity authoritative for SIP URIs in a given domain = can dynamically register reachability information for that domain with anot= her domain. The SIP protocol [RFC 3261 and its extensions] supports multiple means of o= btaining the connection information necessary to deliver out-of-dialog SIP = requests to their intended targets. When a SIP Proxy needs to send a reque= st to a target address-of-record (AoR) within its domain, it can use a loca= tion service to obtain the registered contact URI, together with any associ= ated path information [RFC 3327], and build a route set to reach the target= UA(s). The SIP REGISTER method can be used to register contact URIs and p= ath information. SIP-outbound [RFC 5626] enhances this mechanism to cater f= or UAs behind NATs and firewalls. When a SIP UA or Proxy needs to send a re= quest to a target for which it is not authoritative, the UA/Proxy can use R= FC3263 procedures for using DNS to resolve the next-hop connection informat= ion. It is not uncommon, however, to use a dynamic registration mechanism to pro= vide reachability information from a first domain to a second domain, to en= able the second domain to deliver out-of-dialog requests targeted at the fi= rst domain. A typical example is a SIP-PBX in a small/medium business that = needs to be reachable from a SIP Service Provider (SSP). Even if the SIP-PB= X has its own domain name, it is expected that in most situations this will= be a sub-domain of the service provider's domain name. However, not every= service provider wishes to maintain DNS infrastructure supporting dynamic = registration, and not all SIP-PBXs support a dynamic DNS client. Furthermor= e, typical SSP deployments are such that a SIP proxy has to be traversed in= order reach the SIP-PBX, and DNS does not provide a means of discovering t= his. On the other hand, because a single SSP may support multiple thousands of s= uch SMB SIP-PBX's, it is impractical and cost-prohibitive to manually provi= sion their IP addresses in every SIP node along paths to those SIP-PBXs. F= urthermore, IP addresses can be dynamically assigned and therefore can pote= ntially change relatively frequently. In practice, a dynamic reachability mechanism is used, based on the SIP REG= ISTER method. Effectively a single REGISTER request registers the domain of= the SIP-PBX, so that any out-of-dialog request targeted at a SIP URI in th= e SIP-PBX's domain can be delivered from the SSP to the SIP-PBX. However, i= mplementations of this mechanism vary in details, leading to interoperabili= ty issues between SIP-PBXs and SSPs, and the need for equipment to support = different variants. The task of this working group is therefore to standardize a domain registr= ation mechanism for SIP, based on the REGISTER method. The solution will ut= ilize existing SIP mechanisms to the extent possible, although it is antici= pated that small protocol extensions are likely to be required, and hence a= standards track (rather than BCP) deliverable is expected. The solution wi= ll accommodate existing SIP extensions relating to registration (e.g., Path= , Service-Route [RFC 3608] and SIP-outbound) by ensuring that they are not = precluded from use in the context of domain registration, if they are deeme= d relevant. The solution will incorporate a compatibility mechanism to ensu= re a deterministic outcome when interworking with entities that do not supp= ort domain registration. Goals and Milestones Jan 2010 Domain registration specification WGLC Feb 2010 Domain registration specification to IESG (PS) From pkyzivat@cisco.com Wed Nov 4 06:00:58 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9973A68B4 for ; Wed, 4 Nov 2009 06:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 shOGnyhMy1ly for ; Wed, 4 Nov 2009 06:00:57 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BE7B23A67AF for ; Wed, 4 Nov 2009 06:00:56 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGQY8UpAZnwN/2dsb2JhbADFVZgehD0E X-IronPort-AV: E=Sophos;i="4.44,680,1249257600"; d="scan'208";a="66339076" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 04 Nov 2009 14:01:17 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA4E1Hjc004759; Wed, 4 Nov 2009 14:01:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 09:01:17 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 09:01:17 -0500 Message-ID: <4AF1892C.4060504@cisco.com> Date: Wed, 04 Nov 2009 09:01:16 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Sanjay Sinha (sanjsinh)" References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C00A1@XMB-RCD-101.cisco.com> In-Reply-To: <00FC4AA684E90E4DA2FF71021CD5A6CA0C00A1@XMB-RCD-101.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2009 14:01:17.0197 (UTC) FILETIME=[473983D0:01CA5D57] Cc: Leon Portman , dispatch@ietf.org Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 14:00:58 -0000 I always use 3pcc as a test case, because it presents problems almost every time. Of course the problem with 3pcc is that one "side" may remain the same, while the other "side" is replaced. The replacement typically has no knowledge of the history of what went on before it joined. So there usually needs to be some mechanism for it to be clued in about that. I don't know if the same is true here or not. It depends on whether the UUI information is viewed as transient, or as state of the session. Thanks, Paul Sanjay Sinha (sanjsinh) wrote: > Do you mean same IE that was present in initial INVITE needs to be > presented in Re-Invite as well? > > If the information does not change, then I do not see any value in > carrying the same payload in re-Invite. But if there is a new IE, then > yeah it can be presented in re-Invite. > I am not sure if there can be a new UU IE after the call is setup and > before call termination. > > Sanjay > > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Wednesday, November 04, 2009 3:02 PM > To: Sanjay Sinha (sanjsinh); Alan Johnston; dispatch@ietf.org > Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for > SIP > > Actually I was thinking that if UUI was presented during the original > INVITE, if it is going to be required to be presented during RE_INVITES > as well, especially if it represents some client state information > > Leon > > -----Original Message----- > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > Sent: Wednesday, November 04, 2009 11:18 AM > To: Leon Portman; Alan Johnston; dispatch@ietf.org > Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for > SIP > > I think UUI is carried during session setup and teardown, and hence > re-Invite scenario may not be applicable here. > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Wednesday, November 04, 2009 1:29 PM > To: Alan Johnston; dispatch@ietf.org > Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for > SIP > > Only one comment, does it also supposed to support re-invite (for SRTP > re-keying or media updates) scenarios as well? > > Thanks > > Leon > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Alan Johnston > Sent: Tuesday, November 03, 2009 11:09 PM > To: dispatch@ietf.org > Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP > > All, > > Here is some updated charter text for CCUS. Comments are most welcome. > > Thanks, > Alan > > - - - - - > > The Call Control UUI for SIP (CCUS) working group is chartered to > define a SIP mechanism for transporting call control related > user-to-user (UUI) information between User Agents. > > The mechanism developed in this working group is generally appropriate > in the following situations: > 1. The information is generated and consumed by an application using SIP > > during session setup but the application is not necessarily even SIP > aware. > 2. SIP behavior is unchanged. > 3. Generally only the UAC and UAS are interested in the information. > 4. The information is expected to survive retargeting, redirection, and > retargeting. > 5. SIP elements may need to apply policy about passing and screening the > > information. > 6. Multi-vendor interoperability is important. > > This mechanism is not appropriate in the following situations: > 1. SIP behavior is changed. > 2. The information is generated and consumed at the SIP layer by SIP > elements. > 3. SIP elements besides the UAC and UAS might be interested and consume > the information. > 4. There are specific privacy or cross-RAI issues involved with the > information being transported. > > User data of the mechanism will be clearly marked with the application, > encoding, semantics, and contents of the data, allowing policy to be > applied by UAs. The working group will define the information which > each application must specify in a standards-track document to utilize > the mechanism. > > One important application of this mechanism is interworking with the > ISDN User to User Information Service. This application defined by > ITU-T Q.931, is extensively deployed in the PSTN today, supporting such > applications as contact centers, call centers, and automatic call > distributors (ACDs). A major barrier to the movement of these > applications to SIP is the lack of a standard mechanism to transport > this information in SIP. For interworking with ISDN, minimal > information about the content of the UUI is available. In this case > only, the content will just indicate ISDN UUI Service 1 interworking > rather than the actual content. > > Call control UUI is user information conveyed between user agents during > > call control operations. As a result, the information must be conveyed > with the INVITE transaction, and must survive proxy retargeting, > redirection, and transfers. The mechanism must utilize a minimum of SIP > > extensions as it will need to be supported by many simple SIP user > agents such as PSTN gateways. The mechanism must interwork with the > existing ISDN service but should also be extensible for use by other > applications and non-ISDN protocols. > > While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI > > can be generated by a number of protocols that are not ISUP, and as such > > it is architecturally unreasonable to interwork these protocols at the > SIP / ISUP gateway. That is, existing SIP-T approaches defined in > RFC3372 do not meet the requirements. > > Mechanisms based on the SIP INFO method, RFC2976, will not be considered > > by the working group since the UUI contents carry information that must > be conveyed during session setup at the user agent - the information > must be conveyed with the INVITE transaction. The information must be > passed with the session setup request (INVITE), responses to that > INVITE, or session termination requests. As a result, it is not > possible to use INFO in these cases. > > The group will produce: > > - A problem statement and requirements document for implementing a SIP > call control UUI mechanism > > - A specification of the SIP extension to best meet those requirements. > > Goals and Milestones > ==================== > > Mar 10 - Problem statement and requirements document to IESG > (Informational) > Aug 10 - SIP call control UUI specification to IESG (PS) > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From Leon.Portman@nice.com Wed Nov 4 06:08:11 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7903A6956 for ; Wed, 4 Nov 2009 06:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 S7PSmSj9pkAy for ; Wed, 4 Nov 2009 06:08:10 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id AF2A13A68F7 for ; Wed, 4 Nov 2009 06:08:09 -0800 (PST) Received: from tlvcas02.nice.com (172.18.253.6) by tlvcas01.nice.com (192.168.253.111) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 4 Nov 2009 16:08:29 +0200 Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Wed, 4 Nov 2009 16:08:29 +0200 From: Leon Portman To: Paul Kyzivat Date: Wed, 4 Nov 2009 16:08:28 +0200 Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Thread-Index: AcpdVsPEFRuzjZuHT8CGwj9VwUzUmAAALcXg Message-ID: <07465C1D981ABC41A344374066AE1A2C37D6AF5B7D@TLVMBX01.nice.com> References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> <4AF18822.4070603@cisco.com> In-Reply-To: <4AF18822.4070603@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 14:08:11 -0000 I will try to explain my case. The use case for example is a customer is calling to an organization via SI= P trunk with some UUI info from the hosted IVR session (business data). He = is connected to an agent and then was put on hold, triggering REINVITE with= updated SDP. And then transferred to another agent. Under assumption that = UUI represents some kind business data state of the call (IVR selection, cu= stomer ID etc), this information has to be preserved during all session cha= nges. It is not transient state that is delivered via INFO. Or even more complex, the call is transferred via SIP trunk to completely a= nother PBX as another SIP session (B2BUA scenario). Thanks Leon -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Wednesday, November 04, 2009 3:57 PM To: Leon Portman Cc: Sanjay Sinha (sanjsinh); Alan Johnston; dispatch@ietf.org Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SI= P Leon Portman wrote: > Actually I was thinking that if UUI was presented during the original INV= ITE, if it is going to be required to be presented during RE_INVITES as wel= l, especially if it represents some client state information Can you explain more about this? The charter seems to spend its time explaining that this is governed by=20 the needs for session setup. If this is a mechanism that is also=20 intended for use after the session is established, then I think more=20 explanation is required. As described, this is just plain tunneling, pure and simple. And INFO (expecially with the new Info-Package work) is yet another=20 mechanism for tunneling. The rationale for not using INFO for UUI is=20 that it is needed during session establishment. Clearly that doesn't=20 apply after the session is established. Of course its a mess to have two mechanisms with overlapping purposes.=20 It would be silly to use two mechanisms to transport the same=20 information, depending on when in the lifetime of the session the info=20 was being transported. But I'm having difficulty drawing a clear=20 distinction between the applicability of the two mechanisms. Thanks, Paul > Leon >=20 > -----Original Message----- > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com]=20 > Sent: Wednesday, November 04, 2009 11:18 AM > To: Leon Portman; Alan Johnston; dispatch@ietf.org > Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for = SIP >=20 > I think UUI is carried during session setup and teardown, and hence > re-Invite scenario may not be applicable here. >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Wednesday, November 04, 2009 1:29 PM > To: Alan Johnston; dispatch@ietf.org > Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for > SIP >=20 > Only one comment, does it also supposed to support re-invite (for SRTP > re-keying or media updates) scenarios as well? >=20 > Thanks >=20 > Leon >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Alan Johnston > Sent: Tuesday, November 03, 2009 11:09 PM > To: dispatch@ietf.org > Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP >=20 > All, >=20 > Here is some updated charter text for CCUS. Comments are most welcome. >=20 > Thanks, > Alan >=20 > - - - - - >=20 > The Call Control UUI for SIP (CCUS) working group is chartered to=20 > define a SIP mechanism for transporting call control related=20 > user-to-user (UUI) information between User Agents. >=20 > The mechanism developed in this working group is generally appropriate=20 > in the following situations: > 1. The information is generated and consumed by an application using SIP >=20 > during session setup but the application is not necessarily even SIP > aware. > 2. SIP behavior is unchanged. > 3. Generally only the UAC and UAS are interested in the information. > 4. The information is expected to survive retargeting, redirection, and=20 > retargeting. > 5. SIP elements may need to apply policy about passing and screening the >=20 > information. > 6. Multi-vendor interoperability is important. >=20 > This mechanism is not appropriate in the following situations: > 1. SIP behavior is changed. > 2. The information is generated and consumed at the SIP layer by SIP=20 > elements. > 3. SIP elements besides the UAC and UAS might be interested and consume=20 > the information. > 4. There are specific privacy or cross-RAI issues involved with the=20 > information being transported. >=20 > User data of the mechanism will be clearly marked with the application,=20 > encoding, semantics, and contents of the data, allowing policy to be=20 > applied by UAs. The working group will define the information which=20 > each application must specify in a standards-track document to utilize=20 > the mechanism. >=20 > One important application of this mechanism is interworking with the=20 > ISDN User to User Information Service. This application defined by=20 > ITU-T Q.931, is extensively deployed in the PSTN today, supporting such=20 > applications as contact centers, call centers, and automatic call=20 > distributors (ACDs). A major barrier to the movement of these=20 > applications to SIP is the lack of a standard mechanism to transport=20 > this information in SIP. For interworking with ISDN, minimal=20 > information about the content of the UUI is available. In this case=20 > only, the content will just indicate ISDN UUI Service 1 interworking=20 > rather than the actual content. >=20 > Call control UUI is user information conveyed between user agents during >=20 > call control operations. As a result, the information must be conveyed=20 > with the INVITE transaction, and must survive proxy retargeting,=20 > redirection, and transfers. The mechanism must utilize a minimum of SIP >=20 > extensions as it will need to be supported by many simple SIP user=20 > agents such as PSTN gateways. The mechanism must interwork with the=20 > existing ISDN service but should also be extensible for use by other=20 > applications and non-ISDN protocols. >=20 > While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI >=20 > can be generated by a number of protocols that are not ISUP, and as such >=20 > it is architecturally unreasonable to interwork these protocols at the=20 > SIP / ISUP gateway. That is, existing SIP-T approaches defined in=20 > RFC3372 do not meet the requirements. >=20 > Mechanisms based on the SIP INFO method, RFC2976, will not be considered >=20 > by the working group since the UUI contents carry information that must=20 > be conveyed during session setup at the user agent - the information=20 > must be conveyed with the INVITE transaction. The information must be=20 > passed with the session setup request (INVITE), responses to that=20 > INVITE, or session termination requests. As a result, it is not=20 > possible to use INFO in these cases. >=20 > The group will produce: >=20 > - A problem statement and requirements document for implementing a SIP=20 > call control UUI mechanism >=20 > - A specification of the SIP extension to best meet those requirements. >=20 > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Mar 10 - Problem statement and requirements document to IESG=20 > (Informational) > Aug 10 - SIP call control UUI specification to IESG (PS) >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From alan@sipstation.com Wed Nov 4 07:47:01 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549FB3A697C for ; Wed, 4 Nov 2009 07:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORnvoGSg29ZU for ; Wed, 4 Nov 2009 07:46:59 -0800 (PST) Received: from outbound-mail-341.bluehost.com (outbound-mail-341.bluehost.com [66.147.249.2]) by core3.amsl.com (Postfix) with SMTP id D8A9A3A67D4 for ; Wed, 4 Nov 2009 07:46:59 -0800 (PST) Received: (qmail 14717 invoked by uid 0); 4 Nov 2009 15:47:21 -0000 Received: from unknown (HELO host350.hostmonster.com) (66.147.240.150) by outboundproxy7.bluehost.com.bluehost.com with SMTP; 4 Nov 2009 15:47:21 -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=lhQTRsIn0mEAUShl8iw3ZCiIPjfQivvTA9pHvBNSgrc3r3w3RKiW/69RO0hrtV6xlinJUTUnjKx2mTYzSql4johd+ZhrN5FGNYVKEE9EcXJUAiOM/tozG9VAM6Rwb9tN; Received: from [166.205.6.28] (helo=[10.157.189.204]) by host350.hostmonster.com with esmtpa (Exim 4.69) (envelope-from ) id 1N5i4s-0000pF-Md; Wed, 04 Nov 2009 08:47:21 -0700 References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C00A1@XMB-RCD-101.cisco.com> <4AF1892C.4060504@cisco.com> Message-Id: <99713295-BEB2-40C8-AB6D-92AC30B038F2@sipstation.com> From: Alan Johnston To: Paul Kyzivat In-Reply-To: <4AF1892C.4060504@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Wed, 4 Nov 2009 09:47:12 -0600 X-Identified-User: {2451:host350.hostmonster.com:aeternus:sipstation.com} {sentby:smtp auth 166.205.6.28 authed with alan+sipstation.com} Cc: Leon Portman , "dispatch@ietf.org" Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 15:47:01 -0000 This is an interesting question. On first blush, it seems that due to 3pcc type applications, the mechanism will need to be used in re- INVITEs. However, we will need to be very careful to define the semantics for true mid-call uses. I don't think the charter needs to specify this much detail - the requirements document produced by the working group should include this. Any comments on the charter text? I know I am looking forward to getting back to the mechanism discussion... Thanks Alan On Nov 4, 2009, at 8:01 AM, Paul Kyzivat wrote: > I always use 3pcc as a test case, because it presents problems > almost every time. > > Of course the problem with 3pcc is that one "side" may remain the > same, while the other "side" is replaced. The replacement typically > has no knowledge of the history of what went on before it joined. So > there usually needs to be some mechanism for it to be clued in about > that. > > I don't know if the same is true here or not. It depends on whether > the UUI information is viewed as transient, or as state of the > session. > > Thanks, > Paul > > Sanjay Sinha (sanjsinh) wrote: >> Do you mean same IE that was present in initial INVITE needs to be >> presented in Re-Invite as well? If the information does not change, >> then I do not see any value in >> carrying the same payload in re-Invite. But if there is a new IE, >> then >> yeah it can be presented in re-Invite. >> I am not sure if there can be a new UU IE after the call is setup and >> before call termination. >> Sanjay >> -----Original Message----- >> From: Leon Portman [mailto:Leon.Portman@nice.com] Sent: Wednesday, >> November 04, 2009 3:02 PM >> To: Sanjay Sinha (sanjsinh); Alan Johnston; dispatch@ietf.org >> Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control >> UUI for >> SIP >> Actually I was thinking that if UUI was presented during the original >> INVITE, if it is going to be required to be presented during >> RE_INVITES >> as well, especially if it represents some client state information >> Leon >> -----Original Message----- >> From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] Sent: >> Wednesday, November 04, 2009 11:18 AM >> To: Leon Portman; Alan Johnston; dispatch@ietf.org >> Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control >> UUI for >> SIP >> I think UUI is carried during session setup and teardown, and hence >> re-Invite scenario may not be applicable here. >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Leon Portman >> Sent: Wednesday, November 04, 2009 1:29 PM >> To: Alan Johnston; dispatch@ietf.org >> Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control >> UUI for >> SIP >> Only one comment, does it also supposed to support re-invite (for >> SRTP >> re-keying or media updates) scenarios as well? >> Thanks >> Leon >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Alan Johnston >> Sent: Tuesday, November 03, 2009 11:09 PM >> To: dispatch@ietf.org >> Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI >> for SIP >> All, >> Here is some updated charter text for CCUS. Comments are most >> welcome. >> Thanks, >> Alan >> - - - - - >> The Call Control UUI for SIP (CCUS) working group is chartered to >> define a SIP mechanism for transporting call control related user- >> to-user (UUI) information between User Agents. >> The mechanism developed in this working group is generally >> appropriate in the following situations: >> 1. The information is generated and consumed by an application >> using SIP >> during session setup but the application is not necessarily even SIP >> aware. >> 2. SIP behavior is unchanged. >> 3. Generally only the UAC and UAS are interested in the information. >> 4. The information is expected to survive retargeting, redirection, >> and retargeting. >> 5. SIP elements may need to apply policy about passing and >> screening the >> information. >> 6. Multi-vendor interoperability is important. >> This mechanism is not appropriate in the following situations: >> 1. SIP behavior is changed. >> 2. The information is generated and consumed at the SIP layer by >> SIP elements. >> 3. SIP elements besides the UAC and UAS might be interested and >> consume the information. >> 4. There are specific privacy or cross-RAI issues involved with the >> information being transported. >> User data of the mechanism will be clearly marked with the >> application, encoding, semantics, and contents of the data, >> allowing policy to be applied by UAs. The working group will >> define the information which each application must specify in a >> standards-track document to utilize the mechanism. >> One important application of this mechanism is interworking with >> the ISDN User to User Information Service. This application >> defined by ITU-T Q.931, is extensively deployed in the PSTN today, >> supporting such applications as contact centers, call centers, and >> automatic call distributors (ACDs). A major barrier to the >> movement of these applications to SIP is the lack of a standard >> mechanism to transport this information in SIP. For interworking >> with ISDN, minimal information about the content of the UUI is >> available. In this case only, the content will just indicate ISDN >> UUI Service 1 interworking rather than the actual content. >> Call control UUI is user information conveyed between user agents >> during >> call control operations. As a result, the information must be >> conveyed with the INVITE transaction, and must survive proxy >> retargeting, redirection, and transfers. The mechanism must >> utilize a minimum of SIP >> extensions as it will need to be supported by many simple SIP user >> agents such as PSTN gateways. The mechanism must interwork with >> the existing ISDN service but should also be extensible for use by >> other applications and non-ISDN protocols. >> While PSTN UUI is carried in ISUP (ISDN User Part), SIP call >> control UUI >> can be generated by a number of protocols that are not ISUP, and as >> such >> it is architecturally unreasonable to interwork these protocols at >> the SIP / ISUP gateway. That is, existing SIP-T approaches defined >> in RFC3372 do not meet the requirements. >> Mechanisms based on the SIP INFO method, RFC2976, will not be >> considered >> by the working group since the UUI contents carry information that >> must be conveyed during session setup at the user agent - the >> information must be conveyed with the INVITE transaction. The >> information must be passed with the session setup request (INVITE), >> responses to that INVITE, or session termination requests. As a >> result, it is not possible to use INFO in these cases. >> The group will produce: >> - A problem statement and requirements document for implementing a >> SIP call control UUI mechanism >> - A specification of the SIP extension to best meet those >> requirements. >> Goals and Milestones >> ==================== >> Mar 10 - Problem statement and requirements document to IESG >> (Informational) >> Aug 10 - SIP call control UUI specification to IESG (PS) >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From sanjsinh@cisco.com Wed Nov 4 08:07:09 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969683A67E4 for ; Wed, 4 Nov 2009 08:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Ep2lqhGgSA+0 for ; Wed, 4 Nov 2009 08:07:08 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 737923A63EB for ; Wed, 4 Nov 2009 08:07:08 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK818UqrR7Ht/2dsb2JhbADGKpgXhD0E X-IronPort-AV: E=Sophos;i="4.44,680,1249257600"; d="scan'208";a="201119107" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 04 Nov 2009 16:07:28 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA4G7RD9010544; Wed, 4 Nov 2009 16:07:28 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 10:07:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Nov 2009 10:07:23 -0600 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA0FFEF0@XMB-RCD-101.cisco.com> In-Reply-To: <4AF1892C.4060504@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Thread-Index: AcpdV0ewYMgVX6VQQQqmiGVVuLDLXAAERWFA References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C00A1@XMB-RCD-101.cisco.com> <4AF1892C.4060504@cisco.com> From: "Sanjay Sinha (sanjsinh)" To: "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 04 Nov 2009 16:07:27.0603 (UTC) FILETIME=[E789CC30:01CA5D68] Cc: Leon Portman , dispatch@ietf.org Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 16:07:09 -0000 Yeah this is a good case and for it we need re-Invite to carry it. If it is session related data, then for transfers should it be carried in REFER also, esp. for REFER with Replaces? Sanjay -----Original Message----- From: Paul Kyzivat (pkyzivat)=20 Sent: Wednesday, November 04, 2009 7:31 PM To: Sanjay Sinha (sanjsinh) Cc: Leon Portman; Alan Johnston; dispatch@ietf.org Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP I always use 3pcc as a test case, because it presents problems almost=20 every time. Of course the problem with 3pcc is that one "side" may remain the same,=20 while the other "side" is replaced. The replacement typically has no=20 knowledge of the history of what went on before it joined. So there=20 usually needs to be some mechanism for it to be clued in about that. I don't know if the same is true here or not. It depends on whether the=20 UUI information is viewed as transient, or as state of the session. Thanks, Paul Sanjay Sinha (sanjsinh) wrote: > Do you mean same IE that was present in initial INVITE needs to be > presented in Re-Invite as well?=20 >=20 > If the information does not change, then I do not see any value in > carrying the same payload in re-Invite. But if there is a new IE, then > yeah it can be presented in re-Invite. > I am not sure if there can be a new UU IE after the call is setup and > before call termination. >=20 > Sanjay >=20 > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > Sent: Wednesday, November 04, 2009 3:02 PM > To: Sanjay Sinha (sanjsinh); Alan Johnston; dispatch@ietf.org > Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for > SIP >=20 > Actually I was thinking that if UUI was presented during the original > INVITE, if it is going to be required to be presented during RE_INVITES > as well, especially if it represents some client state information >=20 > Leon >=20 > -----Original Message----- > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com]=20 > Sent: Wednesday, November 04, 2009 11:18 AM > To: Leon Portman; Alan Johnston; dispatch@ietf.org > Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for > SIP >=20 > I think UUI is carried during session setup and teardown, and hence > re-Invite scenario may not be applicable here. >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Wednesday, November 04, 2009 1:29 PM > To: Alan Johnston; dispatch@ietf.org > Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for > SIP >=20 > Only one comment, does it also supposed to support re-invite (for SRTP > re-keying or media updates) scenarios as well? >=20 > Thanks >=20 > Leon >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Alan Johnston > Sent: Tuesday, November 03, 2009 11:09 PM > To: dispatch@ietf.org > Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP >=20 > All, >=20 > Here is some updated charter text for CCUS. Comments are most welcome. >=20 > Thanks, > Alan >=20 > - - - - - >=20 > The Call Control UUI for SIP (CCUS) working group is chartered to=20 > define a SIP mechanism for transporting call control related=20 > user-to-user (UUI) information between User Agents. >=20 > The mechanism developed in this working group is generally appropriate > in the following situations: > 1. The information is generated and consumed by an application using SIP >=20 > during session setup but the application is not necessarily even SIP > aware. > 2. SIP behavior is unchanged. > 3. Generally only the UAC and UAS are interested in the information. > 4. The information is expected to survive retargeting, redirection, and=20 > retargeting. > 5. SIP elements may need to apply policy about passing and screening the >=20 > information. > 6. Multi-vendor interoperability is important. >=20 > This mechanism is not appropriate in the following situations: > 1. SIP behavior is changed. > 2. The information is generated and consumed at the SIP layer by SIP=20 > elements. > 3. SIP elements besides the UAC and UAS might be interested and consume=20 > the information. > 4. There are specific privacy or cross-RAI issues involved with the=20 > information being transported. >=20 > User data of the mechanism will be clearly marked with the application,=20 > encoding, semantics, and contents of the data, allowing policy to be=20 > applied by UAs. The working group will define the information which=20 > each application must specify in a standards-track document to utilize > the mechanism. >=20 > One important application of this mechanism is interworking with the=20 > ISDN User to User Information Service. This application defined by=20 > ITU-T Q.931, is extensively deployed in the PSTN today, supporting such=20 > applications as contact centers, call centers, and automatic call=20 > distributors (ACDs). A major barrier to the movement of these=20 > applications to SIP is the lack of a standard mechanism to transport=20 > this information in SIP. For interworking with ISDN, minimal=20 > information about the content of the UUI is available. In this case=20 > only, the content will just indicate ISDN UUI Service 1 interworking=20 > rather than the actual content. >=20 > Call control UUI is user information conveyed between user agents during >=20 > call control operations. As a result, the information must be conveyed=20 > with the INVITE transaction, and must survive proxy retargeting,=20 > redirection, and transfers. The mechanism must utilize a minimum of SIP >=20 > extensions as it will need to be supported by many simple SIP user=20 > agents such as PSTN gateways. The mechanism must interwork with the=20 > existing ISDN service but should also be extensible for use by other=20 > applications and non-ISDN protocols. >=20 > While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI >=20 > can be generated by a number of protocols that are not ISUP, and as such >=20 > it is architecturally unreasonable to interwork these protocols at the > SIP / ISUP gateway. That is, existing SIP-T approaches defined in=20 > RFC3372 do not meet the requirements. >=20 > Mechanisms based on the SIP INFO method, RFC2976, will not be considered >=20 > by the working group since the UUI contents carry information that must=20 > be conveyed during session setup at the user agent - the information=20 > must be conveyed with the INVITE transaction. The information must be > passed with the session setup request (INVITE), responses to that=20 > INVITE, or session termination requests. As a result, it is not=20 > possible to use INFO in these cases. >=20 > The group will produce: >=20 > - A problem statement and requirements document for implementing a SIP > call control UUI mechanism >=20 > - A specification of the SIP extension to best meet those requirements. >=20 > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Mar 10 - Problem statement and requirements document to IESG=20 > (Informational) > Aug 10 - SIP call control UUI specification to IESG (PS) >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From pkyzivat@cisco.com Wed Nov 4 16:10:36 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB90528C0DF for ; Wed, 4 Nov 2009 16:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 U7sY9D8D2WZl for ; Wed, 4 Nov 2009 16:10:35 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 25E7A3A682B for ; Wed, 4 Nov 2009 16:10:35 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAHAFun8UpAZnwM/2dsb2JhbAAHxi6XcIQ9BA X-IronPort-AV: E=Sophos;i="4.44,682,1249257600"; d="scan'208";a="66434688" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 Nov 2009 00:10:56 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA50AuEV014049; Thu, 5 Nov 2009 00:10:56 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 19:10:56 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 19:10:56 -0500 Message-ID: <4AF2180E.2070906@cisco.com> Date: Wed, 04 Nov 2009 19:10:54 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Leon Portman References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> <4AF18822.4070603@cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5B7D@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37D6AF5B7D@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2009 00:10:56.0087 (UTC) FILETIME=[71F12E70:01CA5DAC] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 00:10:36 -0000 Leon Portman wrote: > I will try to explain my case. > > The use case for example is a customer is calling to an organization via SIP trunk with some UUI info from the hosted IVR session (business data). He is connected to an agent and then was put on hold, triggering REINVITE with updated SDP. And then transferred to another agent. Under assumption that UUI represents some kind business data state of the call (IVR selection, customer ID etc), this information has to be preserved during all session changes. It is not transient state that is delivered via INFO. > Or even more complex, the call is transferred via SIP trunk to completely another PBX as another SIP session (B2BUA scenario). So you are making the case that this is *state* that must remain synchronized over time, not just transient information for call establishment. But that supports my argument that this is generalized application-application tunneling over sip. As such it overlaps greatly with the charter for INFO. We then end up with two mechanisms, one using headers and the other using bodies. - INFO can build on the rich structure of MIME definitions but it can't be used until at least an early dialog is established - The proposed UUI mechanism has to be embedded in headers, and has a much more limited representation mechanism built up. (But could you embed arbitrarily complex MIME bodies into a UUI header value?) It can be used earlier, and in contexts where INFO can't. As best I can tell, in practice, the UUI stuff will only be used where the data formats are already established for use in legacy PSTN equipment. As that stuff gets cut over to SIP infrastructure we will be left with applications having to use encodings that are no longer at all natural. (E.g. need to find something that can encode/decode ASN.1 stuff in an application that uses it for nothing else.) And this is all in spite of long resistance to using SIP for tunneling in general. Just grumbling, Paul > Thanks > > Leon > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, November 04, 2009 3:57 PM > To: Leon Portman > Cc: Sanjay Sinha (sanjsinh); Alan Johnston; dispatch@ietf.org > Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP > > > > Leon Portman wrote: >> Actually I was thinking that if UUI was presented during the original INVITE, if it is going to be required to be presented during RE_INVITES as well, especially if it represents some client state information > > Can you explain more about this? > > The charter seems to spend its time explaining that this is governed by > the needs for session setup. If this is a mechanism that is also > intended for use after the session is established, then I think more > explanation is required. > > As described, this is just plain tunneling, pure and simple. > And INFO (expecially with the new Info-Package work) is yet another > mechanism for tunneling. The rationale for not using INFO for UUI is > that it is needed during session establishment. Clearly that doesn't > apply after the session is established. > > Of course its a mess to have two mechanisms with overlapping purposes. > It would be silly to use two mechanisms to transport the same > information, depending on when in the lifetime of the session the info > was being transported. But I'm having difficulty drawing a clear > distinction between the applicability of the two mechanisms. > > Thanks, > Paul > >> Leon >> >> -----Original Message----- >> From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] >> Sent: Wednesday, November 04, 2009 11:18 AM >> To: Leon Portman; Alan Johnston; dispatch@ietf.org >> Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP >> >> I think UUI is carried during session setup and teardown, and hence >> re-Invite scenario may not be applicable here. >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Leon Portman >> Sent: Wednesday, November 04, 2009 1:29 PM >> To: Alan Johnston; dispatch@ietf.org >> Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for >> SIP >> >> Only one comment, does it also supposed to support re-invite (for SRTP >> re-keying or media updates) scenarios as well? >> >> Thanks >> >> Leon >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Alan Johnston >> Sent: Tuesday, November 03, 2009 11:09 PM >> To: dispatch@ietf.org >> Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP >> >> All, >> >> Here is some updated charter text for CCUS. Comments are most welcome. >> >> Thanks, >> Alan >> >> - - - - - >> >> The Call Control UUI for SIP (CCUS) working group is chartered to >> define a SIP mechanism for transporting call control related >> user-to-user (UUI) information between User Agents. >> >> The mechanism developed in this working group is generally appropriate >> in the following situations: >> 1. The information is generated and consumed by an application using SIP >> >> during session setup but the application is not necessarily even SIP >> aware. >> 2. SIP behavior is unchanged. >> 3. Generally only the UAC and UAS are interested in the information. >> 4. The information is expected to survive retargeting, redirection, and >> retargeting. >> 5. SIP elements may need to apply policy about passing and screening the >> >> information. >> 6. Multi-vendor interoperability is important. >> >> This mechanism is not appropriate in the following situations: >> 1. SIP behavior is changed. >> 2. The information is generated and consumed at the SIP layer by SIP >> elements. >> 3. SIP elements besides the UAC and UAS might be interested and consume >> the information. >> 4. There are specific privacy or cross-RAI issues involved with the >> information being transported. >> >> User data of the mechanism will be clearly marked with the application, >> encoding, semantics, and contents of the data, allowing policy to be >> applied by UAs. The working group will define the information which >> each application must specify in a standards-track document to utilize >> the mechanism. >> >> One important application of this mechanism is interworking with the >> ISDN User to User Information Service. This application defined by >> ITU-T Q.931, is extensively deployed in the PSTN today, supporting such >> applications as contact centers, call centers, and automatic call >> distributors (ACDs). A major barrier to the movement of these >> applications to SIP is the lack of a standard mechanism to transport >> this information in SIP. For interworking with ISDN, minimal >> information about the content of the UUI is available. In this case >> only, the content will just indicate ISDN UUI Service 1 interworking >> rather than the actual content. >> >> Call control UUI is user information conveyed between user agents during >> >> call control operations. As a result, the information must be conveyed >> with the INVITE transaction, and must survive proxy retargeting, >> redirection, and transfers. The mechanism must utilize a minimum of SIP >> >> extensions as it will need to be supported by many simple SIP user >> agents such as PSTN gateways. The mechanism must interwork with the >> existing ISDN service but should also be extensible for use by other >> applications and non-ISDN protocols. >> >> While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI >> >> can be generated by a number of protocols that are not ISUP, and as such >> >> it is architecturally unreasonable to interwork these protocols at the >> SIP / ISUP gateway. That is, existing SIP-T approaches defined in >> RFC3372 do not meet the requirements. >> >> Mechanisms based on the SIP INFO method, RFC2976, will not be considered >> >> by the working group since the UUI contents carry information that must >> be conveyed during session setup at the user agent - the information >> must be conveyed with the INVITE transaction. The information must be >> passed with the session setup request (INVITE), responses to that >> INVITE, or session termination requests. As a result, it is not >> possible to use INFO in these cases. >> >> The group will produce: >> >> - A problem statement and requirements document for implementing a SIP >> call control UUI mechanism >> >> - A specification of the SIP extension to best meet those requirements. >> >> Goals and Milestones >> ==================== >> >> Mar 10 - Problem statement and requirements document to IESG >> (Informational) >> Aug 10 - SIP call control UUI specification to IESG (PS) >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From drage@alcatel-lucent.com Thu Nov 5 05:15:54 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDE0E3A682C for ; Thu, 5 Nov 2009 05:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.678 X-Spam-Level: X-Spam-Status: No, score=-3.678 tagged_above=-999 required=5 tests=[AWL=-1.428, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GESvC4M6T1mV for ; Thu, 5 Nov 2009 05:15:53 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 837CA3A685A for ; Thu, 5 Nov 2009 05:15:52 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nA5DGBAV031174 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Nov 2009 14:16:13 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 5 Nov 2009 14:16:11 +0100 From: "DRAGE, Keith (Keith)" To: Alan Johnston , "dispatch@ietf.org" Date: Thu, 5 Nov 2009 14:16:09 +0100 Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Thread-Index: AcpcyeljAbTkDu42TrqVPKBwhNY2FwBTmJeg Message-ID: References: <4AF09BF6.9010902@sipstation.com> In-Reply-To: <4AF09BF6.9010902@sipstation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 13:15:54 -0000 1) "4. The information is expected to survive retargeting, redirection, and= retargeting."=20 "retargeting" appears twice. 2) "For interworking with ISDN, minimal=20 information about the content of the UUI is available. In this case only, = the content will just indicate ISDN UUI Service 1 interworking rather than = the actual content." This could imply that the existing protocol discriminator, which does carry= information about the content, is lost. I hope that is not true. 3) I am somewhat concerned that the focus now appears to be on SIP UA to SI= P UA, rather than interworking with other signalling systems that also carr= y such information. Where we have a SIP UA talking to a SIP UA, For at leas= t some of the usages where a SIP UA is talking to a SIP UA, we may well alr= eady have SIP mechanisms in place to support this. In general, we should be= focussing on those existing usages transported in other protocols, and any= new pure SIP usage should go through the normal SIP extension consideratio= ns. With the focus as it currently appears, we could end up spending years = defining a fully proper solution, whereas I believe we need something quick= er and potentially less than perfect for the SIP UA to SIP UA scenarios. No= te that by SIP UA I am talking about a real SIP endpoint here, not the UA t= hat may form part of an interworking gateway. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston > Sent: Tuesday, November 03, 2009 9:09 PM > To: dispatch@ietf.org > Subject: [dispatch] Updated CCUS Charter Text - Call Control=20 > UUI for SIP >=20 > All, >=20 > Here is some updated charter text for CCUS. Comments are=20 > most welcome. >=20 > Thanks, > Alan >=20 > - - - - - >=20 > The Call Control UUI for SIP (CCUS) working group is=20 > chartered to define a SIP mechanism for transporting call=20 > control related user-to-user (UUI) information between User Agents. >=20 > The mechanism developed in this working group is generally=20 > appropriate in the following situations: > 1. The information is generated and consumed by an=20 > application using SIP during session setup but the=20 > application is not necessarily even SIP aware. > 2. SIP behavior is unchanged. > 3. Generally only the UAC and UAS are interested in the information. > 4. The information is expected to survive retargeting,=20 > redirection, and retargeting. > 5. SIP elements may need to apply policy about passing and=20 > screening the information. > 6. Multi-vendor interoperability is important. >=20 > This mechanism is not appropriate in the following situations: > 1. SIP behavior is changed. > 2. The information is generated and consumed at the SIP layer=20 > by SIP elements. > 3. SIP elements besides the UAC and UAS might be interested=20 > and consume the information. > 4. There are specific privacy or cross-RAI issues involved=20 > with the information being transported. >=20 > User data of the mechanism will be clearly marked with the=20 > application, encoding, semantics, and contents of the data,=20 > allowing policy to be applied by UAs. The working group will=20 > define the information which each application must specify in=20 > a standards-track document to utilize the mechanism. >=20 > One important application of this mechanism is interworking=20 > with the ISDN User to User Information Service. This=20 > application defined by ITU-T Q.931, is extensively deployed=20 > in the PSTN today, supporting such applications as contact=20 > centers, call centers, and automatic call distributors=20 > (ACDs). A major barrier to the movement of these=20 > applications to SIP is the lack of a standard mechanism to transport=20 > this information in SIP. For interworking with ISDN, minimal=20 > information about the content of the UUI is available. In=20 > this case only, the content will just indicate ISDN UUI=20 > Service 1 interworking rather than the actual content. >=20 > Call control UUI is user information conveyed between user=20 > agents during call control operations. As a result, the=20 > information must be conveyed with the INVITE transaction, and=20 > must survive proxy retargeting, redirection, and transfers. =20 > The mechanism must utilize a minimum of SIP extensions as it=20 > will need to be supported by many simple SIP user agents such=20 > as PSTN gateways. The mechanism must interwork with the=20 > existing ISDN service but should also be extensible for use=20 > by other applications and non-ISDN protocols. >=20 > While PSTN UUI is carried in ISUP (ISDN User Part), SIP call=20 > control UUI can be generated by a number of protocols that=20 > are not ISUP, and as such it is architecturally unreasonable=20 > to interwork these protocols at the SIP / ISUP gateway. That=20 > is, existing SIP-T approaches defined in > RFC3372 do not meet the requirements. >=20 > Mechanisms based on the SIP INFO method, RFC2976, will not be=20 > considered by the working group since the UUI contents carry=20 > information that must be conveyed during session setup at the=20 > user agent - the information must be conveyed with the INVITE=20 > transaction. The information must be passed with the session=20 > setup request (INVITE), responses to that INVITE, or session=20 > termination requests. As a result, it is not possible to use=20 > INFO in these cases. >=20 > The group will produce: >=20 > - A problem statement and requirements document for=20 > implementing a SIP call control UUI mechanism >=20 > - A specification of the SIP extension to best meet those=20 > requirements. >=20 > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Mar 10 - Problem statement and requirements document to IESG > (Informational) > Aug 10 - SIP call control UUI specification to IESG (PS) >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From drage@alcatel-lucent.com Thu Nov 5 05:17:18 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5420F3A685A for ; Thu, 5 Nov 2009 05:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuCE4IpCv3au for ; Thu, 5 Nov 2009 05:17:17 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id A3D523A682C for ; Thu, 5 Nov 2009 05:17:16 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nA5DHUg4031726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Nov 2009 14:17:31 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 5 Nov 2009 14:17:30 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "Sanjay Sinha (sanjsinh)" Date: Thu, 5 Nov 2009 14:17:29 +0100 Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Thread-Index: AcpdV07aomEqI2dGQdC8lzR+H5Rb8wAwt52Q Message-ID: References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C00A1@XMB-RCD-101.cisco.com> <4AF1892C.4060504@cisco.com> In-Reply-To: <4AF1892C.4060504@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: Leon Portman , "dispatch@ietf.org" Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 13:17:18 -0000 I would argue that the 3pcc case is covered by the statement that the infor= mation must survive transfer. Talking more generally about the 3pcc case in the charter means that we cou= ld end up discussing scenarios of information transfer during the call.=20 regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, November 04, 2009 2:01 PM > To: Sanjay Sinha (sanjsinh) > Cc: Leon Portman; dispatch@ietf.org > Subject: Re: [dispatch] Updated CCUS Charter Text - Call=20 > Control UUI for SIP >=20 > I always use 3pcc as a test case, because it presents=20 > problems almost every time. >=20 > Of course the problem with 3pcc is that one "side" may remain=20 > the same, while the other "side" is replaced. The replacement=20 > typically has no knowledge of the history of what went on=20 > before it joined. So there usually needs to be some mechanism=20 > for it to be clued in about that. >=20 > I don't know if the same is true here or not. It depends on=20 > whether the UUI information is viewed as transient, or as=20 > state of the session. >=20 > Thanks, > Paul >=20 > Sanjay Sinha (sanjsinh) wrote: > > Do you mean same IE that was present in initial INVITE needs to be=20 > > presented in Re-Invite as well? > >=20 > > If the information does not change, then I do not see any value in=20 > > carrying the same payload in re-Invite. But if there is a=20 > new IE, then=20 > > yeah it can be presented in re-Invite. > > I am not sure if there can be a new UU IE after the call is=20 > setup and=20 > > before call termination. > >=20 > > Sanjay > >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: Wednesday, November 04, 2009 3:02 PM > > To: Sanjay Sinha (sanjsinh); Alan Johnston; dispatch@ietf.org > > Subject: RE: [dispatch] Updated CCUS Charter Text - Call=20 > Control UUI=20 > > for SIP > >=20 > > Actually I was thinking that if UUI was presented during=20 > the original=20 > > INVITE, if it is going to be required to be presented during=20 > > RE_INVITES as well, especially if it represents some client state=20 > > information > >=20 > > Leon > >=20 > > -----Original Message----- > > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > Sent: Wednesday, November 04, 2009 11:18 AM > > To: Leon Portman; Alan Johnston; dispatch@ietf.org > > Subject: RE: [dispatch] Updated CCUS Charter Text - Call=20 > Control UUI=20 > > for SIP > >=20 > > I think UUI is carried during session setup and teardown, and hence=20 > > re-Invite scenario may not be applicable here. > >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On=20 > > Behalf Of Leon Portman > > Sent: Wednesday, November 04, 2009 1:29 PM > > To: Alan Johnston; dispatch@ietf.org > > Subject: Re: [dispatch] Updated CCUS Charter Text - Call=20 > Control UUI=20 > > for SIP > >=20 > > Only one comment, does it also supposed to support=20 > re-invite (for SRTP=20 > > re-keying or media updates) scenarios as well? > >=20 > > Thanks > >=20 > > Leon > >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On=20 > > Behalf Of Alan Johnston > > Sent: Tuesday, November 03, 2009 11:09 PM > > To: dispatch@ietf.org > > Subject: [dispatch] Updated CCUS Charter Text - Call=20 > Control UUI for=20 > > SIP > >=20 > > All, > >=20 > > Here is some updated charter text for CCUS. Comments are=20 > most welcome. > >=20 > > Thanks, > > Alan > >=20 > > - - - - - > >=20 > > The Call Control UUI for SIP (CCUS) working group is chartered to=20 > > define a SIP mechanism for transporting call control related=20 > > user-to-user (UUI) information between User Agents. > >=20 > > The mechanism developed in this working group is generally=20 > appropriate=20 > > in the following situations: > > 1. The information is generated and consumed by an=20 > application using=20 > > SIP > >=20 > > during session setup but the application is not necessarily=20 > even SIP=20 > > aware. > > 2. SIP behavior is unchanged. > > 3. Generally only the UAC and UAS are interested in the information. > > 4. The information is expected to survive retargeting, redirection,=20 > > and retargeting. > > 5. SIP elements may need to apply policy about passing and=20 > screening=20 > > the > >=20 > > information. > > 6. Multi-vendor interoperability is important. > >=20 > > This mechanism is not appropriate in the following situations: > > 1. SIP behavior is changed. > > 2. The information is generated and consumed at the SIP=20 > layer by SIP=20 > > elements. > > 3. SIP elements besides the UAC and UAS might be interested and=20 > > consume the information. > > 4. There are specific privacy or cross-RAI issues involved with the=20 > > information being transported. > >=20 > > User data of the mechanism will be clearly marked with the=20 > > application, encoding, semantics, and contents of the data,=20 > allowing=20 > > policy to be applied by UAs. The working group will define the=20 > > information which each application must specify in a=20 > standards-track=20 > > document to utilize the mechanism. > >=20 > > One important application of this mechanism is interworking=20 > with the=20 > > ISDN User to User Information Service. This application defined by=20 > > ITU-T Q.931, is extensively deployed in the PSTN today, supporting=20 > > such applications as contact centers, call centers, and=20 > automatic call=20 > > distributors (ACDs). A major barrier to the movement of these=20 > > applications to SIP is the lack of a standard mechanism to transport > > this information in SIP. For interworking with ISDN, minimal=20 > > information about the content of the UUI is available. In=20 > this case=20 > > only, the content will just indicate ISDN UUI Service 1=20 > interworking=20 > > rather than the actual content. > >=20 > > Call control UUI is user information conveyed between user agents=20 > > during > >=20 > > call control operations. As a result, the information must be=20 > > conveyed with the INVITE transaction, and must survive proxy=20 > > retargeting, redirection, and transfers. The mechanism=20 > must utilize a=20 > > minimum of SIP > >=20 > > extensions as it will need to be supported by many simple SIP user=20 > > agents such as PSTN gateways. The mechanism must interwork=20 > with the=20 > > existing ISDN service but should also be extensible for use=20 > by other=20 > > applications and non-ISDN protocols. > >=20 > > While PSTN UUI is carried in ISUP (ISDN User Part), SIP=20 > call control=20 > > UUI > >=20 > > can be generated by a number of protocols that are not ISUP, and as=20 > > such > >=20 > > it is architecturally unreasonable to interwork these=20 > protocols at the=20 > > SIP / ISUP gateway. That is, existing SIP-T approaches defined in > > RFC3372 do not meet the requirements. > >=20 > > Mechanisms based on the SIP INFO method, RFC2976, will not be=20 > > considered > >=20 > > by the working group since the UUI contents carry information that=20 > > must be conveyed during session setup at the user agent - the=20 > > information must be conveyed with the INVITE transaction. The=20 > > information must be passed with the session setup request (INVITE),=20 > > responses to that INVITE, or session termination requests. As a=20 > > result, it is not possible to use INFO in these cases. > >=20 > > The group will produce: > >=20 > > - A problem statement and requirements document for=20 > implementing a SIP=20 > > call control UUI mechanism > >=20 > > - A specification of the SIP extension to best meet those=20 > requirements. > >=20 > > Goals and Milestones > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > Mar 10 - Problem statement and requirements document to IESG > > (Informational) > > Aug 10 - SIP call control UUI specification to IESG (PS) > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From drage@alcatel-lucent.com Thu Nov 5 05:17:48 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B2F3A685A for ; Thu, 5 Nov 2009 05:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.624 X-Spam-Level: X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJpx2CVbZm-L for ; Thu, 5 Nov 2009 05:17:46 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 7D9B43A682C for ; Thu, 5 Nov 2009 05:17:46 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nA5DI0Zj032165 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Nov 2009 14:18:01 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 5 Nov 2009 14:18:00 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Leon Portman Date: Thu, 5 Nov 2009 14:17:58 +0100 Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Thread-Index: AcpdVq2bYTC4OHboQSOWk4QvJmrwKQAw6zPA Message-ID: References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> <4AF18822.4070603@cisco.com> In-Reply-To: <4AF18822.4070603@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 13:17:48 -0000 I concur with Paul here. Keith=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, November 04, 2009 1:57 PM > To: Leon Portman > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Updated CCUS Charter Text - Call=20 > Control UUI for SIP >=20 >=20 >=20 > Leon Portman wrote: > > Actually I was thinking that if UUI was presented during=20 > the original=20 > > INVITE, if it is going to be required to be presented during=20 > > RE_INVITES as well, especially if it represents some client state=20 > > information >=20 > Can you explain more about this? >=20 > The charter seems to spend its time explaining that this is=20 > governed by the needs for session setup. If this is a=20 > mechanism that is also intended for use after the session is=20 > established, then I think more explanation is required. >=20 > As described, this is just plain tunneling, pure and simple. > And INFO (expecially with the new Info-Package work) is yet=20 > another mechanism for tunneling. The rationale for not using=20 > INFO for UUI is that it is needed during session=20 > establishment. Clearly that doesn't apply after the session=20 > is established. >=20 > Of course its a mess to have two mechanisms with overlapping=20 > purposes.=20 > It would be silly to use two mechanisms to transport the same=20 > information, depending on when in the lifetime of the session=20 > the info was being transported. But I'm having difficulty=20 > drawing a clear distinction between the applicability of the=20 > two mechanisms. >=20 > Thanks, > Paul >=20 > > Leon > >=20 > > -----Original Message----- > > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > Sent: Wednesday, November 04, 2009 11:18 AM > > To: Leon Portman; Alan Johnston; dispatch@ietf.org > > Subject: RE: [dispatch] Updated CCUS Charter Text - Call=20 > Control UUI=20 > > for SIP > >=20 > > I think UUI is carried during session setup and teardown, and hence=20 > > re-Invite scenario may not be applicable here. > >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On=20 > > Behalf Of Leon Portman > > Sent: Wednesday, November 04, 2009 1:29 PM > > To: Alan Johnston; dispatch@ietf.org > > Subject: Re: [dispatch] Updated CCUS Charter Text - Call=20 > Control UUI=20 > > for SIP > >=20 > > Only one comment, does it also supposed to support=20 > re-invite (for SRTP=20 > > re-keying or media updates) scenarios as well? > >=20 > > Thanks > >=20 > > Leon > >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On=20 > > Behalf Of Alan Johnston > > Sent: Tuesday, November 03, 2009 11:09 PM > > To: dispatch@ietf.org > > Subject: [dispatch] Updated CCUS Charter Text - Call=20 > Control UUI for=20 > > SIP > >=20 > > All, > >=20 > > Here is some updated charter text for CCUS. Comments are=20 > most welcome. > >=20 > > Thanks, > > Alan > >=20 > > - - - - - > >=20 > > The Call Control UUI for SIP (CCUS) working group is chartered to=20 > > define a SIP mechanism for transporting call control related=20 > > user-to-user (UUI) information between User Agents. > >=20 > > The mechanism developed in this working group is generally=20 > appropriate=20 > > in the following situations: > > 1. The information is generated and consumed by an=20 > application using=20 > > SIP > >=20 > > during session setup but the application is not necessarily=20 > even SIP=20 > > aware. > > 2. SIP behavior is unchanged. > > 3. Generally only the UAC and UAS are interested in the information. > > 4. The information is expected to survive retargeting, redirection,=20 > > and retargeting. > > 5. SIP elements may need to apply policy about passing and=20 > screening=20 > > the > >=20 > > information. > > 6. Multi-vendor interoperability is important. > >=20 > > This mechanism is not appropriate in the following situations: > > 1. SIP behavior is changed. > > 2. The information is generated and consumed at the SIP=20 > layer by SIP=20 > > elements. > > 3. SIP elements besides the UAC and UAS might be interested and=20 > > consume the information. > > 4. There are specific privacy or cross-RAI issues involved with the=20 > > information being transported. > >=20 > > User data of the mechanism will be clearly marked with the=20 > > application, encoding, semantics, and contents of the data,=20 > allowing=20 > > policy to be applied by UAs. The working group will define the=20 > > information which each application must specify in a=20 > standards-track=20 > > document to utilize the mechanism. > >=20 > > One important application of this mechanism is interworking=20 > with the=20 > > ISDN User to User Information Service. This application defined by=20 > > ITU-T Q.931, is extensively deployed in the PSTN today, supporting=20 > > such applications as contact centers, call centers, and=20 > automatic call=20 > > distributors (ACDs). A major barrier to the movement of these=20 > > applications to SIP is the lack of a standard mechanism to transport > > this information in SIP. For interworking with ISDN, minimal=20 > > information about the content of the UUI is available. In=20 > this case=20 > > only, the content will just indicate ISDN UUI Service 1=20 > interworking=20 > > rather than the actual content. > >=20 > > Call control UUI is user information conveyed between user agents=20 > > during > >=20 > > call control operations. As a result, the information must be=20 > > conveyed with the INVITE transaction, and must survive proxy=20 > > retargeting, redirection, and transfers. The mechanism=20 > must utilize a=20 > > minimum of SIP > >=20 > > extensions as it will need to be supported by many simple SIP user=20 > > agents such as PSTN gateways. The mechanism must interwork=20 > with the=20 > > existing ISDN service but should also be extensible for use=20 > by other=20 > > applications and non-ISDN protocols. > >=20 > > While PSTN UUI is carried in ISUP (ISDN User Part), SIP=20 > call control=20 > > UUI > >=20 > > can be generated by a number of protocols that are not ISUP, and as=20 > > such > >=20 > > it is architecturally unreasonable to interwork these=20 > protocols at the=20 > > SIP / ISUP gateway. That is, existing SIP-T approaches defined in > > RFC3372 do not meet the requirements. > >=20 > > Mechanisms based on the SIP INFO method, RFC2976, will not be=20 > > considered > >=20 > > by the working group since the UUI contents carry information that=20 > > must be conveyed during session setup at the user agent - the=20 > > information must be conveyed with the INVITE transaction. The=20 > > information must be passed with the session setup request (INVITE),=20 > > responses to that INVITE, or session termination requests. As a=20 > > result, it is not possible to use INFO in these cases. > >=20 > > The group will produce: > >=20 > > - A problem statement and requirements document for=20 > implementing a SIP=20 > > call control UUI mechanism > >=20 > > - A specification of the SIP extension to best meet those=20 > requirements. > >=20 > > Goals and Milestones > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > Mar 10 - Problem statement and requirements document to IESG > > (Informational) > > Aug 10 - SIP call control UUI specification to IESG (PS) > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From drage@alcatel-lucent.com Thu Nov 5 05:20:16 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A86823A6824 for ; Thu, 5 Nov 2009 05:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.661 X-Spam-Level: X-Spam-Status: No, score=-3.661 tagged_above=-999 required=5 tests=[AWL=-1.412, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkZRC50nZ9z9 for ; Thu, 5 Nov 2009 05:20:15 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 7BD3F3A69BE for ; Thu, 5 Nov 2009 05:20:15 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nA5DKW7E032350 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Nov 2009 14:20:36 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 5 Nov 2009 14:20:36 +0100 From: "DRAGE, Keith (Keith)" To: Leon Portman , Alan Johnston , "dispatch@ietf.org" Date: Thu, 5 Nov 2009 14:20:35 +0100 Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP Thread-Index: Acpcyf9cQc7Gv/u7RAyfnE5VWPs2QQAWmnAQAD2ATZA= Message-ID: References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 13:20:16 -0000 Given that the prime purpose of SIP is to support a session description of = the media, which presumably you want to do the SRTP rekeying for, I would a= rgue that the CCU is not the appropriate mechanism to support this. I suspe= ct your SRTP rekeying scenario would also expect to be terminated by some i= nterworking gateways, whereas the CCU information is meant to pass through = such gateways. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Leon Portman > Sent: Wednesday, November 04, 2009 7:59 AM > To: Alan Johnston; dispatch@ietf.org > Subject: Re: [dispatch] Updated CCUS Charter Text - Call=20 > Control UUI for SIP >=20 > Only one comment, does it also supposed to support re-invite=20 > (for SRTP re-keying or media updates) scenarios as well? >=20 > Thanks >=20 > Leon >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston > Sent: Tuesday, November 03, 2009 11:09 PM > To: dispatch@ietf.org > Subject: [dispatch] Updated CCUS Charter Text - Call Control=20 > UUI for SIP >=20 > All, >=20 > Here is some updated charter text for CCUS. Comments are=20 > most welcome. >=20 > Thanks, > Alan >=20 > - - - - - >=20 > The Call Control UUI for SIP (CCUS) working group is=20 > chartered to define a SIP mechanism for transporting call=20 > control related user-to-user (UUI) information between User Agents. >=20 > The mechanism developed in this working group is generally=20 > appropriate in the following situations: > 1. The information is generated and consumed by an=20 > application using SIP during session setup but the=20 > application is not necessarily even SIP aware. > 2. SIP behavior is unchanged. > 3. Generally only the UAC and UAS are interested in the information. > 4. The information is expected to survive retargeting,=20 > redirection, and retargeting. > 5. SIP elements may need to apply policy about passing and=20 > screening the information. > 6. Multi-vendor interoperability is important. >=20 > This mechanism is not appropriate in the following situations: > 1. SIP behavior is changed. > 2. The information is generated and consumed at the SIP layer=20 > by SIP elements. > 3. SIP elements besides the UAC and UAS might be interested=20 > and consume the information. > 4. There are specific privacy or cross-RAI issues involved=20 > with the information being transported. >=20 > User data of the mechanism will be clearly marked with the=20 > application, encoding, semantics, and contents of the data,=20 > allowing policy to be applied by UAs. The working group will=20 > define the information which each application must specify in=20 > a standards-track document to utilize the mechanism. >=20 > One important application of this mechanism is interworking=20 > with the ISDN User to User Information Service. This=20 > application defined by ITU-T Q.931, is extensively deployed=20 > in the PSTN today, supporting such applications as contact=20 > centers, call centers, and automatic call distributors=20 > (ACDs). A major barrier to the movement of these=20 > applications to SIP is the lack of a standard mechanism to transport=20 > this information in SIP. For interworking with ISDN, minimal=20 > information about the content of the UUI is available. In=20 > this case only, the content will just indicate ISDN UUI=20 > Service 1 interworking rather than the actual content. >=20 > Call control UUI is user information conveyed between user=20 > agents during call control operations. As a result, the=20 > information must be conveyed with the INVITE transaction, and=20 > must survive proxy retargeting, redirection, and transfers. =20 > The mechanism must utilize a minimum of SIP extensions as it=20 > will need to be supported by many simple SIP user agents such=20 > as PSTN gateways. The mechanism must interwork with the=20 > existing ISDN service but should also be extensible for use=20 > by other applications and non-ISDN protocols. >=20 > While PSTN UUI is carried in ISUP (ISDN User Part), SIP call=20 > control UUI can be generated by a number of protocols that=20 > are not ISUP, and as such it is architecturally unreasonable=20 > to interwork these protocols at the SIP / ISUP gateway. That=20 > is, existing SIP-T approaches defined in > RFC3372 do not meet the requirements. >=20 > Mechanisms based on the SIP INFO method, RFC2976, will not be=20 > considered by the working group since the UUI contents carry=20 > information that must be conveyed during session setup at the=20 > user agent - the information must be conveyed with the INVITE=20 > transaction. The information must be passed with the session=20 > setup request (INVITE), responses to that INVITE, or session=20 > termination requests. As a result, it is not possible to use=20 > INFO in these cases. >=20 > The group will produce: >=20 > - A problem statement and requirements document for=20 > implementing a SIP call control UUI mechanism >=20 > - A specification of the SIP extension to best meet those=20 > requirements. >=20 > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Mar 10 - Problem statement and requirements document to IESG > (Informational) > Aug 10 - SIP call control UUI specification to IESG (PS) >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From salvatore.loreto@ericsson.com Thu Nov 5 07:04:59 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE583A67C0 for ; Thu, 5 Nov 2009 07:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNnMPSFxI6Uv for ; Thu, 5 Nov 2009 07:04:58 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 491283A699C for ; Thu, 5 Nov 2009 07:04:58 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-97-4af2e9aed281 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 14.54.24026.EA9E2FA4; Thu, 5 Nov 2009 16:05:18 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 16:05:18 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 16:05:17 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5F55424F7; Thu, 5 Nov 2009 17:05:17 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2A73221A2A; Thu, 5 Nov 2009 17:05:17 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D8E9621A21; Thu, 5 Nov 2009 17:05:16 +0200 (EET) Message-ID: <4AF2E9AC.3030906@ericsson.com> Date: Thu, 05 Nov 2009 17:05:16 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Dale Worley References: <4AD333ED.5050107@ericsson.com> <1255383186.21215.54.camel@khone.us.nortel.com> In-Reply-To: <1255383186.21215.54.camel@khone.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 05 Nov 2009 15:05:17.0494 (UTC) FILETIME=[62A21560:01CA5E29] X-Brightmail-Tracker: AAAAAA== Cc: IETF Dispatch Subject: Re: [dispatch] new draft: Updates to Referred-By header X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 15:04:59 -0000 Hi Dale, sorry to be late answering this. see my comments in line. cheer /Sal Dale Worley wrote: > On Mon, 2009-10-12 at 16:49 +0300, Salvatore Loreto wrote: > >> Abstract >> >> SIP Referred-By header field conveys the referrer identity of a >> request. This header field may be used when exploding a SIP MESSAGE >> or a SIP INVITE request to a pre-defined group URI and the >> P-Asserted-Identity header field or From header field in the exploded >> SIP requests needs to carry another value (e.g. the URI of a pre- >> defined group, or a conference focus URI). In those cases, the >> Referred-By header field in the resulting exploded requests is set to >> the P-Asserted-Identity or to the From header field value of the >> original SIP request received before exploding, so as to convey to >> the receiver the identity of the original inviting sender. >> > > What do you do if the original INVITE already has a Referred-By header? > [Sal] this seems to me a general problem of any exploder procedure. My guess is that you would replace it with the new value! > It seems to me that you want a new header to carry this information, as > it has distinct semantics from all existing headers. > [Sal] It is not what we want! > I am also curious why the From header of the exploded messages would > need to be different from the From header of the original message. > [Sal] Yes it is true that RFC5365 says that the exploder MUST include the same From header field value as the incoming request but RFC5365 does not take into consideration exploding when using a pre-defined group. There needs to be a way for the message recipients to know the name of the pre-defined group. For SIP INVITE the From header contains the URI for the conference (see RFC5366), so the original sender goes in the Referred-By. In order to keep things a similar as possible between SIP INVITE and SIP MESSAGE, it makes sense to put the original sender in the Referred-By when SIP MESSAGE From has to carry a pre-defined group instead of the original sender. > Dale > > > From lei.zhu@huawei.com Fri Nov 6 02:14:10 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1084128C189 for ; Fri, 6 Nov 2009 02:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.365 X-Spam-Level: * X-Spam-Status: No, score=1.365 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6iEeMKtts4d for ; Fri, 6 Nov 2009 02:14:09 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 2A77828C182 for ; Fri, 6 Nov 2009 02:14:09 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSO008ISN3XCG@szxga01-in.huawei.com> for dispatch@ietf.org; Fri, 06 Nov 2009 18:14:22 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSO00HRTN3XBE@szxga01-in.huawei.com> for dispatch@ietf.org; Fri, 06 Nov 2009 18:14:21 +0800 (CST) Received: from z41317 ([10.111.16.96]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSO008Q3N3XAL@szxml06-in.huawei.com> for dispatch@ietf.org; Fri, 06 Nov 2009 18:14:21 +0800 (CST) Date: Fri, 06 Nov 2009 18:14:17 +0800 From: Zhu Lei To: dispatch@ietf.org Message-id: <006c01ca5ec9$e69ae9f0$60106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_LC/Y9rTC7v9V8YBKwJHoBw)" Thread-index: AcpeyeY2nqniXHPqSu2Q9IuLVnBVdA== Cc: 'Zhu Lei' Subject: [dispatch] Individual draft for sigcomp X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 10:14:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_LC/Y9rTC7v9V8YBKwJHoBw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, I just updated an individual draft for signalling compression. This draft was submitted to ROHC WG of TSV area, and does not receive opposite comments. http://tools.ietf.org/html/draft-lei-rohc-sigcomp-static-dictionary-01 I think this draft would finally used to compress sip and sdp strings, and needed. Would you like to review this draft? In addition, we may discuss it during IETF 76 event. Best regards, Lei Zhu --Boundary_(ID_LC/Y9rTC7v9V8YBKwJHoBw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi all,
 
I just updated an individual draft for signalling compression. This draft was submitted to ROHC WG of TSV area, and does not receive opposite comments.
 
 
I think this draft would finally used to compress sip and sdp strings, and needed.
 
Would you like to review this draft? In addition, we may discuss it during IETF 76 event.
 
Best regards,
Lei Zhu
--Boundary_(ID_LC/Y9rTC7v9V8YBKwJHoBw)-- From adam@nostrum.com Fri Nov 6 06:15:23 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785923A6AA1 for ; Fri, 6 Nov 2009 06:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.608 X-Spam-Level: X-Spam-Status: No, score=-1.608 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 kuxJ1mUcVHG1 for ; Fri, 6 Nov 2009 06:15:22 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 40FCF3A69FD for ; Fri, 6 Nov 2009 06:15:22 -0800 (PST) Received: from host-144-65.meeting.ietf.org (host-144-65.meeting.ietf.org [133.93.144.65]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nA6EFev6091062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Nov 2009 08:15:43 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4AF36AA9.20409@nostrum.com> Date: Fri, 06 Nov 2009 09:15:37 +0900 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: dispatch@ietf.org References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 133.93.144.65 is authenticated by a trusted mechanism) Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:15:23 -0000 On 10/28/09 6:22 PM, L.Liess@telekom.de wrote: > I will take this as an open issue for the dispatch meeting slides. I > hope Adam will be there because it was his proposal to use combinations > of discrete items rather than hierarchy. Sorry for not following this more closely. At this point, I think we have two different things to tease apart: (1) The semantics for combining different dimensions of ringback, and (2) the syntax for combining these dimensions. We really need to understand the first one before we start quibbling over the second one. So, while I do have some thoughts about the syntax, I'm not going to go into them -- even a little bit -- until we have a better grip on the semantic problem. Here's an important point that Paul raises: > It seems that what you propose is a multidimensional space, where > every point in that space is potentially rendered uniquely. But in > practice values will often be supplied for some but not all of the > dimensions. In that case we end up specifying some "slice" of the > array. I guess in this case you could look to see what you would > render for each point in the slice. If those are all identical, then > you are in good shape. But if they are not, then what? Do you pick one > of the points? That amounts to choosing a default value for each > unspecified dimension. Is that the right answer? I agree. We're effectively defining an n-dimensional space, and assuming that a point can be selected with fewer than n ordinals. And, yes, I think the correct answer is simply defining a default value for every new dimension defined -- preferably within the specification of the dimension itself (although some things, like country indication, would probably be better handled as local policy). Then, you can specify a value for as few as zero of the dimensions, and still have the answer be a point. The other side of that coin is that clients receiving this information will not necessarily understand (or care to support) all of the dimensions being presented. I believe that this is handled on the recipient's part by ignoring any dimensions it does not understand. However, I think that Paul's characterization of the difference between the previous approach and the current approach isn't correct: > It seems like what you must be doing is replacing a hierarchy with an > N-dimensional matrix which is sparsely populated. That seems harder to > deal with. I don't agree that it is sparsely populated. Many of the points might result in the same answer, but that doesn't mean it's sparsely populated. I think you could take the current draft and (modulo the issues with 7.3.3) pick any value from each of the three dimensions at random, and have a semantically sensible ringtone. Here; I'll roll the dice a couple of times: Internal short Brazilian ringback. External priority Pakistani ringback. You can play along at home -- find me an empty space in the matrix, and I'll concede the point. So, quite to the contrary, I think the two approaches are *semantically* identical, and the only difference between what was proposed before and what is proposed now is a *superficial* and *syntactic* difference. If you need proof, I'll write a quick perl script that converts between the two syntactic representations. :) /a From adam@nostrum.com Fri Nov 6 06:15:38 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF713A6825 for ; Fri, 6 Nov 2009 06:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7SJQ8mlEB-q for ; Fri, 6 Nov 2009 06:15:34 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id DD1293A6A87 for ; Fri, 6 Nov 2009 06:15:33 -0800 (PST) Received: from host-144-65.meeting.ietf.org (host-144-65.meeting.ietf.org [133.93.144.65]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nA6EFo5d091089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 08:15:53 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4AF36E29.8050108@nostrum.com> Date: Fri, 06 Nov 2009 09:30:33 +0900 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: L.Liess@telekom.de References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> Content-Type: multipart/alternative; boundary="------------080900010509080401030309" Received-SPF: pass (nostrum.com: 133.93.144.65 is authenticated by a trusted mechanism) Cc: anwars@avaya.com, dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:15:38 -0000 This is a multi-part message in MIME format. --------------080900010509080401030309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/19/09 9:38 PM, L.Liess@telekom.de wrote: > - Alert-Info URNs Indications for country-specific tones > While I think this is a good dimension to have, I question the wisdom of replicating the entire ISO 3166-1 registry in an RFC and into IANA, for a variety of reasons: 1. The initial registered list -- the one in the RFC -- will rapidly become out of date. 2. The IANA registry will require constant updating to match the changes in ISO 3166-1. This either requires the IANA to keep up with changes in that registry (which is a task well beyond what we require of them at the moment) or it requires someone to send notes to IANA to update the registry whenever a change is made. We don't really have the structure necessary to ensure that someone will do that. 3. If IANA and ISO 3166-1 do become out of sync -- which would almost necessarily happen from time to time -- you'll end up with implementations selecting at random between them (which is not a recipe for interoperability). 4. The selection of country codes is highly political and rife with land mines -- some are forseeable (e.g. tw, fk), while others aren't necessarily. You can try to side-step this -- like ICANN tries -- by claiming that we don't take codes outside of ISO 3166-1, and that we must accept all codes in ISO 3166-1; however, that hasn't kept them out of occasional hot water. I would strongly suggest simply citing ISO 3166-1, not putting any values in the IANA registry, and simply giving a couple of representative (and politically uncontroversial) examples. /a --------------080900010509080401030309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/19/09 9:38 PM, L.Liess@telekom.de wrote: 
   - Alert-Info URNs Indications for country-specific tones

While I think this is a good dimension to have, I question the wisdom of replicating the entire ISO 3166-1 registry in an RFC and into IANA, for a variety of reasons:

  1. The initial registered list -- the one in the RFC -- will rapidly become out of date.

  2. The IANA registry will require constant updating to match the changes in ISO 3166-1. This either requires the IANA to keep up with changes in that registry (which is a task well beyond what we require of them at the moment) or it requires someone to send notes to IANA to update the registry whenever a change is made. We don't really have the structure necessary to ensure that someone will do that.

  3. If IANA and ISO 3166-1 do become out of sync -- which would almost necessarily happen from time to time -- you'll end up with implementations selecting at random between them (which is not a recipe for interoperability).

  4. The selection of country codes is highly political and rife with land mines -- some are forseeable (e.g. tw, fk), while others aren't necessarily. You can try to side-step this -- like ICANN tries -- by claiming that we don't take codes outside of ISO 3166-1, and that we must accept all codes in ISO 3166-1; however, that hasn't kept them out of occasional hot water.

I would strongly suggest simply citing ISO 3166-1, not putting any values in the IANA registry, and simply giving a couple of representative (and politically uncontroversial) examples.

/a
--------------080900010509080401030309-- From adam@nostrum.com Fri Nov 6 06:40:21 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802FD3A69BE for ; Fri, 6 Nov 2009 06:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.608 X-Spam-Level: X-Spam-Status: No, score=-1.608 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 wFWZ+TJmj-Kl for ; Fri, 6 Nov 2009 06:40:20 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 10B773A67A7 for ; Fri, 6 Nov 2009 06:40:19 -0800 (PST) Received: from host-144-65.meeting.ietf.org (host-144-65.meeting.ietf.org [133.93.144.65]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nA6EFuqS091097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 08:15:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4AF37113.8030908@nostrum.com> Date: Fri, 06 Nov 2009 09:42:59 +0900 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: R.Jesske@telekom.de References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 133.93.144.65 is authenticated by a trusted mechanism) Cc: audet@nortel.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:40:21 -0000 On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: > Hi Christer and Francois, > I have added a sentence under section Overall Applicability: > > > The appearance of the Reason header is applicable to final responses 4xx, 5xx and 6xx and in addition for 199 Responses. > > Is this proper enough? Or do you have more in mind? > Given that RFC 3398 specifies the generation of a 301 in response to a cause code of 22 under certain circumstances, it seems pretty appropriate to allow the inclusion of a Q.850 cause code in 300-class responses also. Or, at least, as appropriate as it would be to include them in 4xx, 5xx, and 6xx responses. /a From pkyzivat@cisco.com Fri Nov 6 06:59:48 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E903A68EF for ; Fri, 6 Nov 2009 06:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 gU8aFOVnG0UF for ; Fri, 6 Nov 2009 06:59:47 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 523933A68F2 for ; Fri, 6 Nov 2009 06:59:39 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAILI80qrR7Ht/2dsb2JhbADFZJd9hD0E X-IronPort-AV: E=Sophos;i="4.44,694,1249257600"; d="scan'208";a="221936089" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2009 15:00:03 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA6F00M1003404; Fri, 6 Nov 2009 15:00:02 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 10:00:02 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 10:00:01 -0500 Message-ID: <4AF439F2.1050305@cisco.com> Date: Fri, 06 Nov 2009 10:00:02 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4AF36E29.8050108@nostrum.com> In-Reply-To: <4AF36E29.8050108@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2009 15:00:01.0791 (UTC) FILETIME=[D0DF60F0:01CA5EF1] Cc: anwars@avaya.com, dispatch@ietf.org, R.Jesske@telekom.de, L.Liess@telekom.de Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:59:48 -0000 I agree. It would be even better is there were already an URN designating country code. Then it could simply be referenced. But there doesn't seem to be one right now. Perhaps this doc could define one, and cite ISO 3166-1 for the definition of the values it can contain. It could then be used anywhere one wants to reference a country by URN, not just in Alert-Info. Thanks, Paul Adam Roach wrote: > On 10/19/09 9:38 PM, L.Liess@telekom.de wrote: >> - Alert-Info URNs Indications for country-specific tones >> > > While I think this is a good dimension to have, I question the wisdom of > replicating the entire ISO 3166-1 registry in an RFC and into IANA, for > a variety of reasons: > > 1. The initial registered list -- the one in the RFC -- will rapidly > become out of date. > > 2. The IANA registry will require constant updating to match the > changes in ISO 3166-1. This either requires the IANA to keep up > with changes in that registry (which is a task well beyond what we > require of them at the moment) or it requires someone to send > notes to IANA to update the registry whenever a change is made. We > don't really have the structure necessary to ensure that someone > will do that. > > 3. If IANA and ISO 3166-1 do become out of sync -- which would almost > necessarily happen from time to time -- you'll end up with > implementations selecting at random between them (which is not a > recipe for interoperability). > > 4. The selection of country codes is highly political and rife with > land mines -- some are forseeable (e.g. tw, fk), while others > aren't necessarily. You can try to side-step this -- like ICANN > tries -- by claiming that we don't take codes outside of ISO > 3166-1, and that we must accept all codes in ISO 3166-1; however, > that hasn't kept them out of occasional hot water. > > > I would strongly suggest simply citing ISO 3166-1, not putting any > values in the IANA registry, and simply giving a couple of > representative (and politically uncontroversial) examples. > > /a > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From L.Liess@telekom.de Fri Nov 6 07:59:21 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FECA3A6359 for ; Fri, 6 Nov 2009 07:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 epT0Q4CJ4Zwy for ; Fri, 6 Nov 2009 07:59:20 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id F39AB3A68C5 for ; Fri, 6 Nov 2009 07:59:19 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 06 Nov 2009 16:59:34 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 16:59:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5EFA.21D94F5D" Date: Fri, 6 Nov 2009 16:59:28 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00397C872@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4AF36E29.8050108@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New version for the Alert-Info URNsdraft: draft-liess-dispatch-alert-info-urns-00.txt Thread-Index: Acpe66782QP3qwByRP+mu/xkzATangADlI1Q References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4AF36E29.8050108@nostrum.com> From: To: X-OriginalArrivalTime: 06 Nov 2009 15:59:33.0978 (UTC) FILETIME=[220FDBA0:01CA5EFA] Cc: anwars@avaya.com, dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] New version for the Alert-Info URNsdraft: draft-liess-dispatch-alert-info-urns-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 15:59:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5EFA.21D94F5D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's a good proposal. I fully agree.=20 =20 Laura ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach Sent: Friday, November 06, 2009 1:31 AM To: Liess, Laura Cc: anwars@avaya.com; dispatch@ietf.org; Jesske, Roland Subject: Re: [dispatch] New version for the Alert-Info URNsdraft: draft-liess-dispatch-alert-info-urns-00.txt =09 =09 On 10/19/09 9:38 PM, L.Liess@telekom.de wrote:=20 - Alert-Info URNs Indications for country-specific tones =20 While I think this is a good dimension to have, I question the wisdom of replicating the entire ISO 3166-1 registry in an RFC and into IANA, for a variety of reasons: =09 =09 1. The initial registered list -- the one in the RFC -- will rapidly become out of date. =09 =09 2. The IANA registry will require constant updating to match the changes in ISO 3166-1. This either requires the IANA to keep up with changes in that registry (which is a task well beyond what we require of them at the moment) or it requires someone to send notes to IANA to update the registry whenever a change is made. We don't really have the structure necessary to ensure that someone will do that. =09 =09 3. If IANA and ISO 3166-1 do become out of sync -- which would almost necessarily happen from time to time -- you'll end up with implementations selecting at random between them (which is not a recipe for interoperability). =09 =09 4. The selection of country codes is highly political and rife with land mines -- some are forseeable (e.g. tw, fk), while others aren't necessarily. You can try to side-step this -- like ICANN tries -- by claiming that we don't take codes outside of ISO 3166-1, and that we must accept all codes in ISO 3166-1; however, that hasn't kept them out of occasional hot water.=20 I would strongly suggest simply citing ISO 3166-1, not putting any values in the IANA registry, and simply giving a couple of representative (and politically uncontroversial) examples. =09 /a =09 ------_=_NextPart_001_01CA5EFA.21D94F5D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It's = a good=20 proposal. I fully=20 agree. 
 
Laura


From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam=20 Roach
Sent: Friday, November 06, 2009 1:31 AM
To: = Liess,=20 Laura
Cc: anwars@avaya.com; dispatch@ietf.org; Jesske,=20 Roland
Subject: Re: [dispatch] New version for the = Alert-Info=20 URNsdraft: = draft-liess-dispatch-alert-info-urns-00.txt

On 10/19/09 9:38 PM, L.Liess@telekom.de wrote:=20 
   - Alert-Info URNs Indications for =
country-specific tones

While I think this is a good dimension to have, = I=20 question the wisdom of replicating the entire ISO 3166-1 registry in = an RFC=20 and into IANA, for a variety of reasons:

  1. The initial registered list -- the one in the RFC -- will = rapidly become=20 out of date.

  2. The IANA registry will require constant updating to match the = changes in=20 ISO 3166-1. This either requires the IANA to keep up with changes in = that=20 registry (which is a task well beyond what we require of them at the = moment)=20 or it requires someone to send notes to IANA to update the registry = whenever=20 a change is made. We don't really have the structure necessary to = ensure=20 that someone will do that.

  3. If IANA and ISO 3166-1 do become out of sync -- which would = almost=20 necessarily happen from time to time -- you'll end up with = implementations=20 selecting at random between them (which is not a recipe for=20 interoperability).

  4. The selection of country codes is highly political and rife with = land=20 mines -- some are forseeable (e.g. tw, fk), while others aren't = necessarily.=20 You can try to side-step this -- like ICANN tries -- by claiming = that we=20 don't take codes outside of ISO 3166-1, and that we must accept all = codes in=20 ISO 3166-1; however, that hasn't kept them out of occasional hot = water.=20

I would strongly suggest simply citing ISO 3166-1, not = putting=20 any values in the IANA registry, and simply giving a couple of = representative=20 (and politically uncontroversial)=20 examples.

/a
------_=_NextPart_001_01CA5EFA.21D94F5D-- From spencer@wonderhamster.org Fri Nov 6 12:22:46 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C168428C0F2 for ; Fri, 6 Nov 2009 12:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXKW8XUXU7dB for ; Fri, 6 Nov 2009 12:22:45 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id C6BE43A6AA4 for ; Fri, 6 Nov 2009 12:22:45 -0800 (PST) Received: from S73602b ([58.247.8.178]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LczwO-1MOP4k2uFk-00iKXM; Fri, 06 Nov 2009 15:23:09 -0500 Message-ID: <97702E59BDCA483DAB425B98A2AD9756@china.huawei.com> From: "Spencer Dawkins" To: References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com><40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de> <4AF36AA9.20409@nostrum.com> Date: Sat, 7 Nov 2009 04:22:54 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+tOkqZ1yaYcx2eNiH6ommv8Vddsi9z28SrR0O zM6xbfVuaJ5OkHHjeYC+Kbqd1GqAVuOoaHP7nkniNYrkdL0acI wZdr3CH6uVi8Ex3+rmMQidErrKZmiR4SKNgLXMkXC0= Subject: Re: [dispatch] New version for the Alert-InfoURNs draft: draft-liess-dispatch-alert-info-urns-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 20:22:46 -0000 I agree with Adam's point here (matrix isn't sparse, but a lot of the n-dimensional points are really boring because they have the same value as other n-dimensional points). I was seeing this the way Paul was seeing it previously, so this was a helpful insight. Thanks, Spencer >> I will take this as an open issue for the dispatch meeting slides. I >> hope Adam will be there because it was his proposal to use combinations >> of discrete items rather than hierarchy. > > Sorry for not following this more closely. > > At this point, I think we have two different things to tease apart: (1) > The semantics for combining different dimensions of ringback, and (2) the > syntax for combining these dimensions. > > We really need to understand the first one before we start quibbling over > the second one. So, while I do have some thoughts about the syntax, I'm > not going to go into them -- even a little bit -- until we have a better > grip on the semantic problem. > > Here's an important point that Paul raises: >> It seems that what you propose is a multidimensional space, where every >> point in that space is potentially rendered uniquely. But in practice >> values will often be supplied for some but not all of the dimensions. In >> that case we end up specifying some "slice" of the array. I guess in this >> case you could look to see what you would render for each point in the >> slice. If those are all identical, then you are in good shape. But if >> they are not, then what? Do you pick one of the points? That amounts to >> choosing a default value for each unspecified dimension. Is that the >> right answer? > > I agree. We're effectively defining an n-dimensional space, and assuming > that a point can be selected with fewer than n ordinals. And, yes, I think > the correct answer is simply defining a default value for every new > dimension defined -- preferably within the specification of the dimension > itself (although some things, like country indication, would probably be > better handled as local policy). Then, you can specify a value for as few > as zero of the dimensions, and still have the answer be a point. > > The other side of that coin is that clients receiving this information > will not necessarily understand (or care to support) all of the dimensions > being presented. I believe that this is handled on the recipient's part by > ignoring any dimensions it does not understand. > > However, I think that Paul's characterization of the difference between > the previous approach and the current approach isn't correct: >> It seems like what you must be doing is replacing a hierarchy with an >> N-dimensional matrix which is sparsely populated. That seems harder to >> deal with. > > I don't agree that it is sparsely populated. Many of the points might > result in the same answer, but that doesn't mean it's sparsely populated. > I think you could take the current draft and (modulo the issues with > 7.3.3) pick any value from each of the three dimensions at random, and > have a semantically sensible ringtone. Here; I'll roll the dice a couple > of times: Internal short Brazilian ringback. External priority Pakistani > ringback. You can play along at home -- find me an empty space in the > matrix, and I'll concede the point. > > So, quite to the contrary, I think the two approaches are *semantically* > identical, and the only difference between what was proposed before and > what is proposed now is a *superficial* and *syntactic* difference. If you > need proof, I'll write a quick perl script that converts between the two > syntactic representations. :) > > /a From R.Jesske@telekom.de Sun Nov 8 00:16:47 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C133A6848 for ; Sun, 8 Nov 2009 00:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.650, 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 C8BO00bDbMkj for ; Sun, 8 Nov 2009 00:16:47 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 818FF3A6842 for ; Sun, 8 Nov 2009 00:16:45 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 08 Nov 2009 09:17:00 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 09:17:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Nov 2009 09:16:59 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <4AF37113.8030908@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: Acpe67CSvPspMu9GR9OKChe6E6YFlwBX69iA References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com> From: To: X-OriginalArrivalTime: 08 Nov 2009 08:17:00.0177 (UTC) FILETIME=[D8556810:01CA604B] Cc: audet@nortel.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 08:16:47 -0000 Hi Adam, Thank you for your mail. So I propose the following text then: The appearance of the Reason header is applicable to final responses 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as defined = within ietf-sipcore-199.txt. Also the Reason header is applicable to provisional responses18x which are generated by an interworking gateway from ISUP to SIP. Best Beagards Roland=20 -----Urspr=FCngliche Nachricht----- Von: Adam Roach [mailto:adam@nostrum.com]=20 Gesendet: Freitag, 6. November 2009 01:43 An: Jesske, Roland Cc: audet@nortel.com; christer.holmberg@ericsson.com; = gonzalo.camarillo@ericsson.com; dispatch@ietf.org Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: > Hi Christer and Francois, > I have added a sentence under section Overall Applicability: > > > The appearance of the Reason header is applicable to final responses = 4xx, 5xx and 6xx and in addition for 199 Responses. > > Is this proper enough? Or do you have more in mind? > =20 Given that RFC 3398 specifies the generation of a 301 in response to a=20 cause code of 22 under certain circumstances, it seems pretty=20 appropriate to allow the inclusion of a Q.850 cause code in 300-class=20 responses also. Or, at least, as appropriate as it would be to include=20 them in 4xx, 5xx, and 6xx responses. /a From mary.barnes@nortel.com Sun Nov 8 03:56:28 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FFFC3A69F6 for ; Sun, 8 Nov 2009 03:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 YaAM9+5-Ik8m for ; Sun, 8 Nov 2009 03:56:27 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B043528C0DF for ; Sun, 8 Nov 2009 03:56:27 -0800 (PST) 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 nA8Bum804865 for ; Sun, 8 Nov 2009 11:56:48 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_01CA606A.8C9170F8" Date: Sun, 8 Nov 2009 05:56:47 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder: Identity Adhoc - Monday, Nov 9th, 12:00-13:00, Acacia East room Thread-Index: Acpgaox+J5baf/H1RwCXAJHwwxLtIQ== From: "Mary Barnes" To: Subject: [dispatch] Reminder: Identity Adhoc - Monday, Nov 9th, 12:00-13:00, Acacia East room X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 11:56:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA606A.8C9170F8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Per the agenda, the first of 3 DISPATCH adhocs is scheduled for = tomorrow: http://www.ietf.org/proceedings/09nov/agenda/dispatch.html We shifted the start time to allow folks to grab some lunch before the = session.=20 The charts for the session entitled "Identity Adhoc" have been uploaded = to the meeting materials webpage for the DISPATCH WG: https://datatracker.ietf.org/meeting/76/materials.html Regards, Mary.=20 ------_=_NextPart_001_01CA606A.8C9170F8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reminder: Identity Adhoc - Monday, Nov 9th, 12:00-13:00, Acacia = East room

Hi all,

Per the agenda, the first of 3 DISPATCH adhocs is scheduled for = tomorrow:
http:= //www.ietf.org/proceedings/09nov/agenda/dispatch.html

We shifted the start time to allow folks to grab some lunch before the = session.

The charts for the session entitled "Identity Adhoc"  = have been uploaded to the meeting materials webpage for the DISPATCH = WG:
https://d= atatracker.ietf.org/meeting/76/materials.html

Regards,
Mary.

------_=_NextPart_001_01CA606A.8C9170F8-- From gonzalo.camarillo@ericsson.com Sun Nov 8 06:52:55 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1653A680A for ; Sun, 8 Nov 2009 06:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed522h9Yumtt for ; Sun, 8 Nov 2009 06:52:54 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 1340B3A677D for ; Sun, 8 Nov 2009 06:52:53 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-a5-4af6db5db60d Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id F1.28.31706.D5BD6FA4; Sun, 8 Nov 2009 15:53:18 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 15:53:17 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 15:53:17 +0100 Received: from [131.160.126.187] (rvi2-126-187.lmf.ericsson.se [131.160.126.187]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2207F24F7; Sun, 8 Nov 2009 16:53:15 +0200 (EET) Message-ID: <4AF6DB5A.10700@ericsson.com> Date: Sun, 08 Nov 2009 23:53:14 +0900 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2009 14:53:17.0293 (UTC) FILETIME=[349961D0:01CA6083] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org Subject: Re: [dispatch] Reminder: Identity Adhoc - Monday, Nov 9th, 12:00-13:00, Acacia East room X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 14:52:55 -0000 Hi, the hotel has announced a quick lunch service for IETF folks. That may be an option people want to consider. Cheers, Gonzalo Mary Barnes wrote: > Hi all, > > Per the agenda, the first of 3 DISPATCH adhocs is scheduled for tomorrow: > http://www.ietf.org/proceedings/09nov/agenda/dispatch.html > > We shifted the start time to allow folks to grab some lunch before the > session. > > The charts for the session entitled "Identity Adhoc" have been uploaded > to the meeting materials webpage for the DISPATCH WG: > https://datatracker.ietf.org/meeting/76/materials.html > > Regards, > Mary. > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Sun Nov 8 19:57:42 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590CD28B797 for ; Sun, 8 Nov 2009 19:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 rZTs1iz5XXXB for ; Sun, 8 Nov 2009 19:57:41 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5456A28B56A for ; Sun, 8 Nov 2009 19:57:41 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABYi90pAZnwN/2dsb2JhbADDTpY8hD4E X-IronPort-AV: E=Sophos;i="4.44,705,1249257600"; d="scan'208";a="66960471" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 09 Nov 2009 03:58:06 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA93w6CD008705; Mon, 9 Nov 2009 03:58:06 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 22:58:06 -0500 Received: from [10.86.252.50] ([10.86.252.50]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 22:58:06 -0500 Message-ID: <4AF7934B.7080902@cisco.com> Date: Sun, 08 Nov 2009 22:58:03 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: R.Jesske@telekom.de References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com> <9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Nov 2009 03:58:06.0245 (UTC) FILETIME=[D7CD3D50:01CA60F0] Cc: audet@nortel.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:57:42 -0000 R.Jesske@telekom.de wrote: > Hi Adam, > Thank you for your mail. So I propose the following text then: > > The appearance of the Reason header is applicable to final responses > 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as defined within > ietf-sipcore-199.txt. Also the Reason header is > applicable to provisional responses18x which are generated by an > interworking gateway from ISUP to SIP. I think this is ok *except* if you are going to allow one kind of UAS to use Reason in a 18x response, then it should be allowed for *any* UAS to do so. For instance, suppose the gateway is replaced by a B2BUA to another sip environment, and the request eventually arrives as a gateway. Then a 18x response with a Reason header may arrive at the B2BUA and need to be replicated on the other side. Thanks, Paul > Best Beagards > > Roland > > -----Ursprüngliche Nachricht----- > Von: Adam Roach [mailto:adam@nostrum.com] > Gesendet: Freitag, 6. November 2009 01:43 > An: Jesske, Roland > Cc: audet@nortel.com; christer.holmberg@ericsson.com; gonzalo.camarillo@ericsson.com; dispatch@ietf.org > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: >> Hi Christer and Francois, >> I have added a sentence under section Overall Applicability: >> >> >> The appearance of the Reason header is applicable to final responses 4xx, 5xx and 6xx and in addition for 199 Responses. >> >> Is this proper enough? Or do you have more in mind? >> > > Given that RFC 3398 specifies the generation of a 301 in response to a > cause code of 22 under certain circumstances, it seems pretty > appropriate to allow the inclusion of a Q.850 cause code in 300-class > responses also. Or, at least, as appropriate as it would be to include > them in 4xx, 5xx, and 6xx responses. > > /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dworley@nortel.com Sun Nov 8 21:11:42 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0BF28C0CF for ; Sun, 8 Nov 2009 21:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 siGUYNnHYcjk for ; Sun, 8 Nov 2009 21:11:40 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 988B728C0D6 for ; Sun, 8 Nov 2009 21:11:40 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nA95C1N15437 for ; Mon, 9 Nov 2009 05:12:01 GMT Received: from [47.141.31.138] ([47.141.31.138]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 00:12:00 -0500 From: "Dale Worley" To: DISPATCH In-Reply-To: <20091018165027.4C8643A68B9@core3.amsl.com> References: <20091018165027.4C8643A68B9@core3.amsl.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 09 Nov 2009 00:11:58 -0500 Message-Id: <1257743518.4458.11.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2009 05:12:00.0500 (UTC) FILETIME=[2AD2DB40:01CA60FB] Subject: Re: [dispatch] New Version Notification for draft-worley-instrument-identification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:11:42 -0000 I've written up an internet-draft describing how the sipXecs open-source PBX identifies which telephone makes each registration, which allows us to obtain information about specific telephones rather than about AORs. For example, "SUBSCRIBE sip:~~in~0000DEADBEEF@example.net" will get the complete dialog status for the telephone with MAC address 0000DEADBEEF, even if the AORs that appear on it appear on other telephones. The mechanism works well in practice, but it's a hack, since it involves inserting the phone's MAC address into the authorization user-name field. What we want to do is use the phone's "SIP instance" URI to identify itself, but there are a number of problems involved in doing that. It doesn't look like they are particularly difficult, but they would require consensus and getting the phone vendors to bring their devices into line. See section 5 of the draft, which I have copied into the bottom of this message. The announcement of the I-D follows, and then section 5, which I want comments on. Dale On Sun, 2009-10-18 at 09:50 -0700, IETF I-D Submission Tool wrote: > A new version of I-D, draft-worley-instrument-identification-00.txt has been successfuly submitted by Dale Worley and posted to the IETF repository. > > Filename: draft-worley-instrument-identification > Revision: 00 > Title: Identifying Individual Telephone Instruments in SIP > Creation_date: 2009-10-18 > WG ID: Independent Submission > Number_of_pages: 18 > > http://www.ietf.org/id/draft-worley-instrument-identification-00.txt > > Abstract: > When requesting and reporting dialog status in SIP, users often want > to know the status of a particular telephone instrument, rather than > the status of an Address of Record (AOR). The architecture of SIP > makes it difficult to obtain the status of a telephone instrument in > a way that is convenient for use in common situations, in particular, > in an organization's PBX. This document describes a method for > identifying which telephone instrument is making each registration > request that is convenient to deploy in PBXs. This information can > be used to obtain the status of individual telephone instruments. > > Unfortunately, although the method works well in practice, it > violates separation of concerns by carrying instrument identification > information in an authentication-related field. This draft includes > a preliminary discussion of better ways to identify instruments. 5. Future Improvements As well as this method works, it is a hack that violates separation of concerns because instrument identification information is carried in a field which is intended for authentication information. This requires all elements that need to authenticate the source of a request to understand the syntax of the authentication user name. This burden is smaller for centralized systems, but in decentralized systems, there may be a large number of elements that need to authenticate requests, requiring a broad distribution of information that in principle should be encapsulated in the "user name and password" database. The philosophically ideal way to identify instruments is via the SIP "instance id". The instance id is used to support the "SIP outbound" mechanism[outbound], the GRUU mechanism[gruu], and the SIP Forum's UA configuration system[ua-config]. There are two distinct ways to use the SIP instance id to support instrument identification: 1. The instance id is carried in the "+sip.instance" field parameter of each Contact in each REGISTER request. The proxy/registrar can extract the instance id and use it to label each registration database record. Once the registrations are labelled with instrument identifications, requests can be directed to special URIs that route to the registered contacts of a specific instrument. 2. Each instrument can register a single special contact which is intended to identify the instrument as a whole rather than any line appearance on the instrument. This contact can be recognized by containing the instance id as either a component of the contact URI or as a "+sip.instance" field parameter. With this method, the functions described in this document are be implemented by sending SIP requests to this special contact. E.g., the overall dialog status of the instrument would be obtained by a dialog subscription to the special contact. A number of problems need to be overcome before the instance id can be used to provide instrument identification: 1. While the authentication user name is a baseline part of SIP and is always configurable by a PBX's provisioning system, the SIP instance id is not part of baseline SIP, and user agents need to be upgraded to support the SIP instance id. In practice, only some makes of instrument support SIP instance ids. 2. Ideally, all line appearances on an instrument would use the same instance id. Whether this is required by the RFCs is not entirely clear (probably because there has never been any reason to debate doing so). In practice, some instruments do use different instance ids for each line appearance that they register. However, since the preferred format of instance ids is a URN derived from a UUID, which is in turn based on the MAC address of the instrument, it is straightforward to extract the instrument's MAC address from each instance id, and the extracted MAC addresses of the various line appearances will be the same. 3. The PBX's provisioning system needs to be able to map instance ids into its internal instrument identities, which likely requires having the user enter the instrument identifiers into the provisioning system. It would be inconvenient to use full instance id URNs for this reason: UUID-based URNs are quite long and tedious to type. However, using the base MAC addresses of the URNs as the instrument identifiers would be convenient, as they are short enough to be convenient to enter and most SIP phones are clearly labeled with their MAC address 4. The reverse problem can happen with software-based instruments: The provisioning system needs to output an instrument identifier which can be input into the instrument, as the network interface of the hardware platform is not "owned" by the instrument, and the instrument may not be the only one on the platform. In the method of this document, doing so is relatively simple, since the instrument's interface allows the authentication user name to be entered directly by the user. To utilize the instance id, the instrument needs to allow its instance id to be configured, or else it needs to output its instance id so that it can be entered into the provisioning system. From alan@sipstation.com Sun Nov 8 22:40:33 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A5B3A69B0 for ; Sun, 8 Nov 2009 22:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7f0THsGqD79 for ; Sun, 8 Nov 2009 22:40:32 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 790FF3A6906 for ; Sun, 8 Nov 2009 22:40:32 -0800 (PST) Received: from host-18-249.meeting.ietf.org ([133.93.18.249]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1N7Nvt-000Eqw-BF; Mon, 09 Nov 2009 06:40:58 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 133.93.18.249 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18bX2UuAo5yrsw+pNxsY6BR+nYBUoDQeFU= Message-ID: <4AF7B96F.1020905@sipstation.com> Date: Mon, 09 Nov 2009 00:40:47 -0600 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4AF09BF6.9010902@sipstation.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:40:33 -0000 Keith, Thank you for your careful read and comments on the charter text. See my comments below. Your last point below is very important and it would be great to get some opinions from others. Thanks, Alan DRAGE, Keith (Keith) wrote: > 1) "4. The information is expected to survive retargeting, redirection, and retargeting." > > "retargeting" appears twice. > Yes, and the information must survive if the retargeting happens twice, too ;-) > 2) "For interworking with ISDN, minimal > information about the content of the UUI is available. In this case only, the content will just indicate ISDN UUI Service 1 interworking rather than the actual content." > > This could imply that the existing protocol discriminator, which does carry information about the content, is lost. I hope that is not true. > No, we will not loose the protocol discriminator. I didn't think it provided that much information about the content, but whatever information it provides will be available. > 3) I am somewhat concerned that the focus now appears to be on SIP UA to SIP UA, rather than interworking with other signalling systems that also carry such information. Where we have a SIP UA talking to a SIP UA, For at least some of the usages where a SIP UA is talking to a SIP UA, we may well already have SIP mechanisms in place to support this. The previous charter text had an ISDN interworking focus, but the consensus in the DISPATCH meeting was that there was strong interest in UUI outside ISDN interworking. > In general, we should be focussing on those existing usages transported in other protocols, and any new pure SIP usage should go through the normal SIP extension considerations. With the focus as it currently appears, we could end up spending years defining a fully proper solution, whereas I believe we need something quicker and potentially less than perfect for the SIP UA to SIP UA scenarios. Note that by SIP UA I am talking about a real SIP endpoint here, not the UA that may form part of an interworking gateway. > This is an important scope issue for the charter. I understand your concern. I am hopeful that we will not end up with a complicated solution and that the mechanism will work for both ISDN and non-ISDN approaches. I think that enough people care strongly about the ISDN interworking case that if the mechanism discussions bog down, that the WG could recharter to deliver two mechanisms - one for ISDN interworking and another more general mechanism. However, I'd prefer not to start with that approach until we have proven that a single mechanism is too complex. Do others have an opinion on this? > regards > > Keith > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston >> Sent: Tuesday, November 03, 2009 9:09 PM >> To: dispatch@ietf.org >> Subject: [dispatch] Updated CCUS Charter Text - Call Control >> UUI for SIP >> >> All, >> >> Here is some updated charter text for CCUS. Comments are >> most welcome. >> >> Thanks, >> Alan >> >> - - - - - >> >> The Call Control UUI for SIP (CCUS) working group is >> chartered to define a SIP mechanism for transporting call >> control related user-to-user (UUI) information between User Agents. >> >> The mechanism developed in this working group is generally >> appropriate in the following situations: >> 1. The information is generated and consumed by an >> application using SIP during session setup but the >> application is not necessarily even SIP aware. >> 2. SIP behavior is unchanged. >> 3. Generally only the UAC and UAS are interested in the information. >> 4. The information is expected to survive retargeting, >> redirection, and retargeting. >> 5. SIP elements may need to apply policy about passing and >> screening the information. >> 6. Multi-vendor interoperability is important. >> >> This mechanism is not appropriate in the following situations: >> 1. SIP behavior is changed. >> 2. The information is generated and consumed at the SIP layer >> by SIP elements. >> 3. SIP elements besides the UAC and UAS might be interested >> and consume the information. >> 4. There are specific privacy or cross-RAI issues involved >> with the information being transported. >> >> User data of the mechanism will be clearly marked with the >> application, encoding, semantics, and contents of the data, >> allowing policy to be applied by UAs. The working group will >> define the information which each application must specify in >> a standards-track document to utilize the mechanism. >> >> One important application of this mechanism is interworking >> with the ISDN User to User Information Service. This >> application defined by ITU-T Q.931, is extensively deployed >> in the PSTN today, supporting such applications as contact >> centers, call centers, and automatic call distributors >> (ACDs). A major barrier to the movement of these >> applications to SIP is the lack of a standard mechanism to transport >> this information in SIP. For interworking with ISDN, minimal >> information about the content of the UUI is available. In >> this case only, the content will just indicate ISDN UUI >> Service 1 interworking rather than the actual content. >> >> Call control UUI is user information conveyed between user >> agents during call control operations. As a result, the >> information must be conveyed with the INVITE transaction, and >> must survive proxy retargeting, redirection, and transfers. >> The mechanism must utilize a minimum of SIP extensions as it >> will need to be supported by many simple SIP user agents such >> as PSTN gateways. The mechanism must interwork with the >> existing ISDN service but should also be extensible for use >> by other applications and non-ISDN protocols. >> >> While PSTN UUI is carried in ISUP (ISDN User Part), SIP call >> control UUI can be generated by a number of protocols that >> are not ISUP, and as such it is architecturally unreasonable >> to interwork these protocols at the SIP / ISUP gateway. That >> is, existing SIP-T approaches defined in >> RFC3372 do not meet the requirements. >> >> Mechanisms based on the SIP INFO method, RFC2976, will not be >> considered by the working group since the UUI contents carry >> information that must be conveyed during session setup at the >> user agent - the information must be conveyed with the INVITE >> transaction. The information must be passed with the session >> setup request (INVITE), responses to that INVITE, or session >> termination requests. As a result, it is not possible to use >> INFO in these cases. >> >> The group will produce: >> >> - A problem statement and requirements document for >> implementing a SIP call control UUI mechanism >> >> - A specification of the SIP extension to best meet those >> requirements. >> >> Goals and Milestones >> ==================== >> >> Mar 10 - Problem statement and requirements document to IESG >> (Informational) >> Aug 10 - SIP call control UUI specification to IESG (PS) >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> From jdrosen@jdrosen.net Sun Nov 8 23:43:12 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5043A6AF7 for ; Sun, 8 Nov 2009 23:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e60spIYkQIIi for ; Sun, 8 Nov 2009 23:43:11 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.114.155]) by core3.amsl.com (Postfix) with ESMTP id DDE7C3A6A1B for ; Sun, 8 Nov 2009 23:43:11 -0800 (PST) Received: from [194.182.142.5] (helo=[192.168.5.123]) by ecbiz71.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N7OuW-0001WV-Eo; Mon, 09 Nov 2009 02:43:36 -0500 Message-ID: <4AF7C825.2060008@jdrosen.net> Date: Mon, 09 Nov 2009 02:43:33 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Subject: [dispatch] Introducing ViPR: a new federation technology X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:43:12 -0000 Folks, As you are all well aware, SIP has been very successful in the marketplace as a tool for voice and video within a single domain. Its success for inter-domain federation has been more limited, and it has seen almost no deployment over the public Internet for any-to-any federation, even though this was the model originally envisaged for SIP, and a model I still believe in. This is something that needed to be fixed, and I have fixed it. Today, Cullen and I submitted documents describing a new technology called ViPR. ViPR is a new federation technique which will finally enable the any-to-any SIP federation that we have always wanted for SIP. It solves several hard problems that have prevented widespread federation. In particular, it solves the phone number routing problem, providing a non-centralized technique that securely maps phone numbers to domains. It also provides a built-in solution for the VoIP anti-spam problem - a new one that is specific to VoIP. As such, it enables worldwide, scalable, any-to-any federation over the public Internet, securely, for phone numbers, and in a way that supports incremental deployability. This technology is not just documents - it is working code, and was announced by Cisco today as part of their products shipping early next year. I'm extremely excited about ViPR, and I think others will be too. The documents are: http://www.ietf.org/id/draft-rosenberg-dispatch-vipr-overview-01.txt http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-vap-00.txt http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-pvp-00.txt http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-sip-antispam-00.txt http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-reload-usage-00.txt Thanks, Jonathan Rosenberg jdrosen@jdrosen.net From scott.lawrence@nortel.com Mon Nov 9 07:00:49 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8066228C165 for ; Mon, 9 Nov 2009 07:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 fLP6YvxDFL+1 for ; Mon, 9 Nov 2009 07:00:48 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B05D73A684A for ; Mon, 9 Nov 2009 07:00:44 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nA9F14c18108; Mon, 9 Nov 2009 15:01:05 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:00:42 -0500 From: "Scott Lawrence" To: "Vijay K. Gurbani" In-Reply-To: <4AB780B4.3000601@alcatel-lucent.com> References: <4AB780B4.3000601@alcatel-lucent.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 09 Nov 2009 10:00:41 -0500 Message-Id: <1257778841.32566.102.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2009 15:00:42.0833 (UTC) FILETIME=[68932410:01CA614D] Cc: "dispatch@ietf.org" , rai-ads Subject: Re: [dispatch] Charter proposal: Session Recording Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:00:49 -0000 On Mon, 2009-09-21 at 08:33 -0500, Vijay K. Gurbani wrote: > Hi: The following charter proposal is a continuation of the > work presented on the same topic (SIP Session Recording) > at the Stockholm IETF. > > Regards, > > The Session Recording Protocol (SRP) working group is chartered to > define a SIP-based protocol for controlling a session (media) recorder. > > Session recording is a critical requirement in many business > communications environments such as call centers and financial trading > floors. In some of these environments, all calls must be recorded for > regulatory and compliance reasons. In others, calls may be recorded for > quality control, business analytics, or consumer protection. Recording > is typically done by sending a copy of the media to the recording > devices. The working group will produce a specification for a protocol > that will manage delivery of media from an end-point that originates > media or that has access to it to a recording device. PBX and recording > vendors today implement proprietary, incompatible mechanisms to > facilitate recording. A standard protocol will reduce the complexity and > cost of providing such recording services. > > The Session Recording problem presents certain unique requirements that > are not addressed in the current SIP protocol specification. These > include requirements such as the need for a distinction between the > session that is being recorded versus the session that has been > established for recording. I'd like to register my support for this work. I think that the draft does a good job laying out the requirements, and that interoperable solutions to these problems would be of benefit to everyone. I would like to have architectures considered that don't rely on a middlebox of any kind for this, with dataflows like: +-------------+ SIP +-------------+ | |<------------------------------------------->| | | | | | | UA-B |<---------+ +------>| UA-C | | | | RTP RTP | | | +-------------+ | +--------------+ | +-------------+ | | | Recorder | | | Recording Control +--->| (RS) |<-----+ | Call Metadata events | | +------------------------->+--------------+ (SIP) I won't be able to participate even remotely during the DISPATCH session on this, but would like to point out that in many ways this fits the description of BLISS work items: it is fundamentally a calling feature dealing with switching call legs appropriately among participants. Whether to establish a dedicated working group or not is up to the ADs; whether they decide to send it to BLISS or to charter a new group, I look forward to participating. From pkyzivat@cisco.com Mon Nov 9 08:19:04 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137103A6AE5 for ; Mon, 9 Nov 2009 08:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 jasO27pJZPR0 for ; Mon, 9 Nov 2009 08:19:03 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 281B73A677D for ; Mon, 9 Nov 2009 08:19:03 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMPP90pAZnwN/2dsb2JhbADHUZZphD4E X-IronPort-AV: E=Sophos;i="4.44,709,1249257600"; d="scan'208";a="268279296" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2009 16:19:29 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA9GJTs1001064; Mon, 9 Nov 2009 16:19:29 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:19:28 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:19:28 -0500 Message-ID: <4AF84110.90003@cisco.com> Date: Mon, 09 Nov 2009 11:19:28 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alan Johnston References: <4AF09BF6.9010902@sipstation.com> <4AF7B96F.1020905@sipstation.com> In-Reply-To: <4AF7B96F.1020905@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2009 16:19:28.0694 (UTC) FILETIME=[69684D60:01CA6158] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:19:04 -0000 Comment at end Alan Johnston wrote: >> 3) I am somewhat concerned that the focus now appears to be on SIP >> UA to SIP UA, rather than interworking with other signalling systems >> that also carry such information. Where we have a SIP UA talking to a >> SIP UA, For at least some of the usages where a SIP UA is talking to a >> SIP UA, we may well already have SIP mechanisms in place to support this. > > The previous charter text had an ISDN interworking focus, but the > consensus in the DISPATCH meeting was that there was strong interest in > UUI outside ISDN interworking. > >> In general, we should be focussing on those existing usages >> transported in other protocols, and any new pure SIP usage should go >> through the normal SIP extension considerations. With the focus as it >> currently appears, we could end up spending years defining a fully >> proper solution, whereas I believe we need something quicker and >> potentially less than perfect for the SIP UA to SIP UA scenarios. Note >> that by SIP UA I am talking about a real SIP endpoint here, not the UA >> that may form part of an interworking gateway. >> > This is an important scope issue for the charter. > > I understand your concern. I am hopeful that we will not end up with a > complicated solution and that the mechanism will work for both ISDN and > non-ISDN approaches. > > I think that enough people care strongly about the ISDN interworking > case that if the mechanism discussions bog down, that the WG could > recharter to deliver two mechanisms - one for ISDN interworking and > another more general mechanism. However, I'd prefer not to start with > that approach until we have proven that a single mechanism is too complex. > > Do others have an opinion on this? My concern all along has been that if one focuses on ISDN interworking, then what happens when the user that used to have an ISDN device decides to upgrade to a new SIP device, and we then have e2e sip connectivity? The likely scenario is that *nothing* will change. The new device will be expected to emulate the behavior of the ISDN device including using the ISDN-style UUI mechanism, even though it is not "natural" in an all-sip environment. OTOH, if you start with a UUI mechanism that is "sip-friendly" but can also be translated to the ISDN mechanisms when necessary, then the migration is much smoother. And you might avoid having ISDN-isms lingering after ISDN itself is gone. The argument I hear against this is that the ISDN encoding itself is opaque - pure tunneling of bits. But the protocol discriminator is supposed to deal with that isn't it? The values that the discriminator can take on, and the encoding of the remainder for each discriminator value but be standardized somewhere. I think a "natural" encoding for sip would have to consider each discriminator value, and what an appropriate encoding would be for that case. Thanks, Paul From richard@shockey.us Mon Nov 9 09:05:29 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4578A3A68F6 for ; Mon, 9 Nov 2009 09:05:29 -0800 (PST) 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 LItJOpcViGvj for ; Mon, 9 Nov 2009 09:05:28 -0800 (PST) Received: from outbound-mail-12.bluehost.com (outbound-mail-12.bluehost.com [69.89.18.112]) by core3.amsl.com (Postfix) with SMTP id 70BE63A6816 for ; Mon, 9 Nov 2009 09:05:28 -0800 (PST) Received: (qmail 31923 invoked by uid 0); 9 Nov 2009 17:05:55 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy1.bluehost.com with SMTP; 9 Nov 2009 17:05:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=gKLkqlHIBZr4VC/UnRyZbjmFTuSXRTyM3eexmAam+KMQ+W3co8gCAJOq3u4KTDlUjQ4fFbNq9h+7UZs3WBZmhFJZpb936/BJndxRJS2HX3e4lzZ9C50YABTLCvS9ce26; Received: from 72-254-159-206.client.stsn.net ([72.254.159.206] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N7Xgg-0004yp-Ni; Mon, 09 Nov 2009 10:05:54 -0700 From: "Richard Shockey" To: "'Jonathan Rosenberg'" , References: <4AF7C825.2060008@jdrosen.net> In-Reply-To: <4AF7C825.2060008@jdrosen.net> Date: Mon, 9 Nov 2009 12:05:55 -0500 Message-ID: <004401ca615e$e77cdb20$b6769160$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphEFqMptU8GQ23QEC/H+eUu7VckgAThLiw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.254.159.206 authed with richard+shockey.us} Subject: Re: [dispatch] Introducing ViPR: a new federation technology X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:05:29 -0000 OK Asterisk DUNDi on steroids. Useful for enterprise to enterprise supply chain federations, since TRIP was never going to work there, but to a SIP service provider it provides no real value. Did I miss something? > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: Monday, November 09, 2009 2:44 AM > To: dispatch@ietf.org > Subject: [dispatch] Introducing ViPR: a new federation technology > > Folks, > > As you are all well aware, SIP has been very successful in the > marketplace as a tool for voice and video within a single domain. Its > success for inter-domain federation has been more limited, and it has > seen almost no deployment over the public Internet for any-to-any > federation, even though this was the model originally envisaged for > SIP, > and a model I still believe in. > > This is something that needed to be fixed, and I have fixed it. > > Today, Cullen and I submitted documents describing a new technology > called ViPR. ViPR is a new federation technique which will finally > enable the any-to-any SIP federation that we have always wanted for > SIP. > It solves several hard problems that have prevented widespread > federation. In particular, it solves the phone number routing problem, > providing a non-centralized technique that securely maps phone numbers > to domains. It also provides a built-in solution for the VoIP anti- > spam > problem - a new one that is specific to VoIP. As such, it enables > worldwide, scalable, any-to-any federation over the public Internet, > securely, for phone numbers, and in a way that supports incremental > deployability. > > This technology is not just documents - it is working code, and was > announced by Cisco today as part of their products shipping early next > year. > > I'm extremely excited about ViPR, and I think others will be too. > > The documents are: > > > http://www.ietf.org/id/draft-rosenberg-dispatch-vipr-overview-01.txt > http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-vap- > 00.txt > http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-pvp- > 00.txt > http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-sip- > antispam-00.txt > http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr- > reload-usage-00.txt > > > Thanks, > Jonathan Rosenberg > jdrosen@jdrosen.net > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From kpfleming@digium.com Mon Nov 9 14:04:50 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F0F3A69A4 for ; Mon, 9 Nov 2009 14:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.343 X-Spam-Level: X-Spam-Status: No, score=-105.343 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej2SpvKaz8a9 for ; Mon, 9 Nov 2009 14:04:49 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id B36393A6817 for ; Mon, 9 Nov 2009 14:04:49 -0800 (PST) Received: from jupiler.digium.internal ([10.19.29.150] helo=jupiler.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1N7cMN-00042G-Nm for dispatch@ietf.org; Mon, 09 Nov 2009 16:05:15 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by jupiler.digium.com (Postfix) with ESMTP id AC9BADFC829 for ; Mon, 9 Nov 2009 16:05:15 -0600 (CST) Received: from jupiler.digium.com ([127.0.0.1]) by localhost (jupiler.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NZGm8Hq2vYC for ; Mon, 9 Nov 2009 16:05:15 -0600 (CST) Received: from [133.93.144.178] (host-144-178.meeting.ietf.org [133.93.144.178]) (Authenticated sender: kpfleming) by jupiler.digium.com (Postfix) with ESMTP id E9B55DFC828 for ; Mon, 9 Nov 2009 16:05:14 -0600 (CST) Message-ID: <4AF89219.10300@digium.com> Date: Tue, 10 Nov 2009 07:05:13 +0900 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: dispatch@ietf.org References: <4AF7C825.2060008@jdrosen.net> <004401ca615e$e77cdb20$b6769160$@us> In-Reply-To: <004401ca615e$e77cdb20$b6769160$@us> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Introducing ViPR: a new federation technology X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 22:04:50 -0000 Richard Shockey wrote: > OK Asterisk DUNDi on steroids. Sort of, yeah :-) > Useful for enterprise to enterprise supply chain federations, since TRIP was > never going to work there, but to a SIP service provider it provides no real > value. > > Did I miss something? I came away with the same conclusion you did; it's really only applicable to closely-aligned parties that want to federate, not for any providers that may provide SIP connectivity in between the parties that want to federate. This would make it somewhat complex to deploy in a hosted PBX scenario, unless the ViPR server was also virtualized to provide a separate set of data for each hosted PBX that chose to use ViPR. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@digium.com Check us out at www.digium.com & www.asterisk.org From mary.barnes@nortel.com Mon Nov 9 14:21:18 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3243A68C1 for ; Mon, 9 Nov 2009 14:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 Ssj06sxeQQ7D for ; Mon, 9 Nov 2009 14:21:17 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 64F863A6893 for ; Mon, 9 Nov 2009 14:21:17 -0800 (PST) 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 nA9MLd428089 for ; Mon, 9 Nov 2009 22:21:39 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_01CA618A.F8EAF94D" Date: Mon, 9 Nov 2009 16:21:24 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Identity Adhoc - Nov 9th: Notes available Thread-Index: Acphivjjvb8r3mQzTsCSe25UTifW/Q== From: "Mary Barnes" To: Subject: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 22:21:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA618A.F8EAF94D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have uploaded Jim McEachern's notes from the Identity Adhoc yesterday: http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/Identity-AdHoc-N= otes-jmce.doc Regards, Mary.=20 ------_=_NextPart_001_01CA618A.F8EAF94D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Identity Adhoc - Nov 9th: Notes available

Hi all,

I have uploaded Jim McEachern's notes from the Identity Adhoc = yesterday:
http://www.softarmor.com/dispatch/IETF76/Meeting%2= 0notes/Identity-AdHoc-Notes-jmce.doc

Regards,
Mary.

------_=_NextPart_001_01CA618A.F8EAF94D-- From R.Jesske@telekom.de Mon Nov 9 15:57:24 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6034A3A67AD for ; Mon, 9 Nov 2009 15:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=0.433, 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 hVjE-u0BAPPU for ; Mon, 9 Nov 2009 15:57:23 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 100B53A677E for ; Mon, 9 Nov 2009 15:57:22 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 10 Nov 2009 00:57:45 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 00:57:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 00:57:43 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <4AF7934B.7080902@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: Acpg8Nmq5+afqaFTQH+9ByJdXB1RdQAp17eg References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com> <9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de> <4AF7934B.7080902@cisco.com> From: To: X-OriginalArrivalTime: 09 Nov 2009 23:57:45.0363 (UTC) FILETIME=[6EB30630:01CA6198] Cc: audet@nortel.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:57:24 -0000 Hello Paul, Thanks for that hint. I will change this too.=20 Like: The appearance of the Reason header is applicable to final responses 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as = defined within ietf-sipcore-199.txt. Also the Reason header is applicable to provisional responses18x. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Gesendet: Montag, 9. November 2009 12:58 An: Jesske, Roland Cc: adam@nostrum.com; audet@nortel.com; dispatch@ietf.org; = gonzalo.camarillo@ericsson.com Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 R.Jesske@telekom.de wrote: > Hi Adam, > Thank you for your mail. So I propose the following text then: >=20 > The appearance of the Reason header is applicable to final responses > 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as = defined within > ietf-sipcore-199.txt. Also the Reason header is > applicable to provisional responses18x which are generated by an > interworking gateway from ISUP to SIP. I think this is ok *except* if you are going to allow one kind of UAS to = use Reason in a 18x response, then it should be allowed for *any* UAS to = do so. For instance, suppose the gateway is replaced by a B2BUA to another sip=20 environment, and the request eventually arrives as a gateway. Then a 18x = response with a Reason header may arrive at the B2BUA and need to be=20 replicated on the other side. Thanks, Paul > Best Beagards >=20 > Roland=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Adam Roach [mailto:adam@nostrum.com]=20 > Gesendet: Freitag, 6. November 2009 01:43 > An: Jesske, Roland > Cc: audet@nortel.com; christer.holmberg@ericsson.com; = gonzalo.camarillo@ericsson.com; dispatch@ietf.org > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: >> Hi Christer and Francois, >> I have added a sentence under section Overall Applicability: >> >> >> The appearance of the Reason header is applicable to final responses = 4xx, 5xx and 6xx and in addition for 199 Responses. >> >> Is this proper enough? Or do you have more in mind? >> =20 >=20 > Given that RFC 3398 specifies the generation of a 301 in response to a = > cause code of 22 under certain circumstances, it seems pretty=20 > appropriate to allow the inclusion of a Q.850 cause code in 300-class=20 > responses also. Or, at least, as appropriate as it would be to include = > them in 4xx, 5xx, and 6xx responses. >=20 > /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From pkyzivat@cisco.com Mon Nov 9 16:05:59 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDDB3A6945 for ; Mon, 9 Nov 2009 16:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 iy7Mn7d45NQQ for ; Mon, 9 Nov 2009 16:05:59 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BC2C63A691A for ; Mon, 9 Nov 2009 16:05:58 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALQ9+EqtJV2d/2dsb2JhbADGMZdFhD4E X-IronPort-AV: E=Sophos;i="4.44,711,1249257600"; d="scan'208";a="67135877" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 10 Nov 2009 00:06:12 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id nAA06C62014581; Tue, 10 Nov 2009 00:06:12 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 19:06:12 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 19:06:11 -0500 Message-ID: <4AF8AE73.4050405@cisco.com> Date: Mon, 09 Nov 2009 19:06:11 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: R.Jesske@telekom.de References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com> <9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de> <4AF7934B.7080902@cisco.com> <9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 10 Nov 2009 00:06:11.0728 (UTC) FILETIME=[9C843100:01CA6199] Cc: audet@nortel.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:05:59 -0000 Roland, Thanks! That addresses my concern. Thanks, Paul R.Jesske@telekom.de wrote: > Hello Paul, > Thanks for that hint. I will change this too. > Like: > > The appearance of the Reason header is applicable to final responses > 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as defined within > ietf-sipcore-199.txt. Also the Reason header is > applicable to provisional responses18x. > > Best Regards > > Roland > > -----Ursprüngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Montag, 9. November 2009 12:58 > An: Jesske, Roland > Cc: adam@nostrum.com; audet@nortel.com; dispatch@ietf.org; gonzalo.camarillo@ericsson.com > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > > > R.Jesske@telekom.de wrote: >> Hi Adam, >> Thank you for your mail. So I propose the following text then: >> >> The appearance of the Reason header is applicable to final responses >> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as defined within >> ietf-sipcore-199.txt. Also the Reason header is >> applicable to provisional responses18x which are generated by an >> interworking gateway from ISUP to SIP. > > I think this is ok *except* if you are going to allow one kind of UAS to > use Reason in a 18x response, then it should be allowed for *any* UAS to > do so. > > For instance, suppose the gateway is replaced by a B2BUA to another sip > environment, and the request eventually arrives as a gateway. Then a 18x > response with a Reason header may arrive at the B2BUA and need to be > replicated on the other side. > > Thanks, > Paul > >> Best Beagards >> >> Roland >> >> -----Ursprüngliche Nachricht----- >> Von: Adam Roach [mailto:adam@nostrum.com] >> Gesendet: Freitag, 6. November 2009 01:43 >> An: Jesske, Roland >> Cc: audet@nortel.com; christer.holmberg@ericsson.com; gonzalo.camarillo@ericsson.com; dispatch@ietf.org >> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: >>> Hi Christer and Francois, >>> I have added a sentence under section Overall Applicability: >>> >>> >>> The appearance of the Reason header is applicable to final responses 4xx, 5xx and 6xx and in addition for 199 Responses. >>> >>> Is this proper enough? Or do you have more in mind? >>> >> Given that RFC 3398 specifies the generation of a 301 in response to a >> cause code of 22 under certain circumstances, it seems pretty >> appropriate to allow the inclusion of a Q.850 cause code in 300-class >> responses also. Or, at least, as appropriate as it would be to include >> them in 4xx, 5xx, and 6xx responses. >> >> /a >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From christer.holmberg@ericsson.com Mon Nov 9 16:11:34 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34DA03A6972 for ; Mon, 9 Nov 2009 16:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uo-q2jXyKE4H for ; Mon, 9 Nov 2009 16:11:32 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 398543A677E for ; Mon, 9 Nov 2009 16:11:32 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-e6-4af8afcda2ca Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 81.61.31706.DCFA8FA4; Tue, 10 Nov 2009 01:11:57 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 01:11:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 01:11:56 +0100 Message-ID: In-Reply-To: <4AF8AE73.4050405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 thread-index: Acphmai1yr71k3mYSOWqng/P+/xffwAAF7NA References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> <4AF 8AE73.40 50405@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , X-OriginalArrivalTime: 10 Nov 2009 00:11:57.0236 (UTC) FILETIME=[6A748740:01CA619A] X-Brightmail-Tracker: AAAAAA== Cc: audet@nortel.com, dispatch@ietf.org, Gonzalo Camarillo Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:11:34 -0000 Hi, A small editorial change proposal: "The appearance of the Reason header is applicable to 3xx, 4xx, 5xx and = 6xx final responses and 18x and 199 provisional responsess." Regards, Christer -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Paul Kyzivat Sent: 10. marraskuuta 2009 3:06 To: R.Jesske@telekom.de Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Roland, Thanks! That addresses my concern. Thanks, Paul R.Jesske@telekom.de wrote: > Hello Paul, > Thanks for that hint. I will change this too.=20 > Like: >=20 > The appearance of the Reason header is applicable to final responses > 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as = defined within > ietf-sipcore-199.txt. Also the Reason header is > applicable to provisional responses18x. >=20 > Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Montag, 9. November 2009 12:58 > An: Jesske, Roland > Cc: adam@nostrum.com; audet@nortel.com; dispatch@ietf.org;=20 > gonzalo.camarillo@ericsson.com > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 >=20 >=20 > R.Jesske@telekom.de wrote: >> Hi Adam, >> Thank you for your mail. So I propose the following text then: >> >> The appearance of the Reason header is applicable to final responses >> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as = defined within >> ietf-sipcore-199.txt. Also the Reason header is >> applicable to provisional responses18x which are generated by = an >> interworking gateway from ISUP to SIP. >=20 > I think this is ok *except* if you are going to allow one kind of UAS=20 > to use Reason in a 18x response, then it should be allowed for *any*=20 > UAS to do so. >=20 > For instance, suppose the gateway is replaced by a B2BUA to another=20 > sip environment, and the request eventually arrives as a gateway. Then = > a 18x response with a Reason header may arrive at the B2BUA and need=20 > to be replicated on the other side. >=20 > Thanks, > Paul >=20 >> Best Beagards >> >> Roland >> >> -----Urspr=FCngliche Nachricht----- >> Von: Adam Roach [mailto:adam@nostrum.com] >> Gesendet: Freitag, 6. November 2009 01:43 >> An: Jesske, Roland >> Cc: audet@nortel.com; christer.holmberg@ericsson.com;=20 >> gonzalo.camarillo@ericsson.com; dispatch@ietf.org >> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: >>> Hi Christer and Francois, >>> I have added a sentence under section Overall Applicability: >>> >>> >>> The appearance of the Reason header is applicable to final responses = 4xx, 5xx and 6xx and in addition for 199 Responses. >>> >>> Is this proper enough? Or do you have more in mind? >>> =20 >> Given that RFC 3398 specifies the generation of a 301 in response to=20 >> a cause code of 22 under certain circumstances, it seems pretty=20 >> appropriate to allow the inclusion of a Q.850 cause code in 300-class = >> responses also. Or, at least, as appropriate as it would be to=20 >> include them in 4xx, 5xx, and 6xx responses. >> >> /a >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From andrew.hutton@siemens-enterprise.com Mon Nov 9 17:42:40 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B43F28C2A6 for ; Mon, 9 Nov 2009 17:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdsdZdxAZQSC for ; Mon, 9 Nov 2009 17:42:39 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 2F38F28C29E for ; Mon, 9 Nov 2009 17:42:39 -0800 (PST) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id nAA1gxoX002980; Tue, 10 Nov 2009 02:43:00 +0100 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nAA1gx3b003264; Tue, 10 Nov 2009 02:42:59 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.110]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Tue, 10 Nov 2009 02:42:58 +0100 From: "Hutton, Andrew" To: Scott Lawrence , "Vijay K. Gurbani" Date: Tue, 10 Nov 2009 02:42:51 +0100 Thread-Topic: [dispatch] Charter proposal: Session Recording Protocol Thread-Index: AcphTZrerUcxw3tBQlyKr7wnGfUPNQAVr3RQ Message-ID: <78E9EEAA7D0BD94B8A578369FD7B1B92072517647E@DEMCHP99E35MSX.ww902.siemens.net> References: <4AB780B4.3000601@alcatel-lucent.com> <1257778841.32566.102.camel@scott> In-Reply-To: <1257778841.32566.102.camel@scott> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , rai-ads Subject: Re: [dispatch] Charter proposal: Session Recording Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:42:40 -0000 Hi Scott, I agree that the architecture you described with no middle boxes should be = considered and included in the architecture draft. I think the result of today's Dispatch meeting is that a new WG will be for= med which I think is probably the best way forward because session recordin= g is much more than a call control feature which is what I believe BLISS is= chartered for. Regards Andy >-----Original Message----- >From: dispatch-bounces@ietf.org >[mailto:dispatch-bounces@ietf.org] On Behalf Of Scott Lawrence >Sent: 09 November 2009 15:01 >To: Vijay K. Gurbani >Cc: dispatch@ietf.org; rai-ads >Subject: Re: [dispatch] Charter proposal: Session Recording Protocol > >On Mon, 2009-09-21 at 08:33 -0500, Vijay K. Gurbani wrote: >> Hi: The following charter proposal is a continuation of the >> work presented on the same topic (SIP Session Recording) >> at the Stockholm IETF. >> >> Regards, >> >> The Session Recording Protocol (SRP) working group is chartered to >> define a SIP-based protocol for controlling a session >(media) recorder. >> >> Session recording is a critical requirement in many business >> communications environments such as call centers and >financial trading >> floors. In some of these environments, all calls must be >recorded for >> regulatory and compliance reasons. In others, calls may be >recorded for >> quality control, business analytics, or consumer protection. > Recording >> is typically done by sending a copy of the media to the recording >> devices. The working group will produce a specification for >a protocol >> that will manage delivery of media from an end-point that originates >> media or that has access to it to a recording device. PBX >and recording >> vendors today implement proprietary, incompatible mechanisms to >> facilitate recording. A standard protocol will reduce the >complexity and >> cost of providing such recording services. >> >> The Session Recording problem presents certain unique >requirements that >> are not addressed in the current SIP protocol specification. These >> include requirements such as the need for a distinction between the >> session that is being recorded versus the session that has been >> established for recording. > >I'd like to register my support for this work. I think that the draft >does a good job laying out the requirements, and that interoperable >solutions to these problems would be of benefit to everyone. > >I would like to have architectures considered that don't rely on a >middlebox of any kind for this, with dataflows like: > > > +-------------+ SIP >+-------------+ > | |<------------------------------------------->| > | > | | | > | > | UA-B |<---------+ +------>| > UA-C | > | | | RTP RTP | | > | > +-------------+ | +--------------+ | >+-------------+ > | | | Recorder | | > | Recording Control +--->| (RS) |<-----+ > | Call Metadata events | | > +------------------------->+--------------+ > (SIP) > >I won't be able to participate even remotely during the >DISPATCH session >on this, but would like to point out that in many ways this fits the >description of BLISS work items: it is fundamentally a calling feature >dealing with switching call legs appropriately among participants. >Whether to establish a dedicated working group or not is up to the ADs; >whether they decide to send it to BLISS or to charter a new group, I >look forward to participating. > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch > From adam@nostrum.com Mon Nov 9 18:03:44 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 874F73A68B1 for ; Mon, 9 Nov 2009 18:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.372, 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 J1riwc2whvWy for ; Mon, 9 Nov 2009 18:03:43 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E76183A6870 for ; Mon, 9 Nov 2009 18:03:42 -0800 (PST) Received: from host-16-62.meeting.ietf.org (host-16-62.meeting.ietf.org [133.93.16.62]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAA241Er081062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 20:04:02 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4AF8CA10.9010502@nostrum.com> Date: Tue, 10 Nov 2009 11:04:00 +0900 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Christer Holmberg References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> <4AF 8AE73.40 50405@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 133.93.16.62 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org, audet@nortel.com, R.Jesske@telekom.de, Gonzalo Camarillo Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 02:03:44 -0000 To clarify the point I was trying to make in the meeting today -- if we've decided to go down this path, I'll save you the trouble of creating the new ABNF for the new INVITE header fields. Here's what they look like: Nature-Of-Connection-Indicators = "Nature-Of-Connection-Indicators" HCOLON quoted-string Forward-Call-Indicators = "Forward-Call-Indicators" HCOLON quoted-string Calling-Party's-Category = "Calling-Party's-Category" HCOLON quoted-string Transmission-Medium-Requirement = "Transmission-Medium-Requirement" HCOLON quoted-string Called-Party-Number = "Called-Party-Number" HCOLON quoted-string Transit-Network-Selection = "Transit-Network-Selection" HCOLON quoted-string Call-Reference = "Call-Reference" HCOLON quoted-string Calling-Party-Number = "Calling-Party-Number" HCOLON quoted-string Optional-Forward-Call-Indicators = "Optional-Forward-Call-Indicators" HCOLON quoted-string Redirecting-Number = "Redirecting-Number" HCOLON quoted-string Redirection-Information = "Redirection-Information" HCOLON quoted-string Closed-User-Group-Interlock-Code = "Closed-User-Group-Interlock-Code" HCOLON quoted-string Connection-Request = "Connection-Request" HCOLON quoted-string Original-Called-Number = "Original-Called-Number" HCOLON quoted-string User-to-user-Information = "User-to-user-Information" HCOLON quoted-string Access-Transport = "Access-Transport" HCOLON quoted-string User-Service-Information = "User-Service-Information" HCOLON quoted-string User-to-user-Indicators = "User-to-user-Indicators" HCOLON quoted-string Generic-Number = "Generic-Number" HCOLON quoted-string Propagation-Delay-Counter = "Propagation-Delay-Counter" HCOLON quoted-string User-Service-Information-Prime = "User-Service-Information-Prime" HCOLON quoted-string Network-Specific-Facility = "Network-Specific-Facility" HCOLON quoted-string Generic-Digits = "Generic-Digits" HCOLON quoted-string Origination-ISC-Point-Code = "Origination-ISC-Point-Code" HCOLON quoted-string User-Teleservice-Information = "User-Teleservice-Information" HCOLON quoted-string Remote-Operations = "Remote-Operations" HCOLON quoted-string Parameter-Compatibility-Information = "Parameter-Compatibility-Information" HCOLON quoted-string Generic-Notification-Indicator = "Generic-Notification-Indicator" HCOLON quoted-string Service-Activation = "Service-Activation" HCOLON quoted-string Generic-Reference = "Generic-Reference" HCOLON quoted-string MLPP-Precedence = "MLPP-Precedence" HCOLON quoted-string Transmission-Medium-Requirement-Prime = "Transmission-Medium-Requirement-Prime" HCOLON quoted-string Location-Number = "Location-Number" HCOLON quoted-string Forward-GVNS = "Forward-GVNS" HCOLON quoted-string CCSS = "CCSS" HCOLON quoted-string Network-Management-Controls = "Network-Management-Controls" HCOLON quoted-string Circuit-Assignment-Map = "Circuit-Assignment-Map" HCOLON quoted-string Correlation-Id = "Correlation-Id" HCOLON quoted-string Call-Diversion-Treatment-Indicators = "Call-Diversion-Treatment-Indicators" HCOLON quoted-string Called-IN-Number = "Called-IN-Number" HCOLON quoted-string Call-Offering-Treatment-Indicators = "Call-Offering-Treatment-Indicators" HCOLON quoted-string Conference-Treatment-Indicators = "Conference-Treatment-Indicators" HCOLON quoted-string SCF-Id = "SCF-Id" HCOLON quoted-string UID-Capability-Indicators = "UID-Capability-Indicators" HCOLON quoted-string Echo-Control-Information = "Echo-Control-Information" HCOLON quoted-string Hop-Counter = "Hop-Counter" HCOLON quoted-string Collect-Call-Request = "Collect-Call-Request" HCOLON quoted-string Application-Transport-Parameter = "Application-Transport-Parameter" HCOLON quoted-string Pivot-Capability = "Pivot-Capability" HCOLON quoted-string Called-Directory-Number = "Called-Directory-Number" HCOLON quoted-string Original-Called-IN-Number = "Original-Called-IN-Number" HCOLON quoted-string Calling-Geodetic-Location = "Calling-Geodetic-Location" HCOLON quoted-string Network-Routing-Number = "Network-Routing-Number" HCOLON quoted-string QoR-Capability = "QoR-Capability" HCOLON quoted-string Pivot-Counter = "Pivot-Counter" HCOLON quoted-string Pivot-Routing-Forward-Information = "Pivot-Routing-Forward-Information" HCOLON quoted-string Redirect-Capability = "Redirect-Capability" HCOLON quoted-string Redirect-Counter = "Redirect-Counter" HCOLON quoted-string Redirect-Status = "Redirect-Status" HCOLON quoted-string Redirect-Forward-Information = "Redirect-Forward-Information" HCOLON quoted-string Number-Portability-Forward-Information = "Number-Portability-Forward-Information" HCOLON quoted-string Perhaps we can refine some the the quoted strings with tokens, but I think this is a good start. /a From Simo.Veikkolainen@nokia.com Mon Nov 9 18:14:04 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28FB3A67AF for ; Mon, 9 Nov 2009 18:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 leFQ5HdKDBKc for ; Mon, 9 Nov 2009 18:14:03 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 3A93E3A676A for ; Mon, 9 Nov 2009 18:14:02 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAA2EE8U004702 for ; Tue, 10 Nov 2009 04:14:27 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 04:14:24 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 04:14:20 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 10 Nov 2009 03:14:19 +0100 From: To: Date: Tue, 10 Nov 2009 03:14:14 +0100 Thread-Topic: Agenda for SIP/XMPP co-existence ad-hoc meeting on Friday Nov 13 Thread-Index: Acphq3+7QIq//Yy7SEWFsFfhjjdzPw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Nov 2009 02:14:20.0104 (UTC) FILETIME=[83254480:01CA61AB] X-Nokia-AV: Clean Subject: [dispatch] Agenda for SIP/XMPP co-existence ad-hoc meeting on Friday Nov 13 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 02:14:04 -0000 Hello, Here is the proposed agenda for the DISPATCH WG ad-hoc sessionon SIP/XMPP c= o-existence scheduled for Friday Nov 13, 2009, at 13:00-15:00 at room Cattl= eya West. The ad-hoc session will be chaired by Gonzalo Camarillo. 1. Motivation and objectives of SIP/XMPP co-existence (10 min) 2. Overview of solution space (15 min) - baseline proposal http://tools.ietf.org/html/draft-veikkolainen-sip-voip-= xmpp-im-01 3. Technical issues discussed so far (15 min) - http://www.ietf.org/mail-archive/web/dispatch/current/msg00845.html 4. Discussion on charter proposal (30 min) - http://www.ietf.org/mail-archive/web/dispatch/current/msg00560.html 5. Conclusion and next steps=20 Regards, Simo From bernard_aboba@hotmail.com Mon Nov 9 19:30:48 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53413A6836 for ; Mon, 9 Nov 2009 19:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=1.347, 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 Kr3q4LdlO0xF for ; Mon, 9 Nov 2009 19:30:47 -0800 (PST) Received: from blu0-omc4-s15.blu0.hotmail.com (blu0-omc4-s15.blu0.hotmail.com [65.55.111.154]) by core3.amsl.com (Postfix) with ESMTP id B51DB3A635F for ; Mon, 9 Nov 2009 19:30:47 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.136]) by blu0-omc4-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 19:31:14 -0800 X-Originating-IP: [131.107.0.70] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: References: In-Reply-To: Date: Mon, 9 Nov 2009 19:17:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphpykSUsCixUtqTVOlQEfXK0PdsQACLHQg Content-Language: en-us X-OriginalArrivalTime: 10 Nov 2009 03:31:14.0426 (UTC) FILETIME=[417EEDA0:01CA61B6] Subject: Re: [dispatch] Introducing ViPR: a new federation technology X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:30:48 -0000 Kevin Fleming said: " I came away with the same conclusion you did; it's really only applicable to closely-aligned parties that want to federate, not for any providers that may provide SIP connectivity in between the parties that want to federate. This would make it somewhat complex to deploy in a hosted PBX scenario, unless the ViPR server was also virtualized to provide a separate set of data for each hosted PBX that chose to use ViPR." I'm not sure that it's only applicable to closely-aligned parties. As noted, the DHT approach does scale logarithmically. Although one might quibble with some of the dependencies (e.g. SRP/TLS is encumbered by multiple IPR declarations, as is RELOAD), the overall approach does not require pre-existing trust between the parties. There are existing approaches for moderate numbers of closely-aligned parties (e.g. DUNDI works at that scale, and even the existing RFC 3261 model isn't that broken in for that case, since I'm aware of customers who are federating with dozens of suppliers/customers using TLS with mutual authentication). The bigger issue as I see it is the tying of SIP federation in non-VOIP scenarios (e.g. Video, Web conferencing, IM&P) to PSTN and phone number identifiers. In those scenarios, the proposed introduction and verification mechanisms aren't much better than existing "buddy list" techniques for trust establishment. Those techniques have been in use for a long time (e.g. in XMPP federation) and have proven quite effective. Also, if one buys the arguments, then one could conclude that all that is necessary for VOIP bypass is a PRI and an Internet connection. Why bother with SIP trunking? However, that argument assumes that as the decline in the PSTN accelerates that SIP Trunking providers will utilize infrastructure ENUM to their advantage to route calls directly over the Internet without passing on the savings to customers. However, the evolution of Internet peering would indicate this not the most likely outcome. Back in the mid-1990s, peering was a significant issue for second Tier ISPs and access cost much more than it does today. Today recent measurements show that 50 percent of Internet traffic is originating in only 150 ASes, and that kind of consolidation also tends to go along with major declines in consumer costs and an lessening of importance of peering concerns. So my own guess is that as SIP trunking becomes a commodity that the industry will grow more and more competitive and that in a decade infrastructure ENUM will apply to a very large fraction of all calls, with the benefits being passed on to customers. In that kind of scenario, ViPR would be unnecessary. From hsinnrei@adobe.com Mon Nov 9 20:52:34 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C403A6820 for ; Mon, 9 Nov 2009 20:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.371 X-Spam-Level: X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[AWL=1.228, 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 QjYyxKuMjlJC for ; Mon, 9 Nov 2009 20:52:28 -0800 (PST) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by core3.amsl.com (Postfix) with ESMTP id B4D503A680F for ; Mon, 9 Nov 2009 20:52:26 -0800 (PST) Received: from source ([192.150.8.22]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKSvjxpAoxPBZ5eIQOeDeSR67GbFUCnqqk@postini.com; Mon, 09 Nov 2009 20:52:55 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id nAA4qoW0021087; Mon, 9 Nov 2009 20:52:50 -0800 (PST) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id nAA4qA8b017017; Mon, 9 Nov 2009 20:52:48 -0800 (PST) Received: from excas02.corp.adobe.com (10.8.188.212) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 9 Nov 2009 20:52:37 -0800 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Mon, 9 Nov 2009 20:52:37 -0800 From: Henry Sinnreich To: Bernard Aboba , "dispatch@ietf.org" Date: Mon, 9 Nov 2009 20:52:35 -0800 Thread-Topic: [dispatch] Introducing ViPR: a new federation technology Thread-Index: AcphpykSUsCixUtqTVOlQEfXK0PdsQACLHQgAARw6u0= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C71F20A310EC7hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [dispatch] Introducing ViPR: a new federation technology X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:52:34 -0000 --_000_C71F20A310EC7hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >In that kind of scenario, ViPR would be unnecessary. 100% agree for the reasons given below and several other that already well = known and need not be repeated here. I also don't remember reading anywhere in the Internet architecture about f= ederations and cartels. My two personal cents, Henry On 11/10/09 12:17 PM, "Bernard Aboba" wrote: Kevin Fleming said: " I came away with the same conclusion you did; it's really only applicable to closely-aligned parties that want to federate, not for any providers that may provide SIP connectivity in between the parties that want to federate. This would make it somewhat complex to deploy in a hosted PBX scenario, unless the ViPR server was also virtualized to provide a separate set of data for each hosted PBX that chose to use ViPR." I'm not sure that it's only applicable to closely-aligned parties. As noted, the DHT approach does scale logarithmically. Although one might quibble with some of the dependencies (e.g. SRP/TLS is encumbered by multiple IPR declarations, as is RELOAD), the overall approach does not require pre-existing trust between the parties. There are existing approaches for moderate numbers of closely-aligned parties (e.g. DUNDI works at that scale, and even the existing RFC 3261 model isn't that broken in for that case, since I'm aware of customers who are federating with dozens of suppliers/customers using TLS with mutual authentication). The bigger issue as I see it is the tying of SIP federation in non-VOIP scenarios (e.g. Video, Web conferencing, IM&P) to PSTN and phone number identifiers. In those scenarios, the proposed introduction and verificatio= n mechanisms aren't much better than existing "buddy list" techniques for trust establishment. Those techniques have been in use for a long time (e.g. in XMPP federation) and have proven quite effective. Also, if one buys the arguments, then one could conclude that all that is necessary for VOIP bypass is a PRI and an Internet connection. Why bother with SIP trunking? However, that argument assumes that as the decline in th= e PSTN accelerates that SIP Trunking providers will utilize infrastructure ENUM to their advantage to route calls directly over the Internet without passing on the savings to customers. However, the evolution of Internet peering would indicate this not the most likely outcome. Back in the mid-1990s, peering was a significant issue for second Tier ISPs and access cost much more than it does today. Today recen= t measurements show that 50 percent of Internet traffic is originating in onl= y 150 ASes, and that kind of consolidation also tends to go along with major declines in consumer costs and an lessening of importance of peering concerns. So my own guess is that as SIP trunking becomes a commodity that the industry will grow more and more competitive and that in a decade infrastructure ENUM will apply to a very large fraction of all calls, with the benefits being passed on to customers. In that kind of scenario, ViPR would be unnecessary. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_C71F20A310EC7hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Introducing ViPR: a new federation technology >In that kind of scenario, ViPR would be unnecessary.

100% agree for the reasons given below and several other that already well = known and need not be repeated here.
I also don’t remember reading anywhere in the Internet architecture a= bout federations and cartels.

My two personal cents,

Henry


On 11/10/09 12:17 PM, "Bernard Aboba" <bernard_aboba@hotmail.com> wrote:

Kevin Fleming said:

" I came away with the same conclusion you did; it's really only appli= cable
to closely-aligned parties that want to federate, not for any  provide= rs
that may provide SIP connectivity in between the parties that want to
federate. This would make it somewhat complex to deploy in a hosted PBX
scenario, unless the ViPR server was also virtualized to provide a separate=
set of data for each hosted PBX that chose to use ViPR."

I'm not sure that it's only applicable to closely-aligned parties.  As=
noted, the DHT approach does scale logarithmically.  Although one migh= t
quibble with some of the dependencies (e.g. SRP/TLS is encumbered by
multiple IPR declarations, as is RELOAD), the overall approach does not
require pre-existing trust between the parties.

There are existing approaches for moderate numbers of closely-aligned
parties (e.g. DUNDI works at that scale, and even the existing RFC 3261
model isn't that broken in for that case, since I'm aware of customers who<= BR> are federating with dozens of suppliers/customers using TLS with mutual
authentication).

The bigger issue as I see it is the tying of SIP federation in non-VOIP
scenarios (e.g. Video, Web conferencing, IM&P) to PSTN and phone number=
identifiers.  In those scenarios, the proposed introduction and verifi= cation
mechanisms aren't much better than existing "buddy list" techniqu= es for
trust establishment.  Those techniques have been in use for a long tim= e
(e.g. in XMPP federation) and have proven quite effective.

Also, if one buys the arguments, then one could conclude that all that is necessary for VOIP bypass is a PRI and an Internet connection.  Why bo= ther
with SIP trunking? However, that argument assumes that as the decline in th= e
PSTN accelerates that SIP Trunking providers will utilize infrastructure ENUM to their advantage to route calls directly over the Internet without passing on the savings to customers.

However, the evolution of Internet peering would indicate this not the most=
likely outcome.  Back in the mid-1990s, peering was a significant issu= e for
second Tier ISPs and access cost much more than it does today.  Today = recent
measurements show that 50 percent of Internet traffic is originating in onl= y
150 ASes, and that kind of consolidation also tends to go along with major<= BR> declines in consumer costs and an lessening of importance of peering
concerns.

So my own guess is that as SIP trunking becomes a commodity that the
industry will grow more and more competitive and that in a decade
infrastructure ENUM will apply to a very large fraction of all calls, with<= BR> the benefits being passed on to customers.

In that kind of scenario, ViPR would be unnecessary.

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

--_000_C71F20A310EC7hsinnreiadobecom_-- From BeckW@telekom.de Mon Nov 9 21:01:24 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430993A692D for ; Mon, 9 Nov 2009 21:01:24 -0800 (PST) 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 5Ivm31FI4Fcj for ; Mon, 9 Nov 2009 21:01:22 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 1DB1D3A67CF for ; Mon, 9 Nov 2009 21:01:21 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 10 Nov 2009 06:01:43 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 06:01:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 06:01:41 +0100 Message-ID: <4A956CE47D1066408D5C7EB34368A511054E1D35@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4AF8CA10.9010502@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04; why encapsulation is problematic Thread-Index: Acphqhxx8u5K/S7OTtuYQRL6bZ4BbAAE8png References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> <4AF8AE73.40 50405@cisco.com> <4AF8CA10.9010502@nostrum.com> From: To: , X-OriginalArrivalTime: 10 Nov 2009 05:01:43.0231 (UTC) FILETIME=[E550D4F0:01CA61C2] Cc: audet@nortel.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com, R.Jesske@telekom.de Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04; why encapsulation is problematic X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:01:24 -0000 =20 These are my issues with SIP-T: 1) ISUP messages end up at end users. This violates regulatory = requirements in countries where ISUP must only be sent to licensed = carriers. For example, called parties will see the calling party = numbers, even if the calling party required privacy. Apart from the MIME = issues, this prevents us from using encapsulation.=20 2) Encrypting SIP-T message bodies would solve 1), but looking at SIPit = results, S/MIME for SIP is a dead technology. 3) Will application servers acting as B2BUAs deal properly with SIP-T = multipart MIME bodies? People seem to be worried that they are not even = able to forward a Reason header.. 4) Many client don't implement Multipart MIME, as it can get quite = complex (what to do with multiple SDP bodies, alternative SDP bodies = etc). I'd have to ask my vendors to add complexity to the software = without real benefit ("You'll have to implement multipart MIME, so we = can send binary blobs to you the device has to throw away"). In the year = 2009 some SIP clients don't even get simple SDP offer/answer right, how = could we expect them to handle Multipart MIME in a sensible manner?=20 5) User agents might have to switch TCP, just to receive oversized SIP = messages with SIP-T bodies that will by thrown away.=20 Wolfgang Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Wolfgang Beck=20 TE 122-14=20 Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 +49 6151 6282832 (Tel.)=20 E-Mail: beckw@telekom.de=20 http://www.telekom.com=20 Erleben, was verbindet. 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 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Adam Roach Gesendet: Dienstag, 10. November 2009 03:04 An: Christer Holmberg Cc: dispatch@ietf.org; audet@nortel.com; Jesske, Roland; Gonzalo = Camarillo Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 To clarify the point I was trying to make in the meeting today -- if=20 we've decided to go down this path, I'll save you the trouble of=20 creating the new ABNF for the new INVITE header fields. Here's what they = look like: Nature-Of-Connection-Indicators =3D = "Nature-Of-Connection-Indicators" HCOLON quoted-string Forward-Call-Indicators =3D "Forward-Call-Indicators" HCOLON quoted-string Calling-Party's-Category =3D "Calling-Party's-Category" HCOLON quoted-string Transmission-Medium-Requirement =3D = "Transmission-Medium-Requirement" HCOLON quoted-string Called-Party-Number =3D "Called-Party-Number" HCOLON quoted-string Transit-Network-Selection =3D "Transit-Network-Selection" HCOLON quoted-string Call-Reference =3D "Call-Reference" HCOLON quoted-string Calling-Party-Number =3D "Calling-Party-Number" HCOLON quoted-string Optional-Forward-Call-Indicators =3D=20 "Optional-Forward-Call-Indicators" HCOLON quoted-string Redirecting-Number =3D "Redirecting-Number" HCOLON quoted-string Redirection-Information =3D "Redirection-Information" HCOLON quoted-string Closed-User-Group-Interlock-Code =3D=20 "Closed-User-Group-Interlock-Code" HCOLON quoted-string Connection-Request =3D "Connection-Request" HCOLON quoted-string Original-Called-Number =3D "Original-Called-Number" HCOLON quoted-string User-to-user-Information =3D "User-to-user-Information" HCOLON quoted-string Access-Transport =3D "Access-Transport" HCOLON quoted-string User-Service-Information =3D "User-Service-Information" HCOLON quoted-string User-to-user-Indicators =3D "User-to-user-Indicators" HCOLON quoted-string Generic-Number =3D "Generic-Number" HCOLON quoted-string Propagation-Delay-Counter =3D "Propagation-Delay-Counter" HCOLON quoted-string User-Service-Information-Prime =3D = "User-Service-Information-Prime" HCOLON quoted-string Network-Specific-Facility =3D "Network-Specific-Facility" HCOLON quoted-string Generic-Digits =3D "Generic-Digits" HCOLON quoted-string Origination-ISC-Point-Code =3D = "Origination-ISC-Point-Code" HCOLON quoted-string User-Teleservice-Information =3D = "User-Teleservice-Information" HCOLON quoted-string Remote-Operations =3D "Remote-Operations" HCOLON quoted-string Parameter-Compatibility-Information =3D=20 "Parameter-Compatibility-Information" HCOLON quoted-string Generic-Notification-Indicator =3D = "Generic-Notification-Indicator" HCOLON quoted-string Service-Activation =3D "Service-Activation" HCOLON quoted-string Generic-Reference =3D "Generic-Reference" HCOLON quoted-string MLPP-Precedence =3D "MLPP-Precedence" HCOLON quoted-string Transmission-Medium-Requirement-Prime =3D=20 "Transmission-Medium-Requirement-Prime" HCOLON quoted-string Location-Number =3D "Location-Number" HCOLON quoted-string Forward-GVNS =3D "Forward-GVNS" HCOLON quoted-string CCSS =3D "CCSS" HCOLON quoted-string Network-Management-Controls =3D = "Network-Management-Controls" HCOLON quoted-string Circuit-Assignment-Map =3D "Circuit-Assignment-Map" HCOLON quoted-string Correlation-Id =3D "Correlation-Id" HCOLON quoted-string Call-Diversion-Treatment-Indicators =3D=20 "Call-Diversion-Treatment-Indicators" HCOLON quoted-string Called-IN-Number =3D "Called-IN-Number" HCOLON quoted-string Call-Offering-Treatment-Indicators =3D=20 "Call-Offering-Treatment-Indicators" HCOLON quoted-string Conference-Treatment-Indicators =3D = "Conference-Treatment-Indicators" HCOLON quoted-string SCF-Id =3D "SCF-Id" HCOLON quoted-string UID-Capability-Indicators =3D "UID-Capability-Indicators" HCOLON quoted-string Echo-Control-Information =3D "Echo-Control-Information" HCOLON quoted-string Hop-Counter =3D "Hop-Counter" HCOLON quoted-string Collect-Call-Request =3D "Collect-Call-Request" HCOLON quoted-string Application-Transport-Parameter =3D = "Application-Transport-Parameter" HCOLON quoted-string Pivot-Capability =3D "Pivot-Capability" HCOLON quoted-string Called-Directory-Number =3D "Called-Directory-Number" HCOLON quoted-string Original-Called-IN-Number =3D "Original-Called-IN-Number" HCOLON quoted-string Calling-Geodetic-Location =3D "Calling-Geodetic-Location" HCOLON quoted-string Network-Routing-Number =3D "Network-Routing-Number" HCOLON quoted-string QoR-Capability =3D "QoR-Capability" HCOLON quoted-string Pivot-Counter =3D "Pivot-Counter" HCOLON quoted-string Pivot-Routing-Forward-Information =3D=20 "Pivot-Routing-Forward-Information" HCOLON quoted-string Redirect-Capability =3D "Redirect-Capability" HCOLON quoted-string Redirect-Counter =3D "Redirect-Counter" HCOLON quoted-string Redirect-Status =3D "Redirect-Status" HCOLON quoted-string Redirect-Forward-Information =3D = "Redirect-Forward-Information" HCOLON quoted-string Number-Portability-Forward-Information =3D =20 "Number-Portability-Forward-Information" HCOLON quoted-string Perhaps we can refine some the the quoted strings with tokens, but I=20 think this is a good start. /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Mon Nov 9 21:41:37 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292643A679F for ; Mon, 9 Nov 2009 21:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.331, 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 w3hwoOdYV6dj for ; Mon, 9 Nov 2009 21:41:36 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B0B4D3A6A34 for ; Mon, 9 Nov 2009 21:41:35 -0800 (PST) Received: from host-16-62.meeting.ietf.org (host-16-62.meeting.ietf.org [133.93.16.62]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAA5fsZ6097493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 23:41:57 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4AF8FD21.7040704@nostrum.com> Date: Tue, 10 Nov 2009 14:41:53 +0900 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: BeckW@telekom.de References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> <4AF8AE73.40 50405@cisco.com> <4AF8CA10.9010502@nostrum.com> <4A956CE47D1066408D5C7EB34368A511054E1D35@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4A956CE47D1066408D5C7EB34368A511054E1D35@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 133.93.16.62 is authenticated by a trusted mechanism) Cc: audet@nortel.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com, R.Jesske@telekom.de Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04; why encapsulation is problematic X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:41:37 -0000 On 11/10/09 2:01 PM, BeckW@telekom.de wrote: > > These are my issues with SIP-T: > > 1) ISUP messages end up at end users. This violates regulatory requirements in countries where ISUP must only be sent to licensed carriers. For example, called parties will see the calling party numbers, even if the calling party required privacy. Apart from the MIME issues, this prevents us from using encapsulation. > > 2) Encrypting SIP-T message bodies would solve 1), but looking at SIPit results, S/MIME for SIP is a dead technology. > S/MIME for a general purpose network suffers from the classical key distribution problem. It's not used for the same reason encrypted email is not used (except among the geek community). But you're not talking about general purpose networks. You're talking about tightly constrained networks with PSTN gateways that are either all within a single administrative domain, or that communicate with each other through bilateral agreements. In these circumstances, key distribution is no more difficult a problem than IP address assignment. It's a simple matter of configuration. > 3) Will application servers acting as B2BUAs deal properly with SIP-T multipart MIME bodies? People seem to be worried that they are not even able to forward a Reason header.. > B2BUAs will break whatever they break. Until someone sits down and documents their behavior, we can't really do too much to work around their behavior. It's the same problem we're having all over the place (identity, MSRP ACM, etc). There's no point in talking about something as nebulous as B2BUA behavior. > 4) Many client don't implement Multipart MIME, as it can get quite complex (what to do with multiple SDP bodies, alternative SDP bodies etc). I'd have to ask my vendors to add complexity to the software without real benefit ("You'll have to implement multipart MIME, so we can send binary blobs to you the device has to throw away"). In the year 2009 some SIP clients don't even get simple SDP offer/answer right, how could we expect them to handle Multipart MIME in a sensible manner? While many UAs won't be able to ignore the multitype body (aside: this is sad -- email clients all can), you'd be hard pressed to find one that can't understand multipart that also won't respond to a multipart body in a request with a 415. This ends up looking just like SIP authentication, since the UAC will detect the failure to support multipart and re-attempt with a single body: UAC UAS |---INVITE--->| |<----415-----| |---INVITE--->| |<----180-----| ... |<----200-----| |-----ACK---->| > 5) User agents might have to switch TCP, just to receive oversized SIP messages with SIP-T bodies that will by thrown away. > At one point, you said "IMS." I don't think you'll find an IMS client that has any hope of receiving a UDP SIP message -- show me an INVITE on the terminating side of an IMS network that is somehow smaller than 1500 bytes, and I'll be shocked into silence. TCP is a foregone conclusion. /a From adam@nostrum.com Mon Nov 9 21:50:45 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F3E3A6936 for ; Mon, 9 Nov 2009 21:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.298, 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 DVNLtueK2hJ6 for ; Mon, 9 Nov 2009 21:50:44 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 7002628C105 for ; Mon, 9 Nov 2009 21:50:43 -0800 (PST) Received: from host-16-62.meeting.ietf.org (host-16-62.meeting.ietf.org [133.93.16.62]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAA5p2uJ098205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 23:51:04 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4AF8FF46.3000604@nostrum.com> Date: Tue, 10 Nov 2009 14:51:02 +0900 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Christer Holmberg References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> <4AF 8AE73.40 50405@cisco.com> <4AF8CA10.9010502@nostrum.com> In-Reply-To: <4AF8CA10.9010502@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 133.93.16.62 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org, Gonzalo Camarillo , R.Jesske@telekom.de Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:50:45 -0000 It was pointed out to me that this email was somewhat nonsensical to people who were not in attendance at the face-to-face meeting. My point is that increasing the amount of ISUP information that we include in SIP message headers is going down a slippery slope, the ultimate conclusion of which is including SIP header fields for every ISUP parameter. We have a means for sending ISUP fields transparently through a SIP network (RFC 3398). I think it's folly to revisit that set of decisions simply because someone wants a less-general point solution. /a On 11/10/09 11:04 AM, Adam Roach wrote: > To clarify the point I was trying to make in the meeting today -- if > we've decided to go down this path, I'll save you the trouble of > creating the new ABNF for the new INVITE header fields. Here's what > they look like: > > Nature-Of-Connection-Indicators = > "Nature-Of-Connection-Indicators" > HCOLON quoted-string > > Forward-Call-Indicators = "Forward-Call-Indicators" > HCOLON quoted-string > > Calling-Party's-Category = "Calling-Party's-Category" > HCOLON quoted-string > > Transmission-Medium-Requirement = > "Transmission-Medium-Requirement" > HCOLON quoted-string > > Called-Party-Number = "Called-Party-Number" > HCOLON quoted-string > > Transit-Network-Selection = "Transit-Network-Selection" > HCOLON quoted-string > > Call-Reference = "Call-Reference" > HCOLON quoted-string > > Calling-Party-Number = "Calling-Party-Number" > HCOLON quoted-string > > Optional-Forward-Call-Indicators = > "Optional-Forward-Call-Indicators" > HCOLON quoted-string > > Redirecting-Number = "Redirecting-Number" > HCOLON quoted-string > > Redirection-Information = "Redirection-Information" > HCOLON quoted-string > > Closed-User-Group-Interlock-Code = > "Closed-User-Group-Interlock-Code" > HCOLON quoted-string > > Connection-Request = "Connection-Request" > HCOLON quoted-string > > Original-Called-Number = "Original-Called-Number" > HCOLON quoted-string > > User-to-user-Information = "User-to-user-Information" > HCOLON quoted-string > > Access-Transport = "Access-Transport" > HCOLON quoted-string > > User-Service-Information = "User-Service-Information" > HCOLON quoted-string > > User-to-user-Indicators = "User-to-user-Indicators" > HCOLON quoted-string > > Generic-Number = "Generic-Number" > HCOLON quoted-string > > Propagation-Delay-Counter = "Propagation-Delay-Counter" > HCOLON quoted-string > > User-Service-Information-Prime = > "User-Service-Information-Prime" > HCOLON quoted-string > > Network-Specific-Facility = "Network-Specific-Facility" > HCOLON quoted-string > > Generic-Digits = "Generic-Digits" > HCOLON quoted-string > > Origination-ISC-Point-Code = "Origination-ISC-Point-Code" > HCOLON quoted-string > > User-Teleservice-Information = "User-Teleservice-Information" > HCOLON quoted-string > > Remote-Operations = "Remote-Operations" > HCOLON quoted-string > > Parameter-Compatibility-Information = > "Parameter-Compatibility-Information" > HCOLON quoted-string > > Generic-Notification-Indicator = > "Generic-Notification-Indicator" > HCOLON quoted-string > > Service-Activation = "Service-Activation" > HCOLON quoted-string > > Generic-Reference = "Generic-Reference" > HCOLON quoted-string > > MLPP-Precedence = "MLPP-Precedence" > HCOLON quoted-string > > Transmission-Medium-Requirement-Prime = > "Transmission-Medium-Requirement-Prime" > HCOLON quoted-string > > Location-Number = "Location-Number" > HCOLON quoted-string > > Forward-GVNS = "Forward-GVNS" > HCOLON quoted-string > > CCSS = "CCSS" > HCOLON quoted-string > > Network-Management-Controls = "Network-Management-Controls" > HCOLON quoted-string > > Circuit-Assignment-Map = "Circuit-Assignment-Map" > HCOLON quoted-string > > Correlation-Id = "Correlation-Id" > HCOLON quoted-string > > Call-Diversion-Treatment-Indicators = > "Call-Diversion-Treatment-Indicators" > HCOLON quoted-string > > Called-IN-Number = "Called-IN-Number" > HCOLON quoted-string > > Call-Offering-Treatment-Indicators = > "Call-Offering-Treatment-Indicators" > HCOLON quoted-string > > Conference-Treatment-Indicators = > "Conference-Treatment-Indicators" > HCOLON quoted-string > > SCF-Id = "SCF-Id" > HCOLON quoted-string > > UID-Capability-Indicators = "UID-Capability-Indicators" > HCOLON quoted-string > > Echo-Control-Information = "Echo-Control-Information" > HCOLON quoted-string > > Hop-Counter = "Hop-Counter" > HCOLON quoted-string > > Collect-Call-Request = "Collect-Call-Request" > HCOLON quoted-string > > Application-Transport-Parameter = > "Application-Transport-Parameter" > HCOLON quoted-string > > Pivot-Capability = "Pivot-Capability" > HCOLON quoted-string > > Called-Directory-Number = "Called-Directory-Number" > HCOLON quoted-string > > Original-Called-IN-Number = "Original-Called-IN-Number" > HCOLON quoted-string > > Calling-Geodetic-Location = "Calling-Geodetic-Location" > HCOLON quoted-string > > Network-Routing-Number = "Network-Routing-Number" > HCOLON quoted-string > > QoR-Capability = "QoR-Capability" > HCOLON quoted-string > > Pivot-Counter = "Pivot-Counter" > HCOLON quoted-string > > Pivot-Routing-Forward-Information = > "Pivot-Routing-Forward-Information" > HCOLON quoted-string > > Redirect-Capability = "Redirect-Capability" > HCOLON quoted-string > > Redirect-Counter = "Redirect-Counter" > HCOLON quoted-string > > Redirect-Status = "Redirect-Status" > HCOLON quoted-string > > Redirect-Forward-Information = "Redirect-Forward-Information" > HCOLON quoted-string > > Number-Portability-Forward-Information = > > "Number-Portability-Forward-Information" > HCOLON quoted-string > > Perhaps we can refine some the the quoted strings with tokens, but I > think this is a good start. > > /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jdrosen@jdrosen.net Mon Nov 9 21:59:04 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5729D28C116 for ; Mon, 9 Nov 2009 21:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.916 X-Spam-Level: X-Spam-Status: No, score=0.916 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5Api91rgRSr for ; Mon, 9 Nov 2009 21:59:03 -0800 (PST) Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 65E1228C10D for ; Mon, 9 Nov 2009 21:59:02 -0800 (PST) Received: from [192.168.11.78] (helo=[192.168.11.78]) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N7jlG-0006wV-00; Tue, 10 Nov 2009 07:59:26 +0200 Message-ID: <4AF89ED0.5000009@jdrosen.net> Date: Tue, 10 Nov 2009 00:59:28 +0200 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Introducing ViPR: a new federation technology X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:59:04 -0000 inline: Bernard Aboba wrote: > Kevin Fleming said: > > " I came away with the same conclusion you did; it's really only applicable > to closely-aligned parties that want to federate, not for any providers > that may provide SIP connectivity in between the parties that want to > federate. This would make it somewhat complex to deploy in a hosted PBX > scenario, unless the ViPR server was also virtualized to provide a separate > set of data for each hosted PBX that chose to use ViPR." > > I'm not sure that it's only applicable to closely-aligned parties. As > noted, the DHT approach does scale logarithmically. Although one might > quibble with some of the dependencies (e.g. SRP/TLS is encumbered by > multiple IPR declarations, as is RELOAD), the overall approach does not > require pre-existing trust between the parties. Exactly. The whole idea is that no close alignment is needed; its any-to-any in the traditional Internet model. ViPR applies to any domain that has endpoints that have been assigned numbers. That certainly includes enterprises, but is not at all limited to that. It has applicability to all kinds of service providers - wireless operators (lots of endpoints), application providers (Vonage, Skype), cable operators, traditional LEC, CLEC, etc. > > There are existing approaches for moderate numbers of closely-aligned > parties (e.g. DUNDI works at that scale, and even the existing RFC 3261 > model isn't that broken in for that case, since I'm aware of customers who > are federating with dozens of suppliers/customers using TLS with mutual > authentication). As the drafts point out, private federation is in use today and it works OK at small scales. Stuff like DUNDI can work there, though you run into trust issues quickly as numbers are not verified. > > The bigger issue as I see it is the tying of SIP federation in non-VOIP > scenarios (e.g. Video, Web conferencing, IM&P) to PSTN and phone number > identifiers. In those scenarios, the proposed introduction and verification > mechanisms aren't much better than existing "buddy list" techniques for > trust establishment. Those techniques have been in use for a long time > (e.g. in XMPP federation) and have proven quite effective. Firstly, ViPR is equally applicable to video, specifically for cases where video endpoints aren't 'special' - they are the same endpoint I use for my voip calling. When video is just a feature of my pstn-reachable voice device, ViPR works well. IM&P - which usually doesn't use phone numbers - can be federated with existing DNS mechanisms and buddy-list based trust. However, as I mention in the draft, the reality of the situation is that *most* folks doing voip are still using phone numbers, and that is the problem we're trying to address here. Do you not agree that the majority of voice connections are still being established to phone numbers today? > > Also, if one buys the arguments, then one could conclude that all that is > necessary for VOIP bypass is a PRI and an Internet connection. Why bother > with SIP trunking? SIP trunking would still get you cost savings to non-vipr connected domains and non-voip installtions - all of the rest of the existing PSTN endpoints. That'll continue to be useful for a really long time. ViPR + SIP trunking then further optimizes (and cost reduces) for the domains that you can vipr federate with. However, that argument assumes that as the decline in the > PSTN accelerates that SIP Trunking providers will utilize infrastructure > ENUM to their advantage to route calls directly over the Internet without > passing on the savings to customers. > > However, the evolution of Internet peering would indicate this not the most > likely outcome. Back in the mid-1990s, peering was a significant issue for > second Tier ISPs and access cost much more than it does today. Today recent > measurements show that 50 percent of Internet traffic is originating in only > 150 ASes, and that kind of consolidation also tends to go along with major > declines in consumer costs and an lessening of importance of peering > concerns. > > So my own guess is that as SIP trunking becomes a commodity that the > industry will grow more and more competitive and that in a decade > infrastructure ENUM will apply to a very large fraction of all calls, with > the benefits being passed on to customers. I believe there will be infrastructure enum, absolutely. However, I believe it will be used to create peering relationships amongst the carries which are similar to the ones that exist today - with small regional operators federating with larger international ones, which then federate again off to more local ones. IP federation follows a similar model. These federation agreements are likely in many cases to mirror the existing peering relationships on the PSTN. This is because the peering agreements are likely to include actual RTP transport to, along with the CAC/QoS features that are the IP equivalents of what is done in the PSTN today. That means, in turn, that a call from company A to company B would go as follows: a.com -> SP1 -> SP2 -> SP3 -> b.com and, along the way, pass through the myriad of SBCs and SIP infrastructure in each of these providers: a.com -> SP1-SBC-ingres -> SP1-SBC-egress -> SP2-SBC-ingress -> SP2-SBC-egress -> SP3-SBC-ingress -> SP3-SBC-egress -> b.com That eliminates the trapezoidal model of SIP, which I still believe is essential for feature transparency, feature velocity, and security, amongst many other reasons. The feature velocity one is really important. The more that we have intermediaries in the path, the less likely (exponentially so, in fact) it is that any kind of new feature will ever work. There is a ton of precedent for this. With ViPR, you get: a.com -> b.com And as a consequence, no inderdepdency on anything else for a new feature to work. Thats how the Internet was meant to be. Can you imagine what the web would be like if my HTTP traffic had to be handled by web proxies at each intermediate ISP? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist PHONE: +1 (732) 766-2496 Skype jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From bernarda@microsoft.com Tue Nov 10 00:30:33 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E0C628C10A for ; Tue, 10 Nov 2009 00:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Mty88LNiILr for ; Tue, 10 Nov 2009 00:30:25 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 2C87528C0DC for ; Tue, 10 Nov 2009 00:30:25 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 10 Nov 2009 00:31:09 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.20; Tue, 10 Nov 2009 00:30:51 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 10 Nov 2009 00:30:50 -0800 From: Bernard Aboba To: "dispatch@ietf.org" Thread-Topic: Re: [dispatch] Introducing ViPR: a new federation technology Thread-Index: Acph4CDlLaLoX/4+Rs6gNCcqJ8Wlow== Date: Tue, 10 Nov 2009 08:30:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F839FBA415E97B4DBD5BA437162E0603201E993ATK5EX14MBXW652w_" MIME-Version: 1.0 Subject: Re: [dispatch] Introducing ViPR: a new federation technology X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 08:30:33 -0000 --_000_F839FBA415E97B4DBD5BA437162E0603201E993ATK5EX14MBXW652w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jonathan Rosenberg said: "Do you not agree that the majority of voice connections are still being es= tablished to phone numbers today?" [BA] Sure. And I expect this will be the case for going forward too. My q= uestion was more about the application of ViPR to media *other* than voice. "Firstly, ViPR is equally applicable to video, specifically for cases where= video endpoints aren't 'special' - they are the same endpoint I use for my= voip calling. When video is just a feature of my pstn-reachable voice devi= ce, ViPR works well." [BA] The question in my mind is whether video really is "special" (in the I= M&P sense) or not. That is, today we accept the idea that anyone should be= able to complete a phone call to anyone else. We also accept this for SMS= . However, we don't accept that idea for Instant Messaging (which typicall= y requires being in the buddy list). Do we accept that principle for video?= I'm not sure. There are some inherent disadvantages to accepting video c= alls from anywhere even if we have a verified phone number on the other end= . So even if video is a feature of a voice device, it still might be sufficie= nt to control the ability to complete a video call via a "buddy list". Tha= t's essentially the model for XMPP-based federation with Jingle. Not good = enough to provide telephony as we think of it today. But this does provide= a degree of spam control while retaining something more akin to the RFC 32= 61 federation model (though perhaps with some loosening). "I believe there will be infrastructure enum, absolutely. However, I believ= e it will be used to create peering relationships amongst the carries which= are similar to the ones that exist today - with small regional operators f= ederating with larger international ones, which then federate again off to = more local ones. IP federation follows a similar model. These federation ag= reements are likely in many cases to mirror the existing peering relationsh= ips on the PSTN. This is because the peering agreements are likely to inclu= de actual RTP transport to, along with the CAC/QoS features that are the IP= equivalents of what is done in the PSTN today. That means, in turn, that a call from company A to company B would go as fo= llows: a.com -> SP1 -> SP2 -> SP3 -> b.com and, along the way, pass through the myriad of SBCs and SIP infrastructure = in each of these providers: a.com -> SP1-SBC-ingres -> SP1-SBC-egress -> SP2-SBC-ingress -> SP2-SBC-egr= ess -> SP3-SBC-ingress -> SP3-SBC-egress -> b.com That eliminates the trapezoidal model of SIP, which I still believe is esse= ntial for feature transparency, feature velocity, and security, amongst man= y other reasons. The feature velocity one is really important. The more tha= t we have intermediaries in the path, the less likely (exponentially so, in= fact) it is that any kind of new feature will ever work. There is a ton of= precedent for this. With ViPR, you get: a.com -> b.com " [BA] This seems like the crux of the matter. Even if the costs are equal t= o the customer, a ViPR call could be more direct. If all that's being prov= ided is basic telephony minutes, it might not be very noticeable. But if t= here are services involved, you end up with a more evolvable infrastructure= . "SIP trunking would still get you cost savings to non-vipr connected domain= s and non-voip installations - all of the rest of the existing PSTN endpoin= ts. That'll continue to be useful for a really long time. ViPR + SIP trunking then further optimizes (and cost reduces) for the domai= ns that you can vipr federate with." [BA] Infrastructure ENUM potentially can count in its camp phone numbers fr= om the major consumer VOIP providers, as well as phone numbers provided by = major SIP trunking providers (who are also presumably utilizing infrastruct= ure ENUM). While that seems like an advantage, if the SIP trunking provider still char= ges on a per-minute basis, even for calls which may be carried entirely ove= r the Internet, then there will still be an incentive for a customer to dep= loy a direct alternative (ViPR, DUNDI, etc.) since that will allow calls ma= de entirely over the Internet to be made for free. Although we do see cell= ular operators throwing in "in-networking calling", this is a far cry from = throwing in intra-domain or "out of network" calls as well. This seems a l= ot less likely. --_000_F839FBA415E97B4DBD5BA437162E0603201E993ATK5EX14MBXW652w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jonathan Rosenberg said:

 

“Do you not= agree that the majority of voice connections are still being established to phone numbers today?”

 =

[BA] Sure.  = And I expect this will be the case for going forward too.  My question was m= ore about the application of ViPR to media *other* than voice.

 

“Firstly, ViPR is equally applicable to video, specifically for cases where video endpoints aren't 'special' - they are the same endpoint I use for my voip calling. When video is just a feature of my pstn-reachable voice device, Vi= PR works well.”

 

[BA] The question in my mind is whether video really is “special” (i= n the IM&P sense) or not.  That is, today we accept the idea that an= yone should be able to complete a phone call to anyone else.  We also accep= t this for SMS.  However, we don’t accept that idea for Instant Messaging (which typically requires being in the buddy list). Do we accept = that principle for video?  I’m not sure.  There are some inheren= t disadvantages to accepting video calls from anywhere even if we have a veri= fied phone number on the other end.  

 

So even if video is a feature of a voice device, it still might be sufficient to co= ntrol the ability to complete a video call via a “buddy list”.  = That’s essentially the model for XMPP-based federation with Jingle.  Not good enough to provide telephony as we think of it today.  But this does pr= ovide a degree of spam control while retaining something more akin to the RFC 326= 1 federation model (though perhaps with some loosening).  

 

“I believe there will be infrastructure enum, absolutely. However, I believe i= t will be used to create peering relationships amongst the carries which are similar to the ones that exist today - with small regional operators federa= ting with larger international ones, which then federate again off to more local ones. IP federation follows a similar model. These federation agreements ar= e likely in many cases to mirror the existing peering relationships on the PS= TN. This is because the peering agreements are likely to include actual RTP transport to, along with the CAC/QoS features that are the IP equivalents o= f what is done in the PSTN today.

 

That means, in turn, that a call from company A to company B would go as follows= :

 

a.com -> SP1 -> SP2 -> SP3 -> b.com

 

and, along the way, pass through the myriad of SBCs and SIP infrastructure in ea= ch of these providers:

 

a.com -> SP1-SBC-ingres -> SP1-SBC-egress -> SP2-SBC-ingress -> SP2-SBC-egress -> SP3-SBC-ingress -> SP3-SBC-egress -> b.com

 

That eliminates the trapezoidal model of SIP, which I still believe is essential= for feature transparency, feature velocity, and security, amongst many other re= asons. The feature velocity one is really important. The more that we have intermediaries in the path, the less likely (exponentially so, in fact) it = is that any kind of new feature will ever work. There is a ton of precedent fo= r this.

 

With ViPR, you get:

 

a.com -> b.com

 

”

 

[BA] This seems like the crux of the matter.  Even if the costs are equal t= o the customer, a ViPR call could be more direct.  If all that’s b= eing provided is basic telephony minutes, it might not be very noticeable.  = ;But if there are services involved, you end up with a more evolvable infrastructure.   

 

“SIP trunking would still get you cost savings to non-vipr connected domains and non-voip installations - all of the rest of the existing PSTN endpoints. That'll continue to be useful for a really long time.

 

ViPR + SIP trunking then further optimizes (and cost reduces) for the domains th= at you can vipr federate with.”

 

[BA] Infrastructure ENUM potentially can count in its camp phone numbers from th= e major consumer VOIP providers, as well as phone numbers provided by major S= IP trunking providers (who are also presumably utilizing infrastructure ENUM).=  

 

While that seems like an advantage, if the SIP trunking provider still charges on= a per-minute basis, even for calls which may be carried entirely over the Internet, then there will still be an incentive for a customer to deploy a = direct alternative (ViPR, DUNDI, etc.) since that will allow calls made entirely o= ver the Internet to be made for free.  Although we do see cellular operato= rs throwing in “in-networking calling”, this is a far cry from throwing in = intra-domain or “out of network” calls as well.  This seems a lot less likely. 

 

 

--_000_F839FBA415E97B4DBD5BA437162E0603201E993ATK5EX14MBXW652w_-- From bernard_aboba@hotmail.com Tue Nov 10 00:32:09 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778DB28C11A for ; Tue, 10 Nov 2009 00:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.975 X-Spam-Level: X-Spam-Status: No, score=-0.975 tagged_above=-999 required=5 tests=[AWL=1.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 XO0fvQXOP-VH for ; Tue, 10 Nov 2009 00:32:01 -0800 (PST) Received: from blu0-omc4-s6.blu0.hotmail.com (blu0-omc4-s6.blu0.hotmail.com [65.55.111.145]) by core3.amsl.com (Postfix) with ESMTP id 5844728C121 for ; Tue, 10 Nov 2009 00:31:55 -0800 (PST) Received: from BLU137-DS7 ([65.55.111.137]) by blu0-omc4-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 00:32:22 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 10 Nov 2009 00:32:30 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CB_01CA619D.4A0BD690" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acph4CDlLaLoX/4+Rs6gNCcqJ8WlowAAC5gQ Content-Language: en-us X-OriginalArrivalTime: 10 Nov 2009 08:32:22.0285 (UTC) FILETIME=[52C76BD0:01CA61E0] Subject: Re: [dispatch] Introducing ViPR: a new federation technology X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 08:32:09 -0000 ------=_NextPart_000_00CB_01CA619D.4A0BD690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jonathan Rosenberg said: "Do you not agree that the majority of voice connections are still being established to phone numbers today?" [BA] Sure. And I expect this will be the case for going forward too. My question was more about the application of ViPR to media *other* than voice. "Firstly, ViPR is equally applicable to video, specifically for cases where video endpoints aren't 'special' - they are the same endpoint I use for my voip calling. When video is just a feature of my pstn-reachable voice device, ViPR works well." [BA] The question in my mind is whether video really is "special" (in the IM&P sense) or not. That is, today we accept the idea that anyone should be able to complete a phone call to anyone else. We also accept this for SMS. However, we don't accept that idea for Instant Messaging (which typically requires being in the buddy list). Do we accept that principle for video? I'm not sure. There are some inherent disadvantages to accepting video calls from anywhere even if we have a verified phone number on the other end. So even if video is a feature of a voice device, it still might be sufficient to control the ability to complete a video call via a "buddy list". That's essentially the model for XMPP-based federation with Jingle. Not good enough to provide telephony as we think of it today. But this does provide a degree of spam control while retaining something more akin to the RFC 3261 federation model (though perhaps with some loosening). "I believe there will be infrastructure enum, absolutely. However, I believe it will be used to create peering relationships amongst the carries which are similar to the ones that exist today - with small regional operators federating with larger international ones, which then federate again off to more local ones. IP federation follows a similar model. These federation agreements are likely in many cases to mirror the existing peering relationships on the PSTN. This is because the peering agreements are likely to include actual RTP transport to, along with the CAC/QoS features that are the IP equivalents of what is done in the PSTN today. That means, in turn, that a call from company A to company B would go as follows: a.com -> SP1 -> SP2 -> SP3 -> b.com and, along the way, pass through the myriad of SBCs and SIP infrastructure in each of these providers: a.com -> SP1-SBC-ingres -> SP1-SBC-egress -> SP2-SBC-ingress -> SP2-SBC-egress -> SP3-SBC-ingress -> SP3-SBC-egress -> b.com That eliminates the trapezoidal model of SIP, which I still believe is essential for feature transparency, feature velocity, and security, amongst many other reasons. The feature velocity one is really important. The more that we have intermediaries in the path, the less likely (exponentially so, in fact) it is that any kind of new feature will ever work. There is a ton of precedent for this. With ViPR, you get: a.com -> b.com " [BA] This seems like the crux of the matter. Even if the costs are equal to the customer, a ViPR call could be more direct. If all that's being provided is basic telephony minutes, it might not be very noticeable. But if there are services involved, you end up with a more evolvable infrastructure. "SIP trunking would still get you cost savings to non-vipr connected domains and non-voip installations - all of the rest of the existing PSTN endpoints. That'll continue to be useful for a really long time. ViPR + SIP trunking then further optimizes (and cost reduces) for the domains that you can vipr federate with." [BA] Infrastructure ENUM potentially can count in its camp phone numbers from the major consumer VOIP providers, as well as phone numbers provided by major SIP trunking providers (who are also presumably utilizing infrastructure ENUM). While that seems like an advantage, if the SIP trunking provider still charges on a per-minute basis, even for calls which may be carried entirely over the Internet, then there will still be an incentive for a customer to deploy a direct alternative (ViPR, DUNDI, etc.) since that will allow calls made entirely over the Internet to be made for free. Although we do see cellular operators throwing in "in-networking calling", this is a far cry from throwing in intra-domain or "out of network" calls as well. This seems a lot less likely. ------=_NextPart_000_00CB_01CA619D.4A0BD690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jonathan Rosenberg said:

 

“Do you = not agree that the majority of voice connections are still being established to phone = numbers today?”

 

[BA] = Sure.  And I expect this will be the case for going forward too.  My question = was more about the application of ViPR to media *other* than voice. =

 

“Firstly, ViPR is equally applicable to video, specifically for cases where video endpoints aren't 'special' - they are the same endpoint I use for my = voip calling. When video is just a feature of my pstn-reachable voice device, = ViPR works well.”

 

[BA] The question in my mind is whether video really is “special” = (in the IM&P sense) or not.  That is, today we accept the idea that anyone = should be able to complete a phone call to anyone else.  We also accept this = for SMS.  However, we don’t accept that idea for Instant = Messaging (which typically requires being in the buddy list). Do we accept that principle = for video?  I’m not sure.  There are some inherent = disadvantages to accepting video calls from anywhere even if we have a verified phone = number on the other end.  

 

So even if video is a feature of a voice device, it still might be = sufficient to control the ability to complete a video call via a “buddy = list”.  That’s essentially the model for XMPP-based federation with Jingle.  Not = good enough to provide telephony as we think of it today.  But this does provide a degree of spam control while retaining something more akin to = the RFC 3261 federation model (though perhaps with some loosening). =  

 

“I believe there will be infrastructure enum, absolutely. However, I = believe it will be used to create peering relationships amongst the carries which = are similar to the ones that exist today - with small regional operators = federating with larger international ones, which then federate again off to more = local ones. IP federation follows a similar model. These federation agreements = are likely in many cases to mirror the existing peering relationships on the = PSTN. This is because the peering agreements are likely to include actual RTP transport to, along with the CAC/QoS features that are the IP = equivalents of what is done in the PSTN today.

 

That means, in turn, that a call from company A to company B would go as = follows:

 

a.com -> SP1 -> SP2 -> SP3 -> b.com

 

and, along the way, pass through the myriad of SBCs and SIP infrastructure in = each of these providers:

 

a.com -> SP1-SBC-ingres -> SP1-SBC-egress -> SP2-SBC-ingress -> SP2-SBC-egress -> SP3-SBC-ingress -> SP3-SBC-egress -> b.com =

 

That eliminates the trapezoidal model of SIP, which I still believe is = essential for feature transparency, feature velocity, and security, amongst many other reasons. The feature velocity one is really important. The more that we = have intermediaries in the path, the less likely (exponentially so, in fact) = it is that any kind of new feature will ever work. There is a ton of precedent = for this.

 

With ViPR, you get:

 

a.com -> b.com

 

”

 

[BA] This seems like the crux of the matter.  Even if the costs are = equal to the customer, a ViPR call could be more direct.  If all = that’s being provided is basic telephony minutes, it might not be very noticeable. =  But if there are services involved, you end up with a more evolvable infrastructure.   

 

“SIP trunking would still get you cost savings to non-vipr connected domains = and non-voip installations - all of the rest of the existing PSTN endpoints. That'll continue to be useful for a really long time.

 

ViPR + SIP trunking then further optimizes (and cost reduces) for the domains = that you can vipr federate with.”

 

[BA] Infrastructure ENUM potentially can count in its camp phone numbers from = the major consumer VOIP providers, as well as phone numbers provided by = major SIP trunking providers (who are also presumably utilizing infrastructure ENUM). 

 

While that seems like an advantage, if the SIP trunking provider still charges = on a per-minute basis, even for calls which may be carried entirely over the Internet, then there will still be an incentive for a customer to deploy = a direct alternative (ViPR, DUNDI, etc.) since that will allow calls made entirely over the Internet to be made for free.  Although we do see cellular operators throwing in “in-networking calling”, this = is a far cry from throwing in intra-domain or “out of network” calls as = well.  This seems a lot less likely. 

 

 

------=_NextPart_000_00CB_01CA619D.4A0BD690-- From BeckW@telekom.de Tue Nov 10 00:38:29 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B0F3A6A6C for ; Tue, 10 Nov 2009 00:38:29 -0800 (PST) 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 DcXISF5kWY8F for ; Tue, 10 Nov 2009 00:38:29 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 82AE73A6927 for ; Tue, 10 Nov 2009 00:38:28 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 10 Nov 2009 09:38:50 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 09:38:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 09:38:46 +0100 Message-ID: <4A956CE47D1066408D5C7EB34368A511054E1F5D@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4AF8FF46.3000604@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: Acphydapj5DwqK/QStyaLR/uQsxkcQAERN6w References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> <4AF 8AE73.4050405@cisco.com> <4AF8CA10.9010502@nostrum.com> <4AF 8FF46.30 00604@nostrum.com> From: To: , X-OriginalArrivalTime: 10 Nov 2009 08:38:50.0333 (UTC) FILETIME=[3A12D8D0:01CA61E1] Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, R.Jesske@telekom.de Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 08:38:29 -0000 Adam wrote: > My point is that increasing the amount of ISUP information that we=20 > include in SIP message headers is going down a slippery slope, the=20 > ultimate conclusion of which is including SIP header fields for every=20 > ISUP parameter. This is a valid point, but the proposed alternative has severe problems. If the reason header is the only piece of ISUP information we need, carrying the whole ISUP message is not really elegant. SIP application servers (AS) would have to implement ISUP parsing just to check a simple value. The content of a Reason header could be checked and used by any plain AS. Do we really want to perpetuate ISUP code in SIP networks? > We have a means for sending ISUP fields transparently through a SIP=20 > network (RFC 3398). I think it's folly to revisit that set of decisions=20 > simply because someone wants a less-general point solution. We were talking about scenarios where the PSTN gateway does not know whether a call will be terminated by a different PSTN gateway, or by a SIP user agent. So the originating gateway would have to encapsulate ISUP in SIP, and SIP user agents would receive it. This would violate regulatory requirements in various countries. As S/MIME is not feasible, we would have to introduce yet another B2BUA just to filter ISUP from SIP messages for end user devices. Wolfgang=20 From john.elwell@siemens-enterprise.com Tue Nov 10 00:49:53 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440FD28C12F for ; Tue, 10 Nov 2009 00:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi07+SqZ5ynB for ; Tue, 10 Nov 2009 00:49:52 -0800 (PST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id F395028C11A for ; Tue, 10 Nov 2009 00:49:51 -0800 (PST) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nAA8oFxO021350; Tue, 10 Nov 2009 09:50:15 +0100 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nAA8oEEh002038; Tue, 10 Nov 2009 09:50:14 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.110]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Tue, 10 Nov 2009 09:50:14 +0100 From: "Elwell, John" To: "BeckW@telekom.de" , "adam@nostrum.com" , "christer.holmberg@ericsson.com" Date: Tue, 10 Nov 2009 09:50:12 +0100 Thread-Topic: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: Acphydapj5DwqK/QStyaLR/uQsxkcQAERN6wAAHqfjA= Message-ID: <7402509E63C5A145A6095D46C179A5B70725DA3718@DEMCHP99E35MSX.ww902.siemens.net> References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> <4AF 8AE73.4050405@cisco.com> <4AF8CA10.9010502@nostrum.com> <4AF 8FF46.30 00604@nostrum.com> <4A956CE47D1066408D5C7EB34368A511054E1F5D@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4A956CE47D1066408D5C7EB34368A511054E1F5D@S4DE8PSAAQC.mitte.t-com.de> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , "gonzalo.camarillo@ericsson.com" , "R.Jesske@telekom.de" Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 08:49:53 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of BeckW@telekom.de > Sent: 10 November 2009 08:39 > To: adam@nostrum.com; christer.holmberg@ericsson.com > Cc: dispatch@ietf.org; gonzalo.camarillo@ericsson.com;=20 > R.Jesske@telekom.de > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 >=20 >=20 > Adam wrote: > > My point is that increasing the amount of ISUP information that we=20 > > include in SIP message headers is going down a slippery slope, the=20 > > ultimate conclusion of which is including SIP header fields=20 > for every=20 > > ISUP parameter. > This is a valid point, but the proposed alternative has=20 > severe problems. > If the reason header is the only piece of ISUP information we need, > carrying the whole ISUP message is not really elegant. SIP application > servers (AS) would have to implement ISUP parsing just to=20 > check a simple > value. The content of a Reason header could be checked and used by any > plain AS. Do we really want to perpetuate ISUP code in SIP networks? >=20 > > We have a means for sending ISUP fields transparently through a SIP=20 > > network (RFC 3398). I think it's folly to revisit that set of > decisions=20 > > simply because someone wants a less-general point solution. > We were talking about scenarios where the PSTN gateway does not know > whether a call will be terminated by a different PSTN gateway, or by a > SIP user agent. So the originating gateway would have to encapsulate > ISUP in SIP, and SIP user agents would receive it. This would violate > regulatory requirements in various countries. As S/MIME is=20 > not feasible, > we would have to introduce yet another B2BUA just to filter ISUP from > SIP messages for end user devices. [JRE] SIP UAs would receive the Reason header field too, unless the last pr= oxy/B2BUA strips it out. The only difference is that a body part can only b= e stripped by a B2BUA, not by a proxy. Do you need a solution that will wor= k with proxies? John From R.Jesske@telekom.de Tue Nov 10 00:53:57 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3637D28C11A for ; Tue, 10 Nov 2009 00:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.325, 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 n51nXEaP+8sv for ; Tue, 10 Nov 2009 00:53:56 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 4B74628C148 for ; Tue, 10 Nov 2009 00:53:55 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 10 Nov 2009 09:54:14 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 09:54:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 09:54:12 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD4053724C3@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <4AF8CA10.9010502@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcphqhrvWiUaEDuZT/eUY2FOzy3KqAAOFa/w References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> <4AF 8AE73.40 50405@cisco.com> <4AF8CA10.9010502@nostrum.com> From: To: , X-OriginalArrivalTime: 10 Nov 2009 08:54:14.0543 (UTC) FILETIME=[60F219F0:01CA61E3] Cc: dispatch@ietf.org, audet@nortel.com, gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 08:53:57 -0000 My intension is to avoid your shown ABNF for new INVITE header fields. Instead we want to use the ABNF defined within RFC3326 as follows: Reason =3D "Reason" HCOLON reason-value *(COMMA = reason-value) reason-value =3D protocol *(SEMI reason-params) protocol =3D "SIP" / "Q.850" / token reason-params =3D protocol-cause / reason-text / reason-extension protocol-cause =3D "cause" EQUAL cause cause =3D 1*DIGIT reason-text =3D "text" EQUAL quoted-string reason-extension =3D generic-param The only one missing is to allow this header within Responses. =20 -----Urspr=FCngliche Nachricht----- Von: Adam Roach [mailto:adam@nostrum.com]=20 Gesendet: Dienstag, 10. November 2009 03:04 An: Christer Holmberg Cc: Paul Kyzivat; Jesske, Roland; audet@nortel.com; dispatch@ietf.org; = Gonzalo Camarillo Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 To clarify the point I was trying to make in the meeting today -- if=20 we've decided to go down this path, I'll save you the trouble of=20 creating the new ABNF for the new INVITE header fields. Here's what they = look like: Nature-Of-Connection-Indicators =3D = "Nature-Of-Connection-Indicators" HCOLON quoted-string Forward-Call-Indicators =3D "Forward-Call-Indicators" HCOLON quoted-string Calling-Party's-Category =3D "Calling-Party's-Category" HCOLON quoted-string Transmission-Medium-Requirement =3D = "Transmission-Medium-Requirement" HCOLON quoted-string Called-Party-Number =3D "Called-Party-Number" HCOLON quoted-string Transit-Network-Selection =3D "Transit-Network-Selection" HCOLON quoted-string Call-Reference =3D "Call-Reference" HCOLON quoted-string Calling-Party-Number =3D "Calling-Party-Number" HCOLON quoted-string Optional-Forward-Call-Indicators =3D=20 "Optional-Forward-Call-Indicators" HCOLON quoted-string Redirecting-Number =3D "Redirecting-Number" HCOLON quoted-string Redirection-Information =3D "Redirection-Information" HCOLON quoted-string Closed-User-Group-Interlock-Code =3D=20 "Closed-User-Group-Interlock-Code" HCOLON quoted-string Connection-Request =3D "Connection-Request" HCOLON quoted-string Original-Called-Number =3D "Original-Called-Number" HCOLON quoted-string User-to-user-Information =3D "User-to-user-Information" HCOLON quoted-string Access-Transport =3D "Access-Transport" HCOLON quoted-string User-Service-Information =3D "User-Service-Information" HCOLON quoted-string User-to-user-Indicators =3D "User-to-user-Indicators" HCOLON quoted-string Generic-Number =3D "Generic-Number" HCOLON quoted-string Propagation-Delay-Counter =3D "Propagation-Delay-Counter" HCOLON quoted-string User-Service-Information-Prime =3D = "User-Service-Information-Prime" HCOLON quoted-string Network-Specific-Facility =3D "Network-Specific-Facility" HCOLON quoted-string Generic-Digits =3D "Generic-Digits" HCOLON quoted-string Origination-ISC-Point-Code =3D = "Origination-ISC-Point-Code" HCOLON quoted-string User-Teleservice-Information =3D = "User-Teleservice-Information" HCOLON quoted-string Remote-Operations =3D "Remote-Operations" HCOLON quoted-string Parameter-Compatibility-Information =3D=20 "Parameter-Compatibility-Information" HCOLON quoted-string Generic-Notification-Indicator =3D = "Generic-Notification-Indicator" HCOLON quoted-string Service-Activation =3D "Service-Activation" HCOLON quoted-string Generic-Reference =3D "Generic-Reference" HCOLON quoted-string MLPP-Precedence =3D "MLPP-Precedence" HCOLON quoted-string Transmission-Medium-Requirement-Prime =3D=20 "Transmission-Medium-Requirement-Prime" HCOLON quoted-string Location-Number =3D "Location-Number" HCOLON quoted-string Forward-GVNS =3D "Forward-GVNS" HCOLON quoted-string CCSS =3D "CCSS" HCOLON quoted-string Network-Management-Controls =3D = "Network-Management-Controls" HCOLON quoted-string Circuit-Assignment-Map =3D "Circuit-Assignment-Map" HCOLON quoted-string Correlation-Id =3D "Correlation-Id" HCOLON quoted-string Call-Diversion-Treatment-Indicators =3D=20 "Call-Diversion-Treatment-Indicators" HCOLON quoted-string Called-IN-Number =3D "Called-IN-Number" HCOLON quoted-string Call-Offering-Treatment-Indicators =3D=20 "Call-Offering-Treatment-Indicators" HCOLON quoted-string Conference-Treatment-Indicators =3D = "Conference-Treatment-Indicators" HCOLON quoted-string SCF-Id =3D "SCF-Id" HCOLON quoted-string UID-Capability-Indicators =3D "UID-Capability-Indicators" HCOLON quoted-string Echo-Control-Information =3D "Echo-Control-Information" HCOLON quoted-string Hop-Counter =3D "Hop-Counter" HCOLON quoted-string Collect-Call-Request =3D "Collect-Call-Request" HCOLON quoted-string Application-Transport-Parameter =3D = "Application-Transport-Parameter" HCOLON quoted-string Pivot-Capability =3D "Pivot-Capability" HCOLON quoted-string Called-Directory-Number =3D "Called-Directory-Number" HCOLON quoted-string Original-Called-IN-Number =3D "Original-Called-IN-Number" HCOLON quoted-string Calling-Geodetic-Location =3D "Calling-Geodetic-Location" HCOLON quoted-string Network-Routing-Number =3D "Network-Routing-Number" HCOLON quoted-string QoR-Capability =3D "QoR-Capability" HCOLON quoted-string Pivot-Counter =3D "Pivot-Counter" HCOLON quoted-string Pivot-Routing-Forward-Information =3D=20 "Pivot-Routing-Forward-Information" HCOLON quoted-string Redirect-Capability =3D "Redirect-Capability" HCOLON quoted-string Redirect-Counter =3D "Redirect-Counter" HCOLON quoted-string Redirect-Status =3D "Redirect-Status" HCOLON quoted-string Redirect-Forward-Information =3D = "Redirect-Forward-Information" HCOLON quoted-string Number-Portability-Forward-Information =3D =20 "Number-Portability-Forward-Information" HCOLON quoted-string Perhaps we can refine some the the quoted strings with tokens, but I=20 think this is a good start. /a From john.elwell@siemens-enterprise.com Tue Nov 10 01:07:03 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05373A6A10 for ; Tue, 10 Nov 2009 01:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.094 X-Spam-Level: X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYMkvuiqPx7U for ; Tue, 10 Nov 2009 01:07:02 -0800 (PST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id 6E7873A68B9 for ; Tue, 10 Nov 2009 01:07:02 -0800 (PST) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nAA97OGO004014; Tue, 10 Nov 2009 10:07:25 +0100 Received: from DEMCHP99ET0MSX.ww902.siemens.net (demchp99et0msx.ww902.siemens.net [139.25.131.181]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nAA97OTv020182; Tue, 10 Nov 2009 10:07:24 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.110]) by DEMCHP99ET0MSX.ww902.siemens.net ([139.25.131.181]) with mapi; Tue, 10 Nov 2009 10:07:23 +0100 From: "Elwell, John" To: DISPATCH Date: Tue, 10 Nov 2009 10:07:21 +0100 Thread-Topic: SIP Forum UA config work - status update Thread-Index: Acph5TY450RiZILcSaOPA1uqinoNYA== Message-ID: <7402509E63C5A145A6095D46C179A5B70725DA372D@DEMCHP99E35MSX.ww902.siemens.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Eric Burger , Marc Robins Subject: [dispatch] SIP Forum UA config work - status update X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 09:07:03 -0000 The SIP Forum work on UA config is nearing completion and "last call" of th= e specification is expected to start in a couple of weeks. The latest draft= (v17) is available here: http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,3= 61/Itemid,261/ There is an accompanying presentation that Scott Lawrence put together and = presented at SIPit to an interested audience. This is available here: http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,3= 21/Itemid,261/ Note that the specification has changed considerably since we last presente= d to DISPATCH. We were hoping to find a room to present the work to interested IETF folks,= but we failed to do so. However, I would be prepared to talk it through in= formally to anybody interested. We can meet at 08.00 Friday at IETF registr= ation. Let me know if interested, and also bring your own downloaded copy o= f the presentation, since there won't be a projector. John= From thomas.belling@nsn.com Tue Nov 10 04:14:14 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38BA83A6A94 for ; Tue, 10 Nov 2009 04:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brNEFlD-7rEI for ; Tue, 10 Nov 2009 04:14:11 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 0E8043A683C for ; Tue, 10 Nov 2009 04:14:09 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nAACEVJY002388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Nov 2009 13:14:31 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nAACEVcn007114; Tue, 10 Nov 2009 13:14:31 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 13:14:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 13:14:26 +0100 Message-ID: <744A66DF31B5B34EA8B08BBD8187A722C1B3B2@DEMUEXC014.nsn-intra.net> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4053724C3@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcphqhrvWiUaEDuZT/eUY2FOzy3KqAAOFa/wAAcZmEA= References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> <4AF8AE73.40 50405@cisco.com><4AF8CA10.9010502@nostrum.com> <988! 6E5FCA6D7 6549A3011068483A4BD4053724C3@S4DE8PSAAQB.mitte.t-com.de> From: "Belling, Thomas (NSN - DE/Munich)" To: , , X-OriginalArrivalTime: 10 Nov 2009 12:14:29.0773 (UTC) FILETIME=[5A94B3D0:01CA61FF] Cc: audet@nortel.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 12:14:14 -0000 I am bit surprised that the principle of the reason haeder in general = and reason headers in requests are discussed. I thought this has been = agreeed in RFC 3326. In my understnding the intention of the draft is to allow reason headers = in responses. Thomas B ----------------------------------=20 Dr. Thomas Belling=20 3GPP Standardisation Nokia Siemens Networks=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext R.Jesske@telekom.de Sent: Tuesday, November 10, 2009 4:54 PM To: adam@nostrum.com; christer.holmberg@ericsson.com Cc: dispatch@ietf.org; audet@nortel.com; gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 My intension is to avoid your shown ABNF for new INVITE header fields. Instead we want to use the ABNF defined within RFC3326 as follows: Reason =3D "Reason" HCOLON reason-value *(COMMA = reason-value) reason-value =3D protocol *(SEMI reason-params) protocol =3D "SIP" / "Q.850" / token reason-params =3D protocol-cause / reason-text / reason-extension protocol-cause =3D "cause" EQUAL cause cause =3D 1*DIGIT reason-text =3D "text" EQUAL quoted-string reason-extension =3D generic-param The only one missing is to allow this header within Responses. =20 -----Urspr=FCngliche Nachricht----- Von: Adam Roach [mailto:adam@nostrum.com] Gesendet: Dienstag, 10. November 2009 03:04 An: Christer Holmberg Cc: Paul Kyzivat; Jesske, Roland; audet@nortel.com; dispatch@ietf.org; = Gonzalo Camarillo Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 To clarify the point I was trying to make in the meeting today -- if = we've decided to go down this path, I'll save you the trouble of = creating the new ABNF for the new INVITE header fields. Here's what they = look like: Nature-Of-Connection-Indicators =3D = "Nature-Of-Connection-Indicators" HCOLON quoted-string Forward-Call-Indicators =3D "Forward-Call-Indicators" HCOLON quoted-string Calling-Party's-Category =3D "Calling-Party's-Category" HCOLON quoted-string Transmission-Medium-Requirement =3D = "Transmission-Medium-Requirement" HCOLON quoted-string Called-Party-Number =3D "Called-Party-Number" HCOLON quoted-string Transit-Network-Selection =3D "Transit-Network-Selection" HCOLON quoted-string Call-Reference =3D "Call-Reference" HCOLON quoted-string Calling-Party-Number =3D "Calling-Party-Number" HCOLON quoted-string Optional-Forward-Call-Indicators =3D=20 "Optional-Forward-Call-Indicators" HCOLON quoted-string Redirecting-Number =3D "Redirecting-Number" HCOLON quoted-string Redirection-Information =3D "Redirection-Information" HCOLON quoted-string Closed-User-Group-Interlock-Code =3D=20 "Closed-User-Group-Interlock-Code" HCOLON quoted-string Connection-Request =3D "Connection-Request" HCOLON quoted-string Original-Called-Number =3D "Original-Called-Number" HCOLON quoted-string User-to-user-Information =3D "User-to-user-Information" HCOLON quoted-string Access-Transport =3D "Access-Transport" HCOLON quoted-string User-Service-Information =3D "User-Service-Information" HCOLON quoted-string User-to-user-Indicators =3D "User-to-user-Indicators" HCOLON quoted-string Generic-Number =3D "Generic-Number" HCOLON quoted-string Propagation-Delay-Counter =3D "Propagation-Delay-Counter" HCOLON quoted-string User-Service-Information-Prime =3D = "User-Service-Information-Prime" HCOLON quoted-string Network-Specific-Facility =3D "Network-Specific-Facility" HCOLON quoted-string Generic-Digits =3D "Generic-Digits" HCOLON quoted-string Origination-ISC-Point-Code =3D = "Origination-ISC-Point-Code" HCOLON quoted-string User-Teleservice-Information =3D = "User-Teleservice-Information" HCOLON quoted-string Remote-Operations =3D "Remote-Operations" HCOLON quoted-string Parameter-Compatibility-Information =3D=20 "Parameter-Compatibility-Information" HCOLON quoted-string Generic-Notification-Indicator =3D = "Generic-Notification-Indicator" HCOLON quoted-string Service-Activation =3D "Service-Activation" HCOLON quoted-string Generic-Reference =3D "Generic-Reference" HCOLON quoted-string MLPP-Precedence =3D "MLPP-Precedence" HCOLON quoted-string Transmission-Medium-Requirement-Prime =3D=20 "Transmission-Medium-Requirement-Prime" HCOLON quoted-string Location-Number =3D "Location-Number" HCOLON quoted-string Forward-GVNS =3D "Forward-GVNS" HCOLON quoted-string CCSS =3D "CCSS" HCOLON quoted-string Network-Management-Controls =3D = "Network-Management-Controls" HCOLON quoted-string Circuit-Assignment-Map =3D "Circuit-Assignment-Map" HCOLON quoted-string Correlation-Id =3D "Correlation-Id" HCOLON quoted-string Call-Diversion-Treatment-Indicators =3D=20 "Call-Diversion-Treatment-Indicators" HCOLON quoted-string Called-IN-Number =3D "Called-IN-Number" HCOLON quoted-string Call-Offering-Treatment-Indicators =3D=20 "Call-Offering-Treatment-Indicators" HCOLON quoted-string Conference-Treatment-Indicators =3D = "Conference-Treatment-Indicators" HCOLON quoted-string SCF-Id =3D "SCF-Id" HCOLON quoted-string UID-Capability-Indicators =3D "UID-Capability-Indicators" HCOLON quoted-string Echo-Control-Information =3D "Echo-Control-Information" HCOLON quoted-string Hop-Counter =3D "Hop-Counter" HCOLON quoted-string Collect-Call-Request =3D "Collect-Call-Request" HCOLON quoted-string Application-Transport-Parameter =3D = "Application-Transport-Parameter" HCOLON quoted-string Pivot-Capability =3D "Pivot-Capability" HCOLON quoted-string Called-Directory-Number =3D "Called-Directory-Number" HCOLON quoted-string Original-Called-IN-Number =3D "Original-Called-IN-Number" HCOLON quoted-string Calling-Geodetic-Location =3D "Calling-Geodetic-Location" HCOLON quoted-string Network-Routing-Number =3D "Network-Routing-Number" HCOLON quoted-string QoR-Capability =3D "QoR-Capability" HCOLON quoted-string Pivot-Counter =3D "Pivot-Counter" HCOLON quoted-string Pivot-Routing-Forward-Information =3D=20 "Pivot-Routing-Forward-Information" HCOLON quoted-string Redirect-Capability =3D "Redirect-Capability" HCOLON quoted-string Redirect-Counter =3D "Redirect-Counter" HCOLON quoted-string Redirect-Status =3D "Redirect-Status" HCOLON quoted-string Redirect-Forward-Information =3D = "Redirect-Forward-Information" HCOLON quoted-string Number-Portability-Forward-Information =3D =20 "Number-Portability-Forward-Information" HCOLON quoted-string Perhaps we can refine some the the quoted strings with tokens, but I = think this is a good start. /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From klaus.mailinglists@pernau.at Tue Nov 10 06:51:10 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D6D28C1C2 for ; Tue, 10 Nov 2009 06:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.182 X-Spam-Level: X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GZnJuPOPMQx for ; Tue, 10 Nov 2009 06:51:09 -0800 (PST) Received: from ds3000.pernau.at (ds3000.pernau.at [88.198.53.113]) by core3.amsl.com (Postfix) with ESMTP id 0BF533A6AC1 for ; Tue, 10 Nov 2009 06:51:08 -0800 (PST) Received: from [10.10.0.51] (nat.labs.nic.at [83.136.33.3]) by ds3000.pernau.at (Postfix) with ESMTP id 348B610805D6; Tue, 10 Nov 2009 15:51:35 +0100 (CET) Message-ID: <4AF97DF7.40002@pernau.at> Date: Tue, 10 Nov 2009 15:51:35 +0100 From: Klaus Darilion User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Shockey References: <4AF7C825.2060008@jdrosen.net> <004401ca615e$e77cdb20$b6769160$@us> In-Reply-To: <004401ca615e$e77cdb20$b6769160$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Introducing ViPR: a new federation technology X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:51:10 -0000 Richard Shockey schrieb: > OK Asterisk DUNDi on steroids. > > Useful for enterprise to enterprise supply chain federations, since TRIP was > never going to work there, but to a SIP service provider it provides no real > value. I guess it depends on the provider's business model. If the provider wants to receive termination fees for incoming calls, then he wont use ViPR. If the provider does not care about termination fees, then he can allow incoming calls with ViPR, e.g. to save gateway resource. Anyway, it can use ViPR on outgoing calls to avoid transit costs. regards Klaus > Did I miss something? > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Jonathan Rosenberg >> Sent: Monday, November 09, 2009 2:44 AM >> To: dispatch@ietf.org >> Subject: [dispatch] Introducing ViPR: a new federation technology >> >> Folks, >> >> As you are all well aware, SIP has been very successful in the >> marketplace as a tool for voice and video within a single domain. Its >> success for inter-domain federation has been more limited, and it has >> seen almost no deployment over the public Internet for any-to-any >> federation, even though this was the model originally envisaged for >> SIP, >> and a model I still believe in. >> >> This is something that needed to be fixed, and I have fixed it. >> >> Today, Cullen and I submitted documents describing a new technology >> called ViPR. ViPR is a new federation technique which will finally >> enable the any-to-any SIP federation that we have always wanted for >> SIP. >> It solves several hard problems that have prevented widespread >> federation. In particular, it solves the phone number routing problem, >> providing a non-centralized technique that securely maps phone numbers >> to domains. It also provides a built-in solution for the VoIP anti- >> spam >> problem - a new one that is specific to VoIP. As such, it enables >> worldwide, scalable, any-to-any federation over the public Internet, >> securely, for phone numbers, and in a way that supports incremental >> deployability. >> >> This technology is not just documents - it is working code, and was >> announced by Cisco today as part of their products shipping early next >> year. >> >> I'm extremely excited about ViPR, and I think others will be too. >> >> The documents are: >> >> >> http://www.ietf.org/id/draft-rosenberg-dispatch-vipr-overview-01.txt >> http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-vap- >> 00.txt >> http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-pvp- >> 00.txt >> http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-sip- >> antispam-00.txt >> http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr- >> reload-usage-00.txt >> >> >> Thanks, >> Jonathan Rosenberg >> jdrosen@jdrosen.net >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > From klaus.mailinglists@pernau.at Tue Nov 10 07:02:26 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C363A689F for ; Tue, 10 Nov 2009 07:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRfFVHJeA37R for ; Tue, 10 Nov 2009 07:02:26 -0800 (PST) Received: from ds3000.pernau.at (ds3000.pernau.at [88.198.53.113]) by core3.amsl.com (Postfix) with ESMTP id E41723A67F1 for ; Tue, 10 Nov 2009 07:02:25 -0800 (PST) Received: from [10.10.0.51] (nat.labs.nic.at [83.136.33.3]) by ds3000.pernau.at (Postfix) with ESMTP id 3B98610805D6; Tue, 10 Nov 2009 16:02:52 +0100 (CET) Message-ID: <4AF9809C.1040004@pernau.at> Date: Tue, 10 Nov 2009 16:02:52 +0100 From: Klaus Darilion User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Introducing ViPR: a new federation technology X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 15:02:26 -0000 Bernard Aboba schrieb: > Also, if one buys the arguments, then one could conclude that all that is > necessary for VOIP bypass is a PRI and an Internet connection. Why bother > with SIP trunking? However, that argument assumes that as the decline in the It is not about PRI vs. SIP trunking, but about PSTN connectivity vs. adhoc SIP peering. The trust is based on a phone call that happened on the PSTN (PSTN means telcos/carriers with interconnect and customers connected to those telcos). It does not matter which technology the telcos use for interconnection or for connections of its customers. E.g. an enterprise which already uses a SIP trunk to a SIP service provider is also connected to the PSTN. That mean for routes which are not routable with ViPR the SIP trunk as used as the SIP trunk is part of the PSTN. regards klaus > PSTN accelerates that SIP Trunking providers will utilize infrastructure > ENUM to their advantage to route calls directly over the Internet without > passing on the savings to customers. > > However, the evolution of Internet peering would indicate this not the most > likely outcome. Back in the mid-1990s, peering was a significant issue for > second Tier ISPs and access cost much more than it does today. Today recent > measurements show that 50 percent of Internet traffic is originating in only > 150 ASes, and that kind of consolidation also tends to go along with major > declines in consumer costs and an lessening of importance of peering > concerns. > > So my own guess is that as SIP trunking becomes a commodity that the > industry will grow more and more competitive and that in a decade > infrastructure ENUM will apply to a very large fraction of all calls, with > the benefits being passed on to customers. > > In that kind of scenario, ViPR would be unnecessary. > > From victor.pascual.avila@gmail.com Tue Nov 10 08:55:54 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06683A6B14 for ; Tue, 10 Nov 2009 08:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 8bmYXl4-wcyf for ; Tue, 10 Nov 2009 08:55:53 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 9AE943A6B0E for ; Tue, 10 Nov 2009 08:55:53 -0800 (PST) Received: by fxm7 with SMTP id 7so225964fxm.29 for ; Tue, 10 Nov 2009 08:56:17 -0800 (PST) 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:content-type :content-transfer-encoding; bh=R5lMzPGdltHNxZRyKrsZvNXQoUN8FMGtx4X7U7lMs94=; b=F1A5j3r78he3JO8+W8LGbQk8y/OC9yUgzwvhh3BdoEfDcos/ObKUIuLaayHtS9t/rW xxN/2t5hb6rpcgh/I5bwD+6oUGEdMblhHxPqUXe0vdd3uWzoNUg2bnjjVP22a0MMycGM EcPWca4V990YVBNgI3/l0HumeZQVri1gdtgK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=DzCSJEEUgusSpNyaD/Xf8HVnVGrZD21YKw2cmseQ7kVls0eoo7x8JDNMr/lYpUnFMq gBpxKcnLiivgGmVj2SHUFD+G0KKhKECH5PfuNSWf4GKb7I70s9bGVHuzAO/UTfUC+7mY jUleP4tySWyTvbz9kdbxen6rP52wCCmkLKThs= MIME-Version: 1.0 Received: by 10.204.150.77 with SMTP id x13mr327831bkv.100.1257872177267; Tue, 10 Nov 2009 08:56:17 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Nov 2009 17:56:17 +0100 Message-ID: <618e24240911100856y4582c723pfb450144c9e2ea4@mail.gmail.com> From: Victor Pascual Avila To: dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 16:55:54 -0000 As a very brief summary: - Unanimous Agreement that we do have a problem to be solved - Next step is to work the requirements until we have better agreement - Several folks indicated interest and willingness to be involved in ongoing work Cheers, -Victor On Mon, Nov 9, 2009 at 11:21 PM, Mary Barnes wrote= : > > Hi all, > > I have uploaded Jim McEachern's notes from the Identity Adhoc yesterday: > http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/Identity-AdHoc-N= otes-jmce.doc > > Regards, > Mary. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --=20 Victor Pascual =C3=81vila From pkyzivat@cisco.com Tue Nov 10 12:52:01 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1853A6900 for ; Tue, 10 Nov 2009 12:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.295 X-Spam-Level: X-Spam-Status: No, score=-8.295 tagged_above=-999 required=5 tests=[AWL=1.704, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjbnuGZsyijD for ; Tue, 10 Nov 2009 12:52:00 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DF5703A68ED for ; Tue, 10 Nov 2009 12:51:59 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArACAMFh+UpAZnwMgWdsb2JhbACcBgEBFiSqPZg7hD4E X-IronPort-AV: E=Sophos;i="4.44,718,1249257600"; d="scan'208";a="54102678" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 20:52:25 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAAKqPPE001850; Tue, 10 Nov 2009 20:52:25 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 15:52:25 -0500 Received: from [161.44.182.192] ([161.44.182.192]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 15:52:25 -0500 Message-ID: <4AF9D289.2000603@cisco.com> Date: Tue, 10 Nov 2009 15:52:25 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 10 Nov 2009 20:52:25.0151 (UTC) FILETIME=[B4F314F0:01CA6247] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Introducing ViPR: a new federation technology - VIDEO X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:52:01 -0000 Bernard Aboba wrote: > [BA] The question in my mind is whether video really is “special” (in > the IM&P sense) or not. That is, today we accept the idea that anyone > should be able to complete a phone call to anyone else. We also accept > this for SMS. However, we don’t accept that idea for Instant Messaging > (which typically requires being in the buddy list). Do we accept that > principle for video? I’m not sure. There are some inherent > disadvantages to accepting video calls from anywhere even if we have a > verified phone number on the other end. I don't think this has much of anything to do with buddy lists. Even when my mother calls, whether I want to transmit video will vary depending on current state. (Am I dressed, is there anything/anybody in sight that I don't want her to see, ...) There are mechanisms and conventions yet to be developed around this. There has been little motivation to do it so far because there has not been use cases that demand it. It seems very likely to me that a simple answer is that a video phone will typically *answer* in video recvonly mode, and require some manual intervention to start transmitting. And when initiating a call from a video phone there of course must also be options as to whether to transmit by default. Other more sophisticated features can evolve. But I think they are all compatible with a "call anybody" model. It may however put more of a premium on accurate callerid and calleeid information. Thanks, Paul From BeckW@telekom.de Tue Nov 10 17:04:58 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F8B3A68B3 for ; Tue, 10 Nov 2009 17:04:58 -0800 (PST) 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 rL59GUwBuEbL for ; Tue, 10 Nov 2009 17:04:58 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 914093A689C for ; Tue, 10 Nov 2009 17:04:57 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 11 Nov 2009 02:05:19 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 02:05:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 02:05:15 +0100 Message-ID: <4A956CE47D1066408D5C7EB34368A5110551F72B@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4AF8FD21.7040704@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04; why encapsulation is problematic Thread-Index: AcphyIq0+NyXb+yPQGq2bN/U5nQwqwAn/M9A References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de> <4AF8AE73.40 50405@cisco.com> <4AF8CA10.9010502@nostrum.com> <4A956CE47D1066408D5C7EB34368A511054E1D35@S4DE8PSAAQC.mitte.t-com.de> <4 AF8FD21. 7040704@nostrum.com> From: To: X-OriginalArrivalTime: 11 Nov 2009 01:05:18.0924 (UTC) FILETIME=[093918C0:01CA626B] Cc: audet@nortel.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com, R.Jesske@telekom.de Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04; why encapsulation is problematic X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:04:58 -0000 Adam wrote: > S/MIME for a general purpose network suffers from the classical key=20 > distribution problem. It's not used for the same reason encrypted email=20 > is not used (except among the geek community). >=20 > But you're not talking about general purpose networks. > You're talking about tightly constrained networks with PSTN gateways=20 > that are either all within a single administrative domain, or that=20 > communicate with each other through bilateral agreements. In these=20 > circumstances, key distribution is no more difficult a problem than IP > address assignment. It's a simple matter of configuration. In theory, S/MIME should be doable in an administrative domain. It's the lack of implementations that troubles me.=20 =20 Adam wrote: > B2BUAs will break whatever they break. Until someone sits down and=20 > documents their behavior, we can't really do too much to work around=20 > their behavior. It's the same problem we're having all over the place=20 > (identity, MSRP ACM, etc). There's no point in talking about something > as nebulous as B2BUA behavior. Sure. I was referring to an argument made (not by Adam) in the meeting.=20 Adam wrote: > While many UAs won't be able to ignore the multitype body (aside: this > is sad -- email clients all can), you'd be hard pressed to find one that=20 > can't understand multipart that also won't respond to a multipart body > in a request with a 415. Right, but connection setup times are already a concern now, without the extra transaction to reject multipart content. Adam wrote: > At one point, you said "IMS." I don't think you'll find an IMS client=20 > that has any hope of receiving a UDP SIP message -- show me an INVITE on=20 > the terminating side of an IMS network that is somehow smaller than 1500=20 > bytes, and I'll be shocked into silence. TCP is a foregone conclusion. The universal deployment of IMS may take some time. Until that glorious day, we may have networks that would profit from the Reason header and don't have big SIP messages.=20 Wolfgang From thomas.belling@nsn.com Tue Nov 10 23:52:01 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD0C3A6882 for ; Tue, 10 Nov 2009 23:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF8jmrXfjrVD for ; Tue, 10 Nov 2009 23:52:01 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 458C23A67B0 for ; Tue, 10 Nov 2009 23:51:57 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nAB7qIrf028897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2009 08:52:18 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nAB7qC2B028237; Wed, 11 Nov 2009 08:52:17 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 08:52:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 08:50:36 +0100 Message-ID: <744A66DF31B5B34EA8B08BBD8187A722C6423E@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: Acphmai1yr71k3mYSOWqng/P+/xffwAAF7NAAEH0pVA= References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de><4AF! 8AE73.40 50405@cisco .com> From: "Belling, Thomas (NSN - DE/Munich)" To: , X-OriginalArrivalTime: 11 Nov 2009 07:52:17.0142 (UTC) FILETIME=[E39D7960:01CA62A3] Cc: "ext Calme, James A \(Jim\)" , Paul While Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 07:52:02 -0000 Dear Roland, we discussed the interworking of ISUP ACM and CPG causes to SIP reasons = headers in provisional responses in 3GPP CT3 yesterday. The conclusion was that we will only insert a reason header in a 183 = provisional response. May I therefor suggest the following wording: The Reason header is applicable to 3xx, 4xx, 5xx and 6xx final = responses and 183 and 199 provisional responses. Further, it would be very helpfull for 3GPP if you could make the = updated draft available very quickly as we have several dependent CRs in = the 3GPP CTx meeting which is ongoing this week. Thomas ----------------------------------=20 Dr. Thomas Belling=20 3GPP Standardisation Nokia Siemens Networks=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext Christer Holmberg Sent: Tuesday, November 10, 2009 8:12 AM To: Paul Kyzivat; R.Jesske@telekom.de Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Hi, A small editorial change proposal: "The appearance of the Reason header is applicable to 3xx, 4xx, 5xx and = 6xx final responses and 18x and 199 provisional responsess." Regards, Christer -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Paul Kyzivat Sent: 10. marraskuuta 2009 3:06 To: R.Jesske@telekom.de Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Roland, Thanks! That addresses my concern. Thanks, Paul R.Jesske@telekom.de wrote: > Hello Paul, > Thanks for that hint. I will change this too.=20 > Like: >=20 > The appearance of the Reason header is applicable to final responses > 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as = defined within > ietf-sipcore-199.txt. Also the Reason header is > applicable to provisional responses18x. >=20 > Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Montag, 9. November 2009 12:58 > An: Jesske, Roland > Cc: adam@nostrum.com; audet@nortel.com; dispatch@ietf.org;=20 > gonzalo.camarillo@ericsson.com > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 >=20 >=20 > R.Jesske@telekom.de wrote: >> Hi Adam, >> Thank you for your mail. So I propose the following text then: >> >> The appearance of the Reason header is applicable to final responses >> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as = defined within >> ietf-sipcore-199.txt. Also the Reason header is >> applicable to provisional responses18x which are generated by = an >> interworking gateway from ISUP to SIP. >=20 > I think this is ok *except* if you are going to allow one kind of UAS=20 > to use Reason in a 18x response, then it should be allowed for *any*=20 > UAS to do so. >=20 > For instance, suppose the gateway is replaced by a B2BUA to another=20 > sip environment, and the request eventually arrives as a gateway. Then = > a 18x response with a Reason header may arrive at the B2BUA and need=20 > to be replicated on the other side. >=20 > Thanks, > Paul >=20 >> Best Beagards >> >> Roland >> >> -----Urspr=FCngliche Nachricht----- >> Von: Adam Roach [mailto:adam@nostrum.com] >> Gesendet: Freitag, 6. November 2009 01:43 >> An: Jesske, Roland >> Cc: audet@nortel.com; christer.holmberg@ericsson.com;=20 >> gonzalo.camarillo@ericsson.com; dispatch@ietf.org >> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: >>> Hi Christer and Francois, >>> I have added a sentence under section Overall Applicability: >>> >>> >>> The appearance of the Reason header is applicable to final responses = 4xx, 5xx and 6xx and in addition for 199 Responses. >>> >>> Is this proper enough? Or do you have more in mind? >>> =20 >> Given that RFC 3398 specifies the generation of a 301 in response to=20 >> a cause code of 22 under certain circumstances, it seems pretty=20 >> appropriate to allow the inclusion of a Q.850 cause code in 300-class = >> responses also. Or, at least, as appropriate as it would be to=20 >> include them in 4xx, 5xx, and 6xx responses. >> >> /a >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From eburger@standardstrack.com Wed Nov 11 00:26:17 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8674D3A6C4C for ; Wed, 11 Nov 2009 00:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 0Nxp6NceLkwz for ; Wed, 11 Nov 2009 00:26:13 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id DCE953A6C3D for ; Wed, 11 Nov 2009 00:26:13 -0800 (PST) Received: from host-40-25.meeting.ietf.org ([133.93.40.25]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N88X8-0004Rc-Q7 for dispatch@ietf.org; Wed, 11 Nov 2009 00:26:30 -0800 Message-Id: From: Eric Burger To: dispatch@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 17:26:36 +0900 X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [dispatch] DREGS ad hoc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:26:17 -0000 The DREGS ad hoc will be in Orchard East, 11.45 - 12.40 JT tomorrow (Thursday). We do need scribes and jabber scribes. Please respond directly to me to volunteer. Thanks. From mary.barnes@nortel.com Wed Nov 11 02:45:10 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1943A6842 for ; Wed, 11 Nov 2009 02:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 s4gtQKxQosnb for ; Wed, 11 Nov 2009 02:45:09 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A028C3A67FB for ; Wed, 11 Nov 2009 02:45:09 -0800 (PST) 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 nABAjPS19277; Wed, 11 Nov 2009 10:45:25 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_01CA62BB.88F808A9" Date: Wed, 11 Nov 2009 04:41:00 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DREGS ad hoc Thread-Index: AcpiqLfMihG6O67mQge+mdHHRPO7OgAEr2QF References: From: "Mary Barnes" To: "Eric Burger" , Subject: Re: [dispatch] DREGS ad hoc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 10:45:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA62BB.88F808A9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Orchard -> Orchid =20 -----Original Message----- From: dispatch-bounces@ietf.org on behalf of Eric Burger Sent: Wed 11/11/2009 2:26 AM To: dispatch@ietf.org Subject: [dispatch] DREGS ad hoc =20 The DREGS ad hoc will be in Orchard East, 11.45 - 12.40 JT tomorrow =20 (Thursday). We do need scribes and jabber scribes. Please respond directly to me =20 to volunteer. Thanks. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------_=_NextPart_001_01CA62BB.88F808A9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dispatch] DREGS ad hoc

Orchard -> Orchid  

-----Original Message-----
From: dispatch-bounces@ietf.org on behalf of Eric Burger
Sent: Wed 11/11/2009 2:26 AM
To: dispatch@ietf.org
Subject: [dispatch] DREGS ad hoc

The DREGS ad hoc will be in Orchard East, 11.45 - 12.40 JT = tomorrow 
(Thursday).

We do need scribes and jabber scribes.  Please respond directly to = me 
to volunteer.  Thanks.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch

------_=_NextPart_001_01CA62BB.88F808A9-- From pkyzivat@cisco.com Wed Nov 11 05:57:14 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3FFB3A6A0A for ; Wed, 11 Nov 2009 05:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.62 X-Spam-Level: X-Spam-Status: No, score=-6.62 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 ultzjnXVxqeH for ; Wed, 11 Nov 2009 05:57:12 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CC6583A6895 for ; Wed, 11 Nov 2009 05:57:12 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAJR+kqrR7Ht/2dsb2JhbADEXpgehDwE X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="429982408" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2009 13:57:38 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nABDvakS022160; Wed, 11 Nov 2009 13:57:38 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 08:57:38 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 08:57:37 -0500 Message-ID: <4AFAC2DF.3090001@cisco.com> Date: Wed, 11 Nov 2009 08:57:51 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de><4AF! 8AE73.40 50405@cisco .com> <744A66DF31B5B34EA8B08BBD8187A722C6423E@DEMUEXC014.nsn-intra.net> In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A722C6423E@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2009 13:57:37.0839 (UTC) FILETIME=[ED5E63F0:01CA62D6] Cc: Paul While , dispatch@ietf.org, R.Jesske@telekom.de, "ext Calme, James A \(Jim\)" Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 13:57:14 -0000 I hate to see *anything* restricted to 183, rather than being applicable to all 1xx (or at least 18x) responses. Restricting to 183 implies that there is something *special* about 183. I have seen that erroneous assumption in the wild too - and it is distressing. Anything you can do with 183 should also work with 180. Thanks, Paul Belling, Thomas (NSN - DE/Munich) wrote: > Dear Roland, > > we discussed the interworking of ISUP ACM and CPG causes to SIP reasons headers in provisional responses in 3GPP CT3 yesterday. > The conclusion was that we will only insert a reason header in a 183 provisional response. > > May I therefor suggest the following wording: > > The Reason header is applicable to 3xx, 4xx, 5xx and 6xx final responses > and 183 and 199 provisional responses. > > Further, it would be very helpfull for 3GPP if you could make the updated draft available very quickly as we have several dependent CRs in the 3GPP CTx meeting which is ongoing this week. > > Thomas > > > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > Nokia Siemens Networks > > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Christer Holmberg > Sent: Tuesday, November 10, 2009 8:12 AM > To: Paul Kyzivat; R.Jesske@telekom.de > Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > > Hi, > > A small editorial change proposal: > > "The appearance of the Reason header is applicable to 3xx, 4xx, 5xx and 6xx final responses and 18x and 199 provisional responsess." > > Regards, > > Christer > > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 10. marraskuuta 2009 3:06 > To: R.Jesske@telekom.de > Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > Roland, > > Thanks! That addresses my concern. > > Thanks, > Paul > > R.Jesske@telekom.de wrote: >> Hello Paul, >> Thanks for that hint. I will change this too. >> Like: >> >> The appearance of the Reason header is applicable to final responses >> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as defined within >> ietf-sipcore-199.txt. Also the Reason header is >> applicable to provisional responses18x. >> >> Best Regards >> >> Roland >> >> -----Ursprüngliche Nachricht----- >> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Gesendet: Montag, 9. November 2009 12:58 >> An: Jesske, Roland >> Cc: adam@nostrum.com; audet@nortel.com; dispatch@ietf.org; >> gonzalo.camarillo@ericsson.com >> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> >> >> R.Jesske@telekom.de wrote: >>> Hi Adam, >>> Thank you for your mail. So I propose the following text then: >>> >>> The appearance of the Reason header is applicable to final responses >>> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as defined within >>> ietf-sipcore-199.txt. Also the Reason header is >>> applicable to provisional responses18x which are generated by an >>> interworking gateway from ISUP to SIP. >> I think this is ok *except* if you are going to allow one kind of UAS >> to use Reason in a 18x response, then it should be allowed for *any* >> UAS to do so. >> >> For instance, suppose the gateway is replaced by a B2BUA to another >> sip environment, and the request eventually arrives as a gateway. Then >> a 18x response with a Reason header may arrive at the B2BUA and need >> to be replicated on the other side. >> >> Thanks, >> Paul >> >>> Best Beagards >>> >>> Roland >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Adam Roach [mailto:adam@nostrum.com] >>> Gesendet: Freitag, 6. November 2009 01:43 >>> An: Jesske, Roland >>> Cc: audet@nortel.com; christer.holmberg@ericsson.com; >>> gonzalo.camarillo@ericsson.com; dispatch@ietf.org >>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>> >>> On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: >>>> Hi Christer and Francois, >>>> I have added a sentence under section Overall Applicability: >>>> >>>> >>>> The appearance of the Reason header is applicable to final responses 4xx, 5xx and 6xx and in addition for 199 Responses. >>>> >>>> Is this proper enough? Or do you have more in mind? >>>> >>> Given that RFC 3398 specifies the generation of a 301 in response to >>> a cause code of 22 under certain circumstances, it seems pretty >>> appropriate to allow the inclusion of a Q.850 cause code in 300-class >>> responses also. Or, at least, as appropriate as it would be to >>> include them in 4xx, 5xx, and 6xx responses. >>> >>> /a >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From R.Jesske@telekom.de Wed Nov 11 06:25:19 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012103A6981 for ; Wed, 11 Nov 2009 06:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6, 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 SZr+R-cWOPA3 for ; Wed, 11 Nov 2009 06:25:17 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 3BAA33A6894 for ; Wed, 11 Nov 2009 06:25:17 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 11 Nov 2009 15:25:38 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 15:25:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 15:25:33 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD405372C90@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <4AFAC2DF.3090001@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: Acpi1vObjf/406KeTKuKWza0HjU7AgAA2QoA References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de><4AF! 8AE73.4050405@cisco.com> <744A66DF31B5B34EA8B08BBD8187A722C6423E@DEMUEXC014.nsn-intra.net> <4AFAC2DF.3090001@cisco.com> From: To: , X-OriginalArrivalTime: 11 Nov 2009 14:25:37.0231 (UTC) FILETIME=[D65D45F0:01CA62DA] Cc: calme@alcatel-lucent.com, dispatch@ietf.org, paul.while@ericsson.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:25:19 -0000 Hello Paul, Thank you for your comment. I have the sam opinion. Due to the fact that = 1xx is not done end to end I have put the following sentence into the = draft. The appearance of the Reason header is applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x and 199 provisional responses [I-D.ietf-sipcore-199]. I hope that fits.=20 Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Paul Kyzivat Gesendet: Mittwoch, 11. November 2009 22:58 An: Belling, Thomas (NSN - DE/Munich) Cc: Paul While; dispatch@ietf.org; Jesske, Roland; ext Calme,James A = (Jim) Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 I hate to see *anything* restricted to 183, rather than being applicable = to all 1xx (or at least 18x) responses. Restricting to 183 implies that there is something *special* about 183. I have seen that erroneous assumption in the wild too - and it is=20 distressing. Anything you can do with 183 should also work with 180. Thanks, Paul Belling, Thomas (NSN - DE/Munich) wrote: > Dear Roland, >=20 > we discussed the interworking of ISUP ACM and CPG causes to SIP = reasons headers in provisional responses in 3GPP CT3 yesterday. > The conclusion was that we will only insert a reason header in a 183 = provisional response. >=20 > May I therefor suggest the following wording: >=20 > The Reason header is applicable to 3xx, 4xx, 5xx and 6xx final = responses > and 183 and 199 provisional responses. >=20 > Further, it would be very helpfull for 3GPP if you could make the = updated draft available very quickly as we have several dependent CRs in = the 3GPP CTx meeting which is ongoing this week. >=20 > Thomas >=20 >=20 > ----------------------------------=20 > Dr. Thomas Belling=20 > 3GPP Standardisation > Nokia Siemens Networks=20 >=20 >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext Christer Holmberg > Sent: Tuesday, November 10, 2009 8:12 AM > To: Paul Kyzivat; R.Jesske@telekom.de > Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 >=20 > Hi, >=20 > A small editorial change proposal: >=20 > "The appearance of the Reason header is applicable to 3xx, 4xx, 5xx = and 6xx final responses and 18x and 199 provisional = responsess." >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Paul Kyzivat > Sent: 10. marraskuuta 2009 3:06 > To: R.Jesske@telekom.de > Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Roland, >=20 > Thanks! That addresses my concern. >=20 > Thanks, > Paul >=20 > R.Jesske@telekom.de wrote: >> Hello Paul, >> Thanks for that hint. I will change this too.=20 >> Like: >> >> The appearance of the Reason header is applicable to final responses >> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as = defined within >> ietf-sipcore-199.txt. Also the Reason header is >> applicable to provisional responses18x. >> >> Best Regards >> >> Roland >> >> -----Urspr=FCngliche Nachricht----- >> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Gesendet: Montag, 9. November 2009 12:58 >> An: Jesske, Roland >> Cc: adam@nostrum.com; audet@nortel.com; dispatch@ietf.org;=20 >> gonzalo.camarillo@ericsson.com >> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> >> >> R.Jesske@telekom.de wrote: >>> Hi Adam, >>> Thank you for your mail. So I propose the following text then: >>> >>> The appearance of the Reason header is applicable to final responses >>> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as = defined within >>> ietf-sipcore-199.txt. Also the Reason header is >>> applicable to provisional responses18x which are generated by = an >>> interworking gateway from ISUP to SIP. >> I think this is ok *except* if you are going to allow one kind of UAS = >> to use Reason in a 18x response, then it should be allowed for *any*=20 >> UAS to do so. >> >> For instance, suppose the gateway is replaced by a B2BUA to another=20 >> sip environment, and the request eventually arrives as a gateway. = Then=20 >> a 18x response with a Reason header may arrive at the B2BUA and need=20 >> to be replicated on the other side. >> >> Thanks, >> Paul >> >>> Best Beagards >>> >>> Roland >>> >>> -----Urspr=FCngliche Nachricht----- >>> Von: Adam Roach [mailto:adam@nostrum.com] >>> Gesendet: Freitag, 6. November 2009 01:43 >>> An: Jesske, Roland >>> Cc: audet@nortel.com; christer.holmberg@ericsson.com;=20 >>> gonzalo.camarillo@ericsson.com; dispatch@ietf.org >>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>> >>> On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: >>>> Hi Christer and Francois, >>>> I have added a sentence under section Overall Applicability: >>>> >>>> >>>> The appearance of the Reason header is applicable to final = responses 4xx, 5xx and 6xx and in addition for 199 Responses. >>>> >>>> Is this proper enough? Or do you have more in mind? >>>> =20 >>> Given that RFC 3398 specifies the generation of a 301 in response to = >>> a cause code of 22 under certain circumstances, it seems pretty=20 >>> appropriate to allow the inclusion of a Q.850 cause code in = 300-class=20 >>> responses also. Or, at least, as appropriate as it would be to=20 >>> include them in 4xx, 5xx, and 6xx responses. >>> >>> /a >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Wed Nov 11 06:59:05 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33AE3A6A47 for ; Wed, 11 Nov 2009 06:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.318 X-Spam-Level: X-Spam-Status: No, score=-6.318 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9g5GiebAIug for ; Wed, 11 Nov 2009 06:59:04 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 181FA3A693E for ; Wed, 11 Nov 2009 06:58:59 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAANg+kqtJV2c/2dsb2JhbADFF5gehDwE X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="67435800" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 11 Nov 2009 14:59:26 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id nABExQJI027464; Wed, 11 Nov 2009 14:59:26 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:59:26 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:59:25 -0500 Message-ID: <4AFAD150.9070900@cisco.com> Date: Wed, 11 Nov 2009 09:59:28 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: R.Jesske@telekom.de References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de><4AF! 8AE73.4050405@cisco.com> <744A66DF31B5B34EA8B08BBD8187A722C6423E@DEMUEXC014.nsn-intra.net> <4AFAC2DF.3090001@cisco.com> <9886E5FCA6D76549A3011068483A4BD405372C90@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD405372C90@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2009 14:59:25.0582 (UTC) FILETIME=[8F5B12E0:01CA62DF] Cc: calme@alcatel-lucent.com, dispatch@ietf.org, paul.while@ericsson.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:59:06 -0000 R.Jesske@telekom.de wrote: > Hello Paul, > Thank you for your comment. I have the sam opinion. Due to the fact that 1xx is not done end to end 1xx means 101-199, excluding 100. Only 100 is hop by hop. All the 1xx are end to end. > I have put the following sentence into the draft. > > The appearance of the Reason header is applicable to final responses > 3xx, 4xx, 5xx and 6xx and 18x and 199 provisional responses > [I-D.ietf-sipcore-199]. I'd prefer to see it just say 1xx. Thanks, Paul > I hope that fits. > > Best Regards > > Roland > > -----Ursprüngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul Kyzivat > Gesendet: Mittwoch, 11. November 2009 22:58 > An: Belling, Thomas (NSN - DE/Munich) > Cc: Paul While; dispatch@ietf.org; Jesske, Roland; ext Calme,James A (Jim) > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > I hate to see *anything* restricted to 183, rather than being applicable > to all 1xx (or at least 18x) responses. > > Restricting to 183 implies that there is something *special* about 183. > I have seen that erroneous assumption in the wild too - and it is > distressing. Anything you can do with 183 should also work with 180. > > Thanks, > Paul > > Belling, Thomas (NSN - DE/Munich) wrote: >> Dear Roland, >> >> we discussed the interworking of ISUP ACM and CPG causes to SIP reasons headers in provisional responses in 3GPP CT3 yesterday. >> The conclusion was that we will only insert a reason header in a 183 provisional response. >> >> May I therefor suggest the following wording: >> >> The Reason header is applicable to 3xx, 4xx, 5xx and 6xx final responses >> and 183 and 199 provisional responses. >> >> Further, it would be very helpfull for 3GPP if you could make the updated draft available very quickly as we have several dependent CRs in the 3GPP CTx meeting which is ongoing this week. >> >> Thomas >> >> >> ---------------------------------- >> Dr. Thomas Belling >> 3GPP Standardisation >> Nokia Siemens Networks >> >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Christer Holmberg >> Sent: Tuesday, November 10, 2009 8:12 AM >> To: Paul Kyzivat; R.Jesske@telekom.de >> Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo >> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> >> Hi, >> >> A small editorial change proposal: >> >> "The appearance of the Reason header is applicable to 3xx, 4xx, 5xx and 6xx final responses and 18x and 199 provisional responsess." >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 10. marraskuuta 2009 3:06 >> To: R.Jesske@telekom.de >> Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo >> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> Roland, >> >> Thanks! That addresses my concern. >> >> Thanks, >> Paul >> >> R.Jesske@telekom.de wrote: >>> Hello Paul, >>> Thanks for that hint. I will change this too. >>> Like: >>> >>> The appearance of the Reason header is applicable to final responses >>> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as defined within >>> ietf-sipcore-199.txt. Also the Reason header is >>> applicable to provisional responses18x. >>> >>> Best Regards >>> >>> Roland >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Gesendet: Montag, 9. November 2009 12:58 >>> An: Jesske, Roland >>> Cc: adam@nostrum.com; audet@nortel.com; dispatch@ietf.org; >>> gonzalo.camarillo@ericsson.com >>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>> >>> >>> >>> R.Jesske@telekom.de wrote: >>>> Hi Adam, >>>> Thank you for your mail. So I propose the following text then: >>>> >>>> The appearance of the Reason header is applicable to final responses >>>> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as defined within >>>> ietf-sipcore-199.txt. Also the Reason header is >>>> applicable to provisional responses18x which are generated by an >>>> interworking gateway from ISUP to SIP. >>> I think this is ok *except* if you are going to allow one kind of UAS >>> to use Reason in a 18x response, then it should be allowed for *any* >>> UAS to do so. >>> >>> For instance, suppose the gateway is replaced by a B2BUA to another >>> sip environment, and the request eventually arrives as a gateway. Then >>> a 18x response with a Reason header may arrive at the B2BUA and need >>> to be replicated on the other side. >>> >>> Thanks, >>> Paul >>> >>>> Best Beagards >>>> >>>> Roland >>>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Adam Roach [mailto:adam@nostrum.com] >>>> Gesendet: Freitag, 6. November 2009 01:43 >>>> An: Jesske, Roland >>>> Cc: audet@nortel.com; christer.holmberg@ericsson.com; >>>> gonzalo.camarillo@ericsson.com; dispatch@ietf.org >>>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>>> >>>> On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: >>>>> Hi Christer and Francois, >>>>> I have added a sentence under section Overall Applicability: >>>>> >>>>> >>>>> The appearance of the Reason header is applicable to final responses 4xx, 5xx and 6xx and in addition for 199 Responses. >>>>> >>>>> Is this proper enough? Or do you have more in mind? >>>>> >>>> Given that RFC 3398 specifies the generation of a 301 in response to >>>> a cause code of 22 under certain circumstances, it seems pretty >>>> appropriate to allow the inclusion of a Q.850 cause code in 300-class >>>> responses also. Or, at least, as appropriate as it would be to >>>> include them in 4xx, 5xx, and 6xx responses. >>>> >>>> /a >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From brett@broadsoft.com Wed Nov 11 07:07:41 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0238F3A690A for ; Wed, 11 Nov 2009 07:07:41 -0800 (PST) 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_55=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 KHdS4vtaytJn for ; Wed, 11 Nov 2009 07:07:39 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id D44713A68AC for ; Wed, 11 Nov 2009 07:07:39 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 11 Nov 2009 07:08:07 -0800 From: Brett Tate To: Paul Kyzivat , "dispatch@ietf.org" Date: Wed, 11 Nov 2009 07:07:56 -0800 Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: Acpi35ZxKlOnToSjRmm5bnpiH4jbhgAAIxAA Message-ID: <747A6506A991724FB09B129B79D5FEB613FE0B9A3B@EXMBXCLUS01.citservers.local> References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de><4AF! 8AE73.4050405@cisco.com> <744A66DF31B5B34EA8B08BBD8187A722C6423E@DEMUEXC014.nsn-intra.net> <4AFAC2DF.3090001@cisco.com> <9886E5FCA6D76549A3011068483A4BD405372C90@S4DE8PSAAQB.mitte.t-com.de> <4AFAD150.9070900@cisco.com> In-Reply-To: <4AFAD150.9070900@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 15:07:41 -0000 Although some people/documents might use 1xx when they really mean "101-199= ", rfc3261 section 7.2 indicates that 100 is included within 1xx. "For this reason, any response with a status code between 100 and 199 is re= ferred to as a "1xx response"," > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Wednesday, November 11, 2009 9:59 AM > To: R.Jesske@telekom.de > Cc: calme@alcatel-lucent.com; dispatch@ietf.org; > paul.while@ericsson.com > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 >=20 >=20 > R.Jesske@telekom.de wrote: > > Hello Paul, > > Thank you for your comment. I have the sam opinion. Due to the fact > that 1xx is not done end to end >=20 > 1xx means 101-199, excluding 100. Only 100 is hop by hop. All the 1xx > are end to end. >=20 > > I have put the following sentence into the draft. > > > > The appearance of the Reason header is applicable to final responses > > 3xx, 4xx, 5xx and 6xx and 18x and 199 provisional responses > > [I-D.ietf-sipcore-199]. >=20 > I'd prefer to see it just say 1xx. >=20 > Thanks, > Paul >=20 > > I hope that fits. > > > > Best Regards > > > > Roland > > > > -----Urspr=FCngliche Nachricht----- > > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im > Auftrag von Paul Kyzivat > > Gesendet: Mittwoch, 11. November 2009 22:58 > > An: Belling, Thomas (NSN - DE/Munich) > > Cc: Paul While; dispatch@ietf.org; Jesske, Roland; ext Calme,James A > (Jim) > > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > > > I hate to see *anything* restricted to 183, rather than being > applicable > > to all 1xx (or at least 18x) responses. > > > > Restricting to 183 implies that there is something *special* about > 183. > > I have seen that erroneous assumption in the wild too - and it is > > distressing. Anything you can do with 183 should also work with 180. > > > > Thanks, > > Paul > > > > Belling, Thomas (NSN - DE/Munich) wrote: > >> Dear Roland, > >> > >> we discussed the interworking of ISUP ACM and CPG causes to SIP > reasons headers in provisional responses in 3GPP CT3 yesterday. > >> The conclusion was that we will only insert a reason header in a 183 > provisional response. > >> > >> May I therefor suggest the following wording: > >> > >> The Reason header is applicable to 3xx, 4xx, 5xx and 6xx > final responses > >> and 183 and 199 provisional responses. > >> > >> Further, it would be very helpfull for 3GPP if you could make the > updated draft available very quickly as we have several dependent CRs > in the 3GPP CTx meeting which is ongoing this week. > >> > >> Thomas > >> > >> > >> ---------------------------------- > >> Dr. Thomas Belling > >> 3GPP Standardisation > >> Nokia Siemens Networks > >> > >> > >> > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On Behalf Of ext Christer Holmberg > >> Sent: Tuesday, November 10, 2009 8:12 AM > >> To: Paul Kyzivat; R.Jesske@telekom.de > >> Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo > >> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >> > >> > >> Hi, > >> > >> A small editorial change proposal: > >> > >> "The appearance of the Reason header is applicable to 3xx, 4xx, 5xx > and 6xx final responses and 18x and 199 provisional > responsess." > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On Behalf Of Paul Kyzivat > >> Sent: 10. marraskuuta 2009 3:06 > >> To: R.Jesske@telekom.de > >> Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo > >> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >> > >> Roland, > >> > >> Thanks! That addresses my concern. > >> > >> Thanks, > >> Paul > >> > >> R.Jesske@telekom.de wrote: > >>> Hello Paul, > >>> Thanks for that hint. I will change this too. > >>> Like: > >>> > >>> The appearance of the Reason header is applicable to final > responses > >>> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as > defined within > >>> ietf-sipcore-199.txt. Also the Reason header is > >>> applicable to provisional responses18x. > >>> > >>> Best Regards > >>> > >>> Roland > >>> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Gesendet: Montag, 9. November 2009 12:58 > >>> An: Jesske, Roland > >>> Cc: adam@nostrum.com; audet@nortel.com; dispatch@ietf.org; > >>> gonzalo.camarillo@ericsson.com > >>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >>> > >>> > >>> > >>> R.Jesske@telekom.de wrote: > >>>> Hi Adam, > >>>> Thank you for your mail. So I propose the following text then: > >>>> > >>>> The appearance of the Reason header is applicable to final > responses > >>>> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as > defined within > >>>> ietf-sipcore-199.txt. Also the Reason header is > >>>> applicable to provisional responses18x which are generated > by an > >>>> interworking gateway from ISUP to SIP. > >>> I think this is ok *except* if you are going to allow one kind of > UAS > >>> to use Reason in a 18x response, then it should be allowed for > *any* > >>> UAS to do so. > >>> > >>> For instance, suppose the gateway is replaced by a B2BUA to another > >>> sip environment, and the request eventually arrives as a gateway. > Then > >>> a 18x response with a Reason header may arrive at the B2BUA and > need > >>> to be replicated on the other side. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Best Beagards > >>>> > >>>> Roland > >>>> > >>>> -----Urspr=FCngliche Nachricht----- > >>>> Von: Adam Roach [mailto:adam@nostrum.com] > >>>> Gesendet: Freitag, 6. November 2009 01:43 > >>>> An: Jesske, Roland > >>>> Cc: audet@nortel.com; christer.holmberg@ericsson.com; > >>>> gonzalo.camarillo@ericsson.com; dispatch@ietf.org > >>>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >>>> > >>>> On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: > >>>>> Hi Christer and Francois, > >>>>> I have added a sentence under section Overall Applicability: > >>>>> > >>>>> > >>>>> The appearance of the Reason header is applicable to final > responses 4xx, 5xx and 6xx and in addition for 199 Responses. > >>>>> > >>>>> Is this proper enough? Or do you have more in mind? > >>>>> > >>>> Given that RFC 3398 specifies the generation of a 301 in response > to > >>>> a cause code of 22 under certain circumstances, it seems pretty > >>>> appropriate to allow the inclusion of a Q.850 cause code in 300- > class > >>>> responses also. Or, at least, as appropriate as it would be to > >>>> include them in 4xx, 5xx, and 6xx responses. > >>>> > >>>> /a > >>>> _______________________________________________ > >>>> dispatch mailing list > >>>> dispatch@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dispatch > >>>> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From R.Jesske@telekom.de Wed Nov 11 07:10:33 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BBB93A68C8 for ; Wed, 11 Nov 2009 07:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6, 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 Aj-5fwTeLl0C for ; Wed, 11 Nov 2009 07:10:32 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 3FAB63A6878 for ; Wed, 11 Nov 2009 07:10:31 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 11 Nov 2009 16:10:49 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 16:10:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 16:10:45 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD405372CDE@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <4AFAD150.9070900@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: Acpi35O6+rZy1UosQ961v8eTBCDNHAAARiSA References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de><4AF! 8AE73.4050405@cisco.com> <744A66DF31B5B34EA8B08BBD8187A722C6423E@DEMUEXC014.nsn-intra.net> <4AFAC2DF.3090001@cisco.com> <9886E5FCA6D76549A3011068483A4BD405372C90@S4DE8PSAAQB.mitte.t-com.de> <4AFAD1 50.9070900@cisco.com> From: To: X-OriginalArrivalTime: 11 Nov 2009 15:10:49.0544 (UTC) FILETIME=[27076480:01CA62E1] Cc: calme@alcatel-lucent.com, dispatch@ietf.org, paul.while@ericsson.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 15:10:33 -0000 Hi Paul, Sorry. I was to fast with my writing an sending.=20 What I meant to write was the 100. But I dont know any other 1xx beyond = 18x and 199 that would fit. Or did I forgot one. Or is it more the general avalibility for 1xx for future. Best Regards Roland=20 -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Gesendet: Mittwoch, 11. November 2009 23:59 An: Jesske, Roland Cc: thomas.belling@nsn.com; paul.while@ericsson.com; dispatch@ietf.org; = calme@alcatel-lucent.com Betreff: Re: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 R.Jesske@telekom.de wrote: > Hello Paul, > Thank you for your comment. I have the sam opinion. Due to the fact = that 1xx is not done end to end 1xx means 101-199, excluding 100. Only 100 is hop by hop. All the 1xx=20 are end to end. > I have put the following sentence into the draft. >=20 > The appearance of the Reason header is applicable to final responses > 3xx, 4xx, 5xx and 6xx and 18x and 199 provisional responses > [I-D.ietf-sipcore-199]. I'd prefer to see it just say 1xx. Thanks, Paul > I hope that fits.=20 >=20 > Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Paul Kyzivat > Gesendet: Mittwoch, 11. November 2009 22:58 > An: Belling, Thomas (NSN - DE/Munich) > Cc: Paul While; dispatch@ietf.org; Jesske, Roland; ext Calme,James A = (Jim) > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > I hate to see *anything* restricted to 183, rather than being = applicable=20 > to all 1xx (or at least 18x) responses. >=20 > Restricting to 183 implies that there is something *special* about = 183. > I have seen that erroneous assumption in the wild too - and it is=20 > distressing. Anything you can do with 183 should also work with 180. >=20 > Thanks, > Paul >=20 > Belling, Thomas (NSN - DE/Munich) wrote: >> Dear Roland, >> >> we discussed the interworking of ISUP ACM and CPG causes to SIP = reasons headers in provisional responses in 3GPP CT3 yesterday. >> The conclusion was that we will only insert a reason header in a 183 = provisional response. >> >> May I therefor suggest the following wording: >> >> The Reason header is applicable to 3xx, 4xx, 5xx and 6xx = final responses >> and 183 and 199 provisional responses. >> >> Further, it would be very helpfull for 3GPP if you could make the = updated draft available very quickly as we have several dependent CRs in = the 3GPP CTx meeting which is ongoing this week. >> >> Thomas >> >> >> ----------------------------------=20 >> Dr. Thomas Belling=20 >> 3GPP Standardisation >> Nokia Siemens Networks=20 >> >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext Christer Holmberg >> Sent: Tuesday, November 10, 2009 8:12 AM >> To: Paul Kyzivat; R.Jesske@telekom.de >> Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo >> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> >> Hi, >> >> A small editorial change proposal: >> >> "The appearance of the Reason header is applicable to 3xx, 4xx, 5xx = and 6xx final responses and 18x and 199 provisional = responsess." >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Paul Kyzivat >> Sent: 10. marraskuuta 2009 3:06 >> To: R.Jesske@telekom.de >> Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo >> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> Roland, >> >> Thanks! That addresses my concern. >> >> Thanks, >> Paul >> >> R.Jesske@telekom.de wrote: >>> Hello Paul, >>> Thanks for that hint. I will change this too.=20 >>> Like: >>> >>> The appearance of the Reason header is applicable to final = responses >>> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as = defined within >>> ietf-sipcore-199.txt. Also the Reason header is >>> applicable to provisional responses18x. >>> >>> Best Regards >>> >>> Roland >>> >>> -----Urspr=FCngliche Nachricht----- >>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Gesendet: Montag, 9. November 2009 12:58 >>> An: Jesske, Roland >>> Cc: adam@nostrum.com; audet@nortel.com; dispatch@ietf.org;=20 >>> gonzalo.camarillo@ericsson.com >>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>> >>> >>> >>> R.Jesske@telekom.de wrote: >>>> Hi Adam, >>>> Thank you for your mail. So I propose the following text then: >>>> >>>> The appearance of the Reason header is applicable to final = responses >>>> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as = defined within >>>> ietf-sipcore-199.txt. Also the Reason header is >>>> applicable to provisional responses18x which are generated by = an >>>> interworking gateway from ISUP to SIP. >>> I think this is ok *except* if you are going to allow one kind of = UAS=20 >>> to use Reason in a 18x response, then it should be allowed for *any* = >>> UAS to do so. >>> >>> For instance, suppose the gateway is replaced by a B2BUA to another=20 >>> sip environment, and the request eventually arrives as a gateway. = Then=20 >>> a 18x response with a Reason header may arrive at the B2BUA and need = >>> to be replicated on the other side. >>> >>> Thanks, >>> Paul >>> >>>> Best Beagards >>>> >>>> Roland >>>> >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: Adam Roach [mailto:adam@nostrum.com] >>>> Gesendet: Freitag, 6. November 2009 01:43 >>>> An: Jesske, Roland >>>> Cc: audet@nortel.com; christer.holmberg@ericsson.com;=20 >>>> gonzalo.camarillo@ericsson.com; dispatch@ietf.org >>>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>>> >>>> On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: >>>>> Hi Christer and Francois, >>>>> I have added a sentence under section Overall Applicability: >>>>> >>>>> >>>>> The appearance of the Reason header is applicable to final = responses 4xx, 5xx and 6xx and in addition for 199 Responses. >>>>> >>>>> Is this proper enough? Or do you have more in mind? >>>>> =20 >>>> Given that RFC 3398 specifies the generation of a 301 in response = to=20 >>>> a cause code of 22 under certain circumstances, it seems pretty=20 >>>> appropriate to allow the inclusion of a Q.850 cause code in = 300-class=20 >>>> responses also. Or, at least, as appropriate as it would be to=20 >>>> include them in 4xx, 5xx, and 6xx responses. >>>> >>>> /a >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From pkyzivat@cisco.com Wed Nov 11 07:36:22 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A3D3A67F5 for ; Wed, 11 Nov 2009 07:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjq+OWbwJjKz for ; Wed, 11 Nov 2009 07:36:21 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5E0CD3A67E5 for ; Wed, 11 Nov 2009 07:36:21 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACdp+kqrRN+K/2dsb2JhbADFQJgehDwE X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="48996759" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2009 15:36:49 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nABFaljr021138; Wed, 11 Nov 2009 15:36:49 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 10:36:40 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 10:36:39 -0500 Message-ID: <4AFADA01.2060303@cisco.com> Date: Wed, 11 Nov 2009 10:36:33 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brett Tate References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de><4AF! 8AE73.4050405@cisco.com> <744A66DF31B5B34EA8B08BBD8187A722C6423E@DEMUEXC014.nsn-intra.net> <4AFAC2DF.3090001@cisco.com> <9886E5FCA6D76549A3011068483A4BD405372C90@S4DE8PSAAQB.mitte.t-com.de> <4AFAD150.9070900@cisco.com> <747A6506A991724FB09B129B79D5FEB613FE0B9A3B@EXMBXCLUS01.citservers.l ocal> In-Reply-To: <747A6506A991724FB09B129B79D5FEB613FE0B9A3B@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2009 15:36:39.0567 (UTC) FILETIME=[C2EA21F0:01CA62E4] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 15:36:22 -0000 Brett Tate wrote: > Although some people/documents might use 1xx when they really mean "101-199", rfc3261 section 7.2 indicates that 100 is included within 1xx. > > "For this reason, any response with a status code between 100 and 199 is referred to as a "1xx response"," Damn! Sorry. Ok. Then lets go for 101-199. Thanks, Paul >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Wednesday, November 11, 2009 9:59 AM >> To: R.Jesske@telekom.de >> Cc: calme@alcatel-lucent.com; dispatch@ietf.org; >> paul.while@ericsson.com >> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> >> >> R.Jesske@telekom.de wrote: >>> Hello Paul, >>> Thank you for your comment. I have the sam opinion. Due to the fact >> that 1xx is not done end to end >> >> 1xx means 101-199, excluding 100. Only 100 is hop by hop. All the 1xx >> are end to end. >> >>> I have put the following sentence into the draft. >>> >>> The appearance of the Reason header is applicable to final responses >>> 3xx, 4xx, 5xx and 6xx and 18x and 199 provisional responses >>> [I-D.ietf-sipcore-199]. >> I'd prefer to see it just say 1xx. >> >> Thanks, >> Paul >> >>> I hope that fits. >>> >>> Best Regards >>> >>> Roland >>> >>> -----Ursprüngliche Nachricht----- >>> Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im >> Auftrag von Paul Kyzivat >>> Gesendet: Mittwoch, 11. November 2009 22:58 >>> An: Belling, Thomas (NSN - DE/Munich) >>> Cc: Paul While; dispatch@ietf.org; Jesske, Roland; ext Calme,James A >> (Jim) >>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>> >>> I hate to see *anything* restricted to 183, rather than being >> applicable >>> to all 1xx (or at least 18x) responses. >>> >>> Restricting to 183 implies that there is something *special* about >> 183. >>> I have seen that erroneous assumption in the wild too - and it is >>> distressing. Anything you can do with 183 should also work with 180. >>> >>> Thanks, >>> Paul >>> >>> Belling, Thomas (NSN - DE/Munich) wrote: >>>> Dear Roland, >>>> >>>> we discussed the interworking of ISUP ACM and CPG causes to SIP >> reasons headers in provisional responses in 3GPP CT3 yesterday. >>>> The conclusion was that we will only insert a reason header in a 183 >> provisional response. >>>> May I therefor suggest the following wording: >>>> >>>> The Reason header is applicable to 3xx, 4xx, 5xx and 6xx >> final responses >>>> and 183 and 199 provisional responses. >>>> >>>> Further, it would be very helpfull for 3GPP if you could make the >> updated draft available very quickly as we have several dependent CRs >> in the 3GPP CTx meeting which is ongoing this week. >>>> Thomas >>>> >>>> >>>> ---------------------------------- >>>> Dr. Thomas Belling >>>> 3GPP Standardisation >>>> Nokia Siemens Networks >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On Behalf Of ext Christer Holmberg >>>> Sent: Tuesday, November 10, 2009 8:12 AM >>>> To: Paul Kyzivat; R.Jesske@telekom.de >>>> Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo >>>> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>>> >>>> >>>> Hi, >>>> >>>> A small editorial change proposal: >>>> >>>> "The appearance of the Reason header is applicable to 3xx, 4xx, 5xx >> and 6xx final responses and 18x and 199 provisional >> responsess." >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On Behalf Of Paul Kyzivat >>>> Sent: 10. marraskuuta 2009 3:06 >>>> To: R.Jesske@telekom.de >>>> Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo >>>> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>>> >>>> Roland, >>>> >>>> Thanks! That addresses my concern. >>>> >>>> Thanks, >>>> Paul >>>> >>>> R.Jesske@telekom.de wrote: >>>>> Hello Paul, >>>>> Thanks for that hint. I will change this too. >>>>> Like: >>>>> >>>>> The appearance of the Reason header is applicable to final >> responses >>>>> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as >> defined within >>>>> ietf-sipcore-199.txt. Also the Reason header is >>>>> applicable to provisional responses18x. >>>>> >>>>> Best Regards >>>>> >>>>> Roland >>>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Gesendet: Montag, 9. November 2009 12:58 >>>>> An: Jesske, Roland >>>>> Cc: adam@nostrum.com; audet@nortel.com; dispatch@ietf.org; >>>>> gonzalo.camarillo@ericsson.com >>>>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>>>> >>>>> >>>>> >>>>> R.Jesske@telekom.de wrote: >>>>>> Hi Adam, >>>>>> Thank you for your mail. So I propose the following text then: >>>>>> >>>>>> The appearance of the Reason header is applicable to final >> responses >>>>>> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as >> defined within >>>>>> ietf-sipcore-199.txt. Also the Reason header is >>>>>> applicable to provisional responses18x which are generated >> by an >>>>>> interworking gateway from ISUP to SIP. >>>>> I think this is ok *except* if you are going to allow one kind of >> UAS >>>>> to use Reason in a 18x response, then it should be allowed for >> *any* >>>>> UAS to do so. >>>>> >>>>> For instance, suppose the gateway is replaced by a B2BUA to another >>>>> sip environment, and the request eventually arrives as a gateway. >> Then >>>>> a 18x response with a Reason header may arrive at the B2BUA and >> need >>>>> to be replicated on the other side. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Best Beagards >>>>>> >>>>>> Roland >>>>>> >>>>>> -----Ursprüngliche Nachricht----- >>>>>> Von: Adam Roach [mailto:adam@nostrum.com] >>>>>> Gesendet: Freitag, 6. November 2009 01:43 >>>>>> An: Jesske, Roland >>>>>> Cc: audet@nortel.com; christer.holmberg@ericsson.com; >>>>>> gonzalo.camarillo@ericsson.com; dispatch@ietf.org >>>>>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>>>>> >>>>>> On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: >>>>>>> Hi Christer and Francois, >>>>>>> I have added a sentence under section Overall Applicability: >>>>>>> >>>>>>> >>>>>>> The appearance of the Reason header is applicable to final >> responses 4xx, 5xx and 6xx and in addition for 199 Responses. >>>>>>> Is this proper enough? Or do you have more in mind? >>>>>>> >>>>>> Given that RFC 3398 specifies the generation of a 301 in response >> to >>>>>> a cause code of 22 under certain circumstances, it seems pretty >>>>>> appropriate to allow the inclusion of a Q.850 cause code in 300- >> class >>>>>> responses also. Or, at least, as appropriate as it would be to >>>>>> include them in 4xx, 5xx, and 6xx responses. >>>>>> >>>>>> /a >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Wed Nov 11 07:39:49 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DB5F3A672F for ; Wed, 11 Nov 2009 07:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmOy8y6zzgGq for ; Wed, 11 Nov 2009 07:39:48 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 510233A697F for ; Wed, 11 Nov 2009 07:39:48 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ9p+kqrRN+K/2dsb2JhbADFN5gZhDwE X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="103551509" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2009 15:40:16 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nABFeGmf022422; Wed, 11 Nov 2009 15:40:16 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 10:40:15 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 10:40:15 -0500 Message-ID: <4AFADAD9.7040402@cisco.com> Date: Wed, 11 Nov 2009 10:40:09 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: R.Jesske@telekom.de References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> <4AF37113.8030908@nostrum.com><9886E5FCA6D76549A3011068483A4BD405319E68@S4DE8PSAAQB.mitte.t-com.de><4AF7934B.7080902@cisco.com><9886E5FCA6D76549A3011068483A4BD40537238D@S4DE8PSAAQB.mitte.t-com.de><4AF! 8AE73.4050405@cisco.com> <744A66DF31B5B34EA8B08BBD8187A722C6423E@DEMUEXC014.nsn-intra.net> <4AFAC2DF.3090001@cisco.com> <9886E5FCA6D76549A3011068483A4BD405372C90@S4DE8PSAAQB.mitte.t-com.de> <4AFAD1 50.9070900@cisco.com> <9886E5FCA6D76549A3011068483A4BD405372CDE@S4DE8PSAAQB.mitte.t-com.d e> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD405372CDE@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2009 15:40:15.0565 (UTC) FILETIME=[43A8CFD0:01CA62E5] Cc: calme@alcatel-lucent.com, dispatch@ietf.org, paul.while@ericsson.com Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 15:39:49 -0000 R.Jesske@telekom.de wrote: > Hi Paul, > Sorry. I was to fast with my writing an sending. > What I meant to write was the 100. But I dont know any other 1xx beyond 18x and 199 that would fit. Or did I forgot one. > > Or is it more the general avalibility for 1xx for future. Enumerating which ones are meaningful isn't future proof. Maybe this is a special case since there is a requirement to explicitly document which responses this header may appear in (why?), but IMO it would be better not to second guess, and just allow them all. My fallback from that would be all 18x and 199. Thanks, Paul > Best Regards > > Roland > > -----Ursprüngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Mittwoch, 11. November 2009 23:59 > An: Jesske, Roland > Cc: thomas.belling@nsn.com; paul.while@ericsson.com; dispatch@ietf.org; calme@alcatel-lucent.com > Betreff: Re: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > > > R.Jesske@telekom.de wrote: >> Hello Paul, >> Thank you for your comment. I have the sam opinion. Due to the fact that 1xx is not done end to end > > 1xx means 101-199, excluding 100. Only 100 is hop by hop. All the 1xx > are end to end. > >> I have put the following sentence into the draft. >> >> The appearance of the Reason header is applicable to final responses >> 3xx, 4xx, 5xx and 6xx and 18x and 199 provisional responses >> [I-D.ietf-sipcore-199]. > > I'd prefer to see it just say 1xx. > > Thanks, > Paul > >> I hope that fits. >> >> Best Regards >> >> Roland >> >> -----Ursprüngliche Nachricht----- >> Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul Kyzivat >> Gesendet: Mittwoch, 11. November 2009 22:58 >> An: Belling, Thomas (NSN - DE/Munich) >> Cc: Paul While; dispatch@ietf.org; Jesske, Roland; ext Calme,James A (Jim) >> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> I hate to see *anything* restricted to 183, rather than being applicable >> to all 1xx (or at least 18x) responses. >> >> Restricting to 183 implies that there is something *special* about 183. >> I have seen that erroneous assumption in the wild too - and it is >> distressing. Anything you can do with 183 should also work with 180. >> >> Thanks, >> Paul >> >> Belling, Thomas (NSN - DE/Munich) wrote: >>> Dear Roland, >>> >>> we discussed the interworking of ISUP ACM and CPG causes to SIP reasons headers in provisional responses in 3GPP CT3 yesterday. >>> The conclusion was that we will only insert a reason header in a 183 provisional response. >>> >>> May I therefor suggest the following wording: >>> >>> The Reason header is applicable to 3xx, 4xx, 5xx and 6xx final responses >>> and 183 and 199 provisional responses. >>> >>> Further, it would be very helpfull for 3GPP if you could make the updated draft available very quickly as we have several dependent CRs in the 3GPP CTx meeting which is ongoing this week. >>> >>> Thomas >>> >>> >>> ---------------------------------- >>> Dr. Thomas Belling >>> 3GPP Standardisation >>> Nokia Siemens Networks >>> >>> >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Christer Holmberg >>> Sent: Tuesday, November 10, 2009 8:12 AM >>> To: Paul Kyzivat; R.Jesske@telekom.de >>> Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo >>> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>> >>> >>> Hi, >>> >>> A small editorial change proposal: >>> >>> "The appearance of the Reason header is applicable to 3xx, 4xx, 5xx and 6xx final responses and 18x and 199 provisional responsess." >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: 10. marraskuuta 2009 3:06 >>> To: R.Jesske@telekom.de >>> Cc: audet@nortel.com; dispatch@ietf.org; Gonzalo Camarillo >>> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>> >>> Roland, >>> >>> Thanks! That addresses my concern. >>> >>> Thanks, >>> Paul >>> >>> R.Jesske@telekom.de wrote: >>>> Hello Paul, >>>> Thanks for that hint. I will change this too. >>>> Like: >>>> >>>> The appearance of the Reason header is applicable to final responses >>>> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as defined within >>>> ietf-sipcore-199.txt. Also the Reason header is >>>> applicable to provisional responses18x. >>>> >>>> Best Regards >>>> >>>> Roland >>>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Gesendet: Montag, 9. November 2009 12:58 >>>> An: Jesske, Roland >>>> Cc: adam@nostrum.com; audet@nortel.com; dispatch@ietf.org; >>>> gonzalo.camarillo@ericsson.com >>>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>>> >>>> >>>> >>>> R.Jesske@telekom.de wrote: >>>>> Hi Adam, >>>>> Thank you for your mail. So I propose the following text then: >>>>> >>>>> The appearance of the Reason header is applicable to final responses >>>>> 3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as defined within >>>>> ietf-sipcore-199.txt. Also the Reason header is >>>>> applicable to provisional responses18x which are generated by an >>>>> interworking gateway from ISUP to SIP. >>>> I think this is ok *except* if you are going to allow one kind of UAS >>>> to use Reason in a 18x response, then it should be allowed for *any* >>>> UAS to do so. >>>> >>>> For instance, suppose the gateway is replaced by a B2BUA to another >>>> sip environment, and the request eventually arrives as a gateway. Then >>>> a 18x response with a Reason header may arrive at the B2BUA and need >>>> to be replicated on the other side. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Best Beagards >>>>> >>>>> Roland >>>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: Adam Roach [mailto:adam@nostrum.com] >>>>> Gesendet: Freitag, 6. November 2009 01:43 >>>>> An: Jesske, Roland >>>>> Cc: audet@nortel.com; christer.holmberg@ericsson.com; >>>>> gonzalo.camarillo@ericsson.com; dispatch@ietf.org >>>>> Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>>>> >>>>> On 8/6/09 7:28 PM, R.Jesske@telekom.de wrote: >>>>>> Hi Christer and Francois, >>>>>> I have added a sentence under section Overall Applicability: >>>>>> >>>>>> >>>>>> The appearance of the Reason header is applicable to final responses 4xx, 5xx and 6xx and in addition for 199 Responses. >>>>>> >>>>>> Is this proper enough? Or do you have more in mind? >>>>>> >>>>> Given that RFC 3398 specifies the generation of a 301 in response to >>>>> a cause code of 22 under certain circumstances, it seems pretty >>>>> appropriate to allow the inclusion of a Q.850 cause code in 300-class >>>>> responses also. Or, at least, as appropriate as it would be to >>>>> include them in 4xx, 5xx, and 6xx responses. >>>>> >>>>> /a >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From mary.barnes@nortel.com Wed Nov 11 07:41:04 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306ED3A672F for ; Wed, 11 Nov 2009 07:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.004, 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 J7Qcx151QHXX for ; Wed, 11 Nov 2009 07:41:03 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 290743A67F5 for ; Wed, 11 Nov 2009 07:41:03 -0800 (PST) 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 nABFfHT18941; Wed, 11 Nov 2009 15:41: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_01CA62E5.65B501FB" Date: Wed, 11 Nov 2009 09:39:26 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DREGS ad hoc Thread-Index: AcpiqLfMihG6O67mQge+mdHHRPO7OgAEr2QFAApsS8Y= References: From: "Mary Barnes" To: "Mary Barnes" , "Eric Burger" , Subject: Re: [dispatch] DREGS ad hoc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 15:41:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA62E5.65B501FB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The charts for this session have been uploaded to the meeting repository = under the DISPATCH WG - entitled "DREGS Adhoc". https://datatracker.ietf.org/meeting/76/materials.html Regards, Mary.=20 -----Original Message----- From: dispatch-bounces@ietf.org on behalf of Eric Burger Sent: Wed 11/11/2009 2:26 AM To: dispatch@ietf.org Subject: [dispatch] DREGS ad hoc =20 The DREGS ad hoc will be in Orchid East, 11.45 - 12.40 JT tomorrow =20 (Thursday). We do need scribes and jabber scribes. Please respond directly to me =20 to volunteer. Thanks. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------_=_NextPart_001_01CA62E5.65B501FB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dispatch] DREGS ad hoc

The charts for this session have been uploaded to the = meeting repository under the DISPATCH WG - entitled "DREGS = Adhoc".
https://d= atatracker.ietf.org/meeting/76/materials.html

Regards,
Mary.


-----Original Message-----
From: dispatch-bounces@ietf.org on behalf of Eric Burger
Sent: Wed 11/11/2009 2:26 AM
To: dispatch@ietf.org
Subject: [dispatch] DREGS ad hoc

The DREGS ad hoc will be in Orchid East, 11.45 - 12.40 JT = tomorrow 
(Thursday).

We do need scribes and jabber scribes.  Please respond directly to = me 
to volunteer.  Thanks.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch

------_=_NextPart_001_01CA62E5.65B501FB-- From eburger@standardstrack.com Wed Nov 11 13:09:47 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6188F3A682C for ; Wed, 11 Nov 2009 13:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2LlF+VKd0v6 for ; Wed, 11 Nov 2009 13:09:46 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 8AB2D3A67AE for ; Wed, 11 Nov 2009 13:09:42 -0800 (PST) Received: from host-113-35.meeting.ietf.org ([133.93.113.35]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N8KS5-0001Kr-MC for dispatch@ietf.org; Wed, 11 Nov 2009 13:10:05 -0800 Message-Id: From: Eric Burger To: dispatch@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 v936) Date: Thu, 12 Nov 2009 06:10:07 +0900 References: X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [dispatch] DREGS ad hoc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 21:09:47 -0000 We still need Scribes!!! On Nov 11, 2009, at 7:41 PM, Mary Barnes wrote: > > Orchard -> Orchid > > -----Original Message----- > From: dispatch-bounces@ietf.org on behalf of Eric Burger > Sent: Wed 11/11/2009 2:26 AM > To: dispatch@ietf.org > Subject: [dispatch] DREGS ad hoc > > The DREGS ad hoc will be in Orchard East, 11.45 - 12.40 JT tomorrow > (Thursday). > > We do need scribes and jabber scribes. Please respond directly to me > to volunteer. Thanks. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From david.middleton@nsn.com Wed Nov 11 13:13:17 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 842763A6A7C for ; Wed, 11 Nov 2009 13:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 LBZ4ITp-Rn-3 for ; Wed, 11 Nov 2009 13:13:12 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id D1CD73A69F8 for ; Wed, 11 Nov 2009 13:13:11 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nABLDYRK000583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2009 22:13:34 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nABLDYIQ016208; Wed, 11 Nov 2009 22:13:34 +0100 Received: from USCHEXC006.nsn-intra.net ([10.159.160.11]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 22:13:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 15:13:07 -0600 Message-ID: <159B27ECF9D16E40BD7ABD5778522B010389E177@USCHEXC006.nsn-intra.net> In-Reply-To: <4AEB78AD.5070608@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] To-URI in domain-registration Thread-Index: AcpZue9KRbQOCEeXRx6AR/epLJfHpAJV/yZw References: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com><9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> <024101ca528e$fbd0a8b0$f371fa10$@us> <159B27ECF9D16E40BD7ABD5778522B0103792C9C@USCHEXC006.nsn-intra.net> <4AEB78AD.5070608@cisco.com> From: "Middleton, David (NSN - US/Boca Raton)" To: "ext Paul Kyzivat" X-OriginalArrivalTime: 11 Nov 2009 21:13:34.0260 (UTC) FILETIME=[D3CF7F40:01CA6313] Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 21:13:17 -0000 Paul, Sorry for the delay in responding. I think you are on target as far as describing many (perhaps most) SP / = PBX interconnect arrangements. However, the functionality of having the = SP route calls per user is a real-world scenario which proves there is = merit for having the capability. Also see inline. David -----Original Message----- From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Friday, October 30, 2009 7:37 PM To: Middleton, David (NSN - US/Boca Raton) Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration David, IIUC, you are proposing a case such as: - a customer of sp.net has domain cust.sp.net - the customer has two PBX systems, east and west. - you propose that they register, respectively To: east@cust.sp.net, and To: west@cust.sp.net. - then numbers assigned to the customer are routed something like: 1-212-555-88xx -> contact from east@cust.sp.net 1-408-555-88xx -> contact from west@cust.sp.net - also, routing for names be something like: bob@cust.sp.net -> contact from east@cust.sp.net carol@cust.sp.net -> " ted@cust.sp.net -> contact from west@cust.sp.net alice@cust.sp.net -> " others... Is that right? Yes You then can't describe that as setting up routing paths for=20 cust.sp.net. You are instead describing some entirely different routing=20 algorithm based on the user part. Yes, it requires a local policy to determine the location of the = users. Subdomains east.cust.sp.net and west.cust.sp.net solve this problem in=20 large part - at least for the numbers. You clearly don't find that acceptable for the names. If those names=20 were exposed to end users I wouldn't find it acceptable either. (I want=20 to be pkyzivat@cisco.com, not pkyzivat@east.cisco.com.) Agreed The question is whether this is the best way to solve that problem. I think that solution won't be very acceptable to an SP, or to the=20 customer of that SP. Having the SP provision every one of your users=20 just isn't going to be popular with anyone. (Unless the SP gets a big=20 enough per-user fee.) I agree but if the parties involved reach an acceptable agreement, = the technology should support it IMO. Its not quite as much of a problem with numbers, because they are likely = to be managed in blocks. And the numbers are really owned/managed by the = SP anyway so they are forced to do something about them. This is also a problem that is not unique to this SP interconnect=20 mechanism. It is pretty much the same problem in any big company with a=20 lot of sites, even if they have a private network connecting all the = sites. What you need in this case is a proxy at the company domain level=20 (cust.sp.net in this case perhaps) that has the roster of all usernames=20 and a mapping to a subdomain - mapping bob@cust.sp.net to=20 bob@east.cust.sp.net. Yes but some enterprise customers do not want to do this and are = able to convince the SP to do this. Then, the company has one server registering To:cust.sp.net to provide=20 this mapping, and other servers registering To:east.cust.sp.net, ... Thanks, Paul Middleton, David (NSN - US/Boca Raton) wrote: > Some colleagues have pointed out an aspect that I had not considered = concerning the domain registration To: user part. There are cases where = an Enterprise has multiple PBXs that register and calls should be routed = to one of the PBXs based on which user is called. In other words, = instead of the Enterprise with multiple PBXs appearing as one logical = PBX, the Enterprise customer wants the service provider to take = responsibility for distributing the calls to the specific PBX that hosts = the called user. >=20 > While this problem could be solved with a local policy to choose one = of several contacts it is not as clean an approach as being able to = treat each registration as a separate entity with it's own contact(s). = While one could propose that these be treated separately by making = different sub-domains, the Enterprise most assuredly will not want to = publish this sub-domain on business cards, etc. when using e-mail style = addresses. Besides, it would cause the address to change if the user = moves from one PBX to another as might happen with a physical move. >=20 > Another aspect to consider is that the Enterprise user, in this = scenario, is only reachable via one registered "To: user@host". So not = having separate registrations would result in a more complex definition = and implementation of things like (a.) is there an unexpired binding and = (b.) picking appropriate contacts by q-value. >=20 > I think this makes a strong case for having a user part in the To: = header and treating each unique user@host as a separate registration =E0 = la RFC 3264. >=20 > In summary, I support Option 1) as well. >=20 > - David >=20 > =20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext Richard Shockey > Sent: Wednesday, October 21, 2009 4:42 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] To-URI in domain-registration >=20 > +1 to Option 1) as well >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On >> Behalf Of David Hancock >> Sent: Wednesday, October 21, 2009 4:05 PM >> To: Brian Lindsay; Hadriel Kaplan; dispatch@ietf.org >> Subject: Re: [dispatch] To-URI in domain-registration >> =20 >> =20 >> Hadriel - I'd prefer option 1) as well. >> =20 >> David >> =20 >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On >> > Behalf Of Brian Lindsay >> > Sent: Wednesday, October 21, 2009 1:53 PM >> > To: Hadriel Kaplan; dispatch@ietf.org >> > Subject: Re: [dispatch] To-URI in domain-registration >> > >> > Hi Hadriel, >> > >> > Per my comment yesterday, I'd prefer (1). >> > >> > Thanks. >> > >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On >> > Behalf Of Hadriel Kaplan >> > Sent: Wednesday, October 21, 2009 3:43 PM >> > To: dispatch@ietf.org >> > Subject: [dispatch] To-URI in domain-registration >> > >> > Howdy, >> > I'd like to get a consensus call on the question of what the = To-URI >> > should be for the REGISTER request of a domain registration, = before >> > finishing the next rev of the draft. This will affect quite a bit >> of >> > text in the draft (e.g., examples), and I think that the decision >> about >> > that will also affect whether we need more than a = Require:option-tag >> as >> > well. >> > >> > The choices right now are: >> > 1) Mandate the To-URI be in the syntactical form of an AoR, >> including >> > the user@ portion, the same as the From-URI. >> > Pros: closer to what current proprietary and other-SDO >> > mechanisms do, on the wire. Therefore, presumably less of a = change >> and >> > less barrier to adoption. >> > 2) Mandate the To-URI be a domain only (no user@), while the From- >> URI >> > remains the "AoR" of the PBX registering. >> > Pros: semantically accurate (you're registering a domain, not an >> > AoR), and may obviate the need for a new header or param to = indicate >> > this new mechanism is being used. >> > >> > Can people please indicate which they'd prefer? >> > >> > Thanks! >> > -hadriel >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From spencer@wonderhamster.org Wed Nov 11 14:24:50 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE363A693B for ; Wed, 11 Nov 2009 14:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 2xv+I8O-40QM for ; Wed, 11 Nov 2009 14:24:49 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 743CE3A68F2 for ; Wed, 11 Nov 2009 14:24:47 -0800 (PST) Received: from S73602b (host-193-214.meeting.ietf.org [133.93.193.214]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Ln8s9-1MTUR00S8z-00hsTj; Wed, 11 Nov 2009 17:25:14 -0500 Message-ID: From: "Spencer Dawkins" To: "Eric Burger" , References: Date: Thu, 12 Nov 2009 07:24:54 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+eEqic8ScarQyHzvSKvg8x/pczYsvHgh9glSx SdY0qF6fDUhcaNam8PKzGRp7Cqy999IN03KqRmuaLENRjnEytJ uT/mUY6CnvaGc/9ohxdFn7Wc8mKF7N6BjCfuKghR4w= Subject: Re: [dispatch] DREGS ad hoc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 22:24:50 -0000 And at least one of The Usual Suspects is helping to present!!! so can't reasonably be drafted at the beginning of the session without this turning into a DoS attack!!! :-) > We still need Scribes!!! Spencer!!! From pkyzivat@cisco.com Wed Nov 11 14:34:36 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FAF3A697D for ; Wed, 11 Nov 2009 14:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 5ZGRHPdFPqWx for ; Wed, 11 Nov 2009 14:34:34 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2378C3A68A4 for ; Wed, 11 Nov 2009 14:34:34 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKfK+kpAZnwN/2dsb2JhbADFPJgMhDwE X-IronPort-AV: E=Sophos;i="4.44,725,1249257600"; d="scan'208";a="67571048" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2009 22:35:01 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nABMZ16B000811; Wed, 11 Nov 2009 22:35:02 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 17:35:01 -0500 Received: from [161.44.182.192] ([161.44.182.192]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 17:35:01 -0500 Message-ID: <4AFB3C0F.40203@cisco.com> Date: Wed, 11 Nov 2009 17:34:55 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Middleton, David (NSN - US/Boca Raton)" References: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com><9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> <024101ca528e$fbd0a8b0$f371fa10$@us> <159B27ECF9D16E40BD7ABD5778522B0103792C9C@USCHEXC006.nsn-intra.net> <4AEB78AD.5070608@cisco.com> <159B27ECF9D16E40BD7ABD5778522B010389E177@USCHEXC006.nsn-intra.net> In-Reply-To: <159B27ECF9D16E40BD7ABD5778522B010389E177@USCHEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2009 22:35:01.0593 (UTC) FILETIME=[34E35490:01CA631F] Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 22:34:36 -0000 Middleton, David (NSN - US/Boca Raton) wrote: > Paul, > > Sorry for the delay in responding. > > I think you are on target as far as describing many (perhaps most) SP / PBX interconnect arrangements. However, the functionality of having the SP route calls per user is a real-world scenario which proves there is merit for having the capability. This could still be dealt with by having the pbxes register to separate sub-domains and the SP knowing (via provisioning) which things to route to each. So instead of having: foo-east-pbx register to east@foo.sp.com foo-west-pbx register to west@foo.sp.com you could simply have foo-east-pbx register to east.foo.sp.com foo-west-pbx register to west.foo.sp.com Then the question of how requests addressed to xyz@foo.sp.com are mapped to something@east.foo.sp.com or something@west.foo.sp.com is simply out of scope of this document. Thanks, Paul > Also see inline. > > David > > > > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, October 30, 2009 7:37 PM > To: Middleton, David (NSN - US/Boca Raton) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] To-URI in domain-registration > > David, > > IIUC, you are proposing a case such as: > > - a customer of sp.net has domain cust.sp.net > - the customer has two PBX systems, east and west. > - you propose that they register, respectively > To: east@cust.sp.net, and > To: west@cust.sp.net. > - then numbers assigned to the customer are routed > something like: > 1-212-555-88xx -> contact from east@cust.sp.net > 1-408-555-88xx -> contact from west@cust.sp.net > - also, routing for names be something like: > bob@cust.sp.net -> contact from east@cust.sp.net > carol@cust.sp.net -> " > ted@cust.sp.net -> contact from west@cust.sp.net > alice@cust.sp.net -> " > others... > > Is that right? > Yes > > You then can't describe that as setting up routing paths for > cust.sp.net. You are instead describing some entirely different routing > algorithm based on the user part. > Yes, it requires a local policy to determine the location of the users. > > Subdomains east.cust.sp.net and west.cust.sp.net solve this problem in > large part - at least for the numbers. > > You clearly don't find that acceptable for the names. If those names > were exposed to end users I wouldn't find it acceptable either. (I want > to be pkyzivat@cisco.com, not pkyzivat@east.cisco.com.) > Agreed > > The question is whether this is the best way to solve that problem. > > I think that solution won't be very acceptable to an SP, or to the > customer of that SP. Having the SP provision every one of your users > just isn't going to be popular with anyone. (Unless the SP gets a big > enough per-user fee.) > I agree but if the parties involved reach an acceptable agreement, the technology should support it IMO. > > Its not quite as much of a problem with numbers, because they are likely > to be managed in blocks. And the numbers are really owned/managed by the > SP anyway so they are forced to do something about them. > > This is also a problem that is not unique to this SP interconnect > mechanism. It is pretty much the same problem in any big company with a > lot of sites, even if they have a private network connecting all the sites. > > What you need in this case is a proxy at the company domain level > (cust.sp.net in this case perhaps) that has the roster of all usernames > and a mapping to a subdomain - mapping bob@cust.sp.net to > bob@east.cust.sp.net. > Yes but some enterprise customers do not want to do this and are able to convince the SP to do this. > > Then, the company has one server registering To:cust.sp.net to provide > this mapping, and other servers registering To:east.cust.sp.net, ... > > Thanks, > Paul > > > Middleton, David (NSN - US/Boca Raton) wrote: >> Some colleagues have pointed out an aspect that I had not considered concerning the domain registration To: user part. There are cases where an Enterprise has multiple PBXs that register and calls should be routed to one of the PBXs based on which user is called. In other words, instead of the Enterprise with multiple PBXs appearing as one logical PBX, the Enterprise customer wants the service provider to take responsibility for distributing the calls to the specific PBX that hosts the called user. >> >> While this problem could be solved with a local policy to choose one of several contacts it is not as clean an approach as being able to treat each registration as a separate entity with it's own contact(s). While one could propose that these be treated separately by making different sub-domains, the Enterprise most assuredly will not want to publish this sub-domain on business cards, etc. when using e-mail style addresses. Besides, it would cause the address to change if the user moves from one PBX to another as might happen with a physical move. >> >> Another aspect to consider is that the Enterprise user, in this scenario, is only reachable via one registered "To: user@host". So not having separate registrations would result in a more complex definition and implementation of things like (a.) is there an unexpired binding and (b.) picking appropriate contacts by q-value. >> >> I think this makes a strong case for having a user part in the To: header and treating each unique user@host as a separate registration à la RFC 3264. >> >> In summary, I support Option 1) as well. >> >> - David >> >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Richard Shockey >> Sent: Wednesday, October 21, 2009 4:42 PM >> To: dispatch@ietf.org >> Subject: Re: [dispatch] To-URI in domain-registration >> >> +1 to Option 1) as well >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of David Hancock >>> Sent: Wednesday, October 21, 2009 4:05 PM >>> To: Brian Lindsay; Hadriel Kaplan; dispatch@ietf.org >>> Subject: Re: [dispatch] To-URI in domain-registration >>> >>> >>> Hadriel - I'd prefer option 1) as well. >>> >>> David >>> >>> > -----Original Message----- >>> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >>> On >>> > Behalf Of Brian Lindsay >>> > Sent: Wednesday, October 21, 2009 1:53 PM >>> > To: Hadriel Kaplan; dispatch@ietf.org >>> > Subject: Re: [dispatch] To-URI in domain-registration >>> > >>> > Hi Hadriel, >>> > >>> > Per my comment yesterday, I'd prefer (1). >>> > >>> > Thanks. >>> > >>> > -----Original Message----- >>> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >>> On >>> > Behalf Of Hadriel Kaplan >>> > Sent: Wednesday, October 21, 2009 3:43 PM >>> > To: dispatch@ietf.org >>> > Subject: [dispatch] To-URI in domain-registration >>> > >>> > Howdy, >>> > I'd like to get a consensus call on the question of what the To-URI >>> > should be for the REGISTER request of a domain registration, before >>> > finishing the next rev of the draft. This will affect quite a bit >>> of >>> > text in the draft (e.g., examples), and I think that the decision >>> about >>> > that will also affect whether we need more than a Require:option-tag >>> as >>> > well. >>> > >>> > The choices right now are: >>> > 1) Mandate the To-URI be in the syntactical form of an AoR, >>> including >>> > the user@ portion, the same as the From-URI. >>> > Pros: closer to what current proprietary and other-SDO >>> > mechanisms do, on the wire. Therefore, presumably less of a change >>> and >>> > less barrier to adoption. >>> > 2) Mandate the To-URI be a domain only (no user@), while the From- >>> URI >>> > remains the "AoR" of the PBX registering. >>> > Pros: semantically accurate (you're registering a domain, not an >>> > AoR), and may obviate the need for a new header or param to indicate >>> > this new mechanism is being used. >>> > >>> > Can people please indicate which they'd prefer? >>> > >>> > Thanks! >>> > -hadriel >>> > _______________________________________________ >>> > dispatch mailing list >>> > dispatch@ietf.org >>> > https://www.ietf.org/mailman/listinfo/dispatch >>> > _______________________________________________ >>> > dispatch mailing list >>> > dispatch@ietf.org >>> > https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From stpeter@stpeter.im Wed Nov 11 16:52:03 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F2928C165 for ; Wed, 11 Nov 2009 16:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.794 X-Spam-Level: X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[AWL=-0.195, 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 tp7ONeMTZXqp for ; Wed, 11 Nov 2009 16:52:02 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5B56628C12D for ; Wed, 11 Nov 2009 16:52:02 -0800 (PST) Received: from host-18-99.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A51D440D09; Wed, 11 Nov 2009 17:52:29 -0700 (MST) Message-ID: <4AFB5C49.3090204@stpeter.im> Date: Thu, 12 Nov 2009 09:52:25 +0900 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060400070009020509030108" Cc: dispatch@ietf.org Subject: Re: [dispatch] Agenda for SIP/XMPP co-existence ad-hoc meeting on Friday Nov 13 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 00:52:03 -0000 This is a cryptographically signed message in MIME format. --------------ms060400070009020509030108 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/10/09 11:14 AM, Simo.Veikkolainen@nokia.com wrote: > Hello, > > Here is the proposed agenda for the DISPATCH WG ad-hoc session on > SIP/XMPP co-existence scheduled for Friday Nov 13, 2009, at > 13:00-15:00 at room Cattleya West. The ad-hoc session will be chaired > by Gonzalo Camarillo. I'm really sorry that I won't be there. > 1. Motivation and objectives of SIP/XMPP co-existence (10 min) > > 2. Overview of solution space (15 min) - baseline proposal > http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01 > > 3. Technical issues discussed so far (15 min) - > http://www.ietf.org/mail-archive/web/dispatch/current/msg00845.html > > 4. Discussion on charter proposal (30 min) - > http://www.ietf.org/mail-archive/web/dispatch/current/msg00560.html > > 5. Conclusion and next steps My overriding concern is that we keep it simple (SIMPLE?) and focus on some small practical tasks first, to solve "pain points" among existing implementations and deployments. Clearly, many use cases and scenarios might be interesting eventually, but first let's do things that might have an immediate impact. That said, I would be happy to put some time into the draft-saintandre-sip-xmpp-* document series if we feel that's needed. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms060400070009020509030108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTExMjAwNTIyNVowIwYJKoZIhvcNAQkEMRYEFD+G1XUFF3FDwFHVPppV YLt3S6Z/MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAdLwbJPYwvUwhSw3OTd8/9JR0cs9PZ1175iC3wXOb MvJpO2tT45C6vnH+Azt+bdodP3dru/+/cajtwv95VwNv76clUG2J8U/hsNUwPbIlOxu4i0L3 kGu4BPjqahzKsCCcVCfEiYMcY+D2PKjtWEMv0KYB3F/qp4BSzLT2w/zgEg67uLFBGp9nQMbp Is6rr65jv4LD42M1wyNbWrVknrbJi7UzDFfHkwsAQN4QGDDucVhe2G8AP2oKP0YLxH13HLod 7ZmGNgksPJk+GGGqsx5p+WsrXO760mP1JttY7PnR9Yz2nKKN3iUPLRlsAbSFU61RK7rjeUdq VcGS7l9QlfQHOAAAAAAAAA== --------------ms060400070009020509030108-- From mary.barnes@nortel.com Wed Nov 11 22:55:38 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA21F3A6A4F for ; Wed, 11 Nov 2009 22:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.010, 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 D4QwcWDl4QVD for ; Wed, 11 Nov 2009 22:55:37 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B0A433A6853 for ; Wed, 11 Nov 2009 22:55:37 -0800 (PST) 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 nAC6u1Q24834 for ; Thu, 12 Nov 2009 06:56:01 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_01CA6365.311EB083" Date: Thu, 12 Nov 2009 00:56:00 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting notes: DREGS Adhoc Thread-Index: AcpjZTEV+4KYCML9SYOEdphHl5XREg== From: "Mary Barnes" To: Subject: [dispatch] Meeting notes: DREGS Adhoc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 06:55:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6365.311EB083 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, The notes from the DREGS Adhoc held today from 11:45-12:50 are available = on the DISPATCH WG supplemental webpage: http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/DREGS-adhoc-note= s-shida.txt http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/DREGS Adhoc = Meeting notes-jmce.doc=09 Regards, Mary.=20 ------_=_NextPart_001_01CA6365.311EB083 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Meeting notes: DREGS Adhoc

Hi all,

The notes from the DREGS Adhoc held today from 11:45-12:50 are available = on the DISPATCH WG supplemental webpage:
http://www.softarmor.com/dispatch/IETF76/Meeting%20n= otes/DREGS-adhoc-notes-shida.txt
h= ttp://www.softarmor.com/dispatch/IETF76/Meeting%20notes/DREGS Adhoc = Meeting notes-jmce.doc    


Regards,
Mary.

------_=_NextPart_001_01CA6365.311EB083-- From eburger@standardstrack.com Thu Nov 12 00:14:15 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9356128C0CE for ; Thu, 12 Nov 2009 00:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, 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 Y9uoWEcVKDWd for ; Thu, 12 Nov 2009 00:14:02 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 998243A6935 for ; Thu, 12 Nov 2009 00:13:56 -0800 (PST) Received: from host-40-25.meeting.ietf.org ([133.93.40.25]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N8Uov-0002os-IW for dispatch@ietf.org; Thu, 12 Nov 2009 00:14:22 -0800 Message-Id: <3902F3D7-0D42-44A0-AC01-4BE8782A3AD3@standardstrack.com> From: Eric Burger To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-63-533587073 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Nov 2009 17:14:21 +0900 X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [dispatch] DREGS Ad Hoc minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 08:14:15 -0000 --Apple-Mail-63-533587073 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable DREGS Adhoc Thursday 12 November 2009, 11:30 =96 1:00 Chairs: Eric Burger and Mary Barnes Scribes: Shida Schubert and Jim McEachern John Elwell =96 Charter Discussion. http://www.ietf.org/proceedings/09nov/slides/dispatch-6.ppt Jon Peterson reacted to the John=92s statement that =93decided we needed = a =20 new WG=94 and said that he had suggested it perhaps should be in =20 DRINKS. Was concerned about the presumption of what needs to be done =20= to address the open issue. Cullen: the purpose of dispatch is to recommend what should be done. =20= So we could recommend it go to DRINKS or wherever. Let=92s see what we =20= recommend. Clarified that the proposal was that this should be looked at, not =20 that a WG was needed. Trying to standardize a uniform way for PBXs to register their =20 domain. Today everyone does it their own way, even though they are =20 all very similar. Proposing to use REGISTER with an added header for requesting domain =20 registration. They are proposing this approach because it builds on =20 what is already widely deployed. Adam Roach: Are we really proposing to write the use of REGISTER in =20 the charter? Answer: Yes. Adam stated that he was not prepared to =20 have that discussion today because he thought it would be discussed in =20= the WG. This feels like =93let=92s ratify this draft=94 rather than = =93let=92s =20 work on this problem=94. Spencer Dawkins: the intent is not to ratify existing draft. Note: In spite of Spencer=92s statement, the ensuing discussion made it = =20 very clear that for at least some of the authors, the intent was in =20 fact very much to ratify this draft, or something very near it. =20 Apparently the initial charter draft did not mention REGISTER and it =20 was included because SIP Forum participants explicitly asked for it to =20= be added. Eric: the subject of whether or not REGISTER should be included in the =20= charter has been discussed on the list, but there is not consensus Someone stated that REGISTER was proposed because =93that is what is =20 implemented=94 and we need to align with those implementations to be =20 relevant. Jon countered that earlier it had been stated that the =20 entire reason for this is that there are multiple ways this is =20 implemented and that we need a standard to get interoperability. So =20 if it is being done multiple ways today, the argument that REGISTER =20 needs to be in the charter to align with deployed equipment, simply =20 does not fly. Cable Labs supported the use of REGISTER because that is what they use =20= in their specifications. Jim McEachern & Adam Roach both pointed out that even if you remove =20 the word REGISTER from the charter, it does not mean that the eventual =20= solution will have REGISTER. The bulk of the objections (dare I say =20 the allergic reaction?) is to the fact that the solution (REGISTER) is =20= being specified in the charter, when we should be simply defining the =20= problem we are trying to solve. Anwar Siddiqi Asked about the definition of small =96 medium business, =20= and said that this will not apply to large enterprises since they will =20= never give their register information to the SP. Therefore why not =20 make it optional. Markus Isomaki, Nokia: What does this imply about the addresses of =20 the terminals behind the PBX? Answer: UA registers with the PBX, but =20= this work deals with the PBX registering with the SP. It is designed =20= to help the SP work out where to send requests to =93example.com=94. Jon Peterson: Charter scope question. Is the charter focused on the =20= specific problem on the slide, or the more general problem? (Note: I =20 think this was referring to the bullets specifying =93a header field for = =20 requesting domain registration=94 and =93a SIP option tag to detect non-=20= support of this mechanism=94.) Answer: The more general one. (Note: =20= I think this meant the general problem of PBXs registering=85) Jon Peterson: The only way this charter will get approved is by =20 taking REGISTER out of the draft. Lots of nods to that. Spencer: If this looks like tweaking existing implementations, it =20 will get more interest than if it looked like a new method. =20 Preference is to be up front about this. Cullen (channeling Hadriel): If Hadriel were here he would insist it =20= must be REGISTER or it will never be deployed. Cullen: would the possible solution space now include dynamic dns? =20 The only reason to specify a solution in the charter is to explicitly =20= exclude alternate classes of solution =96 isn=92t it? Chris Stanley =96 cable labs. We need to deploy this for businesses and = =20 need to move quickly. (And REGISTER is the mechanism we use.) Adam Roach: how far are we going to go down this path of specifying =20 the answer in the charter? If we allow it for REGISTER for this WG, =20 what other things are we going to do it for? Cullen as AD: He was the one who earlier encouraged them to be very =20 specific to see if they could get consensus on the approach to shorten =20= the process, even though he suspected the proposal would get the =20 reaction that it is currently getting. However, if the group cannot =20 get consensus to specify the solution in the charter, then the only =20 approach is to remove it. This is clearly the case. Hum: Should we leave the charter exactly as it is? Result: Moderate =20= hum Hum: Should we leave the charter largely as is, but remove the =20 solution (REGISTER) from the charter. Result: Strong hum. Discussed a vote on =93Is there a critical mass in the IETF to work on =20= this problem?=94, but instead decided on the following wording. Hum: Does anyone think that we don=92t have the critical mass and the =20= expertise to tackle this. Result: no one objected. So consensus for =20= this. Hum: is the IETF the place to work on this? Answer: yes Note: The following happened after the meeting had officially closed, =20= but is included here because it pointed toward a possible way forward. Jon: Discussion of the precedent setting risks of just adopting an =20 existing solution. One way forward may be to think about this as a =20 telephone number problem rather than a domain problem, which would =20 make it a much easier problem. If we can scope it that way then it =20 will make it a much quicker problem to solve. Alan Johnston: All the SIP Forum discussion is in fact about =20 telephone numbers, so restricting it to telephone numbers is what we =20 are looking for Cullen: Recognize that we do need to find ways to work faster. =93If =20= you send me a charter by midnight tonight, I will have it on the =20 agenda for the next IESG meeting=94 Meeting officially closed. Since we had time, we had an open discussion of how to make progress=85 Discussion of what would be realistic dates for this? The discussion =20= indicated that March and June might be more believable dates. Cullen: Recognize that we do need to find ways to work faster. =93If =20= you send me a charter by midnight tonight, I will have it on the =20 agenda for the next IESG meeting=94 Robert Sparks: Recipe for success in SDOs cooperating is having a =20 significant overlap of common participants working on the problem. He =20= is concerned that the overlap is not enough. Spencer: Last SIP Forum meeting had 12 people and 7 of them were also =20= in the IETF. Is that enough? Jon: Discussion of the precedent setting risks of just adopting an =20 existing solution. One way forward may be to think about this as a =20 telephone number problem rather than a domain problem, then it is a =20 much easier problem. If we can scope it that way then it will make it =20= a much easier problem to solve. Alan Johnston: All the SIP Forum discussion is in fact about =20 telephone numbers, so restricting it to telephone numbers would be =20 acceptable.=20 =20= --Apple-Mail-63-533587073 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

DREGS Adhoc

Thursday 12 = November 2009, 11:30 =96 1:00

Chairs: Eric = Burger and Mary Barnes

Scribes: Shida Schubert = and Jim McEachern

 

John Elwell =96 Charter Discussion.

http:= //www.ietf.org/proceedings/09nov/slides/dispatch-6.ppt

 

Jon Peterson reacted to the John=92s = statement that =93decided we needed a new WG=94 and said that he had suggested it perhaps should = be in DRINKS.  Was concerned = about the presumption of what needs to be done to address the open issue.

 

Cullen:  the purpose of dispatch is to recommend what should be done.  So we could recommend it go to = DRINKS or wherever.  Let=92s see = what we recommend.

 

Clarified that the proposal was that this should be = looked at, not that a WG was needed.

Trying to = standardize a uniform way for PBXs to register their domain.  Today = everyone does it their own way, even though they are all very similar.

Proposing to use REGISTER with an added header for requesting domain registration.  They are proposing this approach because it builds on what is = already widely deployed.

 

Adam Roach:  Are we really proposing to write the use of REGISTER in the charter?  Answer: = Yes.  Adam stated that he = was not prepared to have that discussion today because he thought it would be discussed in = the WG.  This feels like = =93let=92s ratify this draft=94 rather than =93let=92s work on this problem=94.

 

Spencer= Dawkins: the intent is not to ratify existing draft.

Note:  In spite of Spencer=92s = statement, the ensuing discussion made it very clear that for at least some of the = authors, the intent was in fact very much to ratify this draft, or something very = near it.  Apparently the = initial charter draft did not mention REGISTER and it was included because SIP Forum participants explicitly asked for it to be added.

 

Eric: the subject of whether or not REGISTER = should be included in the charter has been discussed on the list, but there is = not consensus

 

Someone stated that REGISTER was proposed because = =93that is what is implemented=94 and we need to align with those implementations = to be relevant.  Jon = countered that earlier it had been stated that the entire reason for this is that = there are multiple ways this is implemented and that we need a standard to get interoperability.  So if = it is being done multiple ways today, the argument that REGISTER needs to be = in the charter to align with deployed equipment, simply does not fly.

 

Cable = Labs supported the use of REGISTER because that is what they use in their specifications.

 

Jim = McEachern & Adam Roach both pointed out that even if you remove the word REGISTER from the charter, it does not mean = that the eventual solution will have REGISTER.  The bulk of the objections (dare I say the allergic reaction?) is = to the fact that the solution (REGISTER) is being specified in the charter, = when we should be simply defining the problem we are trying to solve.

 

Anwar = Siddiqi Asked about the definition of small =96 medium business, and said that this will not apply to large enterprises = since they will never give their register information to the SP.  Therefore why not make it = optional.

 

Markus Isomaki, Nokia:  What does this imply about the addresses of the = terminals behind the PBX?  = Answer: UA registers with the PBX, but this work deals with the PBX registering = with the SP.  It is designed to = help the SP work out where to send requests to =93example.com=94.

 

Jon = Peterson:  Charter scope question.  = Is the charter focused on the specific problem on the slide, or the more = general problem? (Note: I think this was referring to the bullets specifying = =93a header field for requesting domain registration=94 and =93a SIP option = tag to detect non-support of this mechanism=94.)   Answer: The more general one.  (Note:  I think this meant the general problem of PBXs = registering=85)

 

Jon Peterson:  The only way this charter will get approved is by taking REGISTER = out of the draft.  Lots of nods = to that.

 

Spencer:  If this looks like tweaking existing implementations, it will get = more interest than if it looked like a new method.  Preference is to be up front about this.

 

Cullen = (channeling Hadriel):  = If Hadriel were here he would insist it must be REGISTER or it will never be deployed.

 

Cullen: would the possible solution space now = include dynamic dns?  The only = reason to specify a solution in the charter is to explicitly exclude alternate classes of solution =96 isn=92t it?

 

Chris Stanley =96 cable labs.  We need to deploy this for businesses and need to = move quickly.  (And REGISTER is = the mechanism we use.)

 

Adam Roach:  how far are we going to go down this path of specifying the = answer in the charter?  If we allow = it for REGISTER for this WG, what other things are we going to do it for?

 

Cullen = as AD:  He was the one who earlier encouraged them to be very specific to = see if they could get consensus on the approach to shorten the process, even = though he suspected the proposal would get the reaction that it is currently = getting.  However, if the = group cannot get consensus to specify the solution in the charter, then the only approach = is to remove it.  This is = clearly the case.

 

Hum:  = Should we leave the charter exactly as it is?  Result: Moderate hum

 

Hum:  = Should we leave the charter largely as is,  but remove the solution (REGISTER) from the charter.  Result: Strong = hum.

 

Discussed a vote on =93Is there a critical mass in = the IETF to work on this problem?=94, but instead decided on the following = wording.

 

Hum:  Does anyone think that we don=92t have the critical mass and the = expertise to tackle this.  = Result:  no = one objected.  So = consensus for this.

 

Hum: is the IETF the place to work on = this?  Answer: = yes

 

Note:  = The following happened after the meeting had officially closed, but is = included here because it pointed toward a possible way = forward.

Jon: Discussion of the precedent setting risks of just adopting an existing = solution.  One way forward = may be to think about this as a telephone number problem rather than a domain problem, which = would make it a much easier problem.  = If we can scope it that way then it will make it a much quicker problem to = solve.

Alan Johnston:  All the SIP Forum discussion = is in fact about telephone numbers, so restricting it to telephone numbers is what = we are looking for

 

Cullen:  Recognize that we do need to = find ways to work faster.  =93If you = send me a charter by midnight tonight, I will have it on the agenda for the next = IESG meeting=94

 

Meeting officially = closed.

 

Since = we had time, we had an open discussion of how to make progress=85

 

Discussion= of what would be realistic dates for this?  The discussion indicated that March and June might be more believable dates.

 

Cullen:  Recognize that we do need to find ways to work faster.  =93If you send me a charter by = midnight tonight, I will have it on the agenda for the next IESG meeting=94

 

Robert Sparks:  Recipe for success in SDOs cooperating is having a significant = overlap of common participants working on the problem.  He is concerned that the overlap is not enough.

 

Spencer:  Last SIP Forum meeting had 12 people and 7 of them were also in = the IETF.  Is that = enough?

 

Jon: Discussion of the precedent setting = risks of just adopting an existing solution.  One way forward may be to think about this as a telephone number = problem rather than a domain problem, then it is a much easier problem.  If we can scope it that way = then it will make it a much easier problem to solve.

 

Alan = Johnston:  All the SIP Forum discussion is in fact about telephone numbers, = so restricting it to telephone numbers would be acceptable.   

= --Apple-Mail-63-533587073-- From spencer@wonderhamster.org Thu Nov 12 00:25:59 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF0B3A6A5A for ; Thu, 12 Nov 2009 00:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.606, 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 ty2yZYwX0e9I for ; Thu, 12 Nov 2009 00:25:57 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 2A9813A6935 for ; Thu, 12 Nov 2009 00:25:57 -0800 (PST) Received: from S73602b (host-24-135.meeting.ietf.org [133.93.24.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MJik0-1N9aw93y4q-001fFs; Thu, 12 Nov 2009 03:26:24 -0500 Message-ID: From: "Spencer Dawkins" To: "Eric Burger" , References: <3902F3D7-0D42-44A0-AC01-4BE8782A3AD3@standardstrack.com> Date: Thu, 12 Nov 2009 17:26:00 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4360_01CA63BD.341412E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+TZ2f1UmgL7vRMIpZ1fh4w5TueId1JWu+Jq80 i/Ez4ictcTXM5/xVk/RhH0BqVDZmyHqrge9l1xsBHzIeAUeQPG Npe9/SUlaojaZl0rnzGQC9bVAuAPDHJ1T/uqbkcw8Y= Subject: Re: [dispatch] DREGS Ad Hoc minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 08:25:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_4360_01CA63BD.341412E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Shida and Jim, Thanks for taking notes and publishing them quickly. What *I* thought happened (very close to the end of the meeting), was = that=20 - Robert expressed his concern that SIP Forum participation and IETF = participation didn't overlap, and this was a problem because that's the = IESG's experience with inter-SDO coordination is that nothing good = happens unless there's sufficient overlap, - Spencer said something like "we had about 12 (and John said 14) = participants at the last SIPconnect face-to-face, and about 7 were = regular IETF attendees, is that enough overlap?", and=20 - Robert said he didn't think so. Others can, of course, confirm (and the audio will probably be available = in a small number of days), but it's going to be real important to tease = a way forward on this, and I don't want the notes to give the impression = that Robert was convinced when I asked my question. Thanks, Spencer ----- Original Message -----=20 From: Eric Burger=20 To: dispatch@ietf.org=20 Sent: Thursday, November 12, 2009 5:14 PM Subject: [dispatch] DREGS Ad Hoc minutes DREGS Adhoc Thursday 12 November 2009, 11:30 =96 1:00 Chairs: Eric Burger and Mary Barnes Scribes: Shida Schubert and Jim McEachern John Elwell =96 Charter Discussion. http://www.ietf.org/proceedings/09nov/slides/dispatch-6.ppt=20 Jon Peterson reacted to the John=92s statement that =93decided we = needed a new WG=94 and said that he had suggested it perhaps should be = in DRINKS. Was concerned about the presumption of what needs to be done = to address the open issue. Cullen: the purpose of dispatch is to recommend what should be done. = So we could recommend it go to DRINKS or wherever. Let=92s see what we = recommend. Clarified that the proposal was that this should be looked at, not = that a WG was needed. Trying to standardize a uniform way for PBXs to register their domain. = Today everyone does it their own way, even though they are all very = similar. Proposing to use REGISTER with an added header for requesting domain = registration. They are proposing this approach because it builds on = what is already widely deployed. Adam Roach: Are we really proposing to write the use of REGISTER in = the charter? Answer: Yes. Adam stated that he was not prepared to have = that discussion today because he thought it would be discussed in the = WG. This feels like =93let=92s ratify this draft=94 rather than = =93let=92s work on this problem=94. Spencer Dawkins: the intent is not to ratify existing draft. Note: In spite of Spencer=92s statement, the ensuing discussion made = it very clear that for at least some of the authors, the intent was in = fact very much to ratify this draft, or something very near it. = Apparently the initial charter draft did not mention REGISTER and it was = included because SIP Forum participants explicitly asked for it to be = added. Eric: the subject of whether or not REGISTER should be included in the = charter has been discussed on the list, but there is not consensus Someone stated that REGISTER was proposed because =93that is what is = implemented=94 and we need to align with those implementations to be = relevant. Jon countered that earlier it had been stated that the entire = reason for this is that there are multiple ways this is implemented and = that we need a standard to get interoperability. So if it is being done = multiple ways today, the argument that REGISTER needs to be in the = charter to align with deployed equipment, simply does not fly. Cable Labs supported the use of REGISTER because that is what they use = in their specifications. Jim McEachern & Adam Roach both pointed out that even if you remove = the word REGISTER from the charter, it does not mean that the eventual = solution will have REGISTER. The bulk of the objections (dare I say the = allergic reaction?) is to the fact that the solution (REGISTER) is being = specified in the charter, when we should be simply defining the problem = we are trying to solve. Anwar Siddiqi Asked about the definition of small =96 medium business, = and said that this will not apply to large enterprises since they will = never give their register information to the SP. Therefore why not make = it optional. Markus Isomaki, Nokia: What does this imply about the addresses of = the terminals behind the PBX? Answer: UA registers with the PBX, but = this work deals with the PBX registering with the SP. It is designed to = help the SP work out where to send requests to =93example.com=94. Jon Peterson: Charter scope question. Is the charter focused on the = specific problem on the slide, or the more general problem? (Note: I = think this was referring to the bullets specifying =93a header field for = requesting domain registration=94 and =93a SIP option tag to detect = non-support of this mechanism=94.) Answer: The more general one. = (Note: I think this meant the general problem of PBXs registering=85) Jon Peterson: The only way this charter will get approved is by = taking REGISTER out of the draft. Lots of nods to that. Spencer: If this looks like tweaking existing implementations, it = will get more interest than if it looked like a new method. Preference = is to be up front about this. Cullen (channeling Hadriel): If Hadriel were here he would insist it = must be REGISTER or it will never be deployed. Cullen: would the possible solution space now include dynamic dns? = The only reason to specify a solution in the charter is to explicitly = exclude alternate classes of solution =96 isn=92t it? Chris Stanley =96 cable labs. We need to deploy this for businesses = and need to move quickly. (And REGISTER is the mechanism we use.) Adam Roach: how far are we going to go down this path of specifying = the answer in the charter? If we allow it for REGISTER for this WG, = what other things are we going to do it for? Cullen as AD: He was the one who earlier encouraged them to be very = specific to see if they could get consensus on the approach to shorten = the process, even though he suspected the proposal would get the = reaction that it is currently getting. However, if the group cannot get = consensus to specify the solution in the charter, then the only approach = is to remove it. This is clearly the case. Hum: Should we leave the charter exactly as it is? Result: Moderate = hum Hum: Should we leave the charter largely as is, but remove the = solution (REGISTER) from the charter. Result: Strong hum. Discussed a vote on =93Is there a critical mass in the IETF to work on = this problem?=94, but instead decided on the following wording. Hum: Does anyone think that we don=92t have the critical mass and the = expertise to tackle this. Result: no one objected. So consensus for = this. Hum: is the IETF the place to work on this? Answer: yes Note: The following happened after the meeting had officially closed, = but is included here because it pointed toward a possible way forward. Jon: Discussion of the precedent setting risks of just adopting an = existing solution. One way forward may be to think about this as a = telephone number problem rather than a domain problem, which would make = it a much easier problem. If we can scope it that way then it will make = it a much quicker problem to solve. Alan Johnston: All the SIP Forum discussion is in fact about = telephone numbers, so restricting it to telephone numbers is what we are = looking for Cullen: Recognize that we do need to find ways to work faster. =93If = you send me a charter by midnight tonight, I will have it on the agenda = for the next IESG meeting=94 Meeting officially closed. Since we had time, we had an open discussion of how to make = progress=85 Discussion of what would be realistic dates for this? The discussion = indicated that March and June might be more believable dates. Cullen: Recognize that we do need to find ways to work faster. =93If = you send me a charter by midnight tonight, I will have it on the agenda = for the next IESG meeting=94 Robert Sparks: Recipe for success in SDOs cooperating is having a = significant overlap of common participants working on the problem. He = is concerned that the overlap is not enough. Spencer: Last SIP Forum meeting had 12 people and 7 of them were also = in the IETF. Is that enough? Jon: Discussion of the precedent setting risks of just adopting an = existing solution. One way forward may be to think about this as a = telephone number problem rather than a domain problem, then it is a much = easier problem. If we can scope it that way then it will make it a much = easier problem to solve. Alan Johnston: All the SIP Forum discussion is in fact about = telephone numbers, so restricting it to telephone numbers would be = acceptable. =20 -------------------------------------------------------------------------= ----- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_4360_01CA63BD.341412E0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi, Shida and Jim,
 
Thanks for taking notes and publishing them=20 quickly.
 
What *I* thought happened (very close to the end of = the=20 meeting), was that
 
- Robert expressed his concern that SIP Forum = participation=20 and IETF participation didn't overlap, and this was a problem because = that's the=20 IESG's experience with inter-SDO coordination is that nothing good = happens=20 unless there's sufficient overlap,
 
- Spencer said something like "we had about 12 (and = John said=20 14) participants at the last SIPconnect face-to-face, and about 7 were = regular=20 IETF attendees, is that enough overlap?", and
 
- Robert said he didn't think so.
 
Others can, of course, confirm (and the audio will = probably be=20 available in a small number of days), but it's = going to be=20 real important to tease a way forward on this, and I don't want the = notes to=20 give the impression that Robert was convinced when I asked my=20 question.
 
Thanks,
 
Spencer
----- Original Message -----
From:=20 Eric Burger
Sent: Thursday, November 12, = 2009 5:14=20 PM
Subject: [dispatch] DREGS Ad = Hoc=20 minutes

DREGS Adhoc

Thursday 12 November 2009, 11:30 =96 1:00

Chairs: Eric Burger and Mary Barnes

Scribes: Shida Schubert and Jim McEachern

John Elwell =96 Charter Discussion.

http= ://www.ietf.org/proceedings/09nov/slides/dispatch-6.ppt=20

Jon Peterson reacted to the John=92s = statement that=20 =93decided we needed a new WG=94 and said that he had suggested it = perhaps should=20 be in DRINKS.  Was = concerned about=20 the presumption of what needs to be done to address the open = issue.

Cullen: =20 the purpose of dispatch is to recommend what should be = done.  So we could recommend it go = to DRINKS=20 or wherever.  Let=92s = see what we=20 recommend.

Clarified that the proposal was that this should = be looked=20 at, not that a WG was needed.

Trying to standardize a uniform way for PBXs to = register=20 their domain.  Today = everyone does=20 it their own way, even though they are all very similar.

Proposing to use REGISTER with an added header = for=20 requesting domain registration. =20 They are proposing this approach because it builds on what is = already=20 widely deployed.

Adam Roach: =20 Are we really proposing to write the use of REGISTER in the=20 charter?  Answer: = Yes.  Adam stated that he was not = prepared=20 to have that discussion today because he thought it would be discussed = in the=20 WG.  This feels like = =93let=92s ratify=20 this draft=94 rather than =93let=92s work on this problem=94.

Spencer Dawkins: the intent is not to = ratify=20 existing draft.

Note:  In spite of Spencer=92s = statement, the=20 ensuing discussion made it very clear that for at least some of the = authors,=20 the intent was in fact very much to ratify this draft, or something = very near=20 it.  Apparently the = initial=20 charter draft did not mention REGISTER and it was included because SIP = Forum=20 participants explicitly asked for it to be added.

Eric: the subject of whether or not = REGISTER should=20 be included in the charter has been discussed on the list, but there = is not=20 consensus

Someone stated that REGISTER was proposed because = =93that is=20 what is implemented=94 and we need to align with those implementations = to be=20 relevant.  Jon = countered=20 that earlier it had been stated that the entire reason for this is = that there=20 are multiple ways this is implemented and that we need a standard to = get=20 interoperability.  So if = it is=20 being done multiple ways today, the argument that REGISTER needs to be = in the=20 charter to align with deployed equipment, simply does not fly.

Cable Labs supported the use of REGISTER = because=20 that is what they use in their specifications.

Jim McEachern & Adam Roach both = pointed out that=20 even if you remove the word REGISTER from the charter, it does not = mean that=20 the eventual solution will have REGISTER.  The bulk of the objections = (dare I say=20 the allergic reaction?) is to the fact that the solution (REGISTER) is = being=20 specified in the charter, when we should be simply defining the = problem we are=20 trying to solve.

Anwar Siddiqi Asked about the definition = of small =96=20 medium business, and said that this will not apply to large = enterprises since=20 they will never give their register information to the SP.  Therefore why not make it=20 optional.

Markus Isomaki, Nokia:  What does this imply about = the=20 addresses of the terminals behind the PBX?  Answer: UA registers = with the=20 PBX, but this work deals with the PBX registering with the SP.  It is designed to help the = SP work out=20 where to send requests to =93example.com=94.

Jon Peterson: =20 Charter scope question.  = Is=20 the charter focused on the specific problem on the slide, or the more = general=20 problem? (Note: I think this was referring to the bullets = specifying =93a=20 header field for requesting domain registration=94 and =93a SIP option = tag to=20 detect non-support of this mechanism=94.)   Answer: The more = general=20 one.  (Note:  I think this meant the = general problem=20 of PBXs registering=85)

Jon Peterson: =20 The only way this charter will get approved is by taking = REGISTER out=20 of the draft.  Lots of = nods to=20 that.

Spencer: =20 If this looks like tweaking existing implementations, it will = get more=20 interest than if it looked like a new method.  Preference is to be up front = about=20 this.

Cullen (channeling Hadriel):  If Hadriel were here he = would insist=20 it must be REGISTER or it will never be deployed.

Cullen: would the possible solution space = now=20 include dynamic dns?  = The only=20 reason to specify a solution in the charter is to explicitly exclude = alternate=20 classes of solution =96 isn=92t it?

Chris Stanley =96 cable labs.  We need to deploy this for = businesses=20 and need to move quickly.  = (And=20 REGISTER is the mechanism we use.)

Adam Roach: =20 how far are we going to go down this path of specifying the = answer in=20 the charter?  If we = allow it for=20 REGISTER for this WG, what other things are we going to do it for?

Cullen as AD: =20 He was the one who earlier encouraged them to be very specific = to see=20 if they could get consensus on the approach to shorten the process, = even=20 though he suspected the proposal would get the reaction that it is = currently=20 getting.  However, if = the group=20 cannot get consensus to specify the solution in the charter, then the = only=20 approach is to remove it.  This is=20 clearly the case.

Hum: =20 Should we leave the charter exactly as it is?  Result: Moderate = hum

Hum: =20 Should we leave the charter largely as is,  but remove the solution = (REGISTER)=20 from the charter.  = Result:=20 Strong hum.

Discussed a vote on =93Is there a critical mass = in the IETF=20 to work on this problem?=94, but instead decided on the following = wording.

Hum: =20 Does anyone think that we don=92t have the critical mass and = the=20 expertise to tackle this. =20 Result:  = no one=20 objected.  So consensus = for=20 this.

Hum: is the IETF the place to work on = this?  Answer: yes

Note:  = The=20 following happened after the meeting had officially closed, but is = included=20 here because it pointed toward a possible way = forward.

Jon: = Discussion=20 of the precedent setting risks of just adopting an existing = solution.  One way forward may be to = think about=20 this as a telephone number problem rather than a domain problem, which = would=20 make it a much easier problem.  = If=20 we can scope it that way then it will make it a much quicker problem = to=20 solve.

Alan=20 Johnston:  = All the SIP=20 Forum discussion is in fact about telephone numbers, so restricting it = to=20 telephone numbers is what we are looking for

Cullen:  Recognize that we do need to = find ways=20 to work faster.  =93If = you send me a=20 charter by midnight tonight, I will have it on the agenda for the next = IESG=20 meeting=94

Meeting officially = closed.

Since we had time, we had an open discussion = of how to=20 make progress=85

Discussion of what would be realistic dates for = this?  The discussion indicated = that March=20 and June might be more believable dates.

Cullen: =20 Recognize that we do need to find ways to work faster.  =93If you send me a charter = by midnight=20 tonight, I will have it on the agenda for the next IESG meeting=94

Robert Sparks: =20 Recipe for success in SDOs cooperating is having a significant = overlap=20 of common participants working on the problem.  He is concerned that the = overlap is=20 not enough.

Spencer: =20 Last SIP Forum meeting had 12 people and 7 of them were also in = the=20 IETF.  Is that = enough?

Jon: Discussion of the precedent setting = risks of=20 just adopting an existing solution. =20 One way forward may be to think about this as a telephone = number=20 problem rather than a domain problem, then it is a much easier = problem.  If we can scope it that way = then it=20 will make it a much easier problem to solve.

Alan Johnston: =20 All the SIP Forum discussion is in fact about telephone = numbers, so=20 restricting it to telephone numbers would be acceptable.   

_______________________________________________
dispatch = mailing=20 = list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispat= ch
------=_NextPart_000_4360_01CA63BD.341412E0-- From eburger@standardstrack.com Thu Nov 12 00:34:23 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22543A6899 for ; Thu, 12 Nov 2009 00:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 nwm2pfN0p8eO for ; Thu, 12 Nov 2009 00:34:22 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 68B833A6872 for ; Thu, 12 Nov 2009 00:34:22 -0800 (PST) Received: from host-40-25.meeting.ietf.org ([133.93.40.25]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N8V8h-00055u-Ne for dispatch@ietf.org; Thu, 12 Nov 2009 00:34:47 -0800 Message-Id: From: Eric Burger To: dispatch@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Nov 2009 17:34:47 +0900 X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [dispatch] Note on DREGS Minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 08:34:23 -0000 Very drafty. A bunch of errors already found. Will fix RSN. Comments welcome. From david.middleton@nsn.com Thu Nov 12 04:12:43 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70F23A6A83 for ; Thu, 12 Nov 2009 04:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkJGz3retOfP for ; Thu, 12 Nov 2009 04:12:42 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 270CA3A6882 for ; Thu, 12 Nov 2009 04:12:40 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nACCD36N003150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Nov 2009 13:13:03 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nACCCxEk004600; Thu, 12 Nov 2009 13:13:03 +0100 Received: from USCHEXC006.nsn-intra.net ([10.159.160.11]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 13:13:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 06:12:07 -0600 Message-ID: <159B27ECF9D16E40BD7ABD5778522B010389E40E@USCHEXC006.nsn-intra.net> In-Reply-To: <4AFB3C0F.40203@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] To-URI in domain-registration Thread-Index: AcpjHzh8rekeXIrLSuWr3jGYA5uTygAcdtfA References: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com><9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> <024101ca528e$fbd0a8b0$f371fa10$@us> <159B27ECF9D16E40BD7ABD5778522B0103792C9C@USCHEXC006.nsn-intra.net> <4AEB78AD.5070608@cisco.com> <159B27ECF9D16E40BD7ABD5778522B010389E177@USCHEXC006.nsn-intra.net> <4AFB3C0F.40203@cisco.com> From: "Middleton, David (NSN - US/Boca Raton)" To: "ext Paul Kyzivat" X-OriginalArrivalTime: 12 Nov 2009 12:13:01.0437 (UTC) FILETIME=[7AC132D0:01CA6391] Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 12:12:44 -0000 I agree this is possible but having the SP cross-reference domains is = not in the spirit of domain registration from my perspective. -----Original Message----- From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Wednesday, November 11, 2009 5:35 PM To: Middleton, David (NSN - US/Boca Raton) Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration Middleton, David (NSN - US/Boca Raton) wrote: > Paul, >=20 > Sorry for the delay in responding. >=20 > I think you are on target as far as describing many (perhaps most) SP = / PBX interconnect arrangements. However, the functionality of having = the SP route calls per user is a real-world scenario which proves there = is merit for having the capability. This could still be dealt with by having the pbxes register to separate=20 sub-domains and the SP knowing (via provisioning) which things to route=20 to each. So instead of having: foo-east-pbx register to east@foo.sp.com foo-west-pbx register to west@foo.sp.com you could simply have foo-east-pbx register to east.foo.sp.com foo-west-pbx register to west.foo.sp.com Then the question of how requests addressed to xyz@foo.sp.com are mapped = to something@east.foo.sp.com or something@west.foo.sp.com is simply out=20 of scope of this document. Thanks, Paul > Also see inline. >=20 > David >=20 >=20 >=20 > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, October 30, 2009 7:37 PM > To: Middleton, David (NSN - US/Boca Raton) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] To-URI in domain-registration >=20 > David, >=20 > IIUC, you are proposing a case such as: >=20 > - a customer of sp.net has domain cust.sp.net > - the customer has two PBX systems, east and west. > - you propose that they register, respectively > To: east@cust.sp.net, and > To: west@cust.sp.net. > - then numbers assigned to the customer are routed > something like: > 1-212-555-88xx -> contact from east@cust.sp.net > 1-408-555-88xx -> contact from west@cust.sp.net > - also, routing for names be something like: > bob@cust.sp.net -> contact from east@cust.sp.net > carol@cust.sp.net -> " > ted@cust.sp.net -> contact from west@cust.sp.net > alice@cust.sp.net -> " > others... >=20 > Is that right? > Yes >=20 > You then can't describe that as setting up routing paths for=20 > cust.sp.net. You are instead describing some entirely different = routing=20 > algorithm based on the user part. > Yes, it requires a local policy to determine the location of the = users. >=20 > Subdomains east.cust.sp.net and west.cust.sp.net solve this problem in = > large part - at least for the numbers. >=20 > You clearly don't find that acceptable for the names. If those names=20 > were exposed to end users I wouldn't find it acceptable either. (I = want=20 > to be pkyzivat@cisco.com, not pkyzivat@east.cisco.com.) > Agreed >=20 > The question is whether this is the best way to solve that problem. >=20 > I think that solution won't be very acceptable to an SP, or to the=20 > customer of that SP. Having the SP provision every one of your users=20 > just isn't going to be popular with anyone. (Unless the SP gets a big=20 > enough per-user fee.) > I agree but if the parties involved reach an acceptable = agreement, the technology should support it IMO. >=20 > Its not quite as much of a problem with numbers, because they are = likely=20 > to be managed in blocks. And the numbers are really owned/managed by = the=20 > SP anyway so they are forced to do something about them. >=20 > This is also a problem that is not unique to this SP interconnect=20 > mechanism. It is pretty much the same problem in any big company with = a=20 > lot of sites, even if they have a private network connecting all the = sites. >=20 > What you need in this case is a proxy at the company domain level=20 > (cust.sp.net in this case perhaps) that has the roster of all = usernames=20 > and a mapping to a subdomain - mapping bob@cust.sp.net to=20 > bob@east.cust.sp.net. > Yes but some enterprise customers do not want to do this and are = able to convince the SP to do this. >=20 > Then, the company has one server registering To:cust.sp.net to provide = > this mapping, and other servers registering To:east.cust.sp.net, ... >=20 > Thanks, > Paul >=20 >=20 > Middleton, David (NSN - US/Boca Raton) wrote: >> Some colleagues have pointed out an aspect that I had not considered = concerning the domain registration To: user part. There are cases where = an Enterprise has multiple PBXs that register and calls should be routed = to one of the PBXs based on which user is called. In other words, = instead of the Enterprise with multiple PBXs appearing as one logical = PBX, the Enterprise customer wants the service provider to take = responsibility for distributing the calls to the specific PBX that hosts = the called user. >> >> While this problem could be solved with a local policy to choose one = of several contacts it is not as clean an approach as being able to = treat each registration as a separate entity with it's own contact(s). = While one could propose that these be treated separately by making = different sub-domains, the Enterprise most assuredly will not want to = publish this sub-domain on business cards, etc. when using e-mail style = addresses. Besides, it would cause the address to change if the user = moves from one PBX to another as might happen with a physical move. >> >> Another aspect to consider is that the Enterprise user, in this = scenario, is only reachable via one registered "To: user@host". So not = having separate registrations would result in a more complex definition = and implementation of things like (a.) is there an unexpired binding and = (b.) picking appropriate contacts by q-value. >> >> I think this makes a strong case for having a user part in the To: = header and treating each unique user@host as a separate registration =E0 = la RFC 3264. >> >> In summary, I support Option 1) as well. >> >> - David >> >> =20 >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext Richard Shockey >> Sent: Wednesday, October 21, 2009 4:42 PM >> To: dispatch@ietf.org >> Subject: Re: [dispatch] To-URI in domain-registration >> >> +1 to Option 1) as well >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On >>> Behalf Of David Hancock >>> Sent: Wednesday, October 21, 2009 4:05 PM >>> To: Brian Lindsay; Hadriel Kaplan; dispatch@ietf.org >>> Subject: Re: [dispatch] To-URI in domain-registration >>> =20 >>> =20 >>> Hadriel - I'd prefer option 1) as well. >>> =20 >>> David >>> =20 >>> > -----Original Message----- >>> > From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.org] >>> On >>> > Behalf Of Brian Lindsay >>> > Sent: Wednesday, October 21, 2009 1:53 PM >>> > To: Hadriel Kaplan; dispatch@ietf.org >>> > Subject: Re: [dispatch] To-URI in domain-registration >>> > >>> > Hi Hadriel, >>> > >>> > Per my comment yesterday, I'd prefer (1). >>> > >>> > Thanks. >>> > >>> > -----Original Message----- >>> > From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.org] >>> On >>> > Behalf Of Hadriel Kaplan >>> > Sent: Wednesday, October 21, 2009 3:43 PM >>> > To: dispatch@ietf.org >>> > Subject: [dispatch] To-URI in domain-registration >>> > >>> > Howdy, >>> > I'd like to get a consensus call on the question of what the = To-URI >>> > should be for the REGISTER request of a domain registration, = before >>> > finishing the next rev of the draft. This will affect quite a = bit >>> of >>> > text in the draft (e.g., examples), and I think that the decision >>> about >>> > that will also affect whether we need more than a = Require:option-tag >>> as >>> > well. >>> > >>> > The choices right now are: >>> > 1) Mandate the To-URI be in the syntactical form of an AoR, >>> including >>> > the user@ portion, the same as the From-URI. >>> > Pros: closer to what current proprietary and other-SDO >>> > mechanisms do, on the wire. Therefore, presumably less of a = change >>> and >>> > less barrier to adoption. >>> > 2) Mandate the To-URI be a domain only (no user@), while the = From- >>> URI >>> > remains the "AoR" of the PBX registering. >>> > Pros: semantically accurate (you're registering a domain, not an >>> > AoR), and may obviate the need for a new header or param to = indicate >>> > this new mechanism is being used. >>> > >>> > Can people please indicate which they'd prefer? >>> > >>> > Thanks! >>> > -hadriel >>> > _______________________________________________ >>> > dispatch mailing list >>> > dispatch@ietf.org >>> > https://www.ietf.org/mailman/listinfo/dispatch >>> > _______________________________________________ >>> > dispatch mailing list >>> > dispatch@ietf.org >>> > https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >=20 From pkyzivat@cisco.com Thu Nov 12 05:46:13 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5EF28C0EE for ; Thu, 12 Nov 2009 05:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 4kMzc7j63S9B for ; Thu, 12 Nov 2009 05:46:12 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A5A513A69FE for ; Thu, 12 Nov 2009 05:46:11 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABuh+0pAZnwM/2dsb2JhbADEaIkbCAeOWoJLCIFpBA X-IronPort-AV: E=Sophos;i="4.44,728,1249257600"; d="scan'208";a="67679463" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Nov 2009 13:46:36 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nACDkaQg028506; Thu, 12 Nov 2009 13:46:36 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 08:46:36 -0500 Received: from [10.86.252.153] ([10.86.252.153]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 08:46:35 -0500 Message-ID: <4AFC11BA.2000104@cisco.com> Date: Thu, 12 Nov 2009 08:46:34 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Middleton, David (NSN - US/Boca Raton)" References: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com><9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> <024101ca528e$fbd0a8b0$f371fa10$@us> <159B27ECF9D16E40BD7ABD5778522B0103792C9C@USCHEXC006.nsn-intra.net> <4AEB78AD.5070608@cisco.com> <159B27ECF9D16E40BD7ABD5778522B010389E177@USCHEXC006.nsn-intra.net> <4AFB3C0F.40203@cisco.com> <159B27ECF9D16E40BD7ABD5778522B010389E40E@USCHEXC006.nsn-intra.net> In-Reply-To: <159B27ECF9D16E40BD7ABD5778522B010389E40E@USCHEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Nov 2009 13:46:35.0724 (UTC) FILETIME=[8D2168C0:01CA639E] Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 13:46:13 -0000 Middleton, David (NSN - US/Boca Raton) wrote: > I agree this is possible but having the SP cross-reference domains is not in the spirit of domain registration from my perspective. But having the SP partition traffic for one domain based on the user part of the request *is* in the spirit? IMO it is exactly the same thing, or cleaner. Its a matter of who is responsible for a particular domain, the sp or the pbx. IMO you should only take *other* information (such as the username) into account if you are responsible for the domain of the request. In my example, the sp is responsible for foo.sp.com, but the pbxes are responsible for east.foo.sp.com and west.foo.sp.com. The other way, both the sp and the pbxes are responsible for foo.sp.com, which is problematic to me. I see from the notes of the ad hoc, that there is some desire to restrict the scope to phone numbers. In that case it again is possible to give each pbx its own domain name. Thanks, Paul > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, November 11, 2009 5:35 PM > To: Middleton, David (NSN - US/Boca Raton) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] To-URI in domain-registration > > > > Middleton, David (NSN - US/Boca Raton) wrote: >> Paul, >> >> Sorry for the delay in responding. >> >> I think you are on target as far as describing many (perhaps most) SP / PBX interconnect arrangements. However, the functionality of having the SP route calls per user is a real-world scenario which proves there is merit for having the capability. > > This could still be dealt with by having the pbxes register to separate > sub-domains and the SP knowing (via provisioning) which things to route > to each. > > So instead of having: > > foo-east-pbx register to east@foo.sp.com > foo-west-pbx register to west@foo.sp.com > > you could simply have > > foo-east-pbx register to east.foo.sp.com > foo-west-pbx register to west.foo.sp.com > > Then the question of how requests addressed to xyz@foo.sp.com are mapped > to something@east.foo.sp.com or something@west.foo.sp.com is simply out > of scope of this document. > > Thanks, > Paul > > >> Also see inline. >> >> David >> >> >> >> -----Original Message----- >> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, October 30, 2009 7:37 PM >> To: Middleton, David (NSN - US/Boca Raton) >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] To-URI in domain-registration >> >> David, >> >> IIUC, you are proposing a case such as: >> >> - a customer of sp.net has domain cust.sp.net >> - the customer has two PBX systems, east and west. >> - you propose that they register, respectively >> To: east@cust.sp.net, and >> To: west@cust.sp.net. >> - then numbers assigned to the customer are routed >> something like: >> 1-212-555-88xx -> contact from east@cust.sp.net >> 1-408-555-88xx -> contact from west@cust.sp.net >> - also, routing for names be something like: >> bob@cust.sp.net -> contact from east@cust.sp.net >> carol@cust.sp.net -> " >> ted@cust.sp.net -> contact from west@cust.sp.net >> alice@cust.sp.net -> " >> others... >> >> Is that right? >> Yes >> >> You then can't describe that as setting up routing paths for >> cust.sp.net. You are instead describing some entirely different routing >> algorithm based on the user part. >> Yes, it requires a local policy to determine the location of the users. >> >> Subdomains east.cust.sp.net and west.cust.sp.net solve this problem in >> large part - at least for the numbers. >> >> You clearly don't find that acceptable for the names. If those names >> were exposed to end users I wouldn't find it acceptable either. (I want >> to be pkyzivat@cisco.com, not pkyzivat@east.cisco.com.) >> Agreed >> >> The question is whether this is the best way to solve that problem. >> >> I think that solution won't be very acceptable to an SP, or to the >> customer of that SP. Having the SP provision every one of your users >> just isn't going to be popular with anyone. (Unless the SP gets a big >> enough per-user fee.) >> I agree but if the parties involved reach an acceptable agreement, the technology should support it IMO. >> >> Its not quite as much of a problem with numbers, because they are likely >> to be managed in blocks. And the numbers are really owned/managed by the >> SP anyway so they are forced to do something about them. >> >> This is also a problem that is not unique to this SP interconnect >> mechanism. It is pretty much the same problem in any big company with a >> lot of sites, even if they have a private network connecting all the sites. >> >> What you need in this case is a proxy at the company domain level >> (cust.sp.net in this case perhaps) that has the roster of all usernames >> and a mapping to a subdomain - mapping bob@cust.sp.net to >> bob@east.cust.sp.net. >> Yes but some enterprise customers do not want to do this and are able to convince the SP to do this. >> >> Then, the company has one server registering To:cust.sp.net to provide >> this mapping, and other servers registering To:east.cust.sp.net, ... >> >> Thanks, >> Paul >> >> >> Middleton, David (NSN - US/Boca Raton) wrote: >>> Some colleagues have pointed out an aspect that I had not considered concerning the domain registration To: user part. There are cases where an Enterprise has multiple PBXs that register and calls should be routed to one of the PBXs based on which user is called. In other words, instead of the Enterprise with multiple PBXs appearing as one logical PBX, the Enterprise customer wants the service provider to take responsibility for distributing the calls to the specific PBX that hosts the called user. >>> >>> While this problem could be solved with a local policy to choose one of several contacts it is not as clean an approach as being able to treat each registration as a separate entity with it's own contact(s). While one could propose that these be treated separately by making different sub-domains, the Enterprise most assuredly will not want to publish this sub-domain on business cards, etc. when using e-mail style addresses. Besides, it would cause the address to change if the user moves from one PBX to another as might happen with a physical move. >>> >>> Another aspect to consider is that the Enterprise user, in this scenario, is only reachable via one registered "To: user@host". So not having separate registrations would result in a more complex definition and implementation of things like (a.) is there an unexpired binding and (b.) picking appropriate contacts by q-value. >>> >>> I think this makes a strong case for having a user part in the To: header and treating each unique user@host as a separate registration à la RFC 3264. >>> >>> In summary, I support Option 1) as well. >>> >>> - David >>> >>> >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Richard Shockey >>> Sent: Wednesday, October 21, 2009 4:42 PM >>> To: dispatch@ietf.org >>> Subject: Re: [dispatch] To-URI in domain-registration >>> >>> +1 to Option 1) as well >>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of David Hancock >>>> Sent: Wednesday, October 21, 2009 4:05 PM >>>> To: Brian Lindsay; Hadriel Kaplan; dispatch@ietf.org >>>> Subject: Re: [dispatch] To-URI in domain-registration >>>> >>>> >>>> Hadriel - I'd prefer option 1) as well. >>>> >>>> David >>>> >>>> > -----Original Message----- >>>> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >>>> On >>>> > Behalf Of Brian Lindsay >>>> > Sent: Wednesday, October 21, 2009 1:53 PM >>>> > To: Hadriel Kaplan; dispatch@ietf.org >>>> > Subject: Re: [dispatch] To-URI in domain-registration >>>> > >>>> > Hi Hadriel, >>>> > >>>> > Per my comment yesterday, I'd prefer (1). >>>> > >>>> > Thanks. >>>> > >>>> > -----Original Message----- >>>> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >>>> On >>>> > Behalf Of Hadriel Kaplan >>>> > Sent: Wednesday, October 21, 2009 3:43 PM >>>> > To: dispatch@ietf.org >>>> > Subject: [dispatch] To-URI in domain-registration >>>> > >>>> > Howdy, >>>> > I'd like to get a consensus call on the question of what the To-URI >>>> > should be for the REGISTER request of a domain registration, before >>>> > finishing the next rev of the draft. This will affect quite a bit >>>> of >>>> > text in the draft (e.g., examples), and I think that the decision >>>> about >>>> > that will also affect whether we need more than a Require:option-tag >>>> as >>>> > well. >>>> > >>>> > The choices right now are: >>>> > 1) Mandate the To-URI be in the syntactical form of an AoR, >>>> including >>>> > the user@ portion, the same as the From-URI. >>>> > Pros: closer to what current proprietary and other-SDO >>>> > mechanisms do, on the wire. Therefore, presumably less of a change >>>> and >>>> > less barrier to adoption. >>>> > 2) Mandate the To-URI be a domain only (no user@), while the From- >>>> URI >>>> > remains the "AoR" of the PBX registering. >>>> > Pros: semantically accurate (you're registering a domain, not an >>>> > AoR), and may obviate the need for a new header or param to indicate >>>> > this new mechanism is being used. >>>> > >>>> > Can people please indicate which they'd prefer? >>>> > >>>> > Thanks! >>>> > -hadriel >>>> > _______________________________________________ >>>> > dispatch mailing list >>>> > dispatch@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/dispatch >>>> > _______________________________________________ >>>> > dispatch mailing list >>>> > dispatch@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/dispatch >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> > From richard@shockey.us Thu Nov 12 12:49:52 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929C83A693F for ; Thu, 12 Nov 2009 12:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.457, 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 xppx-VW2J3Js for ; Thu, 12 Nov 2009 12:49:50 -0800 (PST) Received: from outbound-mail-144.bluehost.com (outbound-mail-144.bluehost.com [67.222.38.34]) by core3.amsl.com (Postfix) with SMTP id D05E63A69A6 for ; Thu, 12 Nov 2009 12:49:50 -0800 (PST) Received: (qmail 17144 invoked by uid 0); 12 Nov 2009 20:50:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 12 Nov 2009 20:50:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=X7/FGU+4op36d7tjoDO6fmF5KxdNccaSKZ1xWntfkE97c/CDUlHs8AopQTsa/nGFIm8tdaH7t0oFPayDGIPJQ/3E7Aqi8L9VJfqOHGMDjQrUuFT/fiheKAbIwbz1sV/r; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N8gcV-0002SR-Lc; Thu, 12 Nov 2009 13:50:20 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'Middleton, David \(NSN - US/Boca Raton\)'" References: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com><9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> <024101ca528e$fbd0a8b0$f371fa10$@us> <159B27ECF9D16E40BD7ABD5778522B0103792C9C@USCHEXC006.nsn-intra.net> <4AEB78AD.5070608@cisco.com> <159B27ECF9D16E40BD7ABD5778522B010389E177@USCHEXC006.nsn-intra.net> <4AFB3C0F.40203@cisco.com> <159B27ECF9D16E40BD7ABD5778522B010389E40E@USCHEXC006.nsn-intra.net> <4AFC11BA.2000104@cisco.com> In-Reply-To: <4AFC11BA.2000104@cisco.com> Date: Thu, 12 Nov 2009 15:50:21 -0500 Message-ID: <024f01ca63d9$c0c8d240$425a76c0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpjnpIQqjuqvRliQBeu1TJi1MN3XgAOo/yg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] To-URI in domain-registration X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 20:49:52 -0000 To clarify .. in the discussions within the SIPforum there was no = question that the scope was restricted to phone numbers.=20 here were only 2-3 participants that did not usually attend IETF = meetings and those represented small CLEC's. As a practical matter the overlap between IETF and the SIPforum discussions was nearly total.=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, November 12, 2009 8:47 AM > To: Middleton, David (NSN - US/Boca Raton) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] To-URI in domain-registration > =20 > =20 > =20 > Middleton, David (NSN - US/Boca Raton) wrote: > > I agree this is possible but having the SP cross-reference domains > is not in the spirit of domain registration from my perspective. > =20 > But having the SP partition traffic for one domain based on the user > part of the request *is* in the spirit? IMO it is exactly the same > thing, or cleaner. > =20 > Its a matter of who is responsible for a particular domain, the sp or > the pbx. IMO you should only take *other* information (such as the > username) into account if you are responsible for the domain of the > request. In my example, the sp is responsible for foo.sp.com, but the > pbxes are responsible for east.foo.sp.com and west.foo.sp.com. The > other > way, both the sp and the pbxes are responsible for foo.sp.com, which > is > problematic to me. > =20 > I see from the notes of the ad hoc, that there is some desire to > restrict the scope to phone numbers. In that case it again is = possible > to give each pbx its own domain name. > =20 > Thanks, > Paul > =20 > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, November 11, 2009 5:35 PM > > To: Middleton, David (NSN - US/Boca Raton) > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] To-URI in domain-registration > > > > > > > > Middleton, David (NSN - US/Boca Raton) wrote: > >> Paul, > >> > >> Sorry for the delay in responding. > >> > >> I think you are on target as far as describing many (perhaps most) > SP / PBX interconnect arrangements. However, the functionality of > having the SP route calls per user is a real-world scenario which > proves there is merit for having the capability. > > > > This could still be dealt with by having the pbxes register to > separate > > sub-domains and the SP knowing (via provisioning) which things to > route > > to each. > > > > So instead of having: > > > > foo-east-pbx register to east@foo.sp.com > > foo-west-pbx register to west@foo.sp.com > > > > you could simply have > > > > foo-east-pbx register to east.foo.sp.com > > foo-west-pbx register to west.foo.sp.com > > > > Then the question of how requests addressed to xyz@foo.sp.com are > mapped > > to something@east.foo.sp.com or something@west.foo.sp.com is simply > out > > of scope of this document. > > > > Thanks, > > Paul > > > > > >> Also see inline. > >> > >> David > >> > >> > >> > >> -----Original Message----- > >> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, October 30, 2009 7:37 PM > >> To: Middleton, David (NSN - US/Boca Raton) > >> Cc: dispatch@ietf.org > >> Subject: Re: [dispatch] To-URI in domain-registration > >> > >> David, > >> > >> IIUC, you are proposing a case such as: > >> > >> - a customer of sp.net has domain cust.sp.net > >> - the customer has two PBX systems, east and west. > >> - you propose that they register, respectively > >> To: east@cust.sp.net, and > >> To: west@cust.sp.net. > >> - then numbers assigned to the customer are routed > >> something like: > >> 1-212-555-88xx -> contact from east@cust.sp.net > >> 1-408-555-88xx -> contact from west@cust.sp.net > >> - also, routing for names be something like: > >> bob@cust.sp.net -> contact from east@cust.sp.net > >> carol@cust.sp.net -> " > >> ted@cust.sp.net -> contact from west@cust.sp.net > >> alice@cust.sp.net -> " > >> others... > >> > >> Is that right? > >> Yes > >> > >> You then can't describe that as setting up routing paths for > >> cust.sp.net. You are instead describing some entirely different > routing > >> algorithm based on the user part. > >> Yes, it requires a local policy to determine the location of > the users. > >> > >> Subdomains east.cust.sp.net and west.cust.sp.net solve this = problem > in > >> large part - at least for the numbers. > >> > >> You clearly don't find that acceptable for the names. If those > names > >> were exposed to end users I wouldn't find it acceptable either. (I > want > >> to be pkyzivat@cisco.com, not pkyzivat@east.cisco.com.) > >> Agreed > >> > >> The question is whether this is the best way to solve that = problem. > >> > >> I think that solution won't be very acceptable to an SP, or to the > >> customer of that SP. Having the SP provision every one of your > users > >> just isn't going to be popular with anyone. (Unless the SP gets a > big > >> enough per-user fee.) > >> I agree but if the parties involved reach an acceptable > agreement, the technology should support it IMO. > >> > >> Its not quite as much of a problem with numbers, because they are > likely > >> to be managed in blocks. And the numbers are really owned/managed > by the > >> SP anyway so they are forced to do something about them. > >> > >> This is also a problem that is not unique to this SP interconnect > >> mechanism. It is pretty much the same problem in any big company > with a > >> lot of sites, even if they have a private network connecting all > the sites. > >> > >> What you need in this case is a proxy at the company domain level > >> (cust.sp.net in this case perhaps) that has the roster of all > usernames > >> and a mapping to a subdomain - mapping bob@cust.sp.net to > >> bob@east.cust.sp.net. > >> Yes but some enterprise customers do not want to do this and > are able to convince the SP to do this. > >> > >> Then, the company has one server registering To:cust.sp.net to > provide > >> this mapping, and other servers registering To:east.cust.sp.net, > ... > >> > >> Thanks, > >> Paul > >> > >> > >> Middleton, David (NSN - US/Boca Raton) wrote: > >>> Some colleagues have pointed out an aspect that I had not > considered concerning the domain registration To: user part. There > are cases where an Enterprise has multiple PBXs that register and > calls should be routed to one of the PBXs based on which user is > called. In other words, instead of the Enterprise with multiple PBXs > appearing as one logical PBX, the Enterprise customer wants the > service provider to take responsibility for distributing the calls to > the specific PBX that hosts the called user. > >>> > >>> While this problem could be solved with a local policy to choose > one of several contacts it is not as clean an approach as being able > to treat each registration as a separate entity with it's own > contact(s). While one could propose that these be treated separately > by making different sub-domains, the Enterprise most assuredly will > not want to publish this sub-domain on business cards, etc. when = using > e-mail style addresses. Besides, it would cause the address to = change > if the user moves from one PBX to another as might happen with a > physical move. > >>> > >>> Another aspect to consider is that the Enterprise user, in this > scenario, is only reachable via one registered "To: user@host". So > not having separate registrations would result in a more complex > definition and implementation of things like (a.) is there an > unexpired binding and (b.) picking appropriate contacts by q-value. > >>> > >>> I think this makes a strong case for having a user part in the = To: > header and treating each unique user@host as a separate registration = =E0 > la RFC 3264. > >>> > >>> In summary, I support Option 1) as well. > >>> > >>> - David > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.org] > On Behalf Of ext Richard Shockey > >>> Sent: Wednesday, October 21, 2009 4:42 PM > >>> To: dispatch@ietf.org > >>> Subject: Re: [dispatch] To-URI in domain-registration > >>> > >>> +1 to Option 1) as well > >>> > >>>> -----Original Message----- > >>>> From: dispatch-bounces@ietf.org [mailto:dispatch- > bounces@ietf.org] On > >>>> Behalf Of David Hancock > >>>> Sent: Wednesday, October 21, 2009 4:05 PM > >>>> To: Brian Lindsay; Hadriel Kaplan; dispatch@ietf.org > >>>> Subject: Re: [dispatch] To-URI in domain-registration > >>>> > >>>> > >>>> Hadriel - I'd prefer option 1) as well. > >>>> > >>>> David > >>>> > >>>> > -----Original Message----- > >>>> > From: dispatch-bounces@ietf.org [mailto:dispatch- > bounces@ietf.org] > >>>> On > >>>> > Behalf Of Brian Lindsay > >>>> > Sent: Wednesday, October 21, 2009 1:53 PM > >>>> > To: Hadriel Kaplan; dispatch@ietf.org > >>>> > Subject: Re: [dispatch] To-URI in domain-registration > >>>> > > >>>> > Hi Hadriel, > >>>> > > >>>> > Per my comment yesterday, I'd prefer (1). > >>>> > > >>>> > Thanks. > >>>> > > >>>> > -----Original Message----- > >>>> > From: dispatch-bounces@ietf.org [mailto:dispatch- > bounces@ietf.org] > >>>> On > >>>> > Behalf Of Hadriel Kaplan > >>>> > Sent: Wednesday, October 21, 2009 3:43 PM > >>>> > To: dispatch@ietf.org > >>>> > Subject: [dispatch] To-URI in domain-registration > >>>> > > >>>> > Howdy, > >>>> > I'd like to get a consensus call on the question of what the > To-URI > >>>> > should be for the REGISTER request of a domain registration, > before > >>>> > finishing the next rev of the draft. This will affect quite = a > bit > >>>> of > >>>> > text in the draft (e.g., examples), and I think that the > decision > >>>> about > >>>> > that will also affect whether we need more than a > Require:option-tag > >>>> as > >>>> > well. > >>>> > > >>>> > The choices right now are: > >>>> > 1) Mandate the To-URI be in the syntactical form of an AoR, > >>>> including > >>>> > the user@ portion, the same as the From-URI. > >>>> > Pros: closer to what current proprietary and other-SDO > >>>> > mechanisms do, on the wire. Therefore, presumably less of a > change > >>>> and > >>>> > less barrier to adoption. > >>>> > 2) Mandate the To-URI be a domain only (no user@), while the > From- > >>>> URI > >>>> > remains the "AoR" of the PBX registering. > >>>> > Pros: semantically accurate (you're registering a domain, > not an > >>>> > AoR), and may obviate the need for a new header or param to > indicate > >>>> > this new mechanism is being used. > >>>> > > >>>> > Can people please indicate which they'd prefer? > >>>> > > >>>> > Thanks! > >>>> > -hadriel > >>>> > _______________________________________________ > >>>> > dispatch mailing list > >>>> > dispatch@ietf.org > >>>> > https://www.ietf.org/mailman/listinfo/dispatch > >>>> > _______________________________________________ > >>>> > dispatch mailing list > >>>> > dispatch@ietf.org > >>>> > https://www.ietf.org/mailman/listinfo/dispatch > >>>> _______________________________________________ > >>>> dispatch mailing list > >>>> dispatch@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dispatch > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch > >>> > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Thu Nov 12 13:50:32 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35BE728B23E for ; Thu, 12 Nov 2009 13:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.097 X-Spam-Level: X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJddmJv+8HJq for ; Thu, 12 Nov 2009 13:50:30 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 42FAC3A68F0 for ; Thu, 12 Nov 2009 13:50:28 -0800 (PST) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id nACLoEqT015427; Thu, 12 Nov 2009 22:50:14 +0100 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nACLoEw0008025; Thu, 12 Nov 2009 22:50:14 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.110]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Thu, 12 Nov 2009 22:50:13 +0100 From: "Elwell, John" To: Richard Shockey , "'Paul Kyzivat'" , "'Middleton, David (NSN - US/Boca Raton)'" Date: Thu, 12 Nov 2009 22:50:11 +0100 Thread-Topic: Phone numbers and domain registration (was RE: [dispatch] To-URI in domain-registration) Thread-Index: AcpjnpIQqjuqvRliQBeu1TJi1MN3XgAOo/ygAAIhoVA= Message-ID: <7402509E63C5A145A6095D46C179A5B70725DA3C67@DEMCHP99E35MSX.ww902.siemens.net> References: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com><9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> <024101ca528e$fbd0a8b0$f371fa10$@us> <159B27ECF9D16E40BD7ABD5778522B0103792C9C@USCHEXC006.nsn-intra.net> <4AEB78AD.5070608@cisco.com> <159B27ECF9D16E40BD7ABD5778522B010389E177@USCHEXC006.nsn-intra.net> <4AFB3C0F.40203@cisco.com> <159B27ECF9D16E40BD7ABD5778522B010389E40E@USCHEXC006.nsn-intra.net> <4AFC11BA.2000104@cisco.com> <024f01ca63d9$c0c8d240$425a76c0$@us> In-Reply-To: <024f01ca63d9$c0c8d240$425a76c0$@us> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: [dispatch] Phone numbers and domain registration (was RE: To-URI in domain-registration) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 21:50:32 -0000 During the DISPATCH ad hoc session there was indeed a suggestion to limit t= he mechanism to domains employing E.164-based SIP URIs. However, this would= leave an issue with contact URIs, which would presumably not be constraine= d to being based on telephone numbers. It must be possible to route an out-= of-dialog request to a contact URI issued by the SIP-PBX. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Shockey > Sent: 12 November 2009 20:50 > To: 'Paul Kyzivat'; 'Middleton, David (NSN - US/Boca Raton)' > Cc: dispatch@ietf.org > Subject: Re: [dispatch] To-URI in domain-registration >=20 > To clarify .. in the discussions within the SIPforum there=20 > was no question > that the scope was restricted to phone numbers.=20 >=20 > here were only 2-3 participants that did not usually attend=20 > IETF meetings > and those represented small CLEC's. As a practical matter the overlap > between IETF and the SIPforum discussions was nearly total.=20 >=20 >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Thursday, November 12, 2009 8:47 AM > > To: Middleton, David (NSN - US/Boca Raton) > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] To-URI in domain-registration > > =20 > > =20 > > =20 > > Middleton, David (NSN - US/Boca Raton) wrote: > > > I agree this is possible but having the SP=20 > cross-reference domains > > is not in the spirit of domain registration from my perspective. > > =20 > > But having the SP partition traffic for one domain based=20 > on the user > > part of the request *is* in the spirit? IMO it is exactly the same > > thing, or cleaner. > > =20 > > Its a matter of who is responsible for a particular=20 > domain, the sp or > > the pbx. IMO you should only take *other* information (such as the > > username) into account if you are responsible for the domain of the > > request. In my example, the sp is responsible for=20 > foo.sp.com, but the > > pbxes are responsible for east.foo.sp.com and west.foo.sp.com. The > > other > > way, both the sp and the pbxes are responsible for=20 > foo.sp.com, which > > is > > problematic to me. > > =20 > > I see from the notes of the ad hoc, that there is some desire to > > restrict the scope to phone numbers. In that case it again=20 > is possible > > to give each pbx its own domain name. > > =20 > > Thanks, > > Paul > > =20 > > > -----Original Message----- > > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Wednesday, November 11, 2009 5:35 PM > > > To: Middleton, David (NSN - US/Boca Raton) > > > Cc: dispatch@ietf.org > > > Subject: Re: [dispatch] To-URI in domain-registration > > > > > > > > > > > > Middleton, David (NSN - US/Boca Raton) wrote: > > >> Paul, > > >> > > >> Sorry for the delay in responding. > > >> > > >> I think you are on target as far as describing many=20 > (perhaps most) > > SP / PBX interconnect arrangements. However, the functionality of > > having the SP route calls per user is a real-world scenario which > > proves there is merit for having the capability. > > > > > > This could still be dealt with by having the pbxes register to > > separate > > > sub-domains and the SP knowing (via provisioning) which things to > > route > > > to each. > > > > > > So instead of having: > > > > > > foo-east-pbx register to east@foo.sp.com > > > foo-west-pbx register to west@foo.sp.com > > > > > > you could simply have > > > > > > foo-east-pbx register to east.foo.sp.com > > > foo-west-pbx register to west.foo.sp.com > > > > > > Then the question of how requests addressed to xyz@foo.sp.com are > > mapped > > > to something@east.foo.sp.com or=20 > something@west.foo.sp.com is simply > > out > > > of scope of this document. > > > > > > Thanks, > > > Paul > > > > > > > > >> Also see inline. > > >> > > >> David > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: Friday, October 30, 2009 7:37 PM > > >> To: Middleton, David (NSN - US/Boca Raton) > > >> Cc: dispatch@ietf.org > > >> Subject: Re: [dispatch] To-URI in domain-registration > > >> > > >> David, > > >> > > >> IIUC, you are proposing a case such as: > > >> > > >> - a customer of sp.net has domain cust.sp.net > > >> - the customer has two PBX systems, east and west. > > >> - you propose that they register, respectively > > >> To: east@cust.sp.net, and > > >> To: west@cust.sp.net. > > >> - then numbers assigned to the customer are routed > > >> something like: > > >> 1-212-555-88xx -> contact from east@cust.sp.net > > >> 1-408-555-88xx -> contact from west@cust.sp.net > > >> - also, routing for names be something like: > > >> bob@cust.sp.net -> contact from east@cust.sp.net > > >> carol@cust.sp.net -> " > > >> ted@cust.sp.net -> contact from west@cust.sp.net > > >> alice@cust.sp.net -> " > > >> others... > > >> > > >> Is that right? > > >> Yes > > >> > > >> You then can't describe that as setting up routing paths for > > >> cust.sp.net. You are instead describing some entirely different > > routing > > >> algorithm based on the user part. > > >> Yes, it requires a local policy to determine the=20 > location of > > the users. > > >> > > >> Subdomains east.cust.sp.net and west.cust.sp.net solve=20 > this problem > > in > > >> large part - at least for the numbers. > > >> > > >> You clearly don't find that acceptable for the names. If those > > names > > >> were exposed to end users I wouldn't find it acceptable=20 > either. (I > > want > > >> to be pkyzivat@cisco.com, not pkyzivat@east.cisco.com.) > > >> Agreed > > >> > > >> The question is whether this is the best way to solve=20 > that problem. > > >> > > >> I think that solution won't be very acceptable to an=20 > SP, or to the > > >> customer of that SP. Having the SP provision every one of your > > users > > >> just isn't going to be popular with anyone. (Unless the=20 > SP gets a > > big > > >> enough per-user fee.) > > >> I agree but if the parties involved reach an acceptable > > agreement, the technology should support it IMO. > > >> > > >> Its not quite as much of a problem with numbers,=20 > because they are > > likely > > >> to be managed in blocks. And the numbers are really=20 > owned/managed > > by the > > >> SP anyway so they are forced to do something about them. > > >> > > >> This is also a problem that is not unique to this SP=20 > interconnect > > >> mechanism. It is pretty much the same problem in any big company > > with a > > >> lot of sites, even if they have a private network connecting all > > the sites. > > >> > > >> What you need in this case is a proxy at the company=20 > domain level > > >> (cust.sp.net in this case perhaps) that has the roster of all > > usernames > > >> and a mapping to a subdomain - mapping bob@cust.sp.net to > > >> bob@east.cust.sp.net. > > >> Yes but some enterprise customers do not want to=20 > do this and > > are able to convince the SP to do this. > > >> > > >> Then, the company has one server registering To:cust.sp.net to > > provide > > >> this mapping, and other servers registering To:east.cust.sp.net, > > ... > > >> > > >> Thanks, > > >> Paul > > >> > > >> > > >> Middleton, David (NSN - US/Boca Raton) wrote: > > >>> Some colleagues have pointed out an aspect that I had not > > considered concerning the domain registration To: user part. There > > are cases where an Enterprise has multiple PBXs that register and > > calls should be routed to one of the PBXs based on which user is > > called. In other words, instead of the Enterprise with=20 > multiple PBXs > > appearing as one logical PBX, the Enterprise customer wants the > > service provider to take responsibility for distributing=20 > the calls to > > the specific PBX that hosts the called user. > > >>> > > >>> While this problem could be solved with a local policy=20 > to choose > > one of several contacts it is not as clean an approach as=20 > being able > > to treat each registration as a separate entity with it's own > > contact(s). While one could propose that these be treated=20 > separately > > by making different sub-domains, the Enterprise most assuredly will > > not want to publish this sub-domain on business cards,=20 > etc. when using > > e-mail style addresses. Besides, it would cause the=20 > address to change > > if the user moves from one PBX to another as might happen with a > > physical move. > > >>> > > >>> Another aspect to consider is that the Enterprise user, in this > > scenario, is only reachable via one registered "To: user@host". So > > not having separate registrations would result in a more complex > > definition and implementation of things like (a.) is there an > > unexpired binding and (b.) picking appropriate contacts by q-value. > > >>> > > >>> I think this makes a strong case for having a user=20 > part in the To: > > header and treating each unique user@host as a separate=20 > registration =E0 > > la RFC 3264. > > >>> > > >>> In summary, I support Option 1) as well. > > >>> > > >>> - David > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] > > On Behalf Of ext Richard Shockey > > >>> Sent: Wednesday, October 21, 2009 4:42 PM > > >>> To: dispatch@ietf.org > > >>> Subject: Re: [dispatch] To-URI in domain-registration > > >>> > > >>> +1 to Option 1) as well > > >>> > > >>>> -----Original Message----- > > >>>> From: dispatch-bounces@ietf.org [mailto:dispatch- > > bounces@ietf.org] On > > >>>> Behalf Of David Hancock > > >>>> Sent: Wednesday, October 21, 2009 4:05 PM > > >>>> To: Brian Lindsay; Hadriel Kaplan; dispatch@ietf.org > > >>>> Subject: Re: [dispatch] To-URI in domain-registration > > >>>> > > >>>> > > >>>> Hadriel - I'd prefer option 1) as well. > > >>>> > > >>>> David > > >>>> > > >>>> > -----Original Message----- > > >>>> > From: dispatch-bounces@ietf.org [mailto:dispatch- > > bounces@ietf.org] > > >>>> On > > >>>> > Behalf Of Brian Lindsay > > >>>> > Sent: Wednesday, October 21, 2009 1:53 PM > > >>>> > To: Hadriel Kaplan; dispatch@ietf.org > > >>>> > Subject: Re: [dispatch] To-URI in domain-registration > > >>>> > > > >>>> > Hi Hadriel, > > >>>> > > > >>>> > Per my comment yesterday, I'd prefer (1). > > >>>> > > > >>>> > Thanks. > > >>>> > > > >>>> > -----Original Message----- > > >>>> > From: dispatch-bounces@ietf.org [mailto:dispatch- > > bounces@ietf.org] > > >>>> On > > >>>> > Behalf Of Hadriel Kaplan > > >>>> > Sent: Wednesday, October 21, 2009 3:43 PM > > >>>> > To: dispatch@ietf.org > > >>>> > Subject: [dispatch] To-URI in domain-registration > > >>>> > > > >>>> > Howdy, > > >>>> > I'd like to get a consensus call on the question=20 > of what the > > To-URI > > >>>> > should be for the REGISTER request of a domain=20 > registration, > > before > > >>>> > finishing the next rev of the draft. This will=20 > affect quite a > > bit > > >>>> of > > >>>> > text in the draft (e.g., examples), and I think that the > > decision > > >>>> about > > >>>> > that will also affect whether we need more than a > > Require:option-tag > > >>>> as > > >>>> > well. > > >>>> > > > >>>> > The choices right now are: > > >>>> > 1) Mandate the To-URI be in the syntactical form of an AoR, > > >>>> including > > >>>> > the user@ portion, the same as the From-URI. > > >>>> > Pros: closer to what current proprietary and other-SDO > > >>>> > mechanisms do, on the wire. Therefore, presumably=20 > less of a > > change > > >>>> and > > >>>> > less barrier to adoption. > > >>>> > 2) Mandate the To-URI be a domain only (no user@),=20 > while the > > From- > > >>>> URI > > >>>> > remains the "AoR" of the PBX registering. > > >>>> > Pros: semantically accurate (you're registering=20 > a domain, > > not an > > >>>> > AoR), and may obviate the need for a new header or param to > > indicate > > >>>> > this new mechanism is being used. > > >>>> > > > >>>> > Can people please indicate which they'd prefer? > > >>>> > > > >>>> > Thanks! > > >>>> > -hadriel > > >>>> > _______________________________________________ > > >>>> > dispatch mailing list > > >>>> > dispatch@ietf.org > > >>>> > https://www.ietf.org/mailman/listinfo/dispatch > > >>>> > _______________________________________________ > > >>>> > dispatch mailing list > > >>>> > dispatch@ietf.org > > >>>> > https://www.ietf.org/mailman/listinfo/dispatch > > >>>> _______________________________________________ > > >>>> dispatch mailing list > > >>>> dispatch@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/dispatch > > >>> _______________________________________________ > > >>> dispatch mailing list > > >>> dispatch@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/dispatch > > >>> _______________________________________________ > > >>> dispatch mailing list > > >>> dispatch@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/dispatch > > >>> > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From eburger@standardstrack.com Thu Nov 12 14:16:41 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1831D3A693D for ; Thu, 12 Nov 2009 14:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 5niqbv15sqtk for ; Thu, 12 Nov 2009 14:16:39 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id B08293A6852 for ; Thu, 12 Nov 2009 14:16:39 -0800 (PST) Received: from host-113-35.meeting.ietf.org ([133.93.113.35]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N8hyR-0005nk-Et for dispatch@ietf.org; Thu, 12 Nov 2009 14:17:04 -0800 Message-Id: <3BF94EF1-EA00-4016-8548-6808F9C2B61C@standardstrack.com> From: Eric Burger To: dispatch@ietf.org In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Fri, 13 Nov 2009 07:17:05 +0900 References: <3902F3D7-0D42-44A0-AC01-4BE8782A3AD3@standardstrack.com> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [dispatch] DREGS Ad Hoc minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 22:16:41 -0000 Likewise, I do not think the Note in the statement below is accurate. > Adam Roach: Are we really proposing to write the use of REGISTER in =20= > the charter? Answer: Yes. Adam stated that he was not prepared to =20= > have that discussion today because he thought it would be discussed =20= > in the WG. This feels like =93let=92s ratify this draft=94 rather = than =20 > =93let=92s work on this problem=94. > > > Spencer Dawkins: the intent is not to ratify existing draft. > > Note: In spite of Spencer=92s statement, the ensuing discussion made =20= > it very clear that for at least some of the authors, the intent was =20= > in fact very much to ratify this draft, or something very near it. =20= > Apparently the initial charter draft did not mention REGISTER and it =20= > was included because SIP Forum participants explicitly asked for it =20= > to be added. > > > Eric: the subject of whether or not REGISTER should be included in =20 > the charter has been discussed on the list, but there is not consensus > The reason of including REGISTER in the charter was not to ratify the =20= draft word-for-word, but to satisfy the conditions of no dynamic DNS =20 capability on the part of either the service provider or user. I.e., =20 limit the solution space so we did not spend months evaluating an =20 approach with zero chance of deployment. That said, consensus was the =20= charter limitation was overly restricted and to remove that limitation =20= (restricting the solution space to REGIST) from the draft charter. On Nov 12, 2009, at 5:26 PM, Spencer Dawkins wrote: > Hi, Shida and Jim, > > Thanks for taking notes and publishing them quickly. > > What *I* thought happened (very close to the end of the meeting), =20 > was that > > - Robert expressed his concern that SIP Forum participation and IETF =20= > participation didn't overlap, and this was a problem because that's =20= > the IESG's experience with inter-SDO coordination is that nothing =20 > good happens unless there's sufficient overlap, > > - Spencer said something like "we had about 12 (and John said 14) =20 > participants at the last SIPconnect face-to-face, and about 7 were =20 > regular IETF attendees, is that enough overlap?", and > > - Robert said he didn't think so. > > Others can, of course, confirm (and the audio will probably be =20 > available in a small number of days), but it's going to be real =20 > important to tease a way forward on this, and I don't want the notes =20= > to give the impression that Robert was convinced when I asked my =20 > question. > > Thanks, > > Spencer > ----- Original Message ----- > From: Eric Burger > To: dispatch@ietf.org > Sent: Thursday, November 12, 2009 5:14 PM > Subject: [dispatch] DREGS Ad Hoc minutes > > DREGS Adhoc > > Thursday 12 November 2009, 11:30 =96 1:00 > > Chairs: Eric Burger and Mary Barnes > > Scribes: Shida Schubert and Jim McEachern > > John Elwell =96 Charter Discussion. > > http://www.ietf.org/proceedings/09nov/slides/dispatch-6.ppt > > Jon Peterson reacted to the John=92s statement that =93decided we = needed =20 > a new WG=94 and said that he had suggested it perhaps should be in =20 > DRINKS. Was concerned about the presumption of what needs to be =20 > done to address the open issue. > > Cullen: the purpose of dispatch is to recommend what should be =20 > done. So we could recommend it go to DRINKS or wherever. Let=92s see = =20 > what we recommend. > > Clarified that the proposal was that this should be looked at, not =20 > that a WG was needed. > > Trying to standardize a uniform way for PBXs to register their =20 > domain. Today everyone does it their own way, even though they are =20= > all very similar. > > Proposing to use REGISTER with an added header for requesting domain =20= > registration. They are proposing this approach because it builds on =20= > what is already widely deployed. > > Adam Roach: Are we really proposing to write the use of REGISTER in =20= > the charter? Answer: Yes. Adam stated that he was not prepared to =20= > have that discussion today because he thought it would be discussed =20= > in the WG. This feels like =93let=92s ratify this draft=94 rather = than =20 > =93let=92s work on this problem=94. > > Spencer Dawkins: the intent is not to ratify existing draft. > > Note: In spite of Spencer=92s statement, the ensuing discussion made =20= > it very clear that for at least some of the authors, the intent was =20= > in fact very much to ratify this draft, or something very near it. =20= > Apparently the initial charter draft did not mention REGISTER and it =20= > was included because SIP Forum participants explicitly asked for it =20= > to be added. > > Eric: the subject of whether or not REGISTER should be included in =20 > the charter has been discussed on the list, but there is not consensus > > Someone stated that REGISTER was proposed because =93that is what is =20= > implemented=94 and we need to align with those implementations to be =20= > relevant. Jon countered that earlier it had been stated that the =20 > entire reason for this is that there are multiple ways this is =20 > implemented and that we need a standard to get interoperability. So =20= > if it is being done multiple ways today, the argument that REGISTER =20= > needs to be in the charter to align with deployed equipment, simply =20= > does not fly. > > Cable Labs supported the use of REGISTER because that is what they =20 > use in their specifications. > > Jim McEachern & Adam Roach both pointed out that even if you remove =20= > the word REGISTER from the charter, it does not mean that the =20 > eventual solution will have REGISTER. The bulk of the objections =20 > (dare I say the allergic reaction?) is to the fact that the solution =20= > (REGISTER) is being specified in the charter, when we should be =20 > simply defining the problem we are trying to solve. > > Anwar Siddiqi Asked about the definition of small =96 medium business, = =20 > and said that this will not apply to large enterprises since they =20 > will never give their register information to the SP. Therefore why =20= > not make it optional. > > Markus Isomaki, Nokia: What does this imply about the addresses of =20= > the terminals behind the PBX? Answer: UA registers with the PBX, =20 > but this work deals with the PBX registering with the SP. It is =20 > designed to help the SP work out where to send requests to =20 > =93example.com=94. > > Jon Peterson: Charter scope question. Is the charter focused on =20 > the specific problem on the slide, or the more general problem? =20 > (Note: I think this was referring to the bullets specifying =93a =20 > header field for requesting domain registration=94 and =93a SIP option = =20 > tag to detect non-support of this mechanism=94.) Answer: The more =20= > general one. (Note: I think this meant the general problem of PBXs =20= > registering=85) > > Jon Peterson: The only way this charter will get approved is by =20 > taking REGISTER out of the draft. Lots of nods to that. > > Spencer: If this looks like tweaking existing implementations, it =20 > will get more interest than if it looked like a new method. =20 > Preference is to be up front about this. > > Cullen (channeling Hadriel): If Hadriel were here he would insist =20 > it must be REGISTER or it will never be deployed. > > Cullen: would the possible solution space now include dynamic dns? =20= > The only reason to specify a solution in the charter is to =20 > explicitly exclude alternate classes of solution =96 isn=92t it? > > Chris Stanley =96 cable labs. We need to deploy this for businesses =20= > and need to move quickly. (And REGISTER is the mechanism we use.) > > Adam Roach: how far are we going to go down this path of specifying =20= > the answer in the charter? If we allow it for REGISTER for this WG, =20= > what other things are we going to do it for? > > Cullen as AD: He was the one who earlier encouraged them to be very =20= > specific to see if they could get consensus on the approach to =20 > shorten the process, even though he suspected the proposal would get =20= > the reaction that it is currently getting. However, if the group =20 > cannot get consensus to specify the solution in the charter, then =20 > the only approach is to remove it. This is clearly the case. > > Hum: Should we leave the charter exactly as it is? Result: =20 > Moderate hum > > Hum: Should we leave the charter largely as is, but remove the =20 > solution (REGISTER) from the charter. Result: Strong hum. > > Discussed a vote on =93Is there a critical mass in the IETF to work on = =20 > this problem?=94, but instead decided on the following wording. > > Hum: Does anyone think that we don=92t have the critical mass and the = =20 > expertise to tackle this. Result: no one objected. So consensus =20 > for this. > > Hum: is the IETF the place to work on this? Answer: yes > > Note: The following happened after the meeting had officially =20 > closed, but is included here because it pointed toward a possible =20 > way forward. > > Jon: Discussion of the precedent setting risks of just adopting an =20 > existing solution. One way forward may be to think about this as a =20= > telephone number problem rather than a domain problem, which would =20 > make it a much easier problem. If we can scope it that way then it =20= > will make it a much quicker problem to solve. > > Alan Johnston: All the SIP Forum discussion is in fact about =20 > telephone numbers, so restricting it to telephone numbers is what we =20= > are looking for > > Cullen: Recognize that we do need to find ways to work faster. =93If = =20 > you send me a charter by midnight tonight, I will have it on the =20 > agenda for the next IESG meeting=94 > > Meeting officially closed. > > Since we had time, we had an open discussion of how to make progress=85 > > Discussion of what would be realistic dates for this? The =20 > discussion indicated that March and June might be more believable =20 > dates. > > Cullen: Recognize that we do need to find ways to work faster. =93If = =20 > you send me a charter by midnight tonight, I will have it on the =20 > agenda for the next IESG meeting=94 > > Robert Sparks: Recipe for success in SDOs cooperating is having a =20 > significant overlap of common participants working on the problem. =20= > He is concerned that the overlap is not enough. > > Spencer: Last SIP Forum meeting had 12 people and 7 of them were =20 > also in the IETF. Is that enough? > > Jon: Discussion of the precedent setting risks of just adopting an =20 > existing solution. One way forward may be to think about this as a =20= > telephone number problem rather than a domain problem, then it is a =20= > much easier problem. If we can scope it that way then it will make =20= > it a much easier problem to solve. > > Alan Johnston: All the SIP Forum discussion is in fact about =20 > telephone numbers, so restricting it to telephone numbers would be =20 > acceptable. > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Thu Nov 12 14:29:46 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEDE33A6909 for ; Thu, 12 Nov 2009 14:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 eVFXNjj6gW0t for ; Thu, 12 Nov 2009 14:29:45 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 395BA3A68E8 for ; Thu, 12 Nov 2009 14:29:45 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPsa/EqrR7Ht/2dsb2JhbAC9XokbCAeOc4JLCIFpBA X-IronPort-AV: E=Sophos;i="4.44,731,1249257600"; d="scan'208";a="223846379" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 12 Nov 2009 22:30:14 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nACMUAg9010685; Thu, 12 Nov 2009 22:30:14 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 17:30:11 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 17:30:10 -0500 Message-ID: <4AFC8C72.7030101@cisco.com> Date: Thu, 12 Nov 2009 17:30:10 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com><9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> <024101ca528e$fbd0a8b0$f371fa10$@us> <159B27ECF9D16E40BD7ABD5778522B0103792C9C@USCHEXC006.nsn-intra.net> <4AEB78AD.5070608@cisco.com> <159B27ECF9D16E40BD7ABD5778522B010389E177@USCHEXC006.nsn-intra.net> <4AFB3C0F.40203@cisco.com> <159B27ECF9D16E40BD7ABD5778522B010389E40E@USCHEXC006.nsn-intra.net> <4AFC11BA.2000104@cisco.com> <024f01ca63d9$c0c8d240$425a76c0$@us> <7402509E63C5A145A6095D46C179A5B70725DA3C67@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B70725DA3C67@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Nov 2009 22:30:10.0573 (UTC) FILETIME=[B1D6F3D0:01CA63E7] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Phone numbers and domain registration (was RE: To-URI in domain-registration) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 22:29:47 -0000 Elwell, John wrote: > During the DISPATCH ad hoc session there was indeed a suggestion to limit the mechanism to domains employing E.164-based SIP URIs. However, this would leave an issue with contact URIs, which would presumably not be constrained to being based on telephone numbers. It must be possible to route an out-of-dialog request to a contact URI issued by the SIP-PBX. Hmm, that's true. And it sheds a different light on the question about whether the To: of the register can have a username as well as domain name. The argument for that has been that then the SP can steer requests to different pbxes in the same domain. I can see how that could work for phone numbers - static configuration of those to different "usernames@domain". I can *possibly* imagine that working for email style URIs too, though it would require the SP to provision all the usernames in the domain that the PBXes share. But I really *can't* imagine how that can work for contact addresses using the shared domain and some arbitrary username part. Thanks, Paul > John > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Shockey >> Sent: 12 November 2009 20:50 >> To: 'Paul Kyzivat'; 'Middleton, David (NSN - US/Boca Raton)' >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] To-URI in domain-registration >> >> To clarify .. in the discussions within the SIPforum there >> was no question >> that the scope was restricted to phone numbers. >> >> here were only 2-3 participants that did not usually attend >> IETF meetings >> and those represented small CLEC's. As a practical matter the overlap >> between IETF and the SIPforum discussions was nearly total. >> >> >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Thursday, November 12, 2009 8:47 AM >>> To: Middleton, David (NSN - US/Boca Raton) >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] To-URI in domain-registration >>> >>> >>> >>> Middleton, David (NSN - US/Boca Raton) wrote: >>> > I agree this is possible but having the SP >> cross-reference domains >>> is not in the spirit of domain registration from my perspective. >>> >>> But having the SP partition traffic for one domain based >> on the user >>> part of the request *is* in the spirit? IMO it is exactly the same >>> thing, or cleaner. >>> >>> Its a matter of who is responsible for a particular >> domain, the sp or >>> the pbx. IMO you should only take *other* information (such as the >>> username) into account if you are responsible for the domain of the >>> request. In my example, the sp is responsible for >> foo.sp.com, but the >>> pbxes are responsible for east.foo.sp.com and west.foo.sp.com. The >>> other >>> way, both the sp and the pbxes are responsible for >> foo.sp.com, which >>> is >>> problematic to me. >>> >>> I see from the notes of the ad hoc, that there is some desire to >>> restrict the scope to phone numbers. In that case it again >> is possible >>> to give each pbx its own domain name. >>> >>> Thanks, >>> Paul >>> >>> > -----Original Message----- >>> > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> > Sent: Wednesday, November 11, 2009 5:35 PM >>> > To: Middleton, David (NSN - US/Boca Raton) >>> > Cc: dispatch@ietf.org >>> > Subject: Re: [dispatch] To-URI in domain-registration >>> > >>> > >>> > >>> > Middleton, David (NSN - US/Boca Raton) wrote: >>> >> Paul, >>> >> >>> >> Sorry for the delay in responding. >>> >> >>> >> I think you are on target as far as describing many >> (perhaps most) >>> SP / PBX interconnect arrangements. However, the functionality of >>> having the SP route calls per user is a real-world scenario which >>> proves there is merit for having the capability. >>> > >>> > This could still be dealt with by having the pbxes register to >>> separate >>> > sub-domains and the SP knowing (via provisioning) which things to >>> route >>> > to each. >>> > >>> > So instead of having: >>> > >>> > foo-east-pbx register to east@foo.sp.com >>> > foo-west-pbx register to west@foo.sp.com >>> > >>> > you could simply have >>> > >>> > foo-east-pbx register to east.foo.sp.com >>> > foo-west-pbx register to west.foo.sp.com >>> > >>> > Then the question of how requests addressed to xyz@foo.sp.com are >>> mapped >>> > to something@east.foo.sp.com or >> something@west.foo.sp.com is simply >>> out >>> > of scope of this document. >>> > >>> > Thanks, >>> > Paul >>> > >>> > >>> >> Also see inline. >>> >> >>> >> David >>> >> >>> >> >>> >> >>> >> -----Original Message----- >>> >> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> >> Sent: Friday, October 30, 2009 7:37 PM >>> >> To: Middleton, David (NSN - US/Boca Raton) >>> >> Cc: dispatch@ietf.org >>> >> Subject: Re: [dispatch] To-URI in domain-registration >>> >> >>> >> David, >>> >> >>> >> IIUC, you are proposing a case such as: >>> >> >>> >> - a customer of sp.net has domain cust.sp.net >>> >> - the customer has two PBX systems, east and west. >>> >> - you propose that they register, respectively >>> >> To: east@cust.sp.net, and >>> >> To: west@cust.sp.net. >>> >> - then numbers assigned to the customer are routed >>> >> something like: >>> >> 1-212-555-88xx -> contact from east@cust.sp.net >>> >> 1-408-555-88xx -> contact from west@cust.sp.net >>> >> - also, routing for names be something like: >>> >> bob@cust.sp.net -> contact from east@cust.sp.net >>> >> carol@cust.sp.net -> " >>> >> ted@cust.sp.net -> contact from west@cust.sp.net >>> >> alice@cust.sp.net -> " >>> >> others... >>> >> >>> >> Is that right? >>> >> Yes >>> >> >>> >> You then can't describe that as setting up routing paths for >>> >> cust.sp.net. You are instead describing some entirely different >>> routing >>> >> algorithm based on the user part. >>> >> Yes, it requires a local policy to determine the >> location of >>> the users. >>> >> >>> >> Subdomains east.cust.sp.net and west.cust.sp.net solve >> this problem >>> in >>> >> large part - at least for the numbers. >>> >> >>> >> You clearly don't find that acceptable for the names. If those >>> names >>> >> were exposed to end users I wouldn't find it acceptable >> either. (I >>> want >>> >> to be pkyzivat@cisco.com, not pkyzivat@east.cisco.com.) >>> >> Agreed >>> >> >>> >> The question is whether this is the best way to solve >> that problem. >>> >> >>> >> I think that solution won't be very acceptable to an >> SP, or to the >>> >> customer of that SP. Having the SP provision every one of your >>> users >>> >> just isn't going to be popular with anyone. (Unless the >> SP gets a >>> big >>> >> enough per-user fee.) >>> >> I agree but if the parties involved reach an acceptable >>> agreement, the technology should support it IMO. >>> >> >>> >> Its not quite as much of a problem with numbers, >> because they are >>> likely >>> >> to be managed in blocks. And the numbers are really >> owned/managed >>> by the >>> >> SP anyway so they are forced to do something about them. >>> >> >>> >> This is also a problem that is not unique to this SP >> interconnect >>> >> mechanism. It is pretty much the same problem in any big company >>> with a >>> >> lot of sites, even if they have a private network connecting all >>> the sites. >>> >> >>> >> What you need in this case is a proxy at the company >> domain level >>> >> (cust.sp.net in this case perhaps) that has the roster of all >>> usernames >>> >> and a mapping to a subdomain - mapping bob@cust.sp.net to >>> >> bob@east.cust.sp.net. >>> >> Yes but some enterprise customers do not want to >> do this and >>> are able to convince the SP to do this. >>> >> >>> >> Then, the company has one server registering To:cust.sp.net to >>> provide >>> >> this mapping, and other servers registering To:east.cust.sp.net, >>> ... >>> >> >>> >> Thanks, >>> >> Paul >>> >> >>> >> >>> >> Middleton, David (NSN - US/Boca Raton) wrote: >>> >>> Some colleagues have pointed out an aspect that I had not >>> considered concerning the domain registration To: user part. There >>> are cases where an Enterprise has multiple PBXs that register and >>> calls should be routed to one of the PBXs based on which user is >>> called. In other words, instead of the Enterprise with >> multiple PBXs >>> appearing as one logical PBX, the Enterprise customer wants the >>> service provider to take responsibility for distributing >> the calls to >>> the specific PBX that hosts the called user. >>> >>> >>> >>> While this problem could be solved with a local policy >> to choose >>> one of several contacts it is not as clean an approach as >> being able >>> to treat each registration as a separate entity with it's own >>> contact(s). While one could propose that these be treated >> separately >>> by making different sub-domains, the Enterprise most assuredly will >>> not want to publish this sub-domain on business cards, >> etc. when using >>> e-mail style addresses. Besides, it would cause the >> address to change >>> if the user moves from one PBX to another as might happen with a >>> physical move. >>> >>> >>> >>> Another aspect to consider is that the Enterprise user, in this >>> scenario, is only reachable via one registered "To: user@host". So >>> not having separate registrations would result in a more complex >>> definition and implementation of things like (a.) is there an >>> unexpired binding and (b.) picking appropriate contacts by q-value. >>> >>> >>> >>> I think this makes a strong case for having a user >> part in the To: >>> header and treating each unique user@host as a separate >> registration à >>> la RFC 3264. >>> >>> >>> >>> In summary, I support Option 1) as well. >>> >>> >>> >>> - David >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] >>> On Behalf Of ext Richard Shockey >>> >>> Sent: Wednesday, October 21, 2009 4:42 PM >>> >>> To: dispatch@ietf.org >>> >>> Subject: Re: [dispatch] To-URI in domain-registration >>> >>> >>> >>> +1 to Option 1) as well >>> >>> >>> >>>> -----Original Message----- >>> >>>> From: dispatch-bounces@ietf.org [mailto:dispatch- >>> bounces@ietf.org] On >>> >>>> Behalf Of David Hancock >>> >>>> Sent: Wednesday, October 21, 2009 4:05 PM >>> >>>> To: Brian Lindsay; Hadriel Kaplan; dispatch@ietf.org >>> >>>> Subject: Re: [dispatch] To-URI in domain-registration >>> >>>> >>> >>>> >>> >>>> Hadriel - I'd prefer option 1) as well. >>> >>>> >>> >>>> David >>> >>>> >>> >>>> > -----Original Message----- >>> >>>> > From: dispatch-bounces@ietf.org [mailto:dispatch- >>> bounces@ietf.org] >>> >>>> On >>> >>>> > Behalf Of Brian Lindsay >>> >>>> > Sent: Wednesday, October 21, 2009 1:53 PM >>> >>>> > To: Hadriel Kaplan; dispatch@ietf.org >>> >>>> > Subject: Re: [dispatch] To-URI in domain-registration >>> >>>> > >>> >>>> > Hi Hadriel, >>> >>>> > >>> >>>> > Per my comment yesterday, I'd prefer (1). >>> >>>> > >>> >>>> > Thanks. >>> >>>> > >>> >>>> > -----Original Message----- >>> >>>> > From: dispatch-bounces@ietf.org [mailto:dispatch- >>> bounces@ietf.org] >>> >>>> On >>> >>>> > Behalf Of Hadriel Kaplan >>> >>>> > Sent: Wednesday, October 21, 2009 3:43 PM >>> >>>> > To: dispatch@ietf.org >>> >>>> > Subject: [dispatch] To-URI in domain-registration >>> >>>> > >>> >>>> > Howdy, >>> >>>> > I'd like to get a consensus call on the question >> of what the >>> To-URI >>> >>>> > should be for the REGISTER request of a domain >> registration, >>> before >>> >>>> > finishing the next rev of the draft. This will >> affect quite a >>> bit >>> >>>> of >>> >>>> > text in the draft (e.g., examples), and I think that the >>> decision >>> >>>> about >>> >>>> > that will also affect whether we need more than a >>> Require:option-tag >>> >>>> as >>> >>>> > well. >>> >>>> > >>> >>>> > The choices right now are: >>> >>>> > 1) Mandate the To-URI be in the syntactical form of an AoR, >>> >>>> including >>> >>>> > the user@ portion, the same as the From-URI. >>> >>>> > Pros: closer to what current proprietary and other-SDO >>> >>>> > mechanisms do, on the wire. Therefore, presumably >> less of a >>> change >>> >>>> and >>> >>>> > less barrier to adoption. >>> >>>> > 2) Mandate the To-URI be a domain only (no user@), >> while the >>> From- >>> >>>> URI >>> >>>> > remains the "AoR" of the PBX registering. >>> >>>> > Pros: semantically accurate (you're registering >> a domain, >>> not an >>> >>>> > AoR), and may obviate the need for a new header or param to >>> indicate >>> >>>> > this new mechanism is being used. >>> >>>> > >>> >>>> > Can people please indicate which they'd prefer? >>> >>>> > >>> >>>> > Thanks! >>> >>>> > -hadriel >>> >>>> > _______________________________________________ >>> >>>> > dispatch mailing list >>> >>>> > dispatch@ietf.org >>> >>>> > https://www.ietf.org/mailman/listinfo/dispatch >>> >>>> > _______________________________________________ >>> >>>> > dispatch mailing list >>> >>>> > dispatch@ietf.org >>> >>>> > https://www.ietf.org/mailman/listinfo/dispatch >>> >>>> _______________________________________________ >>> >>>> dispatch mailing list >>> >>>> dispatch@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> >>> dispatch mailing list >>> >>> dispatch@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> >>> dispatch mailing list >>> >>> dispatch@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> > >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From mary.barnes@nortel.com Thu Nov 12 14:32:10 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA2F3A6977 for ; Thu, 12 Nov 2009 14:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.010, 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 3dx9Bnd9KRjt for ; Thu, 12 Nov 2009 14:32:08 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 88C833A6A2F for ; Thu, 12 Nov 2009 14:32:07 -0800 (PST) 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 nACMWNY25851; Thu, 12 Nov 2009 22:32:24 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_01CA63E7.D50A749D" Date: Thu, 12 Nov 2009 16:30:16 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DREGS Ad Hoc minutes Thread-Index: Acpj5eaVchKQE3LQT7aAFfULMG63SAAAc6mU References: <3902F3D7-0D42-44A0-AC01-4BE8782A3AD3@standardstrack.com> <3BF94EF1-EA00-4016-8548-6808F9C2B61C@standardstrack.com> From: "Mary Barnes" To: "Eric Burger" , Subject: Re: [dispatch] DREGS Ad Hoc minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 22:32:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA63E7.D50A749D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The minutes on the server have already been updated to remove the = "Note:" . Mary. -----Original Message----- From: dispatch-bounces@ietf.org on behalf of Eric Burger Sent: Thu 11/12/2009 4:17 PM To: dispatch@ietf.org Subject: Re: [dispatch] DREGS Ad Hoc minutes =20 Likewise, I do not think the Note in the statement below is accurate. > Adam Roach: Are we really proposing to write the use of REGISTER in =20 > the charter? Answer: Yes. Adam stated that he was not prepared to =20 > have that discussion today because he thought it would be discussed =20 > in the WG. This feels like "let's ratify this draft" rather than =20 > "let's work on this problem". > > > Spencer Dawkins: the intent is not to ratify existing draft. > > Note: In spite of Spencer's statement, the ensuing discussion made =20 > it very clear that for at least some of the authors, the intent was =20 > in fact very much to ratify this draft, or something very near it. =20 > Apparently the initial charter draft did not mention REGISTER and it =20 > was included because SIP Forum participants explicitly asked for it =20 > to be added. > > > Eric: the subject of whether or not REGISTER should be included in =20 > the charter has been discussed on the list, but there is not consensus > The reason of including REGISTER in the charter was not to ratify the =20 draft word-for-word, but to satisfy the conditions of no dynamic DNS =20 capability on the part of either the service provider or user. I.e., =20 limit the solution space so we did not spend months evaluating an =20 approach with zero chance of deployment. That said, consensus was the =20 charter limitation was overly restricted and to remove that limitation =20 (restricting the solution space to REGIST) from the draft charter. On Nov 12, 2009, at 5:26 PM, Spencer Dawkins wrote: > Hi, Shida and Jim, > > Thanks for taking notes and publishing them quickly. > > What *I* thought happened (very close to the end of the meeting), =20 > was that > > - Robert expressed his concern that SIP Forum participation and IETF =20 > participation didn't overlap, and this was a problem because that's =20 > the IESG's experience with inter-SDO coordination is that nothing =20 > good happens unless there's sufficient overlap, > > - Spencer said something like "we had about 12 (and John said 14) =20 > participants at the last SIPconnect face-to-face, and about 7 were =20 > regular IETF attendees, is that enough overlap?", and > > - Robert said he didn't think so. > > Others can, of course, confirm (and the audio will probably be =20 > available in a small number of days), but it's going to be real =20 > important to tease a way forward on this, and I don't want the notes =20 > to give the impression that Robert was convinced when I asked my =20 > question. > > Thanks, > > Spencer > ----- Original Message ----- > From: Eric Burger > To: dispatch@ietf.org > Sent: Thursday, November 12, 2009 5:14 PM > Subject: [dispatch] DREGS Ad Hoc minutes > > DREGS Adhoc > > Thursday 12 November 2009, 11:30 - 1:00 > > Chairs: Eric Burger and Mary Barnes > > Scribes: Shida Schubert and Jim McEachern > > John Elwell - Charter Discussion. > > http://www.ietf.org/proceedings/09nov/slides/dispatch-6.ppt > > Jon Peterson reacted to the John's statement that "decided we needed =20 > a new WG" and said that he had suggested it perhaps should be in =20 > DRINKS. Was concerned about the presumption of what needs to be =20 > done to address the open issue. > > Cullen: the purpose of dispatch is to recommend what should be =20 > done. So we could recommend it go to DRINKS or wherever. Let's see =20 > what we recommend. > > Clarified that the proposal was that this should be looked at, not =20 > that a WG was needed. > > Trying to standardize a uniform way for PBXs to register their =20 > domain. Today everyone does it their own way, even though they are =20 > all very similar. > > Proposing to use REGISTER with an added header for requesting domain =20 > registration. They are proposing this approach because it builds on =20 > what is already widely deployed. > > Adam Roach: Are we really proposing to write the use of REGISTER in =20 > the charter? Answer: Yes. Adam stated that he was not prepared to =20 > have that discussion today because he thought it would be discussed =20 > in the WG. This feels like "let's ratify this draft" rather than =20 > "let's work on this problem". > > Spencer Dawkins: the intent is not to ratify existing draft. > > Note: In spite of Spencer's statement, the ensuing discussion made =20 > it very clear that for at least some of the authors, the intent was =20 > in fact very much to ratify this draft, or something very near it. =20 > Apparently the initial charter draft did not mention REGISTER and it =20 > was included because SIP Forum participants explicitly asked for it =20 > to be added. > > Eric: the subject of whether or not REGISTER should be included in =20 > the charter has been discussed on the list, but there is not consensus > > Someone stated that REGISTER was proposed because "that is what is =20 > implemented" and we need to align with those implementations to be =20 > relevant. Jon countered that earlier it had been stated that the =20 > entire reason for this is that there are multiple ways this is =20 > implemented and that we need a standard to get interoperability. So =20 > if it is being done multiple ways today, the argument that REGISTER =20 > needs to be in the charter to align with deployed equipment, simply =20 > does not fly. > > Cable Labs supported the use of REGISTER because that is what they =20 > use in their specifications. > > Jim McEachern & Adam Roach both pointed out that even if you remove =20 > the word REGISTER from the charter, it does not mean that the =20 > eventual solution will have REGISTER. The bulk of the objections =20 > (dare I say the allergic reaction?) is to the fact that the solution =20 > (REGISTER) is being specified in the charter, when we should be =20 > simply defining the problem we are trying to solve. > > Anwar Siddiqi Asked about the definition of small - medium business, =20 > and said that this will not apply to large enterprises since they =20 > will never give their register information to the SP. Therefore why =20 > not make it optional. > > Markus Isomaki, Nokia: What does this imply about the addresses of =20 > the terminals behind the PBX? Answer: UA registers with the PBX, =20 > but this work deals with the PBX registering with the SP. It is =20 > designed to help the SP work out where to send requests to =20 > "example.com". > > Jon Peterson: Charter scope question. Is the charter focused on =20 > the specific problem on the slide, or the more general problem? =20 > (Note: I think this was referring to the bullets specifying "a =20 > header field for requesting domain registration" and "a SIP option =20 > tag to detect non-support of this mechanism".) Answer: The more =20 > general one. (Note: I think this meant the general problem of PBXs =20 > registering.) > > Jon Peterson: The only way this charter will get approved is by =20 > taking REGISTER out of the draft. Lots of nods to that. > > Spencer: If this looks like tweaking existing implementations, it =20 > will get more interest than if it looked like a new method. =20 > Preference is to be up front about this. > > Cullen (channeling Hadriel): If Hadriel were here he would insist =20 > it must be REGISTER or it will never be deployed. > > Cullen: would the possible solution space now include dynamic dns? =20 > The only reason to specify a solution in the charter is to =20 > explicitly exclude alternate classes of solution - isn't it? > > Chris Stanley - cable labs. We need to deploy this for businesses =20 > and need to move quickly. (And REGISTER is the mechanism we use.) > > Adam Roach: how far are we going to go down this path of specifying =20 > the answer in the charter? If we allow it for REGISTER for this WG, =20 > what other things are we going to do it for? > > Cullen as AD: He was the one who earlier encouraged them to be very =20 > specific to see if they could get consensus on the approach to =20 > shorten the process, even though he suspected the proposal would get =20 > the reaction that it is currently getting. However, if the group =20 > cannot get consensus to specify the solution in the charter, then =20 > the only approach is to remove it. This is clearly the case. > > Hum: Should we leave the charter exactly as it is? Result: =20 > Moderate hum > > Hum: Should we leave the charter largely as is, but remove the =20 > solution (REGISTER) from the charter. Result: Strong hum. > > Discussed a vote on "Is there a critical mass in the IETF to work on =20 > this problem?", but instead decided on the following wording. > > Hum: Does anyone think that we don't have the critical mass and the =20 > expertise to tackle this. Result: no one objected. So consensus =20 > for this. > > Hum: is the IETF the place to work on this? Answer: yes > > Note: The following happened after the meeting had officially =20 > closed, but is included here because it pointed toward a possible =20 > way forward. > > Jon: Discussion of the precedent setting risks of just adopting an =20 > existing solution. One way forward may be to think about this as a =20 > telephone number problem rather than a domain problem, which would =20 > make it a much easier problem. If we can scope it that way then it =20 > will make it a much quicker problem to solve. > > Alan Johnston: All the SIP Forum discussion is in fact about =20 > telephone numbers, so restricting it to telephone numbers is what we =20 > are looking for > > Cullen: Recognize that we do need to find ways to work faster. "If =20 > you send me a charter by midnight tonight, I will have it on the =20 > agenda for the next IESG meeting" > > Meeting officially closed. > > Since we had time, we had an open discussion of how to make progress. > > Discussion of what would be realistic dates for this? The =20 > discussion indicated that March and June might be more believable =20 > dates. > > Cullen: Recognize that we do need to find ways to work faster. "If =20 > you send me a charter by midnight tonight, I will have it on the =20 > agenda for the next IESG meeting" > > Robert Sparks: Recipe for success in SDOs cooperating is having a =20 > significant overlap of common participants working on the problem. =20 > He is concerned that the overlap is not enough. > > Spencer: Last SIP Forum meeting had 12 people and 7 of them were =20 > also in the IETF. Is that enough? > > Jon: Discussion of the precedent setting risks of just adopting an =20 > existing solution. One way forward may be to think about this as a =20 > telephone number problem rather than a domain problem, then it is a =20 > much easier problem. If we can scope it that way then it will make =20 > it a much easier problem to solve. > > Alan Johnston: All the SIP Forum discussion is in fact about =20 > telephone numbers, so restricting it to telephone numbers would be =20 > acceptable. > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------_=_NextPart_001_01CA63E7.D50A749D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dispatch] DREGS Ad Hoc minutes

The minutes on the server have already been updated to = remove the "Note:" .


Mary.

-----Original Message-----
From: dispatch-bounces@ietf.org on behalf of Eric Burger
Sent: Thu 11/12/2009 4:17 PM
To: dispatch@ietf.org
Subject: Re: [dispatch] DREGS Ad Hoc minutes

Likewise, I do not think the Note in the statement below is = accurate.
> Adam Roach:  Are we really proposing to write the use of = REGISTER in 
> the charter?  Answer: Yes.  Adam stated that he was not = prepared to 
> have that discussion today because he thought it would be = discussed 
> in the WG.  This feels like "let's ratify this = draft" rather than 
> "let's work on this problem".
>
>
> Spencer Dawkins: the intent is not to ratify existing draft.
>
> Note:  In spite of Spencer's statement, the ensuing discussion = made 
> it very clear that for at least some of the authors, the intent = was 
> in fact very much to ratify this draft, or something very near = it.  
> Apparently the initial charter draft did not mention REGISTER and = it 
> was included because SIP Forum participants explicitly asked for = it 
> to be added.
>
>
> Eric: the subject of whether or not REGISTER should be included = in 
> the charter has been discussed on the list, but there is not = consensus
>


The reason of including REGISTER in the charter was not to ratify = the 
draft word-for-word, but to satisfy the conditions of no dynamic = DNS 
capability on the part of either the service provider or user. = I.e., 
limit the solution space so we did not spend months evaluating = an 
approach with zero chance of deployment.  That said, consensus was = the 
charter limitation was overly restricted and to remove that = limitation 
(restricting the solution space to REGIST) from the draft charter.


On Nov 12, 2009, at 5:26 PM, Spencer Dawkins wrote:

> Hi, Shida and Jim,
>
> Thanks for taking notes and publishing them quickly.
>
> What *I* thought happened (very close to the end of the = meeting), 
> was that
>
> - Robert expressed his concern that SIP Forum participation and = IETF 
> participation didn't overlap, and this was a problem because = that's 
> the IESG's experience with inter-SDO coordination is that = nothing 
> good happens unless there's sufficient overlap,
>
> - Spencer said something like "we had about 12 (and John said = 14) 
> participants at the last SIPconnect face-to-face, and about 7 = were 
> regular IETF attendees, is that enough overlap?", and
>
> - Robert said he didn't think so.
>
> Others can, of course, confirm (and the audio will probably = be 
> available in a small number of days), but it's going to be = real 
> important to tease a way forward on this, and I don't want the = notes 
> to give the impression that Robert was convinced when I asked = my 
> question.
>
> Thanks,
>
> Spencer
> ----- Original Message -----
> From: Eric Burger
> To: dispatch@ietf.org
> Sent: Thursday, November 12, 2009 5:14 PM
> Subject: [dispatch] DREGS Ad Hoc minutes
>
> DREGS Adhoc
>
> Thursday 12 November 2009, 11:30 - 1:00
>
> Chairs: Eric Burger and Mary Barnes
>
> Scribes: Shida Schubert and Jim McEachern
>
> John Elwell - Charter Discussion.
>
> http= ://www.ietf.org/proceedings/09nov/slides/dispatch-6.ppt
>
> Jon Peterson reacted to the John's statement that "decided we = needed 
> a new WG" and said that he had suggested it perhaps should be = in 
> DRINKS.  Was concerned about the presumption of what needs to = be 
> done to address the open issue.
>
> Cullen:  the purpose of dispatch is to recommend what should = be 
> done.  So we could recommend it go to DRINKS or = wherever.  Let's see 
> what we recommend.
>
> Clarified that the proposal was that this should be looked at, = not 
> that a WG was needed.
>
> Trying to standardize a uniform way for PBXs to register = their 
> domain.  Today everyone does it their own way, even though = they are 
> all very similar.
>
> Proposing to use REGISTER with an added header for requesting = domain 
> registration.  They are proposing this approach because it = builds on 
> what is already widely deployed.
>
> Adam Roach:  Are we really proposing to write the use of = REGISTER in 
> the charter?  Answer: Yes.  Adam stated that he was not = prepared to 
> have that discussion today because he thought it would be = discussed 
> in the WG.  This feels like "let's ratify this = draft" rather than 
> "let's work on this problem".
>
> Spencer Dawkins: the intent is not to ratify existing draft.
>
> Note:  In spite of Spencer's statement, the ensuing discussion = made 
> it very clear that for at least some of the authors, the intent = was 
> in fact very much to ratify this draft, or something very near = it.  
> Apparently the initial charter draft did not mention REGISTER and = it 
> was included because SIP Forum participants explicitly asked for = it 
> to be added.
>
> Eric: the subject of whether or not REGISTER should be included = in 
> the charter has been discussed on the list, but there is not = consensus
>
> Someone stated that REGISTER was proposed because "that is = what is 
> implemented" and we need to align with those implementations = to be 
> relevant.  Jon countered that earlier it had been stated that = the 
> entire reason for this is that there are multiple ways this = is 
> implemented and that we need a standard to get = interoperability.  So 
> if it is being done multiple ways today, the argument that = REGISTER 
> needs to be in the charter to align with deployed equipment, = simply 
> does not fly.
>
> Cable Labs supported the use of REGISTER because that is what = they 
> use in their specifications.
>
> Jim McEachern & Adam Roach both pointed out that even if you = remove 
> the word REGISTER from the charter, it does not mean that = the 
> eventual solution will have REGISTER.  The bulk of the = objections 
> (dare I say the allergic reaction?) is to the fact that the = solution 
> (REGISTER) is being specified in the charter, when we should = be 
> simply defining the problem we are trying to solve.
>
> Anwar Siddiqi Asked about the definition of small - medium = business, 
> and said that this will not apply to large enterprises since = they 
> will never give their register information to the SP.  = Therefore why 
> not make it optional.
>
> Markus Isomaki, Nokia:  What does this imply about the = addresses of 
> the terminals behind the PBX?  Answer: UA registers with the = PBX, 
> but this work deals with the PBX registering with the SP.  It = is 
> designed to help the SP work out where to send requests = to 
> "example.com".
>
> Jon Peterson:  Charter scope question.  Is the charter = focused on 
> the specific problem on the slide, or the more general = problem? 
> (Note: I think this was referring to the bullets specifying = "a 
> header field for requesting domain registration" and "a = SIP option 
> tag to detect non-support of this mechanism".)   = Answer: The more 
> general one.  (Note:  I think this meant the general = problem of PBXs 
> registering.)
>
> Jon Peterson:  The only way this charter will get approved is = by 
> taking REGISTER out of the draft.  Lots of nods to that.
>
> Spencer:  If this looks like tweaking existing = implementations, it 
> will get more interest than if it looked like a new = method.  
> Preference is to be up front about this.
>
> Cullen (channeling Hadriel):  If Hadriel were here he would = insist 
> it must be REGISTER or it will never be deployed.
>
> Cullen: would the possible solution space now include dynamic = dns?  
> The only reason to specify a solution in the charter is = to 
> explicitly exclude alternate classes of solution - isn't it?
>
> Chris Stanley - cable labs.  We need to deploy this for = businesses 
> and need to move quickly.  (And REGISTER is the mechanism we = use.)
>
> Adam Roach:  how far are we going to go down this path of = specifying 
> the answer in the charter?  If we allow it for REGISTER for = this WG, 
> what other things are we going to do it for?
>
> Cullen as AD:  He was the one who earlier encouraged them to = be very 
> specific to see if they could get consensus on the approach = to 
> shorten the process, even though he suspected the proposal would = get 
> the reaction that it is currently getting.  However, if the = group 
> cannot get consensus to specify the solution in the charter, = then 
> the only approach is to remove it.  This is clearly the = case.
>
> Hum:  Should we leave the charter exactly as it is?  = Result: 
> Moderate hum
>
> Hum:  Should we leave the charter largely as is,  but = remove the 
> solution (REGISTER) from the charter.  Result: Strong hum.
>
> Discussed a vote on "Is there a critical mass in the IETF to = work on 
> this problem?", but instead decided on the following = wording.
>
> Hum:  Does anyone think that we don't have the critical mass = and the 
> expertise to tackle this.  Result:  no one = objected.  So consensus 
> for this.
>
> Hum: is the IETF the place to work on this?  Answer: yes
>
> Note:  The following happened after the meeting had = officially 
> closed, but is included here because it pointed toward a = possible 
> way forward.
>
> Jon: Discussion of the precedent setting risks of just adopting = an 
> existing solution.  One way forward may be to think about this = as a 
> telephone number problem rather than a domain problem, which = would 
> make it a much easier problem.  If we can scope it that way = then it 
> will make it a much quicker problem to solve.
>
> Alan Johnston:  All the SIP Forum discussion is in fact = about 
> telephone numbers, so restricting it to telephone numbers is what = we 
> are looking for
>
> Cullen:  Recognize that we do need to find ways to work = faster.  "If 
> you send me a charter by midnight tonight, I will have it on = the 
> agenda for the next IESG meeting"
>
> Meeting officially closed.
>
> Since we had time, we had an open discussion of how to make = progress.
>
> Discussion of what would be realistic dates for this?  = The 
> discussion indicated that March and June might be more = believable 
> dates.
>
> Cullen:  Recognize that we do need to find ways to work = faster.  "If 
> you send me a charter by midnight tonight, I will have it on = the 
> agenda for the next IESG meeting"
>
> Robert Sparks:  Recipe for success in SDOs cooperating is = having a 
> significant overlap of common participants working on the = problem.  
> He is concerned that the overlap is not enough.
>
> Spencer:  Last SIP Forum meeting had 12 people and 7 of them = were 
> also in the IETF.  Is that enough?
>
> Jon: Discussion of the precedent setting risks of just adopting = an 
> existing solution.  One way forward may be to think about this = as a 
> telephone number problem rather than a domain problem, then it is = a 
> much easier problem.  If we can scope it that way then it will = make 
> it a much easier problem to solve.
>
> Alan Johnston:  All the SIP Forum discussion is in fact = about 
> telephone numbers, so restricting it to telephone numbers would = be 
> acceptable.
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.= org/mailman/listinfo/dispatch

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

------_=_NextPart_001_01CA63E7.D50A749D-- From jiri@iptel.org Mon Nov 16 11:31:06 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD17128C1E4 for ; Mon, 16 Nov 2009 11:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfZAO1VLOzrv for ; Mon, 16 Nov 2009 11:31:05 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id ADE9E28C205 for ; Mon, 16 Nov 2009 11:31:05 -0800 (PST) Received: from jirimac-2.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 741713707DD; Mon, 16 Nov 2009 20:31:03 +0100 (CET) Message-ID: <4B01A877.4010306@iptel.org> Date: Mon, 16 Nov 2009 20:31:03 +0100 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 19:31:06 -0000 I think it is worth mentioning and doublechecking a problem we touched in this conversation, which is SIP servers modifying SDP to facilitate NAT traversal. I think Jon P. has said this was unacceptable use-case not good enough as motivation for work related to it, because it exposes such calls to MiTM attacks. Is that right, Jon? -jiri Mary Barnes wrote: > > Hi all, > > I have uploaded Jim McEachern's notes from the Identity Adhoc yesterday: > http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/Identity-AdHoc-Notes-jmce.doc > > Regards, > Mary. > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jon.peterson@neustar.biz Mon Nov 16 12:45:35 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3043A6ADF for ; Mon, 16 Nov 2009 12:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6302rAjVQHZZ for ; Mon, 16 Nov 2009 12:45:34 -0800 (PST) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 47EE93A690E for ; Mon, 16 Nov 2009 12:45:34 -0800 (PST) Received: from ([192.168.128.225]) by stihiron1.va.neustar.com with ESMTP id G6K7MJ1.2440599; Mon, 16 Nov 2009 15:45:28 -0500 Message-ID: <4B01B9E8.7050507@neustar.biz> Date: Mon, 16 Nov 2009 12:45:28 -0800 From: Jon Peterson User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Jiri Kuthan References: <4B01A877.4010306@iptel.org> In-Reply-To: <4B01A877.4010306@iptel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 20:45:35 -0000 I was not arguing against NAT traversal, actually. From the start of the SIP identity work, we considered support for NAT traversal as a requirement. Of course, the authors of RFC4474 assumed that something roughly like ICE would take over this role, and obviously the deployment situation is bit more complicated (we similarly hoped that GRUU would make it unnecessary for intermediaries to modify Contact headers, and so on). Regardless, I still believe we need to have a reasonable story for how an identity mechanism will accommodate NAT traversal. To rehash arguments that have circulated in this discussion many times, one must distinguish the NAT traversal case from the "media steering" requirement that has motivated much of the re-examination of identity. RFC4474 signatures are applied not by the user agent (at least not in the typical case), but rather by a server operated by the user agent's administrative domain. The administrative domain can more or less modify signaling arbitrarily before adding an Identity header per RFC4474. Thus, some sort of intermediary that modifies SIP signaling for the sake of NAT traversal can work with RFC4474, provided that the intermediary acts before the Identity header is added. While it can therefore be argued that RFC4474 does not rule out intermediary-based NAT traversal entirely, it does protect against any intermediary altering SDP once a request has left the originating administrative domain with an Identity header. The "media steering" use cases that challenge this design are predicated on an intermediary with no necessary relationship to the originating or terminating administrative domain unilaterally modifying SDP in transit, usually in order to force layer 3 routing of media to pass through one or more anchor points in a network - perhaps for the sake of drawing the traffic across a managed circuit with carefully-managed quality, or to facilitate lawful intercept, or what have you. It is that requirement which I have consistently argued is equivalent to exposing this mechanism to a man-in-the-middle attack. If we removed enough protections in the design of RFC4474 to enable media steering by "good" intermediaries, we are effectively also enabling any malicious entities to change those aspects of SIP requests as well. I do not find the requirement for NAT traversal unacceptable, but I do consider the requirement for media steering highly dubious at best. Jon Peterson NeuStar, Inc Jiri Kuthan wrote: > I think it is worth mentioning and doublechecking a problem we touched > in this conversation, which is SIP servers modifying SDP to facilitate > NAT traversal. I think Jon P. has said this was unacceptable use-case not > good enough as motivation for work related to it, because it exposes > such calls to MiTM attacks. Is that right, Jon? > > -jiri > > Mary Barnes wrote: >> >> Hi all, >> >> I have uploaded Jim McEachern's notes from the Identity Adhoc yesterday: >> http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/Identity-AdHoc-Notes-jmce.doc >> >> >> Regards, >> Mary. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From hsinnrei@adobe.com Mon Nov 16 13:20:56 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54A573A6B27 for ; Mon, 16 Nov 2009 13:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLEIQrp8LWHb for ; Mon, 16 Nov 2009 13:20:49 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by core3.amsl.com (Postfix) with ESMTP id 9246128C1C8 for ; Mon, 16 Nov 2009 13:20:48 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKSwHCLCL+3Bqhm8z2PIVdlJH4ZoCKjRAp@postini.com; Mon, 16 Nov 2009 13:20:48 PST Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id nAGLDPHc002985; Mon, 16 Nov 2009 13:13:26 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id nAGLKX7u007823; Mon, 16 Nov 2009 13:20:41 -0800 (PST) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Mon, 16 Nov 2009 13:20:39 -0800 From: Henry Sinnreich To: Jon Peterson , Jiri Kuthan Date: Mon, 16 Nov 2009 13:20:37 -0800 Thread-Topic: [dispatch] Identity Adhoc - Nov 9th: Notes available Thread-Index: Acpm/g+MzQByePakThCpRPPOqKd/vwABJRMZ Message-ID: In-Reply-To: <4B01B9E8.7050507@neustar.biz> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7271E45726Dhsinnreiadobecom_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 21:20:56 -0000 --_000_C7271E45726Dhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >From the start of the SIP identity work, we considered support for NAT tra= versal as a requirement. In hindsight, this assumption does not include the case when NAT traversal = for all application layer protocols is taken care of by HIP, in which case SIP deve= lopers do not have to worry about it: "Basic HIP Extensions for Traversal of Network Address Translators" http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-09 HIP developers do the NAT traversal work and the problem discussed below do= not arise. HIP uses ICE as well. Is there a way to convince the SIP standards community of the benefits of H= IP? Notable exception: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-hip-bone-03.tx= t Thanks, Henry On 11/16/09 2:45 PM, "Jon Peterson" wrote: I was not arguing against NAT traversal, actually. From the start of the SIP identity work, we considered support for NAT traversal as a requirement. Of course, the authors of RFC4474 assumed that something roughly like ICE would take over this role, and obviously the deployment situation is bit more complicated (we similarly hoped that GRUU would make it unnecessary for intermediaries to modify Contact headers, and so on). Regardless, I still believe we need to have a reasonable story for how an identity mechanism will accommodate NAT traversal. To rehash arguments that have circulated in this discussion many times, one must distinguish the NAT traversal case from the "media steering" requirement that has motivated much of the re-examination of identity. RFC4474 signatures are applied not by the user agent (at least not in the typical case), but rather by a server operated by the user agent's administrative domain. The administrative domain can more or less modify signaling arbitrarily before adding an Identity header per RFC4474. Thus, some sort of intermediary that modifies SIP signaling for the sake of NAT traversal can work with RFC4474, provided that the intermediary acts before the Identity header is added. While it can therefore be argued that RFC4474 does not rule out intermediary-based NAT traversal entirely, it does protect against any intermediary altering SDP once a request has left the originating administrative domain with an Identity header. The "media steering" use cases that challenge this design are predicated on an intermediary with no necessary relationship to the originating or terminating administrative domain unilaterally modifying SDP in transit, usually in order to force layer 3 routing of media to pass through one or more anchor points in a network - perhaps for the sake of drawing the traffic across a managed circuit with carefully-managed quality, or to facilitate lawful intercept, or what have you. It is that requirement which I have consistently argued is equivalent to exposing this mechanism to a man-in-the-middle attack. If we removed enough protections in the design of RFC4474 to enable media steering by "good" intermediaries, we are effectively also enabling any malicious entities to change those aspects of SIP requests as well. I do not find the requirement for NAT traversal unacceptable, but I do consider the requirement for media steering highly dubious at best. Jon Peterson NeuStar, Inc Jiri Kuthan wrote: > I think it is worth mentioning and doublechecking a problem we touched > in this conversation, which is SIP servers modifying SDP to facilitate > NAT traversal. I think Jon P. has said this was unacceptable use-case not > good enough as motivation for work related to it, because it exposes > such calls to MiTM attacks. Is that right, Jon? > > -jiri > > Mary Barnes wrote: >> >> Hi all, >> >> I have uploaded Jim McEachern's notes from the Identity Adhoc yesterday: >> http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/Identity-AdHoc-= Notes-jmce.doc >> >> >> Regards, >> Mary. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_C7271E45726Dhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Identity Adhoc - Nov 9th: Notes available >From the start of the SIP identity work, we considered support fo= r NAT traversal as a
requirement.

In hindsight, this assumption does not include the case when NAT traversal = for all
application layer protocols is taken care of by HIP, in which case SIP deve= lopers do
not have to worry about it:
“Basic HIP Ext= ensions for Traversal of Network Address Translators”
http://tools.ietf.org/html/draft-i= etf-hip-nat-traversal-09

HIP developers do the NAT traversal work and the problem discussed below do= not arise.
HIP uses ICE as well.

Is there a way to convince the SIP standards community of the benefits of H= IP?
Notable exception:
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-= hip-bone-03.txt

Thanks, Henry


On 11/16/09 2:45 PM, "Jon Peterson" <jon.peterson@neustar.biz> wrote:



I was not arguing against NAT traversal, actually. From the start of the SIP identity work, we considered support for NAT traversal as a
requirement. Of course, the authors of RFC4474 assumed that something
roughly like ICE would take over this role, and obviously the deployment situation is bit more complicated (we similarly hoped that GRUU would
make it unnecessary for intermediaries to modify Contact headers, and so on). Regardless, I still believe we need to have a reasonable story for
how an identity mechanism will accommodate NAT traversal.

To rehash arguments that have circulated in this discussion many times,
one must distinguish the NAT traversal case from the "media steering&q= uot;
requirement that has motivated much of the re-examination of identity.
RFC4474 signatures are applied not by the user agent (at least not in
the typical case), but rather by a server operated by the user agent's
administrative domain. The administrative domain can more or less modify signaling arbitrarily before adding an Identity header per RFC4474.
Thus, some sort of intermediary that modifies SIP signaling for the sake of NAT traversal can work with RFC4474, provided that the intermediary
acts before the Identity header is added.

While it can therefore be argued that RFC4474 does not rule out
intermediary-based NAT traversal entirely, it does protect against any
intermediary altering SDP once a request has left the originating
administrative domain with an Identity header. The "media steering&quo= t; use
cases that challenge this design are predicated on an intermediary with
no necessary relationship to the originating or terminating
administrative domain unilaterally modifying SDP in transit, usually in
order to force layer 3 routing of media to pass through one or more
anchor points in a network - perhaps for the sake of drawing the traffic across a managed circuit with carefully-managed quality, or to
facilitate lawful intercept, or what have you. It is that requirement
which I have consistently argued is equivalent to exposing this
mechanism to a man-in-the-middle attack. If we removed enough
protections in the design of RFC4474 to enable media steering by "good= "
intermediaries, we are effectively also enabling any malicious entities
to change those aspects of SIP requests as well.

I do not find the requirement for NAT traversal unacceptable, but I do
consider the requirement for media steering highly dubious at best.

Jon Peterson
NeuStar, Inc

Jiri Kuthan wrote:
> I think it is worth mentioning and doublechecking a problem we touched=
> in this conversation, which is SIP servers modifying SDP to facilitate=
> NAT traversal. I think Jon P. has said this was unacceptable use-case = not
> good enough as motivation for work related to it, because it exposes > such calls to MiTM attacks. Is that right, Jon?
>
> -jiri
>
> Mary Barnes wrote:
>>
>> Hi all,
>>
>> I have uploaded Jim McEachern's notes from the Identity Adhoc yest= erday:
>> http://www.softarmor.com/dispatch/IETF76/M= eeting%20notes/Identity-AdHoc-Notes-jmce.doc
>>
>>
>> Regards,
>> Mary.
>>
>>
>> ------------------------------------------------------------------= ------
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https:/= /www.ietf.org/mailman/listinfo/dispatch

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

--_000_C7271E45726Dhsinnreiadobecom_-- From audet.francois@gmail.com Mon Nov 16 14:06:18 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C496A3A6B32 for ; Mon, 16 Nov 2009 14:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REjtPYvnUqNZ for ; Mon, 16 Nov 2009 14:06:17 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 337123A6B2B for ; Mon, 16 Nov 2009 14:06:17 -0800 (PST) Received: by bwz23 with SMTP id 23so6294526bwz.29 for ; Mon, 16 Nov 2009 14:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=T2U9izL2UYHCo5Ofo3rAVt6hua9HTnvHGLtFaehumRk=; b=q1f9sb86/hxjwChhoz2dbqSZos79mLB8LnlcZeX9I1wI+L9vPkAeRo+r+gVhJG0aHt PMaz5DcCpZ/vj896kb8BozAS6mdsBKMauNmVzLKnY8FO7ZSX/cazKmowgUDO2F/8Hpe8 A/gBhbdCGgzeyNIRxqBpBmCEL67ibPqSGj7XY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=IMkVBg+gr1xN6n1i87BZREBLlwoUVLBdAy/PAidO9KnJxMS+Dt9+oHPfsCm3q4YikP C+qhyi8LD5MUBJ75NUKXxT9b5VW0Uu6nDS1nFUDgRceq0+B8AjmQj18aA4tmjQJFc2hZ tl/vXWtHQOP3K/sWarpqqmp27KgPXR+frla18= Received: by 10.204.32.16 with SMTP id a16mr4338115bkd.190.1258409169103; Mon, 16 Nov 2009 14:06:09 -0800 (PST) Received: from ?192.168.12.175? (89.26.235.80.sta.estpak.ee [80.235.26.89]) by mx.google.com with ESMTPS id 15sm1965952bwz.8.2009.11.16.14.06.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 14:06:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Francois Audet In-Reply-To: <4B01B9E8.7050507@neustar.biz> Date: Tue, 17 Nov 2009 00:06:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9D78C8C9-96FB-49D7-8B9E-ED6FAA6F8CA3@gmail.com> References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> To: Jon Peterson X-Mailer: Apple Mail (2.1077) Cc: dispatch@ietf.org Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 22:06:18 -0000 So, in summary: SDP (and other) modification should only be done on a = UA's behalf by its administrative domain, otherwise, it's unsafe. Seems reasonable to me. We seem to recycle the same arguments over and over again.... On Nov 16, 2009, at 22:45 , Jon Peterson wrote: >=20 > I was not arguing against NAT traversal, actually. =46rom the start of = the SIP identity work, we considered support for NAT traversal as a = requirement. Of course, the authors of RFC4474 assumed that something = roughly like ICE would take over this role, and obviously the deployment = situation is bit more complicated (we similarly hoped that GRUU would = make it unnecessary for intermediaries to modify Contact headers, and so = on). Regardless, I still believe we need to have a reasonable story for = how an identity mechanism will accommodate NAT traversal. >=20 > To rehash arguments that have circulated in this discussion many = times, one must distinguish the NAT traversal case from the "media = steering" requirement that has motivated much of the re-examination of = identity. RFC4474 signatures are applied not by the user agent (at least = not in the typical case), but rather by a server operated by the user = agent's administrative domain. The administrative domain can more or = less modify signaling arbitrarily before adding an Identity header per = RFC4474. Thus, some sort of intermediary that modifies SIP signaling for = the sake of NAT traversal can work with RFC4474, provided that the = intermediary acts before the Identity header is added. >=20 > While it can therefore be argued that RFC4474 does not rule out = intermediary-based NAT traversal entirely, it does protect against any = intermediary altering SDP once a request has left the originating = administrative domain with an Identity header. The "media steering" use = cases that challenge this design are predicated on an intermediary with = no necessary relationship to the originating or terminating = administrative domain unilaterally modifying SDP in transit, usually in = order to force layer 3 routing of media to pass through one or more = anchor points in a network - perhaps for the sake of drawing the traffic = across a managed circuit with carefully-managed quality, or to = facilitate lawful intercept, or what have you. It is that requirement = which I have consistently argued is equivalent to exposing this = mechanism to a man-in-the-middle attack. If we removed enough = protections in the design of RFC4474 to enable media steering by "good" = intermediaries, we are effectively also enabling any malicious entities = to change those aspects of SIP requests as well. >=20 > I do not find the requirement for NAT traversal unacceptable, but I do = consider the requirement for media steering highly dubious at best. >=20 > Jon Peterson > NeuStar, Inc >=20 > Jiri Kuthan wrote: >> I think it is worth mentioning and doublechecking a problem we = touched >> in this conversation, which is SIP servers modifying SDP to = facilitate >> NAT traversal. I think Jon P. has said this was unacceptable use-case = not >> good enough as motivation for work related to it, because it exposes >> such calls to MiTM attacks. Is that right, Jon? >>=20 >> -jiri >>=20 >> Mary Barnes wrote: >>>=20 >>> Hi all, >>>=20 >>> I have uploaded Jim McEachern's notes from the Identity Adhoc = yesterday: >>> = http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/Identity-AdHoc-No= tes-jmce.doc=20 >>>=20 >>> Regards, >>> Mary. >>>=20 >>>=20 >>> = ------------------------------------------------------------------------ >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jiri@iptel.org Tue Nov 17 00:27:26 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725DD3A69FD for ; Tue, 17 Nov 2009 00:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_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 71DhkD58+bS9 for ; Tue, 17 Nov 2009 00:27:25 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id E0E6F3A67F2 for ; Tue, 17 Nov 2009 00:27:24 -0800 (PST) Received: from jirimac-2.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id DC72A37080E; Tue, 17 Nov 2009 09:27:22 +0100 (CET) Message-ID: <4B025E6A.60900@iptel.org> Date: Tue, 17 Nov 2009 09:27:22 +0100 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Jon Peterson References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> In-Reply-To: <4B01B9E8.7050507@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 08:27:26 -0000 Jon Peterson wrote: > > I was not arguing against NAT traversal, actually. From the start of the > SIP identity work, we considered support for NAT traversal as a > requirement. Of course, the authors of RFC4474 assumed that something > roughly like ICE would take over this role, and obviously the deployment > situation is bit more complicated (we similarly hoped that GRUU would > make it unnecessary for intermediaries to modify Contact headers, and so > on). Regardless, I still believe we need to have a reasonable story for > how an identity mechanism will accommodate NAT traversal. > > To rehash arguments that have circulated in this discussion many times, > one must distinguish the NAT traversal case from the "media steering" > requirement that has motivated much of the re-examination of identity. > RFC4474 signatures are applied not by the user agent (at least not in > the typical case), but rather by a server operated by the user agent's > administrative domain. The administrative domain can more or less modify > signaling arbitrarily before adding an Identity header per RFC4474. > Thus, some sort of intermediary that modifies SIP signaling for the sake > of NAT traversal can work with RFC4474, provided that the intermediary > acts before the Identity header is added. > > While it can therefore be argued that RFC4474 does not rule out > intermediary-based NAT traversal entirely, it does protect against any > intermediary altering SDP once a request has left the originating > administrative domain with an Identity header. > The "media steering" use > cases that challenge this design are predicated on an intermediary with > no necessary relationship to the originating or terminating > administrative domain unilaterally modifying SDP in transit, usually in > order to force layer 3 routing of media to pass through one or more > anchor points in a network - perhaps for the sake of drawing the traffic > across a managed circuit with carefully-managed quality, or to > facilitate lawful intercept, or what have you. It is that requirement > which I have consistently argued is equivalent to exposing this > mechanism to a man-in-the-middle attack. how is that different from a MiTM attacking SDP on the path from UA to a 4474-enable proxy? > If we removed enough > protections in the design of RFC4474 to enable media steering by "good" > intermediaries, we are effectively also enabling any malicious entities > to change those aspects of SIP requests as well. I'm wondering if RFC4474 can prevent MiTM as it is not guaranteed to provide end-to-end protection in the typical case. > > I do not find the requirement for NAT traversal unacceptable, but I do > consider the requirement for media steering highly dubious at best. Some while ago I would have thought that in this typical case there are two administrative zones under respective control with a pipe in between. Then it shall be manageable to put a SDP-manipulating closer to UA than 4474 processing. In the meantime I think it became hard to find a SIP path which in between two 4474 entities has nothing that rewrites SDP. -jiri > > Jon Peterson > NeuStar, Inc > > Jiri Kuthan wrote: >> I think it is worth mentioning and doublechecking a problem we touched >> in this conversation, which is SIP servers modifying SDP to facilitate >> NAT traversal. I think Jon P. has said this was unacceptable use-case not >> good enough as motivation for work related to it, because it exposes >> such calls to MiTM attacks. Is that right, Jon? >> >> -jiri >> >> Mary Barnes wrote: >>> >>> Hi all, >>> >>> I have uploaded Jim McEachern's notes from the Identity Adhoc yesterday: >>> http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/Identity-AdHoc-Notes-jmce.doc >>> >>> >>> Regards, >>> Mary. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch > From jiri@iptel.org Tue Nov 17 00:27:38 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DBE93A67F2 for ; Tue, 17 Nov 2009 00:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 EnrY0ExQ4Z4N for ; Tue, 17 Nov 2009 00:27:37 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id ABA9028C0EC for ; Tue, 17 Nov 2009 00:27:36 -0800 (PST) Received: from jirimac-2.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 0F27837080E; Tue, 17 Nov 2009 09:27:35 +0100 (CET) Message-ID: <4B025E76.2060301@iptel.org> Date: Tue, 17 Nov 2009 09:27:34 +0100 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Francois Audet References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> <9D78C8C9-96FB-49D7-8B9E-ED6FAA6F8CA3@gmail.com> In-Reply-To: <9D78C8C9-96FB-49D7-8B9E-ED6FAA6F8CA3@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 08:27:38 -0000 Francois Audet wrote: > So, in summary: SDP (and other) modification should only be done on a UA's behalf by its administrative domain, otherwise, it's unsafe. Hi Francois, I'm not quite yet sure what administrative domain means? The picture I'm having in my mind is using say iptel.org service (located in Central Europe in a facility administered by iptel.org's administrator) from an IETF meeting (administered by the IETF team) to my family (located within what a German ISP administers). -jiri > > Seems reasonable to me. > > We seem to recycle the same arguments over and over again.... > > On Nov 16, 2009, at 22:45 , Jon Peterson wrote: > >> I was not arguing against NAT traversal, actually. From the start of the SIP identity work, we considered support for NAT traversal as a requirement. Of course, the authors of RFC4474 assumed that something roughly like ICE would take over this role, and obviously the deployment situation is bit more complicated (we similarly hoped that GRUU would make it unnecessary for intermediaries to modify Contact headers, and so on). Regardless, I still believe we need to have a reasonable story for how an identity mechanism will accommodate NAT traversal. >> >> To rehash arguments that have circulated in this discussion many times, one must distinguish the NAT traversal case from the "media steering" requirement that has motivated much of the re-examination of identity. RFC4474 signatures are applied not by the user agent (at least not in the typical case), but rather by a server operated by the user agent's administrative domain. The administrative domain can more or less modify signaling arbitrarily before adding an Identity header per RFC4474. Thus, some sort of intermediary that modifies SIP signaling for the sake of NAT traversal can work with RFC4474, provided that the intermediary acts before the Identity header is added. >> >> While it can therefore be argued that RFC4474 does not rule out intermediary-based NAT traversal entirely, it does protect against any intermediary altering SDP once a request has left the originating administrative domain with an Identity header. The "media steering" use cases that challenge this design are predicated on an intermediary with no necessary relationship to the originating or terminating administrative domain unilaterally modifying SDP in transit, usually in order to force layer 3 routing of media to pass through one or more anchor points in a network - perhaps for the sake of drawing the traffic across a managed circuit with carefully-managed quality, or to facilitate lawful intercept, or what have you. It is that requirement which I have consistently argued is equivalent to exposing this mechanism to a man-in-the-middle attack. If we removed enough protections in the design of RFC4474 to enable media steering by "good" intermediaries, we are effectively als o enabling any malicious entities to change those aspects of SIP requests as well. >> >> I do not find the requirement for NAT traversal unacceptable, but I do consider the requirement for media steering highly dubious at best. >> >> Jon Peterson >> NeuStar, Inc >> >> Jiri Kuthan wrote: >>> I think it is worth mentioning and doublechecking a problem we touched >>> in this conversation, which is SIP servers modifying SDP to facilitate >>> NAT traversal. I think Jon P. has said this was unacceptable use-case not >>> good enough as motivation for work related to it, because it exposes >>> such calls to MiTM attacks. Is that right, Jon? >>> >>> -jiri >>> >>> Mary Barnes wrote: >>>> Hi all, >>>> >>>> I have uploaded Jim McEachern's notes from the Identity Adhoc yesterday: >>>> http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/Identity-AdHoc-Notes-jmce.doc >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From jon.peterson@neustar.biz Tue Nov 17 04:20:36 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642953A6A88 for ; Tue, 17 Nov 2009 04:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHHgy2BFewKP for ; Tue, 17 Nov 2009 04:20:35 -0800 (PST) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id F2C243A6A75 for ; Tue, 17 Nov 2009 04:20:34 -0800 (PST) Received: from ([192.168.128.225]) by stihiron1.va.neustar.com with ESMTP id G6K7MJ1.2463587; Tue, 17 Nov 2009 07:20:26 -0500 Message-ID: <4B02950A.9060902@neustar.biz> Date: Tue, 17 Nov 2009 04:20:26 -0800 From: Jon Peterson User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Jiri Kuthan References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> <4B025E6A.60900@iptel.org> In-Reply-To: <4B025E6A.60900@iptel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 12:20:36 -0000 >> The "media steering" use cases that challenge this design are >> predicated on an intermediary with no necessary relationship to the >> originating or terminating administrative domain unilaterally >> modifying SDP in transit, usually in order to force layer 3 routing >> of media to pass through one or more anchor points in a network - >> perhaps for the sake of drawing the traffic across a managed circuit >> with carefully-managed quality, or to facilitate lawful intercept, or >> what have you. It is that requirement which I have consistently >> argued is equivalent to exposing this mechanism to a >> man-in-the-middle attack. > how is that different from a MiTM attacking SDP on the path from UA > to a 4474-enable proxy? I'm not sure how to answer your question except to say that it is a fundamental difference in the protection scope of the mechanism. The path between the user agent and the RFC4474-enabled proxy must be secured in some fashion, it's true, and there are a number of ways that security might be provided that can either allow for the presence of other intermediaries in the administrative domain or not, depending on the SIP deployment of the domain (RFC4474 does talk about this a bit). If those protections aren't in place, then of course any adversary can alter the signaling arbitrarily with fear of detection. Once an Identity header is in place, however, any subsequent modifications to the signaling that could lead to impersonation (in so far as the threat of impersonation is defined in the draft) are supposed to show up as violations. That's the protection that the Identity mechanism affords. So the difference is that in one case, there's supposed to be security, and in the other case there isn't. >> If we removed enough >> protections in the design of RFC4474 to enable media steering by >> "good" intermediaries, we are effectively also enabling any malicious >> entities to change those aspects of SIP requests as well. > I'm wondering if RFC4474 can prevent MiTM as it is not guaranteed to > provide > end-to-end protection in the typical case. No mechanism can "prevent" a man-in-the-middle, it can merely detect it. RFC4474 provides its protections within its defined scope, which is from an authentication service in the administrative domain to the terminating user agent. If the path between the originating user agent and the authentication service is insecure and vulnerable, as discussed above, then yes, RFC4474 doesn't provide end-to-end protection. >> >> I do not find the requirement for NAT traversal unacceptable, but I >> do consider the requirement for media steering highly dubious at best. > Some while ago I would have thought that in this typical case there > are two administrative zones under respective control with a pipe in > between. Then it shall be manageable to put a SDP-manipulating closer > to UA than 4474 processing. In the meantime I think it became hard to > find a SIP path which in between two 4474 entities has nothing that > rewrites SDP. You are not the first one to make this observation, but I don't think this information is very useful in drafting the sorts of requirements in Mr. Elwell's document. The stated requirement for "media steering" assumes something much more specific than simply wanting to rewrite SDP. An intermediary that wants to rewrite SDP may have one of several relationships with the originating and terminating user agents or administrative domains. The "media steering" use cases invariably assume an entity acting unilaterally, without necessarily the knowledge or consent of either side of the transaction - it acts by virtue of being in the path of signaling, even if only as an ALG. If we design a security mechanism that allows an entity to act with that sort of impunity, it may facilitate some few beneficial services but it will also facilitate a variety of attacks. I believe we can do better - we can find ways to allow intermediaries to perform the services they'd like to perform without acting unilaterally. Certainly at the time RFC4474 was under development, we believed that mechanisms like session-policy would eventually provide a way for intermediaries to force user agents to conform with intermediary policy, including session dependent policy cases for SDP. If we're going to dedicate design energy to solving problems in this neighborhood, one could argue that solving for these building blocks first (allowing intermediaries to modify signaling in a collaborative manner rather than unilaterally) will make the path to an identity solution much, much easier. From a requirements perspective, this is much closer to what I'd like to see expressed than something like "media steering," which basically equates to reducing the protection space. Jon Peterson NeuStar, Inc. > -jiri > > From richard@shockey.us Tue Nov 17 07:53:53 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE9528C250 for ; Tue, 17 Nov 2009 07:53:53 -0800 (PST) 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 MD65h3KbJn+Q for ; Tue, 17 Nov 2009 07:53:53 -0800 (PST) Received: from outbound-mail-141.bluehost.com (outbound-mail-141.bluehost.com [67.222.38.31]) by core3.amsl.com (Postfix) with SMTP id ECDF528C17D for ; Tue, 17 Nov 2009 07:53:52 -0800 (PST) Received: (qmail 12570 invoked by uid 0); 17 Nov 2009 15:47:12 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 17 Nov 2009 15:47:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=baMS2xN/BxU1pZJSxjDYHBAuDlfjX8SPUBzUkVFergqhbDzw99jliK2ZITpGMyqbNmyC2qoTTWFreFomo5uz+FmyJKTIheDKu62zoBbZVUY/cpKK8sBaepwgvKgqsH2Y; Received: from [8.22.81.14] (helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NAQGu-0002wQ-9Y; Tue, 17 Nov 2009 08:47:12 -0700 From: "Richard Shockey" To: , Date: Tue, 17 Nov 2009 10:47:11 -0500 Message-ID: <013401ca679d$3a926700$afb73500$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpnXhDNP6UoFkakQWCME6TnXYiPQAAPjF+A Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 8.22.81.14 authed with richard+shockey.us} Subject: [dispatch] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:53:53 -0000 FYI to the general SIP community. There have been substantial field reports of difficulties with T.30 FAX is SIP networks and the SIP Forum was asked to help facilitate discussions among a group of technical experts in fax order to provider recommendations to either the IETF and or ITU SG16 on possible approaches to the problem. Fax is a essential realtime communications service that is not going away and making fax work properly needs to be addressed. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, November 17, 2009 3:15 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Forum - Fax Over IP Task Group Problem Statement Author(s) : X. Chen, et al. Filename : draft-jones-sip-forum-fax-problem-statement-00.txt Pages : 13 Date : 2009-11-17 This memo is published for informational purposes to document the issues identified by the SIP Forum with respect to the transmission of facsimile signaling messages and fax page data over Internet Protocol (IP) networks. Further, it is the intent of this memo to alert the IETF to the formation of a Fax Over IP Task Group within the SIP Forum chartered to investigate and address identified issues as they relate to the deployment of fax services in Session Initiation Protocol (SIP) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-sip-forum-fax-problem-statem ent-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. From jiri@iptel.org Tue Nov 17 09:57:41 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5953A6405 for ; Tue, 17 Nov 2009 09:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 JViXW2mMhytk for ; Tue, 17 Nov 2009 09:57:40 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id B07CD3A672F for ; Tue, 17 Nov 2009 09:57:39 -0800 (PST) Received: from jirimac-2.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 5D36C370754; Tue, 17 Nov 2009 18:57:36 +0100 (CET) Message-ID: <4B02E410.10009@iptel.org> Date: Tue, 17 Nov 2009 18:57:36 +0100 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Jon Peterson References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> <4B025E6A.60900@iptel.org> <4B02950A.9060902@neustar.biz> In-Reply-To: <4B02950A.9060902@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 17:57:41 -0000 Jon Peterson wrote: > >>> The "media steering" use cases that challenge this design are >>> predicated on an intermediary with no necessary relationship to the >>> originating or terminating administrative domain unilaterally >>> modifying SDP in transit, usually in order to force layer 3 routing >>> of media to pass through one or more anchor points in a network - >>> perhaps for the sake of drawing the traffic across a managed circuit >>> with carefully-managed quality, or to facilitate lawful intercept, or >>> what have you. It is that requirement which I have consistently >>> argued is equivalent to exposing this mechanism to a >>> man-in-the-middle attack. >> how is that different from a MiTM attacking SDP on the path from UA >> to a 4474-enable proxy? What is all if it then good for if we don't have guarantee for e2e integrity protectino and have quite likely (Though not lovely) chance that ALGs will break even identity? To me having a partial protection of SDP along the SIP path sounds remarkably similar to the concept of partial pregnancy. > I'm not sure how to answer your question except to say that it is a > fundamental difference in the protection scope of the mechanism. The > path between the user agent and the RFC4474-enabled proxy must be > secured in some fashion, it's true, and there are a number of ways that > security might be provided that can either allow for the presence of > other intermediaries in the administrative domain or not, depending on > the SIP deployment of the domain (RFC4474 does talk about this a bit). > If those protections aren't in place, then of course any adversary can > alter the signaling arbitrarily with fear of detection. Even if there are other technologies (let's assume for a while that TLS can be relied upon along the whole path) that can cover the whole path, what's integrity in 4474 then good for? > Once an Identity > header is in place, however, any subsequent modifications to the > signaling that could lead to impersonation (in so far as the threat of > impersonation is defined in the draft) are supposed to show up as > violations. That's the protection that the Identity mechanism affords. I understand the benefit. The point is that Identity appears meaningful even without that (to the point I know who is calling) and the cost is that it breaks whenever there is an ALG in the path, which happens quite frequently. > > So the difference is that in one case, there's supposed to be security, I'm worried that covering SDP along a piece of the path is not eliminating MiTM attacks and therefore doesn't provide better security. > and in the other case there isn't. >>> If we removed enough >>> protections in the design of RFC4474 to enable media steering by >>> "good" intermediaries, we are effectively also enabling any malicious >>> entities to change those aspects of SIP requests as well. >> I'm wondering if RFC4474 can prevent MiTM as it is not guaranteed to >> provide >> end-to-end protection in the typical case. > No mechanism can "prevent" a man-in-the-middle, it can merely detect it. > RFC4474 provides its protections within its defined scope, which is > from an authentication service in the administrative domain to the > terminating user agent. If the path between the originating user agent > and the authentication service is insecure and vulnerable, as discussed > above, then yes, RFC4474 doesn't provide end-to-end protection. That's my problem -- we only have partial integrity protection and for this limited benefit we don't get over ALGs. >>> >>> I do not find the requirement for NAT traversal unacceptable, but I >>> do consider the requirement for media steering highly dubious at best. >> Some while ago I would have thought that in this typical case there >> are two administrative zones under respective control with a pipe in >> between. Then it shall be manageable to put a SDP-manipulating closer >> to UA than 4474 processing. In the meantime I think it became hard to >> find a SIP path which in between two 4474 entities has nothing that >> rewrites SDP. > You are not the first one to make this observation, but I don't think > this information is very useful in drafting the sorts of requirements in > Mr. Elwell's document. The stated requirement for "media steering" > assumes something much more specific than simply wanting to rewrite SDP. > An intermediary that wants to rewrite SDP may have one of several > relationships with the originating and terminating user agents or > administrative domains. The "media steering" use cases invariably assume > an entity acting unilaterally, without necessarily the knowledge or > consent of either side of the transaction - it acts by virtue of being > in the path of signaling, even if only as an ALG. If we design a > security mechanism that allows an entity to act with that sort of > impunity, it may facilitate some few beneficial services but it will > also facilitate a variety of attacks. I'm afraid the attacks are there anyhow. Use of STUN, for example, exposes the whole architecture to MiTM attack even if there is SDP protection end-to-end in combination with hop-by-hop TLS encryption. TLS implementations are for some reason quite rare. In other words if there is somone in position to rewrite packets as sent from a UA, SDP protection between two proxy servers will not stop him. > I believe we can do better - we > can find ways to allow intermediaries to perform the services they'd > like to perform without acting unilaterally. Certainly at the time > RFC4474 was under development, we believed that mechanisms like > session-policy would eventually provide a way for intermediaries to > force user agents to conform with intermediary policy, including session > dependent policy cases for SDP. If we're going to dedicate design energy > to solving problems in this neighborhood, one could argue that solving > for these building blocks first (allowing intermediaries to modify > signaling in a collaborative manner rather than unilaterally) will make > the path to an identity solution much, much easier. From a requirements > perspective, this is much closer to what I'd like to see expressed than > something like "media steering," which basically equates to reducing the > protection space. The problem I see is it reduces protection space but it does not reduce the problem space. With TLS we could be getting protection along the whole path on a hop-by-hop basis so the residual security risk is that a legitimate SIP element on the path between 4474 issuer and verifier changes SDP. Why do you think that any negotiation consensus-producing facility would fly better than adoption of the policy framework? Or do you rather think along the lines of setting the user expectations? (a la a new error code "18x hang up now and upgrade to nat-free IPv6 or media encryption, otherwise you will be in the middle of a call that may be intercepted by parties with legitimitate as well as illegitimate interest to do so" with obligation that all evil parties send this sort of message...?) OR advisory SDP protection which makes recepients alert of a change but doesn't yet mandate the protocol stack to throw broken traffic away? or a BCP that creates a VPN tunnel, producing security and consensus to use some public address for public trAFFIC? I really don't know what your suggestion above means. The point is really as with NAT's IP address rewriting, there is SDP rewriting and assuming in protocol design that these things don't exist will probably do bigger harm (such as unusability of 4474) then accepting it as matter of fact. -jiri > > Jon Peterson > NeuStar, Inc. > >> -jiri >> >> > From dwing@cisco.com Tue Nov 17 12:28:58 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9623E28C12E for ; Tue, 17 Nov 2009 12:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 ru1oq7GqcZDU for ; Tue, 17 Nov 2009 12:28:57 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 81FE73A69E2 for ; Tue, 17 Nov 2009 12:28:57 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAFuWAkurRN+J/2dsb2JhbACKNLR/mCqCN4IEBIFv X-IronPort-AV: E=Sophos;i="4.44,759,1249257600"; d="scan'208";a="50630118" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2009 20:28:56 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAHKStUF007028; Tue, 17 Nov 2009 20:28:55 GMT From: "Dan Wing" To: "'Jon Peterson'" , "'Jiri Kuthan'" References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> Date: Tue, 17 Nov 2009 12:28:56 -0800 Message-ID: <048d01ca67c4$96503410$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4B01B9E8.7050507@neustar.biz> Thread-Index: Acpm/cAmvPHHm0qVT0mkfw8baK/YYwAxpywQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: dispatch@ietf.org Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 20:28:58 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Jon Peterson > Sent: Monday, November 16, 2009 12:45 PM > To: Jiri Kuthan > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available > > > I was not arguing against NAT traversal, actually. From the > start of the > SIP identity work, we considered support for NAT traversal as a > requirement. Of course, the authors of RFC4474 assumed that something > roughly like ICE would take over this role, and obviously the > deployment > situation is bit more complicated (we similarly hoped that GRUU would > make it unnecessary for intermediaries to modify Contact > headers, and so > on). Regardless, I still believe we need to have a reasonable > story for > how an identity mechanism will accommodate NAT traversal. > > To rehash arguments that have circulated in this discussion > many times, > one must distinguish the NAT traversal case from the "media steering" > requirement that has motivated much of the re-examination of > identity. > RFC4474 signatures are applied not by the user agent (at least not in > the typical case), but rather by a server operated by the > user agent's > administrative domain. The administrative domain can more or > less modify > signaling arbitrarily before adding an Identity header per RFC4474. > Thus, some sort of intermediary that modifies SIP signaling > for the sake > of NAT traversal can work with RFC4474, provided that the > intermediary > acts before the Identity header is added. > > While it can therefore be argued that RFC4474 does not rule out > intermediary-based NAT traversal entirely, it does protect > against any > intermediary altering SDP once a request has left the originating > administrative domain with an Identity header. The "media > steering" use > cases that challenge this design are predicated on an > intermediary with > no necessary relationship to the originating or terminating > administrative domain unilaterally modifying SDP in transit, > usually in > order to force layer 3 routing of media to pass through one or more > anchor points in a network - perhaps for the sake of drawing > the traffic > across a managed circuit with carefully-managed quality, or to > facilitate lawful intercept, or what have you. It is that requirement > which I have consistently argued is equivalent to exposing this > mechanism to a man-in-the-middle attack. If we removed enough > protections in the design of RFC4474 to enable media steering > by "good" > intermediaries, we are effectively also enabling any > malicious entities > to change those aspects of SIP requests as well. > > I do not find the requirement for NAT traversal unacceptable, > but I do > consider the requirement for media steering highly dubious at best. "Highly dubious" = nobody really does it? -d > Jon Peterson > NeuStar, Inc > > Jiri Kuthan wrote: > > I think it is worth mentioning and doublechecking a problem > we touched > > in this conversation, which is SIP servers modifying SDP to > facilitate > > NAT traversal. I think Jon P. has said this was > unacceptable use-case not > > good enough as motivation for work related to it, because it exposes > > such calls to MiTM attacks. Is that right, Jon? > > > > -jiri > > > > Mary Barnes wrote: > >> > >> Hi all, > >> > >> I have uploaded Jim McEachern's notes from the Identity > Adhoc yesterday: > >> > http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/Ident > ity-AdHoc-Notes-jmce.doc > >> > >> > >> Regards, > >> Mary. > >> > >> > >> > -------------------------------------------------------------- > ---------- > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From victor.pascual.avila@gmail.com Tue Nov 17 13:09:00 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F5F3A6B07 for ; Tue, 17 Nov 2009 13:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z18gQoNrX418 for ; Tue, 17 Nov 2009 13:09:00 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id ACA0C3A65A5 for ; Tue, 17 Nov 2009 13:08:59 -0800 (PST) Received: by fxm7 with SMTP id 7so464500fxm.29 for ; Tue, 17 Nov 2009 13:08:55 -0800 (PST) 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 :content-transfer-encoding; bh=+357i+Q5prp3okRO9UR4Bvke3b0MRtnVQTSUnykss/Q=; b=VYtbIJmsi6ppkVz/6KudpqePuxaXCo98+bxtxX+OsMkOXxe51Vhzeac43CYbJmo0/w E6DkeQwL1gqUI6hcDEOJX39zCnxn3d1KZHBeRFMW1uniq0TzqVSSuP80xmZ4/4bNkril iMrlqdqKTY5bWfYGX/Lv2ikgfowhPIdVy9QeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LpQFJXu8WdTbgp/44XmFwj2nf615qWspN3iHOxeVS72MetLNqeglNmy9Tx7YyK2qkZ moD9+ZOef7D7niCPGUuC/id+l9SNXlULBKQuVLvqPtmM+3PkzUaKCUshi8e6bUPXq/HI n4DHx4SyOvTrViVzx4hl37DN48ydCzHcNihe8= MIME-Version: 1.0 Received: by 10.103.122.29 with SMTP id z29mr4737374mum.53.1258492134845; Tue, 17 Nov 2009 13:08:54 -0800 (PST) In-Reply-To: <048d01ca67c4$96503410$c2f0200a@cisco.com> References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> <048d01ca67c4$96503410$c2f0200a@cisco.com> Date: Tue, 17 Nov 2009 22:08:54 +0100 Message-ID: <618e24240911171308s316be105k79baaa974ab17963@mail.gmail.com> From: Victor Pascual Avila To: Dan Wing Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 21:09:00 -0000 On Tue, Nov 17, 2009 at 9:28 PM, Dan Wing wrote: >> I do not find the requirement for NAT traversal unacceptable, >> but I do >> consider the requirement for media steering highly dubious at best. > > "Highly dubious" =3D nobody really does it? Network administrators have actually found it easier to rewrite SDPs than to use other existing mechanisms. Cheers, --=20 Victor Pascual =C3=81vila From dean.willis@softarmor.com Tue Nov 17 13:09:01 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42DE23A65A5 for ; Tue, 17 Nov 2009 13:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIy--m1l6sTC for ; Tue, 17 Nov 2009 13:09:00 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6813B3A6B04 for ; Tue, 17 Nov 2009 13:09:00 -0800 (PST) Received: from [192.168.2.104] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAHL8r7f001341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 15:08:54 -0600 Message-ID: <4B0310E1.9070200@softarmor.com> Date: Tue, 17 Nov 2009 15:08:49 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> <048d01ca67c4$96503410$c2f0200a@cisco.com> In-Reply-To: <048d01ca67c4$96503410$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 21:09:01 -0000 Dan Wing wrote: >Jon said: >>I do not find the requirement for NAT traversal unacceptable, >>but I do >>consider the requirement for media steering highly dubious at best. > > > "Highly dubious" = nobody really does it? People do highly dubious stuff all the time; they have unprotected sex, they jump out of perfectly good airplanes, they vote for Obama, they try for a single-handed Atlantic crossing in a 6 meter sailboat with no preparation, they try to implement RAI specifications from the RFC without parallel testing against existing systems, and so on. The question is: Should we take the human urge to engage in highly dubious practies like traffic steering into account when we write an identity spec? If so, at what level of dubiousness (or dubyaness, for the left-leaning) do we draw the line? -- dean From pkyzivat@cisco.com Tue Nov 17 13:14:14 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791823A6B0E for ; Tue, 17 Nov 2009 13:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 FYOWxBVcq06t for ; Tue, 17 Nov 2009 13:14:13 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 58F7B3A6B02 for ; Tue, 17 Nov 2009 13:14:13 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EAGihAkurRN+J/2dsb2JhbACZE6V2iRsIjxOCNxQIgWgE X-IronPort-AV: E=Sophos;i="4.44,760,1249257600"; d="scan'208";a="105557027" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2009 21:14:12 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAHLEB0t008809; Tue, 17 Nov 2009 21:14:12 GMT Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 16:14:11 -0500 Received: from [161.44.182.187] ([161.44.182.187]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 16:14:10 -0500 Message-ID: <4B031221.3010308@cisco.com> Date: Tue, 17 Nov 2009 16:14:09 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> <048d01ca67c4$96503410$c2f0200a@cisco.com> <4B0310E1.9070200@softarmor.com> In-Reply-To: <4B0310E1.9070200@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2009 21:14:10.0512 (UTC) FILETIME=[E7E59D00:01CA67CA] Cc: dispatch@ietf.org Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 21:14:14 -0000 Dean Willis wrote: > Dan Wing wrote: >> Jon said: >>> I do not find the requirement for NAT traversal unacceptable, but I >>> do consider the requirement for media steering highly dubious at best. >> >> >> "Highly dubious" = nobody really does it? > > People do highly dubious stuff all the time; they have unprotected sex, > they jump out of perfectly good airplanes, they vote for Obama, they try > for a single-handed Atlantic crossing in a 6 meter sailboat with no > preparation, they try to implement RAI specifications from the RFC > without parallel testing against existing systems, and so on. > > The question is: Should we take the human urge to engage in highly > dubious practies like traffic steering into account when we write an > identity spec? If so, at what level of dubiousness (or dubyaness, for > the left-leaning) do we draw the line? I'd been thinking the dubyaness was just a bad dream. Thank you for disabusing me of that. Paul From dwing@cisco.com Tue Nov 17 13:20:36 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726F83A6B0D for ; Tue, 17 Nov 2009 13:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Fq-Ch9Xex7Kw for ; Tue, 17 Nov 2009 13:20:35 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5E88D3A6AF1 for ; Tue, 17 Nov 2009 13:20:35 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAIuiAkurRN+J/2dsb2JhbACKNLRFiRsIjxOCNxQIgWgE X-IronPort-AV: E=Sophos;i="4.44,760,1249257600"; d="scan'208";a="105563151" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2009 21:20:34 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAHLKX2x013158; Tue, 17 Nov 2009 21:20:33 GMT From: "Dan Wing" To: "'Dean Willis'" References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> <048d01ca67c4$96503410$c2f0200a@cisco.com> <4B0310E1.9070200@softarmor.com> Date: Tue, 17 Nov 2009 13:20:33 -0800 Message-ID: <04d101ca67cb$cc67d7e0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4B0310E1.9070200@softarmor.com> Thread-Index: Acpnyi447+3uWg8FSVWg5Dn+PXnsCwAAU5DQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: dispatch@ietf.org Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 21:20:36 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, November 17, 2009 1:09 PM > To: Dan Wing > Cc: 'Jon Peterson'; 'Jiri Kuthan'; dispatch@ietf.org > Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available > > Dan Wing wrote: > >Jon said: > >>I do not find the requirement for NAT traversal unacceptable, > >>but I do > >>consider the requirement for media steering highly dubious at best. > > > > > > "Highly dubious" = nobody really does it? > > People do highly dubious stuff all the time; they have > unprotected sex, > they jump out of perfectly good airplanes, they vote for > Obama, they try > for a single-handed Atlantic crossing in a 6 meter sailboat with no > preparation, they try to implement RAI specifications from the RFC > without parallel testing against existing systems, and so on. > > The question is: Should we take the human urge to engage in highly > dubious practies like traffic steering into account when we write an > identity spec? If so, at what level of dubiousness (or > dubyaness, for the left-leaning) do we draw the line? Said another way: pragmatic versus academic. -d From HKaplan@acmepacket.com Wed Nov 18 11:12:42 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D053A67C2 for ; Wed, 18 Nov 2009 11:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaPKln9SEiRm for ; Wed, 18 Nov 2009 11:12:36 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 787C828C122 for ; Wed, 18 Nov 2009 11:12:29 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 18 Nov 2009 14:12:23 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 18 Nov 2009 14:12:20 -0500 From: Hadriel Kaplan To: Jon Peterson , Jiri Kuthan Date: Wed, 18 Nov 2009 14:11:49 -0500 Thread-Topic: [dispatch] Identity Adhoc - Nov 9th: Notes available Thread-Index: Acpm/cz2ifgzC7UdSOKGWYUpvT4R7ABgzUnw Message-ID: References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> In-Reply-To: <4B01B9E8.7050507@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 19:12:42 -0000 Forget the NAT traversal piece, or even media steering, and just tell me wh= at signing the IP Address/port in the SDP buys you. Not the whole SDP, jus= t the IP/ports. Imagine if the media IP/ports were in a SIP header, and te= ll me why we MUST sign that header to get "SIP Identity". My claim is signing those IP/ports is neither necessary nor sufficient for = the purposes of SIP Identity nor media identity. It's an emperor with no c= lothes, except we end up getting the bill for the clothing. It is not sufficient because it does not prove the authenticity and identit= y of the media. And I don't just mean in an academic sense of "prove". No= t only can the media IP/ports still be spoofed and even intercepted - but n= othing prevents me from just sending media from another address/port to get= you to listen to my advertisement, instructions to call my number to "veri= fy your credit card", or whatever. Only a media-plane mechanism will be sufficient for media identity, such as= DTLS-SRTP. It is not necessary because, given a mechanism such as DTLS-SRTP (which *is= * necessary for the property of media identity), signing the IP/ports is su= perfluous. It's making the mistake of confusing IP with an identity, vs. a= routing identifier. (ie, the argument HIP makes) -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Jon Peterson > Sent: Monday, November 16, 2009 3:45 PM >=20 > To rehash arguments that have circulated in this discussion many times, > one must distinguish the NAT traversal case from the "media steering" > requirement that has motivated much of the re-examination of identity. > RFC4474 signatures are applied not by the user agent (at least not in > the typical case), but rather by a server operated by the user agent's > administrative domain. The administrative domain can more or less modify > signaling arbitrarily before adding an Identity header per RFC4474. > Thus, some sort of intermediary that modifies SIP signaling for the sake > of NAT traversal can work with RFC4474, provided that the intermediary > acts before the Identity header is added. >=20 > While it can therefore be argued that RFC4474 does not rule out > intermediary-based NAT traversal entirely, it does protect against any > intermediary altering SDP once a request has left the originating > administrative domain with an Identity header. The "media steering" use > cases that challenge this design are predicated on an intermediary with > no necessary relationship to the originating or terminating > administrative domain unilaterally modifying SDP in transit, usually in > order to force layer 3 routing of media to pass through one or more > anchor points in a network - perhaps for the sake of drawing the traffic > across a managed circuit with carefully-managed quality, or to > facilitate lawful intercept, or what have you. It is that requirement > which I have consistently argued is equivalent to exposing this > mechanism to a man-in-the-middle attack. If we removed enough > protections in the design of RFC4474 to enable media steering by "good" > intermediaries, we are effectively also enabling any malicious entities > to change those aspects of SIP requests as well. From bernard_aboba@hotmail.com Wed Nov 18 13:05:56 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD8EF3A68DA for ; Wed, 18 Nov 2009 13:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCaN-N+0uqBh for ; Wed, 18 Nov 2009 13:05:54 -0800 (PST) Received: from blu0-omc4-s12.blu0.hotmail.com (blu0-omc4-s12.blu0.hotmail.com [65.55.111.151]) by core3.amsl.com (Postfix) with ESMTP id 469913A68C3 for ; Wed, 18 Nov 2009 13:05:54 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.137]) by blu0-omc4-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 13:05:52 -0800 X-Originating-IP: [131.107.0.105] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 18 Nov 2009 13:05:51 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01CA684F.DAF1DF70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpokujSwuszqjo7Sxi1NVw2rHTZmA== Content-Language: en-us X-OriginalArrivalTime: 18 Nov 2009 21:05:52.0429 (UTC) FILETIME=[E96DEDD0:01CA6892] Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 21:05:57 -0000 ------=_NextPart_000_0012_01CA684F.DAF1DF70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dean said: "People do highly dubious stuff all the time; they have unprotected sex, they jump out of perfectly good airplanes, they vote for Obama, they try for a single-handed Atlantic crossing in a 6 meter sailboat with no preparation, they try to implement RAI specifications from the RFC without parallel testing against existing systems, and so on. The question is: Should we take the human urge to engage in highly dubious practies like traffic steering into account when we write an identity spec? If so, at what level of dubiousness (or dubyaness, for the left-leaning) do we draw the line?" [BA] A key question to answer is whether SIP Identity is for general purpose use or not: a) If it is not for general purpose use, then the analysis (and applicability statement) can focus solely on those use cases for which it is appropriate, and the "dubious" cases can be noted as out of scope. b) If the intent is to provide a facility for general purpose use, then enabling use in commonly encountered situations is a requirement, regardless of how "dubious" they might be. ------=_NextPart_000_0012_01CA684F.DAF1DF70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dean said:

 

"People do highly dubious stuff all the time; = they have unprotected sex,

they jump out of perfectly good airplanes, they = vote for Obama, they try

for a single-handed Atlantic crossing in a 6 meter = sailboat with no

preparation, they try to implement RAI = specifications from the RFC

without parallel testing against existing systems, = and so on.

 

The question is: Should we take the human urge to = engage in highly

dubious practies like traffic steering into account = when we write an

identity spec? If so, at what level of  = dubiousness (or dubyaness, for

the left-leaning) do we draw the = line?"

 

[BA]   A key question to answer is = whether SIP Identity is for general purpose use or not:

 

a)      If it is not for general purpose use, then the = analysis (and applicability statement)

can focus solely on those use cases for which it is appropriate, and the

"dubious" cases can be noted as out of scope.   

 

b)      If the intent is to provide a facility for = general purpose use, then enabling

use in commonly encountered situations is a = requirement, regardless of how

"dubious" they might be.  =

 

 

------=_NextPart_000_0012_01CA684F.DAF1DF70-- From fluffy@cisco.com Wed Nov 18 21:31:17 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87F428C108 for ; Wed, 18 Nov 2009 21:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTnqaZpMSZPa for ; Wed, 18 Nov 2009 21:31:16 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C3D2E28C102 for ; Wed, 18 Nov 2009 21:31:16 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO1mBEurR7H+/2dsb2JhbAC/V4gUj2KCNg6BdwSNBg X-IronPort-AV: E=Sophos;i="4.44,769,1249257600"; d="scan'208";a="435695715" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 19 Nov 2009 05:31:14 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAJ5VDrt001255; Thu, 19 Nov 2009 05:31:14 GMT From: Cullen Jennings To: Hadriel Kaplan In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> Message-Id: <812A0021-6334-49E4-8B91-BBC053B2132B@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 22:31:12 -0700 X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 05:31:17 -0000 If we all believe the only thing SBC rewrite is the IP and port of the media, I'm sure we can solve this in no time flat. Unfortunately, when a solution to solve that problem have been presented, it has become clear that SBC change much more than that. Cullen On Nov 18, 2009, at 12:11 PM, Hadriel Kaplan wrote: > > Forget the NAT traversal piece, or even media steering, and just > tell me what signing the IP Address/port in the SDP buys you. Not > the whole SDP, just the IP/ports. Imagine if the media IP/ports > were in a SIP header, and tell me why we MUST sign that header to > get "SIP Identity". > > My claim is signing those IP/ports is neither necessary nor > sufficient for the purposes of SIP Identity nor media identity. > It's an emperor with no clothes, except we end up getting the bill > for the clothing. > > It is not sufficient because it does not prove the authenticity and > identity of the media. And I don't just mean in an academic sense > of "prove". Not only can the media IP/ports still be spoofed and > even intercepted - but nothing prevents me from just sending media > from another address/port to get you to listen to my advertisement, > instructions to call my number to "verify your credit card", or > whatever. > > Only a media-plane mechanism will be sufficient for media identity, > such as DTLS-SRTP. > > It is not necessary because, given a mechanism such as DTLS-SRTP > (which *is* necessary for the property of media identity), signing > the IP/ports is superfluous. It's making the mistake of confusing > IP with an identity, vs. a routing identifier. (ie, the argument HIP > makes) > > -hadriel > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Jon Peterson >> Sent: Monday, November 16, 2009 3:45 PM >> >> To rehash arguments that have circulated in this discussion many >> times, >> one must distinguish the NAT traversal case from the "media steering" >> requirement that has motivated much of the re-examination of >> identity. >> RFC4474 signatures are applied not by the user agent (at least not in >> the typical case), but rather by a server operated by the user >> agent's >> administrative domain. The administrative domain can more or less >> modify >> signaling arbitrarily before adding an Identity header per RFC4474. >> Thus, some sort of intermediary that modifies SIP signaling for the >> sake >> of NAT traversal can work with RFC4474, provided that the >> intermediary >> acts before the Identity header is added. >> >> While it can therefore be argued that RFC4474 does not rule out >> intermediary-based NAT traversal entirely, it does protect against >> any >> intermediary altering SDP once a request has left the originating >> administrative domain with an Identity header. The "media steering" >> use >> cases that challenge this design are predicated on an intermediary >> with >> no necessary relationship to the originating or terminating >> administrative domain unilaterally modifying SDP in transit, >> usually in >> order to force layer 3 routing of media to pass through one or more >> anchor points in a network - perhaps for the sake of drawing the >> traffic >> across a managed circuit with carefully-managed quality, or to >> facilitate lawful intercept, or what have you. It is that requirement >> which I have consistently argued is equivalent to exposing this >> mechanism to a man-in-the-middle attack. If we removed enough >> protections in the design of RFC4474 to enable media steering by >> "good" >> intermediaries, we are effectively also enabling any malicious >> entities >> to change those aspects of SIP requests as well. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Thu Nov 19 06:51:42 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2635A3A6801 for ; Thu, 19 Nov 2009 06:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmmTQ5XznwQ3 for ; Thu, 19 Nov 2009 06:51:41 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E816B3A6935 for ; Thu, 19 Nov 2009 06:51:40 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 19 Nov 2009 09:51:36 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 19 Nov 2009 09:51:36 -0500 From: Hadriel Kaplan To: Cullen Jennings Date: Thu, 19 Nov 2009 09:51:35 -0500 Thread-Topic: [dispatch] Identity Adhoc - Nov 9th: Notes available Thread-Index: Acpo4oDxbYpW51pVQMauzQYlxyvfhAAQ/RRg Message-ID: References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> <812A0021-6334-49E4-8B91-BBC053B2132B@cisco.com> In-Reply-To: <812A0021-6334-49E4-8B91-BBC053B2132B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 14:51:42 -0000 Sure, but I'm taking it one bite-size issue at a time, starting with the bi= ggest bite. :)=20 Some of the things SBC's change *should* fail a 4474-type signature I think= . And some of them are either not that commonly done, or are done in the o= riginating or terminating domain anyway where changing them doesn't matter = for the mechanism (e.g., transcoding). -hadriel > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, November 19, 2009 12:31 AM > To: Hadriel Kaplan > Cc: Jon Peterson; Jiri Kuthan; dispatch@ietf.org > Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available >=20 >=20 > If we all believe the only thing SBC rewrite is the IP and port of the > media, I'm sure we can solve this in no time flat. Unfortunately, when > a solution to solve that problem have been presented, it has become > clear that SBC change much more than that. >=20 > Cullen >=20 > On Nov 18, 2009, at 12:11 PM, Hadriel Kaplan wrote: >=20 > > > > Forget the NAT traversal piece, or even media steering, and just > > tell me what signing the IP Address/port in the SDP buys you. Not > > the whole SDP, just the IP/ports. Imagine if the media IP/ports > > were in a SIP header, and tell me why we MUST sign that header to > > get "SIP Identity". > > > > My claim is signing those IP/ports is neither necessary nor > > sufficient for the purposes of SIP Identity nor media identity. > > It's an emperor with no clothes, except we end up getting the bill > > for the clothing. > > > > It is not sufficient because it does not prove the authenticity and > > identity of the media. And I don't just mean in an academic sense > > of "prove". Not only can the media IP/ports still be spoofed and > > even intercepted - but nothing prevents me from just sending media > > from another address/port to get you to listen to my advertisement, > > instructions to call my number to "verify your credit card", or > > whatever. > > > > Only a media-plane mechanism will be sufficient for media identity, > > such as DTLS-SRTP. > > > > It is not necessary because, given a mechanism such as DTLS-SRTP > > (which *is* necessary for the property of media identity), signing > > the IP/ports is superfluous. It's making the mistake of confusing > > IP with an identity, vs. a routing identifier. (ie, the argument HIP > > makes) > > > > -hadriel > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Jon Peterson > >> Sent: Monday, November 16, 2009 3:45 PM > >> > >> To rehash arguments that have circulated in this discussion many > >> times, > >> one must distinguish the NAT traversal case from the "media steering" > >> requirement that has motivated much of the re-examination of > >> identity. > >> RFC4474 signatures are applied not by the user agent (at least not in > >> the typical case), but rather by a server operated by the user > >> agent's > >> administrative domain. The administrative domain can more or less > >> modify > >> signaling arbitrarily before adding an Identity header per RFC4474. > >> Thus, some sort of intermediary that modifies SIP signaling for the > >> sake > >> of NAT traversal can work with RFC4474, provided that the > >> intermediary > >> acts before the Identity header is added. > >> > >> While it can therefore be argued that RFC4474 does not rule out > >> intermediary-based NAT traversal entirely, it does protect against > >> any > >> intermediary altering SDP once a request has left the originating > >> administrative domain with an Identity header. The "media steering" > >> use > >> cases that challenge this design are predicated on an intermediary > >> with > >> no necessary relationship to the originating or terminating > >> administrative domain unilaterally modifying SDP in transit, > >> usually in > >> order to force layer 3 routing of media to pass through one or more > >> anchor points in a network - perhaps for the sake of drawing the > >> traffic > >> across a managed circuit with carefully-managed quality, or to > >> facilitate lawful intercept, or what have you. It is that requirement > >> which I have consistently argued is equivalent to exposing this > >> mechanism to a man-in-the-middle attack. If we removed enough > >> protections in the design of RFC4474 to enable media steering by > >> "good" > >> intermediaries, we are effectively also enabling any malicious > >> entities > >> to change those aspects of SIP requests as well. > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Fri Nov 20 12:14:50 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184FE3A6AA8 for ; Fri, 20 Nov 2009 12:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncGA0yCIXSc2 for ; Fri, 20 Nov 2009 12:14:39 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AD6FA3A67E6 for ; Fri, 20 Nov 2009 12:14:39 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAM+HBkurR7Hu/2dsb2JhbACQGK0Tl1+EPAQ X-IronPort-AV: E=Sophos;i="4.47,260,1257120000"; d="scan'208";a="273456169" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 20 Nov 2009 20:14:37 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nAKKEaxi010354 for ; Fri, 20 Nov 2009 20:14:36 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Fri, 20 Nov 2009 13:14:35 -0700 Message-Id: <19DCDFD7-D032-401D-9296-A330285DD108@cisco.com> To: dispatch@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [dispatch] MARTINI Charter based on DREGs ad-hoc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 20:14:55 -0000 I plan to send the following charter to the IESG on monday unless = someone catch significant problems with it. The IESG would discuss it on = the Dec 3 call and would decide if it was ready for IETF LC. At that = point it would be sent for a 2 week IETF Last Call where everyone could = comment on it and then come back to the IESG for approval on the Dec 17 = IESG call.=20 Cullen ------------ Multiple AoR reachabiliTy InformatioN Indication (MARTINI) =20 Proposed Chair(s): Spencer Dawkins Bernard Aboba Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Technical Advisor(s): Mailing Lists: General Discussion: martini@ietf.org To Subscribe: martini-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/martini/index.html Description of Working Group The MARTINI working group is chartered to specify a means by which an = entity authoritative for SIP URIs can dynamically register reachability = information for multiple AoRs with a service provider. The SIP protocol [RFC 3261 and its extensions] supports multiple means = of obtaining the connection information necessary to deliver out-of-dialog = SIP requests to their intended targets. When a SIP Proxy needs to send a = request to a target address-of-record (AoR) within its domain, it can use a = location service to obtain the registered contact URI, together with any = associated path information [RFC 3327], and build a route set to reach the target UA(s). = The SIP REGISTER method can be used to register contact URIs and path information. SIP-outbound [RFC 5626] enhances this mechanism to cater = for UAs behind NATs and firewalls. When a SIP UA or Proxy needs to send a = request to a target for which it is not authoritative, the UA/Proxy can use RFC3263 procedures for using DNS to resolve the next-hop connection information. Since a single SSP may support multiple thousands of such SMB SIP-PBX's, = it is impractical and cost-prohibitive to manually provision their IP = addresses in every SIP node along paths to those SIP-PBXs. Furthermore, IP addresses = can be dynamically assigned and therefore can potentially change relatively = frequently. Today dynamic reachability mechanisms are commonly used, based on the = SIP REGISTER method. Effectively a single REGISTER request registers the = AoR of the SIP-PBX, so that any out-of-dialog request targeted at a SIP URI for = which the SIP-PBX is authoritative can be delivered from the SSP to the SIP-PBX. = However, implementations of this mechanism vary in details, leading to = interoperability issues between SIP-PBXs and SSPs, and the need for equipment to support different variants. The task of this working group is to to standardize a multiple AoR = registration mechanism for SIP that can be widely deployed by service providers at = large scale. The solution will support AoRs with E.164 addresses at a minimum, although support for a broader class of AoRs may be included. The solution will utilize existing SIP mechanisms to the extent = possible, although it is anticipated that small protocol extensions are likely to = be required, and hence a standards track (rather than BCP) deliverable is expected. The solution will accommodate existing SIP extensions relating = to registration (e.g., Path, Service-Route [RFC 3608] and SIP-outbound) by = ensuring that they are not precluded from use in the context of multiple AoR registrations. The solution will incorporate a compatibility mechanism = to ensure a deterministic outcome when interworking with entities that do not = support multiple AoR registration. The working group will work coordinate with SIP Forum and other industry = groups on requirements and other IETF working groups including DRINKS and = SIPCORE. Goals and Milestones Dec 2010 Draft solicitation Jan 2010 Interim meeting Feb 2010 First Working Group Last Call Mar 2010 Second Working Group Last Call Apr 2010 Multiple AoR Registration specification to IESG (PS) From jiri@iptel.org Mon Nov 23 00:23:11 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9118B3A693F for ; Mon, 23 Nov 2009 00:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqYtAYwkJnIv for ; Mon, 23 Nov 2009 00:23:10 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 456793A67F3 for ; Mon, 23 Nov 2009 00:23:10 -0800 (PST) Received: from [127.0.0.1] (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 2360A37093A; Mon, 23 Nov 2009 09:23:05 +0100 (CET) Message-ID: <4B0A4668.2090700@iptel.org> Date: Mon, 23 Nov 2009 09:23:04 +0100 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Cullen Jennings References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> <812A0021-6334-49E4-8B91-BBC053B2132B@cisco.com> In-Reply-To: <812A0021-6334-49E4-8B91-BBC053B2132B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:23:11 -0000 Cullen Jennings wrote: > > If we all believe the only thing SBC rewrite is the IP and port of the > media, I'm sure we can solve this in no time flat. I think there are certainly many who believe this is a reasonable thing to do .... > Unfortunately, when a > solution to solve that problem have been presented, it has become clear > that SBC change much more than that. ... and it would be probably more efficient than trying to overload the work with other interesting features. what are the next steps then? -jiri > > Cullen > > On Nov 18, 2009, at 12:11 PM, Hadriel Kaplan wrote: > >> >> Forget the NAT traversal piece, or even media steering, and just tell >> me what signing the IP Address/port in the SDP buys you. Not the >> whole SDP, just the IP/ports. Imagine if the media IP/ports were in a >> SIP header, and tell me why we MUST sign that header to get "SIP >> Identity". >> >> My claim is signing those IP/ports is neither necessary nor sufficient >> for the purposes of SIP Identity nor media identity. It's an emperor >> with no clothes, except we end up getting the bill for the clothing. >> >> It is not sufficient because it does not prove the authenticity and >> identity of the media. And I don't just mean in an academic sense of >> "prove". Not only can the media IP/ports still be spoofed and even >> intercepted - but nothing prevents me from just sending media from >> another address/port to get you to listen to my advertisement, >> instructions to call my number to "verify your credit card", or whatever. >> >> Only a media-plane mechanism will be sufficient for media identity, >> such as DTLS-SRTP. >> >> It is not necessary because, given a mechanism such as DTLS-SRTP >> (which *is* necessary for the property of media identity), signing the >> IP/ports is superfluous. It's making the mistake of confusing IP with >> an identity, vs. a routing identifier. (ie, the argument HIP makes) >> >> -hadriel >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Jon Peterson >>> Sent: Monday, November 16, 2009 3:45 PM >>> >>> To rehash arguments that have circulated in this discussion many times, >>> one must distinguish the NAT traversal case from the "media steering" >>> requirement that has motivated much of the re-examination of identity. >>> RFC4474 signatures are applied not by the user agent (at least not in >>> the typical case), but rather by a server operated by the user agent's >>> administrative domain. The administrative domain can more or less modify >>> signaling arbitrarily before adding an Identity header per RFC4474. >>> Thus, some sort of intermediary that modifies SIP signaling for the sake >>> of NAT traversal can work with RFC4474, provided that the intermediary >>> acts before the Identity header is added. >>> >>> While it can therefore be argued that RFC4474 does not rule out >>> intermediary-based NAT traversal entirely, it does protect against any >>> intermediary altering SDP once a request has left the originating >>> administrative domain with an Identity header. The "media steering" use >>> cases that challenge this design are predicated on an intermediary with >>> no necessary relationship to the originating or terminating >>> administrative domain unilaterally modifying SDP in transit, usually in >>> order to force layer 3 routing of media to pass through one or more >>> anchor points in a network - perhaps for the sake of drawing the traffic >>> across a managed circuit with carefully-managed quality, or to >>> facilitate lawful intercept, or what have you. It is that requirement >>> which I have consistently argued is equivalent to exposing this >>> mechanism to a man-in-the-middle attack. If we removed enough >>> protections in the design of RFC4474 to enable media steering by "good" >>> intermediaries, we are effectively also enabling any malicious entities >>> to change those aspects of SIP requests as well. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From john.elwell@siemens-enterprise.com Mon Nov 23 00:42:42 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323623A6898 for ; Mon, 23 Nov 2009 00:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaQrHcG2dzrn for ; Mon, 23 Nov 2009 00:42:41 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D749E3A67A8 for ; Mon, 23 Nov 2009 00:42:40 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-90424; Mon, 23 Nov 2009 09:42:36 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4D95F23F01CB; Mon, 23 Nov 2009 09:42:36 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 23 Nov 2009 09:42:36 +0100 From: "Elwell, John" To: Cullen Jennings , "dispatch@ietf.org" Date: Mon, 23 Nov 2009 09:42:33 +0100 Thread-Topic: [dispatch] MARTINI Charter based on DREGs ad-hoc Thread-Index: AcpqHiINa2JtEGQASM6FmYOAG+WQdwB9aTvQ Message-ID: References: <19DCDFD7-D032-401D-9296-A330285DD108@cisco.com> In-Reply-To: <19DCDFD7-D032-401D-9296-A330285DD108@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] MARTINI Charter based on DREGs ad-hoc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:42:42 -0000 Thanks, Cullen and others, for this initiative. Compared with DREGS, this s= eems to address the concerns raised during the ad hoc in Hiroshima. There d= oes seem to be some text missing - see below:=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 20 November 2009 20:15 > To: dispatch@ietf.org > Subject: [dispatch] MARTINI Charter based on DREGs ad-hoc >=20 >=20 > I plan to send the following charter to the IESG on monday=20 > unless someone catch significant problems with it. The IESG=20 > would discuss it on the Dec 3 call and would decide if it was=20 > ready for IETF LC. At that point it would be sent for a 2=20 > week IETF Last Call where everyone could comment on it and=20 > then come back to the IESG for approval on the Dec 17 IESG call.=20 >=20 > Cullen >=20 > ------------ >=20 > Multiple AoR reachabiliTy InformatioN Indication (MARTINI) > =20 > Proposed Chair(s): > Spencer Dawkins > Bernard Aboba >=20 > Real-time Applications and Infrastructure Area Director(s): > Robert Sparks > Cullen Jennings >=20 > Real-time Applications and Infrastructure Area Advisor: > Cullen Jennings >=20 > Technical Advisor(s): >=20 > Mailing Lists: > General Discussion: martini@ietf.org > To Subscribe: martini-request@ietf.org > In Body: subscribe > Archive: http://www.ietf.org/mail-archive/web/martini/index.html >=20 > Description of Working Group >=20 > The MARTINI working group is chartered to specify a means by=20 > which an entity > authoritative for SIP URIs can dynamically register=20 > reachability information for > multiple AoRs with a service provider. >=20 > The SIP protocol [RFC 3261 and its extensions] supports=20 > multiple means of > obtaining the connection information necessary to deliver=20 > out-of-dialog SIP > requests to their intended targets. When a SIP Proxy needs=20 > to send a request to > a target address-of-record (AoR) within its domain, it can=20 > use a location > service to obtain the registered contact URI, together with=20 > any associated path > information [RFC 3327], and build a route set to reach the=20 > target UA(s). The > SIP REGISTER method can be used to register contact URIs and path > information. SIP-outbound [RFC 5626] enhances this mechanism=20 > to cater for UAs > behind NATs and firewalls. When a SIP UA or Proxy needs to=20 > send a request to a > target for which it is not authoritative, the UA/Proxy can use RFC3263 > procedures for using DNS to resolve the next-hop connection=20 > information. > [JRE] There seems to be something missing prior to the text below. We need = something to describe the problem, and we also need to introduce the terms = "SSP" and "SIP-PBX". I propose we add a paragraph: "Practice has shown that existing mechanisms are not always sufficient for = supporting SIP-PBXs for small/medium businesses (SMB). A SIP-PBX might serv= e tens or hundreds of AoRs by acting as the registrar/proxy. UAs register w= ith the SIP-PBX on behalf of the AoRs concerned, and inbound requests to th= ose AoRs need to be delivered to the SIP-PBX for onward delivery to registe= red UAs. Where the SIP-PBX uses a SIP Service Provider (SSP) for external t= raffic, the SIP-PBX needs to be reachable from the SSP for inbound requests= to the AoRs concerned." John =20 > Since a single SSP may support multiple thousands of such SMB=20 > SIP-PBX's, it is > impractical and cost-prohibitive to manually provision their=20 > IP addresses in > every SIP node along paths to those SIP-PBXs. Furthermore,=20 > IP addresses can be > dynamically assigned and therefore can potentially change=20 > relatively frequently. >=20 > Today dynamic reachability mechanisms are commonly used,=20 > based on the SIP > REGISTER method. Effectively a single REGISTER request=20 > registers the AoR of the > SIP-PBX, so that any out-of-dialog request targeted at a SIP=20 > URI for which the > SIP-PBX is authoritative can be delivered from the SSP to the=20 > SIP-PBX. However, > implementations of this mechanism vary in details, leading to=20 > interoperability > issues between SIP-PBXs and SSPs, and the need for equipment=20 > to support > different variants. >=20 > The task of this working group is to to standardize a=20 > multiple AoR registration > mechanism for SIP that can be widely deployed by service=20 > providers at large > scale. The solution will support AoRs with E.164 addresses at=20 > a minimum, > although support for a broader class of AoRs may be included. >=20 > The solution will utilize existing SIP mechanisms to the=20 > extent possible, > although it is anticipated that small protocol extensions are=20 > likely to be > required, and hence a standards track (rather than BCP) deliverable is > expected. The solution will accommodate existing SIP=20 > extensions relating to > registration (e.g., Path, Service-Route [RFC 3608] and=20 > SIP-outbound) by ensuring > that they are not precluded from use in the context of multiple AoR > registrations. The solution will incorporate a compatibility=20 > mechanism to ensure > a deterministic outcome when interworking with entities that=20 > do not support > multiple AoR registration. >=20 > The working group will work coordinate with SIP Forum and=20 > other industry groups > on requirements and other IETF working groups including=20 > DRINKS and SIPCORE. >=20 > Goals and Milestones > Dec 2010 Draft solicitation > Jan 2010 Interim meeting > Feb 2010 First Working Group Last Call > Mar 2010 Second Working Group Last Call > Apr 2010 Multiple AoR Registration specification to IESG (PS) >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From john.elwell@siemens-enterprise.com Mon Nov 23 01:21:16 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C233A69C5 for ; Mon, 23 Nov 2009 01:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKxFZrWC8-ds for ; Mon, 23 Nov 2009 01:21:16 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id BD1A13A67B3 for ; Mon, 23 Nov 2009 01:21:15 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-90998; Mon, 23 Nov 2009 10:21:11 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 434D723F01CB; Mon, 23 Nov 2009 10:21:11 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 23 Nov 2009 10:21:11 +0100 From: "Elwell, John" To: Victor Pascual Avila , Dan Wing Date: Mon, 23 Nov 2009 10:21:09 +0100 Thread-Topic: [dispatch] Identity Adhoc - Nov 9th: Notes available Thread-Index: AcpnyjEC1IMfWq4sQ3mCFA+aKZzVLQEUbdog Message-ID: References: <4B01A877.4010306@iptel.org> <4B01B9E8.7050507@neustar.biz> <048d01ca67c4$96503410$c2f0200a@cisco.com> <618e24240911171308s316be105k79baaa974ab17963@mail.gmail.com> In-Reply-To: <618e24240911171308s316be105k79baaa974ab17963@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 09:21:16 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Victor Pascual Avila > Sent: 17 November 2009 21:09 > To: Dan Wing > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available >=20 > On Tue, Nov 17, 2009 at 9:28 PM, Dan Wing wrote: > >> I do not find the requirement for NAT traversal unacceptable, > >> but I do > >> consider the requirement for media steering highly dubious at best. > > > > "Highly dubious" =3D nobody really does it? >=20 > Network administrators have actually found it easier to rewrite SDPs > than to use other existing mechanisms. [JRE] This is an important point. Those who stand to benefit from e2e (or e= nd-domain-to-end-domain) authenticated identification are the end users and= their domains. Intermediate domains do not benefit. Therefore any mechanis= m that is harder to deploy at intermediate domains without benefiting those= intermediate domains will not be adopted. John >=20 > Cheers, > --=20 > Victor Pascual =C1vila > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From john.elwell@siemens-enterprise.com Tue Nov 24 12:25:13 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF98228C151 for ; Tue, 24 Nov 2009 12:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 ME87FjU7YiFc for ; Tue, 24 Nov 2009 12:25:12 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DA43628C150 for ; Tue, 24 Nov 2009 12:25:11 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-112824 for dispatch@ietf.org; Tue, 24 Nov 2009 21:25:06 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 8FA4D1EB81FD for ; Tue, 24 Nov 2009 21:25:06 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 24 Nov 2009 21:25:06 +0100 From: "Elwell, John" To: "dispatch@ietf.org" Date: Tue, 24 Nov 2009 21:25:05 +0100 Thread-Topic: SIP Forum UA-config presentation Thread-Index: AcptRDWXrDjnRplBSlmrLZDsvsydJA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] SIP Forum UA-config presentation X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 20:25:13 -0000 =20 Members of the SIP Forum UA-config Task Group tried to arrange a presentati= on of this work during the Hiroshima IETF, but failed to obtain a room (and= the late informal offer for Friday 08.00 was clearly inconvenient for most= participants). Therefore we would be prepared to give the presentation by Webex some time = during the coming weeks, if there is sufficient interest. The work has prog= ressed (and changed direction somewhat) since we last talked to DISPATCH (a= t IETF#74), and in fact it is very nearly ready for Last Call.=20 The UA configuration Task Group's home page is here: http://www.sipforum.org/content/view/311/253/ The presentation can be found here: http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,3= 21/Itemid,75/ and the latest draft can be found here: http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,3= 76/Itemid,75/ If you are interested in a presentation and discussion via Webex, please le= t me know and suggest some dates (during week beginning 30th November, 7th = or 14th December). In any case, please do look at the presentation and draft, and feel free to= join our weekly call (Mondays, 16.00 GMT) and/or join the mailing list. John= From bernard_aboba@hotmail.com Tue Nov 24 12:35:27 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D7E3A68B7 for ; Tue, 24 Nov 2009 12:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=0.878, 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 LARohUtiRSel for ; Tue, 24 Nov 2009 12:35:25 -0800 (PST) Received: from blu0-omc4-s26.blu0.hotmail.com (blu0-omc4-s26.blu0.hotmail.com [65.55.111.165]) by core3.amsl.com (Postfix) with ESMTP id 992CB3A67F7 for ; Tue, 24 Nov 2009 12:35:25 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.136]) by blu0-omc4-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 12:35:21 -0800 X-Originating-IP: [64.134.238.98] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 24 Nov 2009 12:35:19 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CA6D02.95DCFB10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcptRaOYkqAb7mEYRyq3okn5IlnGvQ== Content-Language: en-us X-OriginalArrivalTime: 24 Nov 2009 20:35:21.0255 (UTC) FILETIME=[A4717370:01CA6D45] Subject: [dispatch] Draft MARTINI charter with corrections incorporated X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 20:35:27 -0000 ------=_NextPart_000_0022_01CA6D02.95DCFB10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here is an updated version of the MARTINI charter with proposed corrections incorporated: ========================================================================= Multiple AoR reachabiliTy INformatIon (MARTINI) Proposed Chair(s): Spencer Dawkins Bernard Aboba Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Technical Advisor(s): Mailing Lists: General Discussion: martini at ietf.org To Subscribe: martini-request at ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/martini/index.html Description of Working Group The MARTINI working group is chartered to specify a means by which an entity authoritative for SIP URIs can dynamically register reachability information for multiple AoRs with a service provider. The SIP protocol [RFC 3261 and its extensions] supports multiple means of obtaining the connection information necessary to deliver out-of-dialog SIP requests to their intended targets. When a SIP Proxy needs to send a request to a target address-of-record (AoR) within its domain, it can use a location service to obtain the registered contact URI, together with any associated path information [RFC 3327], and build a route set to reach the target UA(s). The SIP REGISTER method can be used to register contact URIs and path information. SIP-outbound [RFC 5626] enhances this mechanism to cater for UAs behind NATs and firewalls. When a SIP UA or Proxy needs to send a request to a target for which it is not authoritative, the UA/Proxy can use RFC 3263 procedures for using DNS to resolve the next-hop connection information. Practice has shown that existing mechanisms are not always sufficient for supporting SIP-PBXs for small/medium businesses (SMB). A SIP-PBX might serve tens or hundreds of AoRs by acting as the registrar/proxy. UAs register with the SIP-PBX on behalf of the AoRs concerned, and inbound requests to those AoRs need to be delivered to the SIP-PBX for onward delivery to registered UAs. Where the SIP-PBX uses a SIP Service Provider (SSP) for external traffic, the SIP-PBX needs to be reachable from the SSP for inbound requests to the AoRs concerned. Since a single SSP may support multiple thousands of such SMB SIP-PBX's, it is impractical and cost-prohibitive to manually provision their IP addresses in every SIP node along paths to those SIP-PBXs. Furthermore, IP addresses can be dynamically assigned and therefore can potentially change relatively frequently. Today dynamic reachability mechanisms are commonly used, based on the SIP REGISTER method. Effectively a single REGISTER request registers the AoR of the SIP-PBX, so that any out-of-dialog request targeted at a SIP URI for which the SIP-PBX is authoritative can be delivered from the SSP to the SIP-PBX. However, implementations of this mechanism vary in details, leading to interoperability issues between SIP-PBXs and SSPs, and the need for equipment to support different variants. The task of this working group is to to standardize a multiple AoR registration mechanism for SIP that can be widely deployed by service providers at large scale. The solution will support AoRs with E.164 addresses at a minimum, although support for a broader class of AoRs may be included. The solution will utilize existing SIP mechanisms to the extent possible, although it is anticipated that small protocol extensions are likely to be required, and hence a standards track (rather than BCP) deliverable is expected. The solution will accommodate existing SIP extensions relating to registration (e.g., Path, Service-Route [RFC 3608] and SIP-outbound) by ensuring that they are not precluded from use in the context of multiple AoR registrations. The solution will incorporate a compatibility mechanism to ensure a deterministic outcome when interworking with entities that do not support multiple AoR registration. The working group will work coordinate with SIP Forum and other industry groups on requirements and other IETF working groups including DRINKS and SIPCORE. Goals and Milestones Dec 2009 Draft solicitation Jan 2010 Interim meeting Feb 2010 First Working Group Last Call Mar 2010 Second Working Group Last Call Apr 2010 Multiple AoR Registration specification to IESG (PS) ------=_NextPart_000_0022_01CA6D02.95DCFB10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is an updated version of the MARTINI charter = with proposed corrections incorporated:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

Multiple AoR reachabiliTy INformatIon = (MARTINI)

 

Proposed Chair(s):

Spencer Dawkins <spencer at = wonderhamster.org>

Bernard Aboba <bernard_aboba at = hotmail.com>

 

Real-time Applications and Infrastructure Area = Director(s):

Robert Sparks <rjsparks at = nostrum.com>

Cullen Jennings <fluffy at = cisco.com>

 

Real-time Applications and Infrastructure Area = Advisor:

Cullen Jennings <fluffy at = cisco.com>

 

Technical Advisor(s):

 

Mailing Lists:

General Discussion: martini at = ietf.org

To Subscribe: martini-request at = ietf.org

In Body: subscribe

Archive: http://www.ietf.org/mail-archive/web/martini/index.html

 

Description of Working Group

 

The MARTINI working group is chartered to specify a = means by

which an entity authoritative for SIP URIs can = dynamically register

reachability information for multiple AoRs with a = service provider.

 

The SIP protocol [RFC 3261 and its extensions] = supports

multiple means of obtaining the connection = information necessary

to deliver out-of-dialog SIP requests to their = intended targets. 

When a SIP Proxy needs  to send a request to a = target address-of-record

(AoR) within its domain, it can use a location = service to obtain the

registered contact URI, together with any = associated path

information [RFC 3327], and build a route set to = reach the

target UA(s).  The SIP REGISTER method can be = used to register contact

URIs and path information. SIP-outbound [RFC 5626] = enhances this mechanism

to cater for UAs behind NATs and firewalls. When a = SIP UA or Proxy needs to

send a request to a target for which it is not authoritative, the UA/Proxy

can use RFC 3263 procedures for using DNS to = resolve the next-hop connection

information.

 

Practice has shown that existing mechanisms are not = always sufficient for

supporting SIP-PBXs for small/medium businesses = (SMB). A SIP-PBX might serve

tens or hundreds of AoRs by acting as the = registrar/proxy. UAs register with

the SIP-PBX on behalf of the AoRs concerned, and = inbound requests to those

AoRs need to be delivered to the SIP-PBX for onward = delivery to registered UAs.

Where the SIP-PBX uses a SIP Service Provider (SSP) = for external traffic, the

SIP-PBX needs to be reachable from the SSP for = inbound requests to the AoRs

concerned.

 

Since a single SSP may support multiple thousands = of such SMB

SIP-PBX's, it is impractical and cost-prohibitive = to manually provision their

IP addresses in every SIP node along paths to those SIP-PBXs.  Furthermore,

IP addresses can be dynamically assigned and = therefore can potentially change

relatively frequently.

 

Today dynamic reachability mechanisms are commonly = used,

based on the SIP REGISTER method.  Effectively = a single REGISTER request

registers the AoR of the SIP-PBX, so that any = out-of-dialog request targeted

at a SIP URI for which the SIP-PBX is authoritative = can be delivered from the

SSP to the SIP-PBX. However, implementations of = this mechanism vary in details,

leading to interoperability issues between SIP-PBXs = and SSPs, and the need for

equipment to support different = variants.

 

The task of this working group is to to standardize = a multiple AoR registration

mechanism for SIP that can be widely deployed by = service providers at large

scale. The solution will support AoRs with E.164 = addresses at

a minimum, although support for a broader class of = AoRs may be included.

 

The solution will utilize existing SIP mechanisms = to the extent possible,

although it is anticipated that small protocol = extensions are likely to be

required, and hence a standards track (rather than = BCP) deliverable is

expected. The solution will accommodate existing = SIP extensions relating to

registration (e.g., Path, Service-Route [RFC 3608] = and SIP-outbound) by ensuring

that they are not precluded from use in the context = of multiple AoR

registrations. The solution will incorporate a = compatibility mechanism to

ensure a deterministic outcome when interworking = with entities that

do not support multiple AoR = registration.

 

The working group will work coordinate with SIP = Forum and other industry groups

on requirements and other IETF working groups = including DRINKS and SIPCORE.

 

Goals and Milestones

Dec 2009     Draft = solicitation

Jan 2010     Interim = meeting

Feb 2010     First Working = Group Last Call

Mar 2010     Second Working = Group Last Call

Apr 2010     Multiple AoR = Registration specification to IESG (PS)

------=_NextPart_000_0022_01CA6D02.95DCFB10-- From gonzalo.camarillo@ericsson.com Thu Nov 26 09:35:44 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBE703A6A9C for ; Thu, 26 Nov 2009 09:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBBwaHapB5Qi for ; Thu, 26 Nov 2009 09:35:44 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C90793A6893 for ; Thu, 26 Nov 2009 09:35:43 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-91-4b0ebc691d43 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id BD.CD.14961.96CBE0B4; Thu, 26 Nov 2009 18:35:37 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 18:35:36 +0100 Received: from [131.160.126.197] ([131.160.126.197]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 18:35:36 +0100 Message-ID: <4B0EBC63.3010007@ericsson.com> Date: Thu, 26 Nov 2009 19:35:31 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2009 17:35:36.0262 (UTC) FILETIME=[DCE99E60:01CA6EBE] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Draft minutes of the main DISPATCH session X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:35:44 -0000 Folks, here you have the draft minutes of the main DISPATCH session. http://www.ietf.org/proceedings/09nov/minutes/dispatch.txt Comments are welcome. We are working with the cochairs of the three ad-hoc meetings we had in Japan to prepare the minutes of those meetings as well (the minutes will be based on the raw notes that have already been distributed). As soon as those are ready, we will append them to the main DISPATCH minutes above so that everything is archived at the IETF. Cheers, Gonzalo DISPATCH co-chair